go to NIST home page go to CSRC home page go to Focus Areas page go to Publications page go to Advisories page go to Events page go to Site Map page go to ITL home page CSRC home page link
header image with links

 CSRC Homepage
 CSRC Site Map

   Search CSRC:

 CSD Publications:
   - Draft Publications
   - Special Publications
   - FIPS Pubs
   - ITL Security Bulletins
   - NIST IRs

 CSD Focus Areas:
   - Cryptographic Standards
       & Application
   - Security Testing
   - Security Research /
       Emerging Technologies
   - Security Management
       & Guidance

 General Information:
   - Site Map
   - List of Acronyms
   - Archived Projects
        & Conferences
   - Virus Information
   - ICAT Alerts

 News & Events  
   - Federal News
   - Security Events

 Services For the: 
   - Federal Community
   - Vendor
   - User

 Links & Organizations
   - Academic
   - Government
   - Professional
   - Additional Links

 Search NIST's ICAT
 Vulnerability Archive:
   Enter vendor, software, or keyword

ITL Security Bulletins header image  

APRIL 1999

Guide For Developing Security Plans For Information Technology Systems

Today’s rapidly changing technical environment requires federal agencies to adopt a minimum set of management controls to protect vital information technology (IT) resources. These management controls are directed at individual IT users in order to reflect the distributed nature of today’s technology. Technical and operational controls support management controls. To be effective, all of these controls must interrelate.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology recently published Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems. Developed by Marianne Swanson and a working group of the Federal Computer Security Program Managers’ Forum, the publication addresses the development of security plans that document the management, technical, and operational controls for federal automated information systems. The publication provides guidance for individuals responsible for IT security at the system level and at the organization level. It is written specifically for individuals with little or no computer security expertise. The document can also be used as an auditing tool by auditors, managers, and IT security officers. The concepts presented are generic and can be applied to organizations in private and public sectors. This ITL Bulletin summarizes the purpose, responsibilities, format, and development of an effective security plan (the guide provides detailed information).

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, and of Public Law 100-235, "Computer Security Act of 1987." 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. OMB Bulletin 90-08, dated July 9, 1990, which provided initial security planning guidance, is superseded by the issuance of Special Publication 800-18. The generic term "system" is used in the document to mean either a major application or a general support system.

Major Application or General Support System Plans
All applications and systems must be covered by system security plans if they are categorized as a "major application" or "general support system". Specific security plans for other applications are not required because the security controls for those applications or systems would be provided by the general support systems in which they operate. For example, a department-wide Financial Management System would be a major application requiring its own security plan. A local program designed to track expenditures against an office budget might not be considered a major application and would be covered by a general support system security plan for an office automation system or a local area network (LAN). Standard commercial off-the-shelf software (such as word processing software, electronic mail software, utility software, or other general- purpose software) would not typically be considered a major application and would be covered by the plans for the general support system on which they are installed.

Purposes of System Security Plans

  • Provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements; and
  • Delineate responsibilities and expected behavior of all individuals who access the system.

Security Plan Responsibilities
The system owner is responsible for ensuring that the security plan is prepared and for implementing the plan and monitoring its effectiveness. Security plans should reflect input from various individuals with responsibilities concerning the system, including functional "end users," information owners, the system administrator, and the system security manager.

Agencies may require contractor compliance with the guide as a contract requirement. A security plan in the format specified in the document or in another agreed-upon format is suggested in those cases where vendors are operating a system under contract to the federal government. In those instances where a contractor or other entity (e.g., state or local government) operates a system that supports a federal function, a security plan is required.

OMB Circular A-130 requires a summary of the security plan to be incorporated into the strategic IRM plan required by the Paperwork Reduction Act (44 U.S.C. Chapter 35).

Agencies should develop policy on the security planning process. Security plans are living documents that require periodic reviews, modifications, and milestone or completion dates for planned controls. Procedures should be in place outlining who reviews the plans and follows up on planned controls. In addition, procedures are needed describing how security plans will be used in the authorization for processing process.

Recommended Format
While the format in Special Publication 800-18 is recommended, it is recognized that some agencies have developed plans using other formats that meet A-130 requirements. The document is intended as guidance only and should not be construed as the only format allowed. A standardized approach, however, not only makes the development of the plan easier by providing examples, but also provides a baseline to review plans. The level of detail included within the plan should be consistent with the criticality and value of the system to the organization’s mission (i.e., a more detailed plan is required for systems critical to the organization’s mission). The security plan should fully identify and describe the controls currently in place or planned for the system and should include a list of rules of behavior (see Appendices A and B of the document).

System Analysis
Once completed, a security plan will contain technical information about the system, its security requirements, and the controls implemented to provide protection against its risks and vulnerabilities. Before the plan can be developed, a determination must be made as to which type of plan is required for a system. An analysis of the system determines the boundaries of the system and the type of system.

System Boundaries Defining what constitutes a "system" for the purposes of the guideline requires an analysis of system boundaries and organizational responsibilities. Constructing logical boundaries around a set of processes, communications, storage, and related resources, as defined by the guideline, identifies a system. The elements within these boundaries constitute a single system requiring a security plan. Each element of the system must:

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

All components of a system need not be physically connected (e.g., a group of stand-alone personal computers (PCs) in an office; a group of PCs placed in employees’ homes under defined telecommuting program rules; a group of portable PCs provided to employees who require mobile computing capability for their jobs; and a system with multiple identical configurations that are installed in locations with the same environmental and physical safeguards).

Multiple Similar Systems An organization may have systems that differ only in the responsible organization or the physical environment in which they are located (e.g., air traffic control systems). In such instances, it is appropriate and recommended to use plans that are identical except for those areas of difference. This approach provides consistent levels of protection for similar systems.

System Category
The next step is to categorize each system as either a "major application" or as a "general support system." All applications should be covered by a security plan. The applications will either be covered individually if they have been designated as a major application or within the security plan of a general support system. A system may be designated as a major application even though it is also supported by a system that has been designated as a general support system. For example, a LAN may be designated a general support system and have a security plan. The organization’s accounting system may be designated as a major application even though the computing and communication resources of the LAN support it. In this example, the major application requires additional security requirements due to the sensitivity of the information the application processes. When a security plan is required for a major application that is supported by a general support system, coordination of both plans is required.

Major Applications
All federal applications have value and require some level of protection. Certain applications, because of the information they contain, process, or transmit or because of their criticality to the organization’s missions, require special management oversight. These applications are major applications.

Agencies are expected to exercise management judgment in determining which of their applications is a major application and to ensure that the security requirements of non-major applications are discussed as part of the security plan for the applicable general support systems.

Major applications are systems that perform clearly defined functions for which there are readily identifiable security considerations and needs (e.g., an electronic funds transfer system). A major application might comprise many individual programs and hardware, software, and telecommunications components. These components can be a single software application or a combination of hardware/software focused on supporting a specific mission-related function. A major application may also consist of multiple individual applications if all are related to a single mission function (e.g., payroll or personnel). If a system is defined as a major application and the application is run on another organization's general support system:

  • Notify the system owner that the application is critical or contains sensitive information and provide specific security requirements;
  • Provide a copy of the major application’s security plan to the operator of the general support system;
  • Request a copy of the system security plan of the general support system and ensure it provides adequate protection for the application and information; and
  • Include a reference to the general support system security plan, including the unique name/identifier information.

General Support System
A general support system is interconnected information resources under the same direct management control that shares common functionality. A general support system normally includes hardware, software, information, data, applications, communications, facilities, and people and provides support for a variety of users and/or applications. A general support system, for example, can be a:

  • LAN including smart terminals that supports a branch office;
  • Backbone (e.g., agency-wide);
  • Communications network;
  • Departmental data processing center including its operating system and utilities;
  • Tactical radio network; or
  • Shared information processing service organization.

A major application can run on a general support system. The general support system plan should reference the major application plan(s).

Plan Development for All Systems
All security plans, at a minimum, should be marked, handled, and controlled to the level of sensitivity determined by organizational policy. In addition, all security plans should be dated for ease of tracking modifications and approvals. Dating each page of a security plan may be appropriate if updates are to be made through change pages. Both types of plans must contain general descriptive information regarding who is responsible for the system, the purpose of the system, and the sensitivity level of the system.

System Identification
System Name/Title
The plan begins with listing the name and title of the system/application. Each system/application should be assigned a unique name/identifier. Assigning a unique identifier to each system helps to ensure that appropriate security requirements are met based on the unique requirements for the system, and that allocated resources are appropriately applied. Further, the use of unique system identifiers is integral to the IT system investment models and analyses established under the requirements of the Information Technology Management Reform Act of 1996 (also known as the Clinger-Cohen Act). The identifier could be a combination of alphabetic and numeric characters and can be used in combination with the system/application name. The unique name/identifier should remain the same throughout the life of the system to allow the organization to track completion of security requirements over time.

Responsible Organization
List the federal organizational sub-component responsible for the system. If a state or local government or contractor performs the function, identify both the federal and other organization and describe the relationship. Be specific about the organization and do not abbreviate. Include physical locations and addresses.

Information Contact(s)
List the name, title, organization, and telephone number of one or more persons designated to be the point(s) of contact for this system. One of the contacts given should be identified as the system owner. The designated persons should have sufficient knowledge of the system to be able to provide additional information or points of contact, as needed.

Assignment of Security Responsibility
An individual must be assigned responsibility in writing to ensure that the application or general support system has adequate security. To be effective, this individual must be knowledgeable of the management, operational, and technical controls used to protect the system. Include the name, title, and telephone number of the individual who has been assigned responsibility for the security of the system.

System Operational Status
Indicate one or more of the following for the system’s operational status. If more than one status is selected, list which part of the system is covered under each status.

  • 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 used to assure that up-front security requirements are included. Include specific controls in the appropriate sections of the plan depending on where the system is in the security life cycle.

General Description/Purpose
Present a brief description (one-three paragraphs) of the function and purpose of the system (e.g., economic indicator, network support for an organization, business census data analysis, crop-reporting support).

If the system is a general support system, list all applications supported by the general support system. Specify if the application is or is not a major application and include unique name/identifiers, where applicable. Describe each application's function and the information processed. 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. Request information from the application owners (and a copy of the security plans for major applications) to ensure their requirements are met.

System Environment
Provide a brief (one-three paragraphs) general description of the technical system. Include any environmental or technical factors that raise special security concerns, such as:

  • The system is connected to the Internet;
  • It is located in a harsh or overseas environment;
  • Software is rapidly implemented;
  • The software resides on an open network used by the general public or with overseas access;
  • The application is processed at a facility outside of the organization's control; or
  • The general support mainframe has dial-up lines.

Describe the primary computing platform(s) used (e.g., mainframe, desk top, LAN or Wide Area Network (WAN). Include a general description of the principal system components, including hardware, software, and communications resources. Discuss the type of communications included (e.g., dedicated circuits, dial circuits, public data/voice networks, Internet). Describe controls used to protect communication lines in the appropriate sections of the security plan.

Include any security software protecting the system and information. Describe in general terms the type of security protection provided (e.g., access control to the computing platform and stored files at the operating system level or access to data records within an application). Include only controls that have been implemented or are planned, rather than listing the controls that are available in the software. Controls that are available, but not implemented, provide no protection.

System Interconnection/Information Sharing

System interconnection is the direct connection of systems for the purpose of sharing information resources. System interconnection, if not appropriately protected, may result in a compromise of all connected systems and the data they store, process, or transmit. It is important that system operators, information owners, and management obtain as much information as possible about the vulnerabilities associated with system interconnection and information sharing and the increased controls required to mitigate those vulnerabilities. The security plan for the systems often serves as a mechanism to effect this security information exchange and allows management to make informed decisions regarding risk reduction and acceptance.

OMB Circular A-130 requires that written management authorization (often in the form of a Memorandum of Understanding or Agreement) be obtained prior to connecting with other systems and/or sharing sensitive data/information. The written authorization shall detail the rules of behavior and controls that must be maintained by the interconnecting systems. A description of the rules for interconnecting systems and for protecting shared data must be included with this security plan.

In this section, provide the following information concerning the authorization for the connection to other systems or the sharing of information:

  • List of interconnected systems (including Internet);
  • Unique system identifiers, if appropriate;
  • Name of system(s);
  • Organization owning the other system(s);
  • Type of interconnection (TCP/IP, Dial, SNA, etc.);
  • Short discussion of major concerns or considerations in determining interconnection;
  • Name and title of authorizing management official(s);
  • Date of authorization;
  • System of Record, if applicable (Privacy Act data);
  • Sensitivity level of each system;
  • Interaction among systems; and
  • Security concerns and Rules of Behavior (see Appendices A and B of the guide) of the other systems that need to be considered in the protection of this system.

Sensitivity of Information Handled
This section provides 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 will provide information to a variety of users, including:

  • Analysts/programmers who will use it to help design appropriate security controls;
  • Internal and external auditors evaluating system security measures; and
  • Managers making decisions about the reasonableness of security countermeasures.

The nature of the information sensitivity and criticality must be described in this section. The description must contain information on applicable laws, regulations, and policies affecting the system and a general description of sensitivity.

The remainder of the guidance document details the management, operational, and technical controls, discussed for both major applications and general support systems. Appendices include Rules of Behavior, templates for security plans, a glossary, references, and an index.

For more information
The planning guideline is available for download in Microsoft Word ‘97 (.doc) and Adobe Acrobat (.pdf) formats. Paper copies can be ordered from the Government Printing Office at (202) 512-1800; the order number is SN003-003-03590-4 and the price is $14.00. Paper copies are also available from the National Technical Information Service (NTIS) at (703) 605-6000; order number is PB99-105116.

To Top

Last updated: February 21, 2003 ->
Page created: April 29, 1999

Disclaimer Notice & Privacy Statement / Security Notice
Send comments or suggestions to webmaster-csrc@nist.gov
NIST is an Agency of the U.S. Commerce Department's
Technology Administration