white paper guide for developing security plans

Revision 1 of 35 April 2003

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 2003


This document maybe freely redistributed in its entirety without alteration. It may not be sold for profit 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, this document is for educational purposes. The information provided here is for reference use only and does not constitute the rendering of professional advice or recommendations by Dana Enterprises, Inc. Copyright © 2003 Dana Enterprises, Inc. www.danaenterprises.org


Table of Contents Acknowledgements ......................................................................................................................... 5 Executive Summary........................................................................................................................ 6 1 Introduction..................................................................................................................... 7 1.1 Background ..................................................................................................................... 7 1.2 Major Application, General Support System, Web Support System Plans .................... 7 1.3 Relationship to Other NIST Security Documents........................................................... 8 1.4 Purposes of Security Plans .............................................................................................. 8 1.5 Security Plan Responsibilities......................................................................................... 9 1.6 Recommended Format .................................................................................................... 9 1.7 Advice and Comment on Plan ........................................................................................ 9 1.8 Audience ......................................................................................................................... 9 2 System Analysis ............................................................................................................ 10 2.1 System Boundaries........................................................................................................ 10 2.2 System Category........................................................................................................... 10 2.2.1 Major Applications ....................................................................................................... 11 2.2.2 General Support System................................................................................................ 12 2.2.3 Web Support System..................................................................................................... 12 3 Plan Development ......................................................................................................... 15 3.1 Plan Control .................................................................................................................. 15 3.2 System Identification .................................................................................................... 15 3.2.1 System Name/Title........................................................................................................ 15 3.2.2 Responsible Organization............................................................................................. 15 3.2.3 Information Contact(s) .................................................................................................. 15 3.2.4 Assignment of Security Responsibility......................................................................... 16 3.3 System Operational Status ............................................................................................ 16 3.4 General Description/Purpose ........................................................................................ 16 3.5 System Environment ..................................................................................................... 16 3.6 System Interconnection/Information Sharing ............................................................... 17 3.7 Sensitivity of Information Handled .............................................................................. 17 3.7.1 Laws, Regulations, and Policies Affecting the System................................................ 18 3.7.2 General Description of Sensitivity................................................................................ 18 4 Management Controls ................................................................................................... 20 4.1 Risk Assessment and Management............................................................................... 20 4.2 Review of Security Controls ......................................................................................... 20 4.3 Rules of Behavior.......................................................................................................... 21 4.4 Planning for Security in the Life Cycle ........................................................................ 21 4.4.1 Initiation Phase.............................................................................................................. 22 4.4.2 Development/Acquisition Phase ................................................................................... 22 4.4.3 Implementation Phase ................................................................................................... 22 4.4.4 Operation/Maintenance Phase....................................................................................... 23 4.4.5 Disposal Phase .............................................................................................................. 23 4.5 Authorize Processing .................................................................................................... 23 5 Operational Controls ..................................................................................................... 25 5.WSS Web Support System – Operational Controls................................................................... 26


5.WSS.1 Personnel Security ......................................................................................................... 26 5.WSS.2 Physical and Environmental Protection......................................................................... 26 5.WSS.2.1 Explanation of Physical and Environment Security................................................... 27 5.WSS.3 Production, Input/Output Controls ................................................................................ 27 5.WSS.4 Contingency Planning.................................................................................................... 28 5.WSS.5 Hardware and Software Maintenance Controls ............................................................. 28 5.WSS.6 Data Integrity/Validation Controls ................................................................................ 29 5.WSS.7 Documentation............................................................................................................... 30 5.WSS.8 Security Awareness and Training .................................................................................. 30 5.WSS.9 Incident Response Capability ........................................................................................ 31 6 Technical Controls ........................................................................................................ 32 6.WSS.1 Identification and Authentication .................................................................................. 32 6.WSS.1.1 Identification............................................................................................................... 32 6.WSS.1.2 Authentication............................................................................................................. 32 6.WSS.2 Logical Access Controls (Authorization/Access Controls) ........................................... 33 6.WSS.3 Public Access Controls .................................................................................................. 34 6.WSS.4 Audit Trails .................................................................................................................... 34


Acknowledgements I would first like to express my thanks to NIST and to Marianne Swanson who originally drafted and published NIST Special Publication (SP) 800-18, Guide for Developing Security Plans for Information Technology Systems. Without that document we would not have the current standard or guidance for creating security plans.


Executive Summary NIST Special Publication (SP) 800-18, Guide for Developing Security Plans for Information Technology Systems, has become the standard used but most all government agencies to develop security plans and the de facto standard for a number of private sector businesses. However, like Security Plans, NIST SP 800-18 needs to be reviewed from time to time to reflect changes. 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. The objective of this document is to try and provide an interpretation of NIST SP 800-18 to reflect this new system and help people classify and secure their intranets and/or extranets with customized security plans that will meet the rigor and requirements of Office of Management and Budget (OMB) Circular A-130 - Management of Federal Information Resources, Appendix III - Security of Federal Automated Information Resources, Public Law 100-235 - Computer Security 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 be present in this document as they appeared in that document. Due to the original thoroughness of NIST 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.


1 Introduction With the push for more security along with the mandate and push for federal agencies to become more accessible to citizenry, the development of federal Internet, Intranet, and Extranet portals have been on the rise. NIST SP 800-18 was put forth in 1998 to help provide federal agencies a way 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 Major Applications. The Internet as a place of commerce and business was just beginning to take off as a requirement for business and even for government. As with NIST 800-18, this document puts forth an interpretation of NIST SP 800-18 to reflect the distributed nature of today’s technology. This document provides an interpretation of the NIST SP 800-18 guideline for federal agencies to follow when developing the security plans that document the management, technical, and operational controls for federal web support systems (WSS).

1.1 Background The completion of system security plans is a requirement of the Office of Management and Budget (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-sensitive systems. Rather, consistent with the Computer Security Act of 1987, the Circular recognizes that federal automated information systems have varied sensitivity and criticality. All federal systems have some level of sensitivity and require protection as part of good management practice. The generic term “system” is used in this document to mean a major application, a general support system, or a web support system. The generic term “web support system” is used in this document to define an Internet Site, Intranet or Extrane t. NOTE: This document will only discuss the web support system in detail. Please refer to NIST SP 800-18 for information on the guidelines for major applications and general support systems.

1.2 Major Application, General Support System, Web Support System Plans All applications and systems are required to be covered by system security plans when they are categorized as a “major application” or “general support system”. While there is no debate about that, the question is what about the extranet or intranet and even possibility the Internet presence the organization has created. Are they a major application or a general support system? Web support systems (Internet sites, Intranets and Extranets) are unique in that they are a combination of both.


The blur for web support systems (WSS) is that like a major application it is dependent on a GSS to function however like a GSS the WSS maybe the support platform that a major application my be dependent on to function and deliver content. Considering the advances in web development and resources this blur has only continued to increase in that WSS’s may support there own authentication 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 a major application and a general support system. Similarly, this document tries to provide a definition of what a WSS and a test to try and help determine if an organization should develop a separate security plan for their WSS. For not all Internet Sites, Intranets, or Extranets may need to be classified as a WSS and can be covered by an existing GSS or MA plan that has been developed.

1.3 Relationship to Other NIST Security Documents This document currently has no official relationship to any other NIST Special Publication or Security Document. It is meant to help supplement NIST SP 800-18 and continue to round out the NIST triad of security guidance (NIST Special Publication 800-12, An Introduction to Computer 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 this document. There is no relationship or recognition of this document to FISMA, OMB, or any other federal regulation, law or agency charged with the oversight of federal information technology security and none should be drawn. The official NIST Special Publications and Security documents can be obtained from the NIST Computer Security Resource Clearinghouse Web site at the URL: http://csrc.nist.gov/

1.4 Purposes of Security Plans Security plans are created as part of an overall security framework and can be viewed as a road map for continuing to improve the security stance for not only the system it covers but for the entire 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.


1.5 Security Plan Responsibilities Ultimately it is the Chief Security Officer (CSO) that is responsible for the overall development of security plan(s) for an organization. However, it is the system owner that was appointed or designated by the CSO that is actually responsible for preparing, implementing, and monitoring the security plan for a given system. While the actual development, implementation, and monitoring of a system security plan maybe outsourced to a contractor, the system owner is not relived of their responsibilities as the system owner or system security officer. They are still responsible to ensure that the security plan is maintained as a living document that is reviewed periodically for modifications and completion of planned milestones and identification of new vulnerabilities. It is also important that the system owner and/or security officer is familiar with the day to day use of the system and not delegate security oversight to technical personnel that are meant to support or develop the system.

1.6 Recommended Format This document uses the same format that NIST SP 800-18 recommend when it was published in 1998. Regardless of whether the NIST SP 800-18 recommendation is used or a format developed by your organization is used, the key point is that a standardized approach to developing and maintaining security plans is used and the level of detail included is constant with criticality and importance to the organization’s mission. Additionally, the security plan should fully identify and describe the controls currently in place or planned for the system and include a unique list of rules of behavior specific to that system.

1.7 Advice and Comment on Plan No 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/or outside the organization. Inside the organization advice and comments should be sought from management, 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 before it is implemented. Outside advice is meant to be provide by individuals independent of the system owner’s reporting chain that have adequate knowledge or experience to ensure the plan contains appropriate information and meets organizational security policy and standards.

1.8 Audience This document is intended to be a supplemental guide to NIST SP 800-18 and was drafted to augment that document. This document is written for use by individuals with little or no IT security experience and for use as an auditing tool. As with the NIST document, the concepts presented here are generic and can be applied to organizations in public and private sectors.


2 System Analysis A completed security plan contains technical information about a system, security requirements, and the controls implemented to protect a system against known risks and vulnerabilities. The first step in developing a plan is determining what type of sys tem is to be done and what type of plan is required for a system. This section walks the reader through the analysis of a system to determine the boundaries of the system and the type of system.

2.1 System Boundaries System boundaries are a logical binding of processes and IT resources. The elements within this logical boundary constitute a single system requiring a security plan. For GSSs and MAs each element 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 the elements 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 management control of the LAN or Data Center operational unit. However, the actual web pages view by the web users are developed and maintained by a different group. A WSS can also have components that span multiple operating environments to provide the required services to support a WSS.

2.2 System Category System Category is where each system is determined either to be a GSS, a MA, or a WSS. All systems and applications should be covered by a security plan. In some cases applications are considered covered under the umbrella of a GSS. Major Applications have their own unique security plan that is coordinated with the security plan of the GSS that supports the MA. A WSS is similar here to a MA in that it should have its own security plan that also requires coordination with a GSS security plan.


2.2.1 Major Applications A major application is an application that because of the information contained, processed, or transmitted in combination with their criticality and importance to the organizations mission require additional management oversight. Major applications are systems that perform a clearly defined function(s) for an organization. Typically a major application is one that is used to support a specific mission-related function (e.g., accounting systems, human resources information systems, customer relation management systems). While in most cases a major application is a single software application, there are also cases where multiple individual applications that are all related to the accomplishment of a single mission function (e.g. payroll systems, customer relations/customer complaint systems). When a system is defined as a major application 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 Guidance The following guidance is designed to assist a system owner in determining if the application should be considered a Major Application. If a system owner can answer yes to the following questions 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 functional 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 make the 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 by the other organization then while the application may be considered a major application, your


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 application should take place to determine exact responsibilities for your organization. Even though your organization my not be responsible for a security plan, you still may want to develop a security plan for additional assurance of system security. Not being responsible for developing a security plan does not relive an organization of security concerns and instead require coordination of the organizations security efforts to meet or exceed those in the security plan or connection agreements for the application from the other organization.

2.2.2 General Support System A general support system is easier to define and is typically an interconnected information resources under the direct management control of a group within the organization, typically the IT 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 Network

A general support system includes hardware, software, information, data, applications, communications, facilities, and people that provides support for a variety of users and/or applications.

2.2.3 Web Support System A web support system is a hybrid of a general support system and a major application. Under NIST SP 800-18 an organization may be covering parts of their Internet sites, intranets, or extranets with their GSS security plan or major application security plan. Unfortunately this may result in security vulnerabilities not being mitigated or properly recognized. A web support system, for this document, is defined as the information technology resources providing web services. A web support system includes the web/internet service software (not the operating systems), the web content pages, and web applications. A web support system will prove to be unique in that developing a security plan for a WSS is that it will most likely require a matrix of personnel that cross departments (e.g. business units and members of the IT department) within an organization to ensure the security of a WSS.


2.2.3.1 Web Support System Determination Guidance Just as not all applications should be considered major applications, the existence of an Internet web presence, intranet, or extranet does not automatically mean that they should be considered a web support system requiring its own security plan. The following guidance is designed to assist an organization in determining if their Internet web presence, intranet, and/or extranet should be considered a web support system. If a system owner can answer yes to the following questions typical the application in question should 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 be considered 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 be considered 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 be considered 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 a


separated security plan does not mean that each system should have an independent security plan. Since these are all similar systems one consolidated security plan for all these systems can be developed and any unique differences between them discussed in the plan.


3 Plan Development The rest of this document helps guide the reader in writing a security plan for a web support system. For guidance on developing on security plans for general support systems and major applications the reader should refer to NIST SP 800-18. This document only provides guidance for a web support system security plan based on an interpretation of that publication.

3.1 Plan Control All security plans should be considered sensitive in nature and the organization should protect the document as required by the organization’s policies and not made widely available to employees or the public. Additionally, all security plans should be placed under documentation control and have revision marking and pagination information on each page to allow for updates to the plan via change pages. A security plan should begin with the following system identification sections.

3.2 System Identification The first section of the security plan should provide the basic identifying information about the system.

3.2.1 System Name/Title List the unique name your organization has given to the web support system. For individual web support systems this may be the name or URL of the intranet or extranet site. For a combined plan, a generic title maybe chosen to encompass all the web presences the organization has.

3.2.2 Responsible Organization The department or group with in the organization that is responsible should be listed here. This section should include the organization name, department or group responsible, and the physical address information. If system maintenance is out sourced, this section should also list the name and address information 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. This information should include contacts for the system owner(s), data owner(s), and GSS support contact(s). Include the name, title, physical address, phone number and e-mail address for all individuals.


3.2.4 Assignment of Security Responsibility One individual must be assigned responsibility in writing to ensure that the web support system has adequate security. This person should be knowledgeable of the system and when possible not 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 this responsibility. The person assigned this responsibility should be someone that has the ability and authority to both oversee the development and maintenance of the web support system as well as being able to interact with the IT support staff that will be maintaining the server(s) in the GSS that support the web support system(s).

3.3 System Operational Status Indicate the system’s operational status. A system can have multiple status selected, however when 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 information about the methods in place to assure that security requirements are included.

3.4 General Description/Purpose Briefly 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 the web support system should be listed and if any are part of it area designated as a major application or part of a major application. Additionally, list the name of the general support system(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 general description 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 are sufficient for the general support system to support the needs of the web support system

3.5 System Environment Briefly describe in one to three paragraphs the general description of the technical system. Any environmental 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 be restricted to information specific to the web support system, such as:


• 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 protection of the system and the information.

3.6 System Interconnection/Information Sharing System interconnection information for a web support system is any connections that the applications residing on the web support system make use of to call or process data. System interconnections that are not documented and protected for a web support system can result in these connections being compromised allowing the general support system or a major application to be compromised. OMB Circular A-130 states that there must be a written management authorization prior to interconnection. For a web support system a Memorandum of Understanding should be created for the interconnections that details the configuration of that interface. For each system interconnection/information sharing connection provide the following information:

• 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 with server authentication database(s) (e.g., Active Directory). This section does not need to include a description about the general support system that the web support system is dependent one. The system interconnection between the general support system and web support system is understood as a dependency.

3.7 Sensitivity of Information Handled Provide a description of the types of information handled by the system and an analysis of the criticality 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 one


of the major factors in risk management. The description must contain information on applicable laws, regulations, and policies affecting the system and a general description of sensitivity as discussed below.

3.7.1 Laws, Regulations, and Policies Affecting the System List any laws, regulations, or policies that establish specific requirements for confidentiality, integrity, or availability of data/information in the system. Each organization should determine what laws or regulations are applicable to the system that should to be included in the security plan. 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 be applicable.

If the system processes records subject to the Privacy Act, include the number and title of the Privacy Act system(s) of records and whether the system(s) are used for computer matching activities.

3.7.2 General Description of Sensitivity The general description of sensitivity reviews the system requirement against the need for confidentiality, integrity, and availability. In addition to this, this section should also discuss the system criticality.

3.7.2.1 System Criticality Describe the systems importance in terms of mission supportive, mission important, or mission critical.

3.7.2.2 System/Data Sensitivity Describe the system in terms of confidentiality, integrity, and availability. In addition to this, the general support system overall system sensitivity rating should be included. An example of a system/data sensitivity section appears below: Sensitivity The sensitivity rating summarizes the sensitivity areas of the system. The overall system sensitivity 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.


SENSITIVITY AREAS RATING GSS HIGH Confidentiality MEDIUM Integrity HIGH Availability HIGH

The criteria used to measure a system’s sensitivity include confidentiality, integrity, and availability. The sensitivity areas for the web support system are described below. Confidentiality - High The system contains information that requires protection from unauthorized disclosure. Integrity - Medium The system contains information, which must be protected from unauthorized, unanticipated, or unintentional modification. Availability - High The system contains information or provides services that must be available on a timely basis to meet mission requirements or to avoid substantial losses. For detailed examples and descriptions of sensitivity and rating confidentiality, integrity, and availability, please refer to section 3.7.2, General Description of Sensitive on page 15 of NIST SP 800-18.


4 Management Controls This section is where the management control measures that are in place or planned for the protection of the system should be talked about. It is important that for any measures tha t are listed as planned that a target implementation date is associated with that measure. This will allow 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 NIST Handbook.

4.1 Risk Assessment and Management Discuss the methods used to assess the nature and level of risk to the system. Discuss the current known threats, vulnerabilities, and effectiveness of current safeguards to the system. Be sure to include the date the last risk assessment was conducted and who performed the assessment. If there has not been a risk assessment conducted for the system, one should be planned and the milestone 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 for this system is know exactly what protocols and ports are being used by the system. This section will also help outline the business need for have a port open or service available on a WSS. In this 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 Controls An independent review of security controls for a system is required to be performed every three years. In this section the findings and recommendations from the last review / risk assessment should be discussed in summary fashion. This discussion should also discuss the organizations response to the findings and recommendations. If there were any findings or deficiencies that are reportable under OMB Circular A-123 they should be indicated here. For findings or recommendations that require a long-term mitigation effort that was accepted by the organization, target milestone dates for the completion of the mitigation process should also indicated in this section. While OMB Circular A-130, requires an independent review of security controls every three years, organizations should also have an internal security review process. This section should outline 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 intended but also to ensure the system continues to adjust to new security threats. For a web support system, reviewing the controls and countermeasures only every-three years exposes the system


to a high risk of vulnerability of being breeched. New vulnerabilities, attacks, and malicious code designed to exploit web support system are discovered on almost a daily basis. Given the high visibility of web support systems, at least once every six to nine months the web support system should be reviewed to ensure its security stance is as strong as possible. These six to nine month reviews should primarily be focused on the technical and operational controls of the web support system that can be conducted with tools like vulnerability scanners.

4.3 Rules of Behavior The rules of behavior for a web support system are very different from rules of behavior for either a general support system or a major application. Depending on what the web support system provides function for, an organization may not be able to have a signed signature page from a user. Additionally, as part of the rules of behavior of the web support system should also contain a privacy policy that outlines what information the web support system may collect and how 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 for access to the system either on a request for access form and on a content page readily identifiable and accessible on the web support system. Depending on the sensitivity of the web support system will determine if this content page needs to have parts of displayed as part of a warning page prior to access any content on the web support system

4.4 Planning for Security in the Life Cycle Planning for Security in the Life Cycle of a web support system is possibly more critical than with a general support system or a major application in that the web support system is publicly available on the Internet. Web support systems can also end up supporting a variety of web based applications that with different authentication and security system. The Life Cycle for a web support system should be a guidance principle that is used to unify the way the web support system 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 the


Life Cycle model chosen by the organization to cover the web support system, it will most likely consist of the five basic phased outlined below. All five phases (or how ever many phases there are in the life cycle plan adopted by your organization) should be discussed in this section regardless of what phase the web support system is currently in. The following NIST Special publications may provide the reader with additional guidance about this 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 Phase During the initiation phase, the need for a system is expressed and the purpose of the system is documented. For a web support system, the initiation phase can also be the strategic vision for the life of the web support system.

4.4.2 Development/Acquisition Phase During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. This phase may consist of other defined cycles depending on the life cycle model adopted by the organization. During this phase, security requirements should be developed at the same time system planners define the requirements of the system. These requirements may be expressed as technical features or operational practices. This phase, include a general description of any specifications that are used and how they are being maintained.

4.4.3 Implementation Phase In the implementation phase, the system’s security features are configured, enabled, and the system is installed and tested. A design review and systems test must be performed prior to placing the system into operation to assure that it meets security specifications. Once that is complete 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 new reviews or tests are performed, and maintained in the official organization records. If the system


or parts of the system are in the implementation phase, describe when and who conducted the design reviews and systems tests. Include information about additional design reviews and systems tests for any new controls added after the initial acceptance tests were completed.

4.4.4 Operation/Maintenance Phase During this phase, the system performs its work. Once in operation during the life of the system it will face modification by the addition of hardware and software and updated content pages. As the system undergoes modifications, determine which phase of the life cycle the system modifications are in and describe the security activities conducted or planned for that part of the system. For the system in the operation/maintenance phase, the security plan documents the security activities. The following high- level items should be described:

• Security Operations and Administration. • Operational Assurance. • Audits and Monitoring.

4.4.5 Disposal Phase The 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 in this 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 Processing Authorization to process is the formal acceptance of management of the risk associated with a system and allows the system to go into the production environment. In this section of the security plan information about the name and title of the management official providing the authorization to process and the date the authorization was granted. If the system has not yet been authorized to process, include the name and title of the person requesting authorization, the date 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.


NIST SP 800-37, Guidelines for the Security Certification and Accreditation of Federal Information Technology Systems may also help the reader to better understand the certification and accreditation process. Once a system is authorized to process, it should under go a process to be re-authorized prior to any major system change and at the very least every three years as part of the independent security review process.


5 Operational Controls This chapter and Chapter 6, Technical Controls, the formats and related guidance provided is for the web support system. For information on the formats and related guidance for major applications or for general support systems, please refer to NIST SP 800-18. The section numbering of these two chapters differs from the rest of the document and follows the same general numbering that was put forth in NIST SP 800-18. The chapters are numbered as 5.WSS and 6.WSS for web support system. This number system was continued from NIST SP 800-18 to allow the user to easily combine the original NIST SP 800-18 along with this documents interpretation for web support systems.


5.WSS Web Support System – Operational Controls Operational 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 operational control measures that are currently in place or measures that are currently planned to be or are in the process of being implemented along with a target implementation date.

5.WSS.1 Personnel Security Intentional and unintentional acts by individuals cause the greatest disruption to a system. Most system disruption can be traced back to the well-meaning action of an individual authorized to use 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 in place 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 Protection Physical and environmental security controls are implemented to protect the facility housing system resources, the system resources themselves, and the facilities used to support their operation. Typically, the components of the web support system reside with LAN general support system or where the data center is located. When that is the case this section becomes a reference point to the general support system that houses the web support system. However, if the web support system is housed outside the data center or server room for a general support system then you must briefly describe the physical and environmental controls in place.


5.WSS.2.1 Explanation of Physical and Environment Security In 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 physical and environmental security is handled by the data center and is covered by the LAN General Support 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 to another 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 Controls In this section, provide a synopsis of the procedures in place that support the web support system. 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.


5.WSS.4 Contingency Planning Web support systems require appropriate emergency, backup, and contingency plans. These plans should be coordinated with the general support system that supports the web support system. In the event of a failure, this contingency plan will be road map for how the web support system is restored to service. This plan maybe very simple in that it relies on a GSS Contingence Plan or have a very detailed plan separate from the GSS. When reviewing the General Support Systems plan for adequate coverage or developing a web support 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 Controls These controls are used to monitor the installation of, and updates to, the web support system to ensure that the software functions as expected and that a historical record is maintained of application changes. This helps ensure that only authorized software is installed on the system. These controls may also be termed version control, change management, or configuration Management. The following questions are examples of items that should be addressed in Responding 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;


• 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 Controls Integrity controls protect the operating system, applications, and information on the web support system from accidental or malicious alteration or destruction and to provide assurance to the user that the information has not been altered. A web support system may have its own set of controls 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 may make 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).


5.WSS.7 Documentation Documentation is a very important security control for a web support system. As there is no standard web support system configuration, the internally generated documentation is all an organization 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 support system, policies, standards, procedures, backup and contingency activities, as well as descriptions of user and operator procedures. An example list is provided to show the type of documentation that would normally be maintained for a system. The list is not intended to be all- inclusive or imply that all systems should 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 systems

5.WSS.8 Security Awareness and Training Web support systems like general support systems and major applications should have a security awareness and training program associated with it. The Computer Security Act requires federal agencies to provide training in computer security awareness. OMB Circular A-130 further enforces this requirement. The trick with web support systems is that most of them are public facing and may be used by more than just the organizations employees and/or contractors. This may require the organization to have a two-tracked security awareness and training program for a web support system: Internal Training and External Training. Internal Training Internal training is geared around security awareness and training for the organizations employees and contractors. This track may actually be combined with the general support system awareness and training program or it may be a stand-alone module that only certain personnel receive. Internal training should also have a special section to it devoted just to the


risks of web development around the environment used by the organization for the web programmers and developers. External Training External Training is geared to statements and static content pages that users of the system can view. In some cases, the organization may also find the need to make use of pop-up screens to provide this information. The external training needs to be geared toward the user population of the 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 Capability The web support system, being a public or semi-public facing system, is the front door to your organization on the Internet. All web support systems should be include in the organizations Incident Response System that is mandate by OMB Circular A-130 and that is normally supported by the general support systems of the organization. In this section, describe the incident 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.


6 Technical Controls Technical controls are the security controls that the system executes automatically. These controls can provide automated login and protection of the system that can be used to facilitate detection and investigation of security violations. While the controls themselves are technical and in most cases automated, there is still a part to these controls that require personnel to audit or monitor the output from these controls. Simply putting the controls in place and walking away 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, the ability to manage the controls by personnel within the organization, and support the needs of any web applications the web support system hosts.

6.WSS.1 Identification and Authentication Access to the web support system usually requires the system to be able identify a user and determine what rights that user has to the web support system. Depending on the web support system users maybe required to login to the system to access it or just to perform certain functions. Though some web support systems are completely public facing and don’t require any login access, the system still should be set up to support the concept of least privilege and user accountability.

6.WSS.1.1 Identification In 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 being allowed to access the system? Correlate Actions to Users: How does the system maintain the actions the users make while using the web support system. Maintenance of User IDs: An organization should ensure that all User IDs belong to currently authorized users. Identification data must be kept current by adding new users and deleting former 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 Authentication Authentication is how the system knows or validates a user is the person they claim to be. While there are many means of establishing the authenticity of a user, typically most web support system only makes use of a shared secret authentication system (e.g., password, PIN).


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 access permitted. In this section the controls in place to restrict the activities of the users of the web support 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-474 requires that a warning message be displayed; notifying unauthorized users that they have accessed a U.S. Government computer system and unauthorized use can be punished by fines or imprisonment. Some of the systems now in use are intended for unrestricted use by the general


public (e.g., Internet-based systems used for widespread public information dissemination), a situation not prevalent when Public Law 99-474 was enacted. Due to their adverse impact on the intended user population, highly restrictive warning banners may not be appropriate. The choice of which screen warning banner to implement is up to the system owner and should be based on system-specific technology limitations, data sensitivity, or other unique system requirements. In this section, describe the rationale for electing to use or not use warning banners and provide an example 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 Controls Since all web support systems have some aspect of them that are public facing and thus available to public access, this section should talk in detail about the safeguards to ensure that the web support system is not use to breech the confidentiality, integrity, or availability of the general support systems and major applications of the organization. For the purpose of this document a web site, an organizational intranet that can be accessed from the Internet via a user ID, and /or extranet 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 having access.

6.WSS.4 Audit Trails Most web support systems have their own unique set of audit trails that are available to be turned on. These audit functions can assist you in tracking user activity, tracking problems, and analysis usage and performance of a web support system. Unlike audit trails with general support systems and major applications, audit trails on a web support system that capture user information must be talked about in the privacy and security statement that is published on the web support system. It is very important that your privacy statement(s) and your audit trail controls are coordinated so that they are in-sync with each other. Since most web support systems are also public facing systems, these audit trails should be reviewed frequently to identify 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);


• 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.

white paper guide for developing security plans

Documents

general support system

system analysis

system boundaries

system category

system identification

system nametitle

system environment

web support system plans