Guide for Developing                      Security Plans for Internet Sites,                      Intranets and Extranets ...
This document maybe freely redistributed in its entirety without alteration. It may not be sold forprofit or used in comme...
Table of ContentsAcknowledgements ...........................................................................................
5.WSS.1 Personnel Security ..................................................................................................
AcknowledgementsI would first like to express my thanks to NIST and to Marianne Swanson who originally draftedand publishe...
Executive SummaryNIST Special Publication (SP) 800-18, Guide for Developing Security Plans for InformationTechnology Syste...
1   IntroductionWith the push for more security along with the mandate and push for federal agencies to becomemore accessi...
The blur for web support systems (WSS) is that like a major application it is dependent on a GSSto function however like a...
1.5 Security Plan ResponsibilitiesUltimately it is the Chief Security Officer (CSO) that is responsible for the overall de...
2 System AnalysisA completed security plan contains technical information about a system, security requirements,and the co...
2.2.1 Major ApplicationsA major application is an application that because of the information contained, processed, ortran...
organization may not be responsible for developing a unique security plan for the application.When this is the case, discu...
2.2.3.1 Web Support System Determination GuidanceJust as not all applications should be considered major applications, the...
separated security plan does not mean that each system should have an independent securityplan. Since these are all simila...
3 Plan DevelopmentThe rest of this document helps guide the reader in writing a security plan for a web supportsystem. For...
3.2.4 Assignment of Security ResponsibilityOne individual must be assigned responsibility in writing to ensure that the we...
•   Web Server Software Name, Manufacture, Revision, and Patch Level;   •   Encryption and/or certificate technology;   • ...
of the major factors in risk management. The description must contain information on applicablelaws, regulations, and poli...
SENSITIVITY AREAS              RATING                GSS                            HIGH                Confidentiality   ...
4 Management ControlsThis section is where the management control measures that are in place or planned for theprotection ...
to a high risk of vulnerability of being breeched. New vulnerabilities, attacks, and maliciouscode designed to exploit web...
Life Cycle model chosen by the organization to cover the web support system, it will most likelyconsist of the five basic ...
or parts of the system are in the implementation phase, describe when and who conducted thedesign reviews and systems test...
NIST SP 800-37, Guidelines for the Security Certification and Accreditation of FederalInformation Technology Systems may a...
5 Operational ControlsThis chapter and Chapter 6, Technical Controls, the formats and related guidance provided is forthe ...
5.WSS Web Support System – Opera tional ControlsOperational controls are the security methods are a mix of technical (syst...
5.WSS.2.1 Explanation of Physical and Environment SecurityIn this section, describe where the web support system is locate...
5.WSS.4 Contingency PlanningWeb support systems require appropriate emergency, backup, and contingency plans. Theseplans s...
•   Are test results documented;   •   How are emergency fixes handled;   •   Are there organizational policies against il...
5.WSS.7 DocumentationDocumentation is a very important security control for a web support system. As there is nostandard w...
risks of web development around the environment used by the organization for the webprogrammers and developers.External Tr...
6 Technical ControlsTechnical controls are the security controls that the system executes automatically. Thesecontrols can...
In this section the web support system’s authentication control mechanisms should be described.Some topics that should be ...
public (e.g., Internet-based systems used for widespread public information dissemination), asituation not prevalent when ...
•   How are audit trails recorded (e.g., written to a database, written to a text file);   •   Who has access to the audit...
Upcoming SlideShare
Loading in …5
×

White Paper Guide For Developing Security Plans

2,513 views

Published on

This white paper is an interpretation of NIST SP 800-18, Guide for Developing Security Plans for Information Technology System, that was released by NIST in December of 1998. In 1998 when the publication became available it covered the major systems of the day: the general support system (GSS) and the Major Applications (MA). Since 1998 we have seen the development of a third system that is a neither truly a GSS or a MA but a fusion of the two, the Intranet and Extranet, which this document refers to as a web support system. This white paper interprets NIST SP 800-18 to reflect the need for a separate security plan for a web support system and how to define and determine what a web support system is. NOTE: This document has no official relationship to any other NIST Special Publication nor should any be drawn.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,513
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
55
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

White Paper Guide For Developing Security Plans

  1. 1. Guide for Developing Security Plans for Internet Sites, Intranets and Extranets An interpretation of NIST SP 800-18 Guide for Developing Security Plans for Information Technology Systems. William L. Dana , CISM, CISSP Dana Enterprises, Inc. April 2003Revision 1 Page 1 of 35April 2003
  2. 2. This document maybe freely redistributed in its entirety without alteration. It may not be sold forprofit or used in commercial documents without the written permission of Dana Enterprises, Inc.This document is provided "as is" without any express or implied warranty.While all information in this document is believed to be correct at the time of writing, thisdocument is for educational purposes. The information provided here is for reference use onlyand does not constitute the rendering of professional advice or recommendations by DanaEnterprises, Inc.Copyright © 2003Dana Enterprises, Inc.www.danaenterprises.orgRevision 1 Page 2 of 35April 2003
  3. 3. Table of ContentsAcknowledgements ......................................................................................................................... 5Executive Summary........................................................................................................................ 61 Introduction..................................................................................................................... 71.1 Background ..................................................................................................................... 71.2 Major Application, General Support System, Web Support System Plans .................... 71.3 Relationship to Other NIST Security Documents........................................................... 81.4 Purposes of Security Plans .............................................................................................. 81.5 Security Plan Responsibilities......................................................................................... 91.6 Recommended Format .................................................................................................... 91.7 Advice and Comment on Plan ........................................................................................ 91.8 Audience ......................................................................................................................... 92 System Analysis ............................................................................................................ 102.1 System Boundaries........................................................................................................ 102.2 System Category........................................................................................................... 102.2.1 Major Applications ....................................................................................................... 112.2.2 General Support System................................................................................................ 122.2.3 Web Support System..................................................................................................... 123 Plan Development ......................................................................................................... 153.1 Plan Control .................................................................................................................. 153.2 System Identification .................................................................................................... 153.2.1 System Name/Title........................................................................................................ 153.2.2 Responsible Organization............................................................................................. 153.2.3 Information Contact(s) .................................................................................................. 153.2.4 Assignment of Security Responsibility......................................................................... 163.3 System Operational Status ............................................................................................ 163.4 General Description/Purpose ........................................................................................ 163.5 System Environment ..................................................................................................... 163.6 System Interconnection/Information Sharing ............................................................... 173.7 Sensitivity of Information Handled .............................................................................. 173.7.1 Laws, Regulations, and Policies Affecting the System ................................................ 183.7.2 General Description of Sensitivity................................................................................ 184 Management Controls ................................................................................................... 204.1 Risk Assessment and Management............................................................................... 204.2 Review of Security Controls ......................................................................................... 204.3 Rules of Behavior.......................................................................................................... 214.4 Planning for Security in the Life Cycle ........................................................................ 214.4.1 Initiation Phase.............................................................................................................. 224.4.2 Development/Acquisition Phase ................................................................................... 224.4.3 Implementation Phase ................................................................................................... 224.4.4 Operation/Maintenance Phase....................................................................................... 234.4.5 Disposal Phase .............................................................................................................. 234.5 Authorize Processing .................................................................................................... 235 Operational Controls ..................................................................................................... 255.WSS Web Support System – Operational Controls................................................................... 26Revision 1 Page 3 of 35April 2003
  4. 4. 5.WSS.1 Personnel Security ......................................................................................................... 265.WSS.2 Physical and Environmental Protection......................................................................... 265.WSS.2.1 Explanation of Physical and Environment Security................................................... 275.WSS.3 Production, Input/Output Controls ................................................................................ 275.WSS.4 Contingency Planning.................................................................................................... 285.WSS.5 Hardware and Software Maintenance Controls ............................................................. 285.WSS.6 Data Integrity/Validation Controls ................................................................................ 295.WSS.7 Documentation............................................................................................................... 305.WSS.8 Security Awareness and Training .................................................................................. 305.WSS.9 Incident Response Capability ........................................................................................ 316 Technical Controls ........................................................................................................ 326.WSS.1 Identification and Authentication .................................................................................. 326.WSS.1.1 Identification............................................................................................................... 326.WSS.1.2 Authentication............................................................................................................. 326.WSS.2 Logical Access Controls (Authorization/Access Controls) ........................................... 336.WSS.3 Public Access Controls .................................................................................................. 346.WSS.4 Audit Trails .................................................................................................................... 34Revision 1 Page 4 of 35April 2003
  5. 5. AcknowledgementsI would first like to express my thanks to NIST and to Marianne Swanson who originally draftedand published NIST Special Publication (SP) 800-18, Guide for Developing Security Plans forInformation Technology Systems. Without that document we would not have the current standardor guidance for creating security plans.Revision 1 Page 5 of 35April 2003
  6. 6. Executive SummaryNIST Special Publication (SP) 800-18, Guide for Developing Security Plans for InformationTechnology Systems, has become the standard used but most all government agencies to developsecurity plans and the de facto standard for a number of private sector businesses. However, likeSecurity Plans, NIST SP 800-18 needs to be reviewed from time to time to reflect changes. In1998 when the publication became available it covered the major systems of the day: the generalsupport system (GSS) and the Major Applications (MA). Since 1998 we have seen thedevelopment of a third system that is a neither truly a GSS or a MA but a fusion of the two, theIntranet and Extranet, which this document refers to as a web support system.The objective of this document is to try and provide an interpretation of NIST SP 800-18 toreflect this new system and help people classify and secure their intranets and/or extranets withcustomized security plans that will meet the rigor and requirements of Office of Managementand Budget (OMB) Circular A-130 - Management of Federal Information Resources, AppendixIII - Security of Federal Automated Information Resources, Public Law 100-235 - ComputerSecurity Act of 1987, and the Federal Information Security management Act (FISMA) of 2002.As this document is an interpretation of NIST SP 800-18 and sections of that document will bepresent in this document as they appeared in that document. Due to the original thoroughness ofNIST SP 800-18 there is no need to recreate a process that has proven to be reliable and proven.Instead, this document seeks to expand upon the original to cover a new need.Revision 1 Page 6 of 35April 2003
  7. 7. 1 IntroductionWith the push for more security along with the mandate and push for federal agencies to becomemore accessible to citizenry, the development of federal Internet, Intranet, and Extranet portalshave been on the rise. NIST SP 800-18 was put forth in 1998 to help provide federal agencies away to adopt a set of minimum controls to protect their information technology (IT) resources.At that time the primary resources were where were defined as General Support Systems (GSS)consisting of Mainframes, Local Area Networks, and Wide Area Networks, and MajorApplications. The Internet as a place of commerce and business was just beginning to take off asa requirement for business and even for government.As with NIST 800-18, this document puts forth an interpretation of NIST SP 800-18 to reflectthe distributed nature of today’s technology.This document provides an interpretation of the NIST SP 800-18 guideline for federal agenciesto follow when developing the security plans that document the management, technical, andoperational controls for federal web support systems (WSS).1.1 BackgroundThe completion of system security plans is a requirement of the Office of Management andBudget (OMB) Circular A-130, “Management of Federal Information Resources,” Appendix III,“Security of Federal Automated Information Resources,” updated in 1996, Public Law 100-235,“Computer Security Act of 1987,” and of the Federal Information Security Management Act(FISMA) of 2002.OMB Circular A-130, Appendix III, does not distinguish between sensitive and non-sensitivesystems. Rather, consistent with the Computer Security Act of 1987, the Circular recognizes thatfederal automated information systems have varied sensitivity and criticality. All federal systemshave some level of sensitivity and require protection as part of good management practice. Thegeneric term “system” is used in this document to mean a major application, a general supportsystem, or a web support system. The generic term “web support system” is used in thisdocument to define an Internet Site, Intranet or Extrane t.NOTE: This document will only discuss the web support system in detail. Please refer to NISTSP 800-18 for information on the guidelines for major applications and general support systems.1.2 Major Application, General Support System, Web Support System PlansAll applications and systems are required to be covered by system security plans when they arecategorized as a “major application” or “general support system”. While there is no debate aboutthat, the question is what about the extranet or intranet and even possibility the Internet presencethe organization has created. Are they a major application or a general support system? Websupport systems (Internet sites, Intranets and Extranets) are unique in that they are a combinationof both.Revision 1 Page 7 of 35April 2003
  8. 8. The blur for web support systems (WSS) is that like a major application it is dependent on a GSSto function however like a GSS the WSS maybe the support platform that a major application mybe dependent on to function and deliver content. Considering the adva nces in web developmentand resources this blur has only continued to increase in that WSS’s may support there ownauthentication systems that are integrated with the GSS’s or in some cases completely separate.In section 1.2 of NIST SP 800-18 on page 1, the document defines and provides examples of amajor application and a general support system. Similarly, this document tries to provide adefinition of what a WSS and a test to try and help determine if an organization should develop aseparate security plan for their WSS. For not all Internet Sites, Intranets, or Extranets may needto be classified as a WSS and can be covered by an existing GSS or MA plan that has beendeveloped.1.3 Relationship to Other NIST Security DocumentsThis document currently has no official relationship to any other NIST Special Publication orSecurity Document. It is meant to help supplement NIST SP 800-18 and continue to round outthe NIST triad of security guidance (NIST Special Publication 800-12, An Introduction toComputer Security: The NIST Handbook (Handbook) and NIST Special Publication 800-14,Generally Accepted Principles and Practices for Securing Information Technology Systems(Principles and Practices)).There is no requirement or mandate for any federal agency or any other person to use thisdocument. There is no relationship or recognition of this document to FISMA, OMB, or anyother federal regulation, law or agency charged with the oversight of federal informationtechnology security and none should be drawn.The official NIST Special Publications and Security documents can be obtained from the NISTComputer Security Resource Clearinghouse Web site at the URL: http://csrc.nist.gov/1.4 Purposes of Security PlansSecurity plans are created as part of an overall security framework and can be viewed as a roadmap for continuing to improve the security stance for not only the system it covers but for theentire organization.Security plans help to: • Provide an outline of security measures for a system; • Describe what measures are in place and what is planned with target implementation dates; • Assign responsibility and accountability to those in charge of security measures; and • Define responsibility and expected behavior of the system users.Revision 1 Page 8 of 35April 2003
  9. 9. 1.5 Security Plan ResponsibilitiesUltimately it is the Chief Security Officer (CSO) that is responsible for the overall developmentof security plan(s) for an organization. However, it is the system owner that was appointed ordesignated by the CSO that is actually responsible for preparing, implementing, and monitoringthe security plan for a given system.While the actual development, implementation, and monitoring of a system security plan maybeoutsourced to a contractor, the system owner is not relived of their responsibilities as the systemowner or system security officer. They are still responsible to ensure that the security plan ismaintained as a living document that is reviewed periodically for modifications and completionof planned milestones and identification of new vulnerabilities. It is also important that thesystem owner and/or security officer is familiar with the day to day use of the system and notdelegate security oversight to technical personnel that are meant to support or develop thesystem.1.6 Recommended FormatThis document uses the same format that NIST SP 800-18 recommend when it was published in1998. Regardless of whether the NIST SP 800-18 recommendation is used or a formatdeveloped by your organization is used, the key point is that a standardized approach todeveloping and maintaining security plans is used and the level of detail included is constantwith criticality and importance to the organization’s mission. Additionally, the security planshould fully identify and describe the controls currently in place or planned for the system andinclude a unique list of rules of behavior specific to that system.1.7 Advice and Comment on PlanNo security plan can be adequately developed by one person or just by the system owner.Advice and comment for the security plan should be sought from individual both within and/oroutside the organization. Inside the organization advice and comments should be sought frommanagement, organization policy, system administrators, system developers and system users.Outside advice and comments about the plan should be sough once the plan is drafted and beforeit is implemented. Outside advice is meant to be provide by individuals independent of thesystem owner’s reporting chain that have adequate knowledge or experience to ensure the plancontains appropriate information and meets organizational security policy and standards.1.8 AudienceThis document is intended to be a supplemental guide to NIST SP 800-18 and was drafted toaugment that document. This document is written for use by individuals with little or no ITsecurity experience and for use as an auditing tool. As with the NIST document, the conceptspresented here are generic and can be applied to organizations in public and private sectors.Revision 1 Page 9 of 35April 2003
  10. 10. 2 System AnalysisA completed security plan contains technical information about a system, security requirements,and the controls implemented to protect a system against known risks and vulnerabilities. Thefirst step in developing a plan is determining what type of sys tem is to be done and what type ofplan is required for a system. This section walks the reader through the analysis of a system todetermine the boundaries of the system and the type of system.2.1 System BoundariesSystem boundaries are a logical binding of processes and IT resources. The elements within thislogical boundary constitute a single system requiring a security plan. For GSSs and MAs eachelement of a system must, as defined in NIST SP 800-18: • Be under the same direct management control; • Have the same function or mission objective; • Have essentially the same operating characteristics and security needs; and • Reside in the same general operating environment.For a WSS the same general elements apply, however there can be differences. With a WSS theelements of a system must: • Have essentially the same operating characteristics and security needs; and • Reside in the same general operating environment.However unlike the GSSs and MAs, WSS may have some elements to them that are: • Under different direct management control; • Have different function(s) or mission objective(s); and • May reside in multiple operating environments.For example a WSS is depended on a server that supports or offers web services (e.g., HTTP,FTP, ASP). The server providing these services, are typically under the direct managementcontrol of the LAN or Data Center operational unit. However, the actual web pages view by theweb users are developed and maintained by a different group. A WSS can also havecomponents that span multiple operating environments to provide the required services tosupport a WSS.2.2 System CategorySystem Category is where each system is determined either to be a GSS, a MA, or a WSS. Allsystems and applications should be covered by a security plan. In some cases applications areconsidered covered under the umbrella of a GSS. Major Applications have their own uniquesecurity plan that is coordinated with the security plan of the GSS that supports the MA. A WSSis similar here to a MA in that it should have its own security plan that also requires coordinationwith a GSS security plan.Revision 1 Page 10 of 35April 2003
  11. 11. 2.2.1 Major ApplicationsA major application is an application that because of the information contained, processed, ortransmitted in combination with their criticality and importance to the organizations missionrequire additional management oversight. Major applications are systems that perform a clearlydefined function(s) for an organization. Typically a major application is one that is used tosupport a specific mission-related function (e.g., accounting systems, human resourcesinformation systems, customer relation management systems). While in most cases a majorapplication is a single software application, there are also cases where multiple individualapplications that are all related to the accomplishment of a single mission function (e.g. payrollsystems, customer relations/customer complaint systems). When a system is defined as a majorapplication that is dependent on a general support system, the major application owner must: • Notify the GSS system owner that the application is critical or contains sensitive information and provide any additional security requirements that will be required of the GSS; • Request a copy of the system security plan of the general support system and ensure it provides adequate protection for the application and information; • Provide the major application’s security plan to the operator of the general support system; and • Include a reference to the general support system security plan, including the unique name/identifier information in Section 3.5, System Environment.2.2.1.1 Major Application Determination GuidanceThe following guidance is designed to assist a system owner in determining if the applicationshould be considered a Major Application. If a system owner can answer yes to the followingquestions typically the application in question should be considered a major application. • Is the application used to support a mission wide goal or does it provide an internal support functio nal that allows the organization to accomplish mission wide goals? • Is the application accessed by employees on a daily basis? • Can the organization function without access to the system for over a month or longer?There are three other questions that a system owner needs to be able to answer in order to makethe final determination about an application. • Is the application provided for use by another organization? • Does your organization have the responsibility for configuring the application and maintaining the application? • Is the organization responsible for the certification and accreditation for the application?If the application is provided to your organization by another organization and is maintained bythe other organization then while the application may be considered a major application, yourRevision 1 Page 11 of 35April 2003
  12. 12. organization may not be responsible for developing a unique security plan for the application.When this is the case, discussions with the organization or group that is providing the applicationshould take place to determine exact responsibilities for your organization. Even though yourorganization my not be responsible for a security plan, you still may want to develop a securityplan for additional assurance of system security. Not being responsible for developing a securityplan does not relive an organization of security concerns and instead require coordination of theorganizations security efforts to meet or exceed those in the security plan or connectionagreements for the application from the other organization.2.2.2 General Support SystemA general support system is easier to define and is typically an interconnected informationresources under the direct management control of a group within the organization, typically theIT Department.Examples of some general support system are: • A Local Area Network • A Wide Area Network • A Wireless Network • A Radio Network • A Voice over IP NetworkA general support system includes hardware, software, information, data, applications,communications, facilities, and people that provides support for a variety of users and/orapplications.2.2.3 Web Support SystemA web support system is a hybrid of a general support system and a major application. UnderNIST SP 800-18 an organization may be covering parts of their Internet sites, intranets, orextranets with their GSS security plan or major application security plan. Unfortunately this mayresult in security vulnerabilities not being mitigated or properly recognized. A web supportsystem, for this document, is defined as the information technology resources providing webservices. A web support system includes the web/internet service software (not the operatingsystems), the web content pages, and web applications. A web support system will prove to beunique in that developing a security plan for a WSS is that it will most likely require a matrix ofpersonnel that cross departments (e.g. business units and members of the IT department) withinan organization to ensure the security of a WSS.Revision 1 Page 12 of 35April 2003
  13. 13. 2.2.3.1 Web Support System Determination GuidanceJust as not all applications should be considered major applications, the existence of an Internetweb presence, intranet, or extranet does not automatically mean that they should be considered aweb support system requiring its own security plan. The following guidance is designed to assistan organization in determining if their Internet web presence, intranet, and/or extranet should beconsidered a web support system.If a system owner can answer yes to the following questions typical the application in questionshould be considered a web support system.Internet Web Presence • Is the site accessible by anonymous access? • Is the site content static? • Does the site host any open applications for user to submit request without requiring a user id/password combination?If the answers to the first two questions is ‘yes’ and the last one is ‘no’, this system should not beconsidered a web support system and continued to be covered under a GSS security plan.Intranet • Does the organization have an intranet available to its employees requiring a user id/password combination to access? • Does the intranet host web applications that allow the employees to interact the organizations applications (e.g., personnel information submission to HR or HR systems, time & attendance application)? • Can the organization function for an extended period of time (i.e., a month) without the Internet site without any noticeable impact on the organizations operations?If the answers to the first two questions is ‘yes’ and the last one is ‘no’, this system should beconsidered a web support system and a separate security plan developed for this system.Extranet • Does the organization have an extranet available to its clients/vendors requiring a user id/password combination to access? • Does the extranet host web applications that allow the users to interact the organizations applications (e.g., supply chain)? • Does the extranet support any mission critical processes or objectives? • Can the organization function for an extended period of time (i.e., a month) without the extranet without any noticeable impact on the organizations mission?If the answers to the first three questions is ‘yes’ and the last one is ‘no’, this system should beconsidered a web support system and a separate security plan developed for this system.In many cases an organization may a combination of Internet web presences / Intranet / Extranet.Having multiple systems that the above guidance indicates that it maybe desirable to have aRevision 1 Page 13 of 35April 2003
  14. 14. separated security plan does not mean that each system should have an independent securityplan. Since these are all similar systems one consolidated security plan for all these systems canbe developed and any unique differences between them discussed in the plan.Revision 1 Page 14 of 35April 2003
  15. 15. 3 Plan DevelopmentThe rest of this document helps guide the reader in writing a security plan for a web supportsystem. For guidance on developing on security plans for general support systems and majorapplications the reader should refer to NIST SP 800-18. This document only provides guidancefor a web support system security plan based on an interpretation of that publication.3.1 Plan ControlAll security plans should be considered sensitive in nature and the organization should protectthe document as required by the organization’s policies and not made widely available toemployees or the public. Additionally, all security plans should be placed under documentationcontrol and have revision marking and pagination information on each page to allow for updatesto the plan via change pages. A security plan should begin with the following systemidentification sections.3.2 System IdentificationThe first section of the security plan should provide the basic identifying information about thesystem.3.2.1 System Name/TitleList the unique name your organization has given to the web support system. For individual websupport systems this may be the name or URL of the intranet or extranet site. For a combinedplan, a generic title maybe chosen to encompass all the web presences the organization has.3.2.2 Responsible OrganizationThe department or group with in the organization that is responsible should be listed here. Thissection should include the organization name, department or group responsible, and the physicaladdress information.If system maintenance is out sourced, this section should also list the name and addressinformation for the group maintaining the system.3.2.3 Information Contact(s)The information contact information should list the main points of contacts for this system. Thisinformation should include contacts for the system owner(s), data owner(s), and GSS supportcontact(s).Include the name, title, physical address, phone number and e- mail address for all individuals.Revision 1 Page 15 of 35April 2003
  16. 16. 3.2.4 Assignment of Security ResponsibilityOne individual must be assigned responsibility in writing to ensure that the web support systemhas adequate security. This person should be knowledgeable of the system and when possiblenot be a system administrator or system developer. As with information contact, the name, title,physical address, phone number and e-mail address for the individual assigned thisresponsibility.The person assigned this responsibility should be someone that has the ability and authority toboth oversee the development and maintenance of the web support system as well as being ableto interact with the IT support staff that will be maintaining the server(s) in the GSS that supportthe web support system(s).3.3 System Operational StatusIndicate the system’s operational status. A system can have multiple status selected, howeverwhen more than one status is selected, this section should indicate which parts are in what status.Additionally subsections for the security in the life cycle and specific controls for each part. • Operational — the system is operating. • Under development — the system is being designed, developed, or implemented. • Undergoing a major modification — the system is undergoing a major conversion or transition.If the system is under development or undergoing a major modification, provide informationabout the methods in place to assure that security requirements are included.3.4 General Description/PurposeBriefly describe in one to three paragraphs the function and purpose of the system (e.g.,organization intranet, partner/customer extranet). A list of all web applications supported by theweb support system should be listed and if any are part of it area designated as a majorapplication or part of a major application. Additionally, list the name of the general supportsystem(s) that support the web support system (e.g., LAN). Include a list of user organizations,whether they are internal or external to the system owner’s organization, and a generaldescription of the type of information and processing provided by the WSS for these groups.Request information from both the general support system(s) owner and any application owners(be sure to obtain a copy of the security plans) to ensure their requirements are met or aresufficient for the general support system to support the needs of the web support system3.5 System EnvironmentBriefly describe in one to three paragraphs the general description of the technical system. Anyenvironmental and/or technical factors that raise special security concerns should be included.This section does not need to describe the details of the general support systems and should berestricted to information specific to the web support system, such as:Revision 1 Page 16 of 35April 2003
  17. 17. • Web Server Software Name, Manufacture, Revision, and Patch Level; • Encryption and/or certificate technology; • Reference the general support system that the web support system is dependent on; • Scripting Languages supported (e.g., JavaScript, VBScript); and • Any software specifically installed for functionality support on the web support system (e.g., search engine software, chat room support).This section should also include security software that has been installed assist in the protectionof the system and the information.3.6 System Interconnection/Information SharingSystem interconnection information for a web support system is any connections that theapplications residing on the web support system make use of to call or process data. Systeminterconnections that are not documented and protected for a web support system can result inthese connections being compromised allowing the general support system or a major applicationto be compromised.OMB Circular A-130 states that there must be a written management authorization prior tointerconnection. For a web support system a Memorandum of Understanding should be createdfor the interconnections that details the configuration of that interface.For each system interconnection/information sharing connection provide the followinginformation: • Interface Name; • Organization owning the system being interfaced to; • Type of interconnection (e.g., ODBC, audio/video streaming, etc.); • Short description of any security concerns about the interconnection; • Name and title of authorizing management official; • Date of authorization; • State if the interconnection is to a system of record; • Sensitivity of the system being connected to;This section should also include a description of how the web support system interfaces withserver authentication database(s) (e.g., Active Directory).This section does not need to include a description about the general support system that the websupport system is dependent one. The system interconnection between the general supportsystem and web support system is understood as a dependency.3.7 Sensitivity of Information HandledProvide a description of the types of information handled by the system and an analysis of thecriticality of the information. The sensitivity and criticality of the information stored within,processed by, or transmitted by a system provides a basis for the value of the system and is oneRevision 1 Page 17 of 35April 2003
  18. 18. of the major factors in risk management. The description must contain information on applicablelaws, regulations, and policies affecting the system and a general description of sensitivity asdiscussed below.3.7.1 Laws, Regulations, and Policies Affecting the SystemList any laws, regulations, or policies that establish specific requirements for confidentiality,integrity, or availability of data/information in the system. Each organization should determinewhat laws or regulations are applicable to the system that should to be included in the securityplan. Examples might include: • The Privacy Act; • HIPAA; • Section 508; • E-Sign Act; and • Gramm Leech Bliley Act.Be sure to include any organizational policies, procedures, and/or handbooks that may beapplicable.If the system processes records subject to the Privacy Act, include the number and title of thePrivacy Act system(s) of records and whether the system(s) are used for computer matchingactivities.3.7.2 General Description of Sensitivity The general description of sensitivity reviews the system requirement against the need forconfidentiality, integrity, and availability. In addition to this, this section should also discuss thesystem criticality.3.7.2.1 System CriticalityDescribe the systems importance in terms of mission supportive, mission important, or missioncritical.3.7.2.2 System/Data SensitivityDescribe the system in terms of confidentiality, integrity, and availability. In addition to this, thegeneral support system overall system sensitivity rating should be included.An example of a system/data sensitivity section appears below:SensitivityThe sensitivity rating summarizes the sensitivity areas of the system. The overall systemsensitivity leve l is determined by the highest value in the Rating Column in the table below.Therefore, the sensitivity level for the web support system is High Sensitivity.Revision 1 Page 18 of 35April 2003
  19. 19. SENSITIVITY AREAS RATING GSS HIGH Confidentiality MEDIUM Integrity HIGH Availability HIGHThe criteria used to measure a system’s sensitivity include confidentiality, integrity, andavailability. The sensitivity areas for the web support system are described below.Confidentiality - HighThe system contains information that requires protection from unauthorized disclosure.Integrity - MediumThe system contains information, which must be protected from unauthorized, unanticipated, orunintentional modification.Availability - HighThe system contains information or provides services that must be available on a timely basis tomeet mission requirements or to avoid substantial losses.For detailed examples and descriptions of sensitivity and rating confidentiality, integrity, andavailability, please refer to section 3.7.2, General Description of Sensitive on page 15 of NISTSP 800-18.Revision 1 Page 19 of 35April 2003
  20. 20. 4 Management ControlsThis section is where the management control measures that are in place or planned for theprotection of the system should be talked about. It is important that for any measures tha t arelisted as planned that a target implementation date is associated with that measure. This willallow you to use this document to help track progress. For more detail on management controls,see NIST Special Publication 800-12, An Introduction to Computer Security: The NISTHandbook.4.1 Risk Assessment and ManagementDiscuss the methods used to assess the nature and level of risk to the system. Discuss the currentknown threats, vulnerabilities, and effectiveness of current safeguards to the system. Be sure toinclude the date the last risk assessment was conducted and who performed the assessment. Ifthere has not been a risk assessment conducted for the system, one should be planned and themilestone for conducting the assessment (month and year) included in this section.With the visibility of the web support system(s) on the internet part of the risk management forthis system is know exactly what protocols and ports are being used by the system. This sectionwill also help outline the business need for have a port open or service available on a WSS. Inthis section a discussion of services, ports, and protocols should incorporated.Some points to consider in this discussion are: • Does the systems support web-based e- mail access; • What ports are used by the system (e.g., 80, 443, 21); and • What protocols are supported (e.g. HTTP, HTTPS, SSL 2.0, FTP, NNTP, SMTP).4.2 Review of Security ControlsAn independent review of security controls for a system is required to be performed every threeyears. In this section the findings and recommendations from the last review / risk assessmentshould be discussed in summary fashion. This discussion should also discuss the organizationsresponse to the findings and recommendations. If there were any findings or deficiencies that arereportable under OMB Circular A-123 they should be indicated here. For findings orrecommendations that require a long-term mitigation effort that was accepted by theorganization, target milestone dates for the completion of the mitigation process should alsoindicated in this section.While OMB Circular A-130, requires an independent review of security controls every threeyears, organizations should also have an internal security review process. This section shouldoutline the other types of security evaluations that the organization conducts on their system,aside from the independent review. Include brief description of each type of review performed,who performs the review, and the output/actions from the review.The purpose of security reviews are to provide verification that controls are working as intendedbut also to ensure the system continues to adjust to new security threats. For a web supportsystem, reviewing the controls and countermeasures only every-three years exposes the systemRevision 1 Page 20 of 35April 2003
  21. 21. to a high risk of vulnerability of being breeched. New vulnerabilities, attacks, and maliciouscode designed to exploit web support system are discovered on almost a daily basis. Given thehigh visibility of web support systems, at least once every six to nine months the web supportsystem should be reviewed to ensure its security stance is as strong as possible. These six to ninemonth reviews should primarily be focused on the technical and operational controls of the websupport system that can be conducted with tools like vulnerability scanners.4.3 Rules of BehaviorThe rules of behavior for a web support system are very different from rules of behavior foreither a general support system or a major application. Depending on what the web supportsystem provides function for, an organization may not be able to have a signed signature pagefrom a user. Additionally, as part of the rules of behavior of the web support system should alsocontain a privacy policy that outlines what information the web support system may collect andhow that information is used.Rules of behavior for a web support system should include the following: • Password policy; • Usage Monitoring; • Privacy Statement; • Information collect by the system (e.g., cookies, IP address, referring URL) • Limitation on use of information published on the system; • Limitation on changing/uploading/downloading of information on the system; • Discussion of copyrighted information; and • Discussion of consequences of noncompliance with the rules published.The rules of behavior should be made available to every user prior to receiving authorization foraccess to the system either on a request for access form and on a content page readily identifiableand accessible on the web support system. Depending on the sensitivity of the web supportsystem will determine if this content page needs to have parts of displayed as part of a warningpage prior to access any content on the web support system4.4 Planning for Security in the Life CyclePlanning for Security in the Life Cycle of a web support system is possibly more critical thanwith a general support system or a major application in that the web support system is publiclyavailable on the Internet. Web support systems can also end up supporting a variety of webbased applications that with different authentication and security system. The Life Cycle for aweb support system should be a guidance principle that is used to unify the way the web supportsystem grows and applications are developed or put in place.In this section, determine which phase(s) of the life cycle the system, or parts of the system, is in.Identify how security has been handled during the applicable life cycle phase. Depending on theRevision 1 Page 21 of 35April 2003
  22. 22. Life Cycle model chosen by the organization to cover the web support system, it will most likelyconsist of the five basic phased outlined below.All five phases (or how ever many phases there are in the life cycle plan adopted by yourorganization) should be discussed in this section regardless of what phase the web supportsystem is currently in.The following NIST Special publications may provide the reader with additional guidance aboutthis life cycle process: • NIST SP 800-23, Guideline to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products; • NIST SP 800-27, Engineering Principle for Information Technology Security (A Baseline for Achieving Security); • NIST SP 800-44, Guidelines on Securing Public Web Servers.4.4.1 Initiation PhaseDuring the initiation phase, the need for a system is expressed and the purpose of the system isdocumented. For a web support system, the initiation phase can also be the strategic vision forthe life of the web support system.4.4.2 Development/Acquisition PhaseDuring this phase, the system is designed, purchased, programmed, developed, or otherwiseconstructed. This phase may consist of other defined cycles depending on the life cycle modeladopted by the organization.During this phase, security requirements should be developed at the same time system plannersdefine the requirements of the system. These requirements may be expressed as technicalfeatures or operational practices. This phase, include a general description of any specificationsthat are used and how they are being maintained.4.4.3 Implementation PhaseIn the implementation phase, the system’s security features are configured, enabled, and thesystem is installed and tested. A design review and systems test must be performed prior toplacing the system into operatio n to assure that it meets security specifications. Once that iscomplete the system can be authorized for processing. (See Section 4.5, Authorize Processing,for a description of that requirement.)The results of the design reviews and system tests should be fully documented, updated as newreviews or tests are performed, and maintained in the official organization records. If the systemRevision 1 Page 22 of 35April 2003
  23. 23. or parts of the system are in the implementation phase, describe when and who conducted thedesign reviews and systems tests. Include information about additional design reviews andsystems tests for any new controls added after the initial acceptance tests were completed.4.4.4 Operation/Maintenance PhaseDuring this phase, the system performs its work. Once in operation during the life of the systemit will face modification by the addition of hardware and software and updated content pages. Asthe system undergoes modifications, determine which phase of the life cycle the systemmodifications are in and describe the security activities conducted or planned for that part of thesystem. For the system in the operation/maintenance phase, the security plan documents thesecurity activities.The following high- level items should be described: • Security Operations and Administration. • Operational Assurance. • Audits and Monitoring.4.4.5 Disposal PhaseThe disposal phase of the IT system life cycle involves the disposition of information, hardware,and software. If the system or part of the system is at the end of the life cycle, briefly describe inthis section how the following items are disposed: • Information. Information may be moved to another system, archived, discarded, or destroyed. When archiving information, consider the method for retrieving the information in the future. • Media Sanitization. The removal of information from a storage medium (such as a hard disk or tape) is called sanitization. Different kinds of sanitization provide different levels of protection. A distinction can be made between clearing information and purging. There are three general methods of purging media: overwriting, degaussing (for magnetic media only), and destruction.4.5 Authorize ProcessingAuthorization to process is the formal acceptance of management of the risk associated with asystem and allows the system to go into the production environment. In this section of thesecurity plan information about the name and title of the management official providing theauthorization to process and the date the authorization was granted. If the system has not yetbeen authorized to process, include the name and title of the person requesting authorization, thedate of the request, and the name and title of the person the request was sent to.Depending on your organization this may be part of the certification and accreditation process.For more information about authorize to process see section 4.5 on page 24 of NIST SP 800-18.Revision 1 Page 23 of 35April 2003
  24. 24. NIST SP 800-37, Guidelines for the Security Certification and Accreditation of FederalInformation Technology Systems may also help the reader to better understand the certificationand accreditation process.Once a system is authorized to process, it should under go a process to be re-authorized prior toany major system change and at the very least every three years as part of the independentsecurity review process.Revision 1 Page 24 of 35April 2003
  25. 25. 5 Operational ControlsThis chapter and Chapter 6, Technical Controls, the formats and related guidance provided is forthe web support system. For information on the formats and related guidance for majorapplications or for general support systems, please refer to NIST SP 800-18. The sectionnumbering of these two chapters differs from the rest of the document and follows the samegeneral numbering that was put forth in NIST SP 800-18. The chapters are numbered as 5.WSSand 6.WSS for web support system. This number system was continued from NIST SP 800-18to allow the user to easily combine the original NIST SP 800-18 along with this documentsinterpretation for web support systems.Revision 1 Page 25 of 35April 2003
  26. 26. 5.WSS Web Support System – Opera tional ControlsOperational controls are the security methods are a mix of technical (system) and non-technical(human) controls that work in concert to protect a system. This section describes the operationalcontrol measures that are currently in place or measures that are currently planned to be or are inthe process of being implemented along with a target implementation date.5.WSS.1 Personnel SecurityIntentional and unintentional acts by individuals cause the greatest disruption to a system. Mostsystem disruption can be traced back to the well- meaning action of an individual authorized touse the system (e.g., installation of a new patch without having tested the patch first).This section should outline and provide the details about personnel security measures put inplace for the web support system. • Have all positions been reviewed for sensitivity level? If all positions have not been reviewed, state the planned date for completion of position sensitivity analysis; • A statement as to whether individuals have received the background screening appropriate for the position to which they are assigned. If all individuals have not had appropriate background screening, include the date by which such screening will be completed; • If individuals are permitted system access prior to completion of appropriate background screening, describe the conditions under which this is allowed and any compensating controls to mitigate the associated risk; • Is user access restricted (least privilege) to data files, to processing capability, or to peripherals and type of access (e.g., read, write, execute, delete) to the minimum necessary to perform the job; • Are critical functions divided among different individuals (separation of duties) to ensure that no individual has all necessary authority or information access which could result in fraudulent activity; • Is there a process for requesting, establishing, issuing, and closing user accounts; • What mechanisms are in place for holding users responsible for their actions; and • What are the termination procedures for a friendly termination and an unfriendly termination.5.WSS.2 Physical and Environmental ProtectionPhysical and environmental security controls are implemented to protect the facility housingsystem resources, the system resources themselves, and the facilities used to support theiroperation. Typically, the components of the web support system reside with LAN generalsupport system or where the data center is located. When that is the case this section becomes areference point to the general support system that houses the web support system. However, ifthe web support system is housed outside the data center or server room for a general supportsystem then you must briefly describe the physical and environmental controls in place.Revision 1 Page 26 of 35April 2003
  27. 27. 5.WSS.2.1 Explanation of Physical and Environment SecurityIn this section, describe where the web support system is located or hosted at. For example:Web support system that resides in the data center:The web support system is co- located within the data center for Organization ABC. All physicaland environmental security is handled by the data center and is covered by the LAN GeneralSupport System Security Plan.Web support system that resides outside of the data center OR outsourced for hosting:The web support system located on the 3rd floor at Organization ABC’s Headquarters.When the web support system resides outside of the organizations data center or is outsource toanother organization to be hosted, this section must also include a discussion about the locations: • Access Control; • Fire Safety Factors; • Failure of Supporting Facilities; • Structural Collapse; and • Interception of Data.5.WSS.3 Production, Input/Output ControlsIn this section, provide a synopsis of the procedures in place that support the web supportsystem. Below is a sampling of topics that should be reported. • User support; • Audit trails for receipt of sensitive inputs/outputs; • Procedures for restricting access to output products; • Procedures and controls used for transporting or mailing media or printed output; • Internal/external labeling for appropriate sensitivity (e.g., Privacy Act, Proprietary); • External labeling with special handling instructions (e.g., log/inventory identifiers controlled access, special storage instructions, release or destruction dates); • Audit trails for inventory management; • Media storage vault or library physical and environmental protection controls and procedures; • Procedures for sanitizing electronic media for reuse (e.g., overwrite or degaussing of electronic media); • Procedures for controlled storage, handling, or destruction of spoiled media or media that cannot be effectively sanitized for reuse; and • Procedures for shredding or other destructive measures for hardcopy media when no longer required.Revision 1 Page 27 of 35April 2003
  28. 28. 5.WSS.4 Contingency PlanningWeb support systems require appropriate emergency, backup, and contingency plans. Theseplans should be coordinated with the general support system that supports the web supportsystem. In the event of a failure, this contingency plan will be road map for how the web supportsystem is restored to service. This plan maybe very simple in that it relies on a GSS ContingencePlan or have a very detailed plan separate from the GSS.When reviewing the General Support Systems plan for adequate coverage or developing a websupport system specific plan, include the following: • Is tested contingency plan in place to permit continuity of mission-critical functions in the event of a catastrophic event; • Is tested disaster recovery plan in place for all supporting IT systems and networks; • Is formal written emergency operating procedure posted or located to facilitate their use in emergency situations; • How often are contingency, disaster, and emergency plans tested; • Are all employees trained in their roles and responsibilities relative to the emergency, disaster, and contingency plans; • Include descriptions of the following controls; • Any agreements for backup processing (e.g., hot-site contract with a commercial service provider); • Documented backup procedures including frequency (daily, weekly, monthly) and scope (full backup, incremental backup, and differential backup); • Location of stored backups (off-site or on-site); • Generations of backups kept; and • Coverage of backup procedures, (e.g., what is being backed up).5.WSS.5 Hardware and Software Maintenance ControlsThese controls are used to monitor the installation of, and updates to, the web support system toensure that the software functions as expected and that a historical record is maintained ofapplication changes. This helps ensure that only authorized software is installed on the system.These controls may also be termed version control, change management, or configurationManagement. The following questions are exa mples of items that should be addressed inResponding to this section: • Was the application software developed in- house or under contract; • Are any COTS applications installed and running on the web support systems (e.g., a search engine); • If a COTS product (or shareware), were sufficient licensed copies of the software purchased for all of the systems on which this application will be processed; • Is there a formal change control process in place for the application, and if so, does it require that all changes to the application software be tested and approved before being put into production; • Are all changes to the application software documented;Revision 1 Page 28 of 35April 2003
  29. 29. • Are test results documented; • How are emergency fixes handled; • Are there organizational policies against illegal use of copyrighted software or shareware; • Are there restriction/controls on those who perform maintenance and repair activities; • Procedures used for items serviced through on-site and off-site maintenance (e.g., escort of maintenance personnel, sanitization of devices removed from the site); • Procedures used for controlling remote maintenance services where diagnostic procedures or maintenance is performed through telecommunications arrangements; • Describe the configuration management procedures for the system. Consider the following items in the description: o Version control that allows association of system components to the appropriate system version; o Procedures for testing and/or approving system components (operating system, other system, utility, applications) prior to promotion to production; o Impact analyses to determine the effect of proposed changes on existing security controls to include the required training for both technical and user communities associated with the change in hardware/software; o Change identification, approval, and documentation procedures; and o Procedures for ensuring contingency plans and other associated documentation are updated to reflect system changes. • Do the policies contain provisions for individual and management responsibilities and accountability, including penalties; • What products and procedures are used to protect against illegal use of software; and • Are software warranties managed to minimize the cost of upgrades and cost reimbursement or replacement for deficiencies.5.WSS.6 Data Integrity/Validation ControlsIntegrity controls protect the operating system, applications, and information on the web supportsystem from accidental or malicious alteration or destruction and to provide assurance to the userthat the informatio n has not been altered. A web support system may have its own set ofcontrols that work in conjunction with the controls in place on the general support system.The following questions are examples of some of the controls that a web support system maymake use of: • Is virus detection and elimination software installed? If so, are there procedures for: o Updating virus signature files; o Automatic and/or manual virus scans (automatic scan on upload of files); and o Virus eradication and reporting. • Are password crackers/checkers used; • Are integrity verification programs used by applications to look for evidence of data tampering, errors, and omissions; • Is system performance monitoring used to analyze system performance logs in real time to look for availability problems, including active attacks, and system and network slowdowns and crashes; and • Is there any encryption systems in use (e.g., SSL, Certificate, PKI).Revision 1 Page 29 of 35April 2003
  30. 30. 5.WSS.7 DocumentationDocumentation is a very important security control for a web support system. As there is nostandard web support system configuration, the internally generated documentation is all anorganization may have that explains how software/hardware was configured for use.Documentation for a web support system includes descriptions of the hardware and software,configuration documentation about the hardware and software as it relates to the web supportsystem, policies, standards, procedures, backup and contingency activities, as well asdescriptions of user and operator procedures.An example list is provided to show the type of documentation that would normally bemaintained for a system. The list is not intended to be all- inclusive or imply that all systemsshould have all items listed. Examples of Web Support System Documentation Ø Vendor supplied documentation on web server software Ø Vendor supplied documentation on COTS applications supporting web functionality (e.g., search engine, web based training applications) Ø Configuration settings for each web site and/or sub-web Ø General Support System Security Plan Ø Web Support System Security Plan Ø User Manuals or FAQ pages Ø Privacy Policy Ø Risk Assessments Ø Recovery Plan & Testing Plan Ø Contingency Plan Ø Authorize to Process Letter / C&A Package Ø Memoranda of understanding with interfacing systems5.WSS.8 Security Awareness and TrainingWeb support systems like general support systems and major applications should have a securityawareness and training program associated with it. The Computer Security Act requires federalagencies to provide training in computer security awareness. OMB Circular A-130 furtherenforces this requirement. The trick with web support systems is that most of them are publicfacing and may be used by more than just the organizations employees and/or contractors. Thismay require the organization to have a two-tracked security awareness and training program for aweb support system: Internal Training and External Training.Internal TrainingInternal training is geared around security awareness and training for the organizationsemployees and contractors. This track may actually be combined with the general supportsystem awareness and training program or it may be a stand-alone module that only certainpersonnel receive. Internal training should also have a special section to it devoted just to theRevision 1 Page 30 of 35April 2003
  31. 31. risks of web development around the environment used by the organization for the webprogrammers and developers.External TrainingExternal Training is geared to statements and static content pages that users of the system canview. In some cases, the organization may also find the need to make use of pop- up screens toprovide this information. The external training needs to be geared toward the user population ofthe web support system and around the controls applicable to those users.Regardless of the type of training the organization makes use of for the web support system,include in this section of the plan information about the following: • The awareness program for the system (posters, booklets, etc.); • The type and frequency of system-specific training provided to employees and contractor personnel (seminars, workshops, etc.); • The procedures for assuring that employees and contractor personnel have been provided adequate training; • The type and frequency of security awareness training provide to the public users.5.WSS.9 Incident Response CapabilityThe web support system, being a public or semi-public facing system, is the front door to yourorganization on the Internet. All web support systems should be include in the organizationsIncident Response System that is mandate by OMB Circular A-130 and that is normallysupported by the general support systems of the organization. In this section, describe theincident handling procedures specifically targeted for the web support system.Some of the areas of consideration that should be included in this section: • Describe the incident response capability; • What are the procedures for reporting and handling incidents; • Who receives and monitors alerts/advisories and vendor updates; • Describe any intrusion detection tools used; and • Describe any other security tools in place to identifying and investigation of activity.Revision 1 Page 31 of 35April 2003
  32. 32. 6 Technical ControlsTechnical controls are the security controls that the system executes automatically. Thesecontrols can provide automated login and protection of the system that can be used to facilitatedetection and investigation of security violations. While the controls themselves are technicaland in most cases automated, there is still a part to these controls that require personnel to auditor monitor the output from these controls. Simply putting the controls in place and walkingaway does not provide adequate security in the long term.The controls put in place or planned should be consistent with the level of risk of the system, theability to manage the controls by personnel within the organization, and support the needs of anyweb applications the web support system hosts.6.WSS.1 Identification and AuthenticationAccess to the web support system usually requires the system to be able identify a user anddetermine what rights that user has to the web support system. Depending on the web supportsystem users maybe required to login to the system to access it or just to perform certainfunctions. Though some web support systems are completely public facing and don’t requireany login access, the system still should be set up to support the concept of least privilege anduser accountability.6.WSS.1.1 IdentificationIn this section of the plan, describe how users are identified to the system.Anonymous Access: What parts of the system can be access without a User ID being entered?Unique Identification: What parts of the system require users to identify themselves before beingallowed to access the system?Correlate Actions to Users: How does the system maintain the actions the users make whileusing the web support system.Maintenance of User IDs: An organization should ensure that all User IDs belong to currentlyauthorized users. Identification data must be kept current by adding new users and deletingformer users.Inactive User IDs: User IDs that are inactive on the system for a specific period of time (e.g.,three months) should be disabled.6.WSS.1.2 AuthenticationAuthentication is how the system knows or validates a user is the person they claim to be. Whilethere are many means of establishing the authenticity of a user, typically most web supportsystem only makes use of a shared secret authentication system (e.g., password, PIN).Revision 1 Page 32 of 35April 2003
  33. 33. In this section the web support system’s authentication control mechanisms should be described.Some topics that should be included in this section are: • Describe the user authentication systems; • Describe the password creation and acceptability policy enforced by the system (e.g., length required, character set required); • Describe the procedure for issuing passwords, handling lost passwords, password changes; • Describe the token system used, if implemented; • How does the web support system request and receive User ID and Passwords (e.g., clear text, SSL, NT Change and Response); • Number of invalid login attempts allow and lock out procedures; and • Describe how the system accommodates and handles electronic signatures (if needed);6.WSS.2 Logical Access Controls (Authorization/Access Controls)Logical access controls govern who has access to specific system resources and type of accesspermitted. In this section the controls in place to restrict the activities of the users of the websupport system should be discussed. • Describe what authority each class of users has (e.g.; anonymous user, browser, author, publisher, webmaster); • Discuss how separation of duties is enforced or how it is mitigated if separation of duties is not enforced; • What ability is available on a web site to run scripts, write, or execute programs; • Does the web support make user of Access Control Lists and how often are they reviewed for accuracy; • Is Discretionary access control allowed; • How is the web support system segregated from the rest of the IT infrastructure; • Does the web support system enforce time-outs from inactivity; • How long does a web support system maintain a logged in connection if communication with the remote user is lost with out logout command issued; • Does the system enforce any hours of operations; • If SSL is used, what version(s) are accepted by the server and discuss the SSL Certificate generation process; • Discuss any encryption used, if any, other than SSL and describe the methodology used; • Discuss protection of the web support system offered from any firewalls, routers, and proxy servers in front and/or behind the web support system; • Are login banners/screens/ pop-ups used:It is recommended that a standardized log-on banner be placed on the system. Public Law 99-474requires that a warning message be displayed; notifying unauthorized users that they haveaccessed a U.S. Government computer system and unauthorized use can be punished by fines orimprisonment. Some of the systems now in use are intended for unrestricted us e by the generalRevision 1 Page 33 of 35April 2003
  34. 34. public (e.g., Internet-based systems used for widespread public information dissemination), asituation not prevalent when Public Law 99-474 was enacted. Due to their adverse impact on theintended user population, highly restrictive warning banners may not be appropriate. The choiceof which screen warning banner to implement is up to the system owner and should be based onsystem-specific technology limitations, data sensitivity, or other unique system requirements. Inthis section, describe the rationale for electing to use or not use warning banners and provide anexample of the banners used. Where appropriate, state whether the Department of Justice,Computer Crime and Intellectual Properties Section, approved the warning banner.6.WSS.3 Public Access ControlsSince all web support systems have some aspect of them that are public facing and thus availableto public access, this section should talk in detail about the safeguards to ensure that the websupport system is not use to breech the confidentiality, integrity, or availability of the generalsupport systems and major applications of the organization. For the purpose of this document aweb site, an organizational intranet that can be accessed from the Internet via a user ID, and /orextranet is considered to be public facing and have some level of public access.Some possible controls or issues to talk about in this section are: • How public users data is validated before the production data systems accept the data; • What form, if any, of identification and authentication is required for users; • How does the public “register” for access, if any is allowed; • Does the system require any encryption to perform actions and protect data; • Does the system verify data uploaded is virus- free; • Is there the ability for users to verify a downloaded file is authentic and has not be altered and is virus free (e.g. hash digests; PGP); • Are there warning banners or disclaimers; and • Are there special legal considerations for having the public having/not ha ving access.6.WSS.4 Audit TrailsMost web support systems have their own unique set of audit trails that are available to be turnedon. These audit functions can assist you in tracking user activity, tracking problems, andanalysis usage and performance of a web support system. Unlike audit trails with generalsupport systems and major applications, audit trails on a web support system that capture userinformation must be talked about in the privacy and security statement that is published on theweb support system. It is very important that your privacy statement(s) and your audit trailcontrols are coordinated so that they are in-sync with each other. Since most web supportsystems are also public facing systems, these audit trails should be reviewed frequently toidentify trends and specious behavior.Some items that should be talked about in detail in this section are: • What items does the web support system audit and record (e.g., referring URL, user IP, User ID, content page view);Revision 1 Page 34 of 35April 2003
  35. 35. • How are audit trails recorded (e.g., written to a database, written to a text file); • Who has access to the audit trails; • How often are the trails reviewed; • Does the audit trail(s) support accountability and the ability for after-the- fact investigations of how, when, and why normal operations ceased; • Can the audit trails be correlated to intrusion detection information; • How long are the audit trails maintained; • Are web support system audit logs review and coordinated with general support audit logs concerning the web support system; and • Are any audit analysis tools used in a real- time or near real-time fashion.Revision 1 Page 35 of 35April 2003

×