Document System Security Plan

System Name and Identifier (Title)

The first item listed in the system security plan is the system name and identifier. As required in OMB Circular A-11, each system should be assigned a name and unique identifier. Assignment of a unique identifier supports the agency’s ability to easily collect agency information and security metrics specific to the system as well as facilitate complete traceability to all requirements related to system implementation and performance. This identifier should remain the same throughout the life of the system and be retained in audit logs related to system use.

The System Security Plan provides an overview of the security requirements for the information system and describes the controls in place or planned for implementation to provide a level of security appropriate for the information to be transmitted, processed or stored by the system. Information security is an asset vital to our critical infrastructure and its effective performance and protection is a key component of our national security program. Proper management of information technology systems is essential to ensure the confidentiality, integrity and availability of the data transmitted, processed or stored by the information system.

The security safeguards implemented for the information system meet the policy and control requirements set forth in this System Security Plan. All systems are subject to monitoring consistent with applicable laws, regulations, agency policies, procedures and practices.

Information System Categorization

Each system identified in the agency’s system inventory must be categorized using FIPS 199. NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, provides implementation guidance in completing this activity.

The overall information system sensitivity categorization is noted in this section.

Information Types

This section describes how the information types used by the information system are categorized for confidentiality, integrity, and availability sensitivity levels.

The section identifies the information types that are input, stored, processed, and/or output from the information system. The selection of the information types is based on guidance provided by OMB Federal Enterprise Architecture Program Management Office Business Reference Model 2.0, and FIPS Pub 199, Standards for Security Categorization of Federal Information and Information Systems which is based on NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories.

The section also identifies the security impact levels for the confidentiality, integrity, and availability for each of the information types expressed as low, moderate, or high. The security impact levels are based on the potential impact definitions for each of the security objectives (i.e., confidentiality, integrity, and availability) discussed in NIST SP 800-60 and FIPS Pub 199.

The potential impact is low if—

- The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

- A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.

The potential impact is moderate if—

- The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

- A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.

The potential impact is high if—

- The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

- A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.

Instruction: Record your information types in the table. Record the sensitivity level for Confidentiality, Integrity, and Availability as High, Moderate, or Low.  Use NIST SP 800-60 Guide for Mapping Types of Information and Systems to Security Categories, Volumes I & II, Revision 1 for guidance. 

NOTE: The information types found in NIST SP 800-60, Volumes I and II Revision 1 are the same information types found in the Federal Enterprise Architecture (FEA) Consolidated Reference Model.

Security Objectives Categorization (FIPS 199)

Based on the information provided in Information Types, default to the high-water mark for the noted Information Types.

NOTE: Refer to FIPS PUB 199 Standards for Security Categorization of Federal Information and Information Systems.

Through review and analysis the baseline security categorization for the information system is determined.

Using this categorization, in conjunction with the risk assessment and any unique security requirements, the security controls for the information system are detailed in this SSP.

E-Authentication Determination (E-Auth)

The information system e-Authentication Determination.

NOTE: Refer to OMB Memo M-04-04 E-Authentication Guidance for Federal Agencies for more information on e-Authentication.

Information System Owner

A designated system owner must be identified in the system security plan for each system. This person is the key point of contact (POC) for the system and is responsible for coordinating system development life cycle (SDLC) activities specific to the system. It is important that this person have expert knowledge of the system capabilities and functionality. The assignment of a system owner should be documented in writing and the plan should include the following contact information:

• Name
• Title
• Company/Organization
• Address
• Phone Number
• Email Address

Authorizing Official

An authorizing official must be identified in the system security plan for each system. This person is the senior management official who has the authority to authorize operation (accredit) of an information system (major application or general support system) and accept the residual risk associated with the system. The assignment of the authorizing official should be in writing, and the plan must include the  contact information.

The Authorizing Official (AO) or Designated Approving Authority (DAA) for this information system is the Federal Risk Authorization Management Program (FedRAMP), Joint Authorization Board (JAB) as comprised of member representatives from the General Services Administration (GSA), Department of Defense (DOD) and Department of Homeland Security (DHS).

Other Information System Designated Contacts

This section should include names of other key contact personnel who possess in-depth knowledge of this system and/or its functions and operation. The same information listed for the Information System Owner should be included for each person listed under this section.

Assignment of Security Responsibility

Within an agency, an individual must be assigned responsibility for each system. This can be accomplished in many ways. In some agencies, the overall responsibility may be delegated to the SAISO. Often, the SAISO is supported by a subnet of security officers assigned to each major component. These security officers may be authorized to address the security requirements for all systems within their domain of authority. Other models may segment this responsibility in other ways based on agency structure and responsibility. The same information listed for the Information System Owner should be included for each person listed under this section.

The individual(s) identified in this section have been appointed in writing and are deemed to have significant cyber and operational role responsibilities (i.e. ISSO or ISSM or equivalent).

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

Information System Type

The information makes use of unique managed service provider architecture layer(s).

In this section of the plan, indicate whether the system is a major application or general support system. If the system contains minor applications, describe them in the General Description/Purpose section of the plan.

Cloud Service Model

Information systems, particularly those based on cloud architecture models, are made up of different service layers. The layers of the information that are defined in the SSP, and are not leveraged by any other Provisional Authorizations, are indicated in the table that follows.

• Software as a Service (SaaS) = Major Application
• Platform as a Service (PaaS) = Major Application
• Infrastructure as a Service (IaaS) = General Support System Application

Note: Please refer to NIST SP 800-145 for information on cloud computing architecture models.

Leveraged Provisional Authorizations

Instruction: The FedRAMP program qualifies different service layers for Provisional Authorizations. One, or multiple service layers, can be qualified in one System Security Plan. See the section on Use Cases in Guide to Understanding FedRAMP for more information.  If a lower level layer has been granted a Provisional Authorization, and another higher level layer represented by this SSP plans to leverage a lower layer’s Provisional Authorization, this System Security Plan must clearly state that intention. If an information system does not leverage any pre-existing Provisional Authorizations, write “None” in the first column of the table.

The information either plans to or does not plan to leverage a pre-existing Provisional Authorization. Provisional Authorizations leveraged by the information system are noted in this section.

General System Description

This section includes a general description of the information system.

System Function and Purpose

Prepare a brief description (one to three paragraphs) of the function and purpose of the system (e.g., economic indicator, network support for an agency, business census data analysis, crop reporting support).

Information System Components and Boundaries

Describe the information system’s major components, inter-connections, etc. in sufficient detail that accurately depicts the authorization boundary for the information system. Formal names of components as they are known at the service provider organization in functional specs, configuration guides, other documents, and in live configurations should be named here and described.

Instruction: In this section describe the information system’s major components, inter-connections, and boundaries in sufficient detail that accurately depicts the authorization boundary for the information system. Formal names of components as they are known at the service provider organization in functional specs, configuration guides, other documents, and live configurations should be named here and described. Please ensure that the discussion on boundaries is consistent with the network diagram shown in Section 3.11.  Please see Guide to Understanding FedRAMP for more information.

Types of Users

All users have their employee status categorized with a sensitivity level in accordance with PS-2. Employees (or contractors) of service providers are considered Internal Users. All other users are considered External Users. User privileges (authorization permission after authentication takes place) are described.

Note: User roles typically align with Active Directory, LDAP, Role-based Access Controls (RBAC), NIS and UNIX groups, and/or UNIX netgroups.

Network Architecture

Instruction: Insert a network architectural diagram. Ensure that the following items are labeled on the diagram: hostnames, DNS servers, authentication and access control servers, directory servers,  firewalls, routers, switches, database servers, major applications, Internet connectivity providers, telecom circuit numbers, and  network numbers/VLANs. 

System Environment

Instruction: In this section provide a general description of the technical system environment. Include information about all system environments that are used, e.g. production environment, test environment, staging or QA environments.

Hardware Inventory

Instruction: Please include server hardware and any major storage components in this section. If the service offering does not include hardware because you are leveraging all hardware from a pre-existing Provisional Authorization, write “None”.

Note:  A complete and detailed list of the system hardware and software inventory is required per NIST SP 800-53, Rev 3 CM-2.

Software Inventory

Instruction: Please include any middleware, databases, or secure file transfer applications in this section.

Network Inventory

Instruction: Please include any switches, routers, hubs, and firewalls that play a role in protecting the information system, or that enable the network to function properly. If all network devices and components are leveraged from a pre-existing Provisional Authorization, write “Leveraged”.

Data Flows

Instruction: In the section describe the flow of data in and out of system boundaries and insert a data flow diagram. See Guide to Understanding FedRAMP for a dataflow example.

Ports Protocols and Services

The section lists the Ports, Protocols, and Services enabled in this information system. TCP ports are indicated with a T and UDP ports are indicated with a U.

Instruction: In this section please indicate the components of the information system that make use of the ports, protocols, and services. In the column labeled “Purpose” indicate the purpose for the service (e.g. system logging, HTTP redirector, load balancing).  This table should be consistent with CM-6 and CM-7. You section must be completed even if you are leveraging a pre-existing Provisional Authorization.

System Interconnection

System interconnection is the direct connection of two or more IT 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 owners, information owners, and management obtain as much information as possible regarding vulnerabilities associated with system interconnections and information sharing. This is essential to selecting the appropriate controls required to mitigate those vulnerabilities. An Interconnection Security Agreement (ISA), Memorandum of Understanding (MOU), or Memorandum of Agreement (MOA) is needed between systems (not between workstations/desktops or publicly accessed systems) that share data that are owned or operated by different organizations. An ISA is not needed with internal agency systems if an agency manages and enforces a rigid system development life cycle, which requires approvals and sign-offs ensuring compliance with security requirements. For additional information on interconnections, see NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems.

List interconnected systems and system identifiers (if appropriate), provide the system name, organization, system type (major application or general support system), indicate if there is an ISA/MOU/SLA on file, date of agreement to interconnect, FIPS 199 category, C&A status, and the name of the authorizing official.

In this section, for each interconnection between systems that are owned or operated by different organizations, provide the following information concerning the authorization for the connection to other systems or the sharing of information:

• Name of system;
• Organization;
• Type of interconnection (Internet, Dial-Up, etc.);
• Authorizations for interconnection (MOU/MOA, ISA);
• Date of agreement;
• FIPS 199 Category;
• Certification and accreditation status of system; and
• Name and title of authorizing official(s).

Instruction: List all interconnected systems. Provide the IP address and interface identifier (ie0, ie1, ie2) for the CSP system that provides the connection. Name the external organization and the IP address of the external system. Indicate how the connection is being secured. For Connection Security indicate how the connection is being secured. For Data Direction, indicate which direction the packets are flowing. For Information Being Transmitted, describe what type of data is being transmitted. If a dedicated telecom line is used, indicate the circuit number. This section should be consistent with CA-3.

Applicable Laws and Regulations

List any laws, regulations, or policies that establish specific requirements for confidentiality, integrity, or availability of the system and information retained by, transmitted by, or processed by the system. General agency security requirements need not be listed since they mandate security for all systems. Each agency should decide on the level of laws, regulations, and policies to include in the system security plan. Examples might include the Privacy Act of 1974 or a specific statute or regulation concerning the information processed (e.g., tax or census information). 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.

Applicable Laws and Regulations

• Computer Fraud and Abuse Act [PL 99-474, 18 USC 1030]
• E-Authentication Guidance for Federal Agencies [OMB M-04-04]
• Federal Information Security Management Act (FISMA) of 2002 [Title III, PL 107-347]
• Federal Information Resources Management Regulation [41 CFR C 201]
• Freedom of Information Act As Amended in 2002 [PL 104-232, 5 USC 552]
• Guidance on Inter-Agency Sharing of Personal Data – Protecting Personal Privacy [OMB M-01-05]
• Homeland Security Presidential Directive-7, Critical Infrastructure Identification, Prioritization, and Protection [HSPD-7]
• Internal Control Systems [OMB Circular A-123]
• Management of Federal Information Resources [OMB Circular A-130]
• Management’s Responsibility for Internal Control [OMB Circular A-123, Revised 12/21/2004]
• Privacy Act of 1974 as amended [5 USC 552a]
• Protection of Sensitive Agency Information [OMB M-06-16]
• Records Management by Federal Agencies [44 USC 31]
• Responsibilities for the Maintenance of Records About Individuals by Federal Agencies [OMB Circular A-108, as amended]
• Security of Federal Automated Information Systems [OMB Circular A-130, Appendix III]

Applicable Standards and Guidance

• A NIST Definition of Cloud Computing [NIST SP 800-145]
• Computer Security Incident Handling Guide [NIST SP 800—61, Revision 1]
• Contingency Planning Guide for Federal Information Systems [NIST SP 800-34, Revision 1]
• Engineering Principles for Information Technology Security (A Baseline for Achieving Security) [NIST SP 800-27, Revision A]
• Guide for Assessing the Security Controls in Federal Information Systems [NIST SP 800-53A]
• Guide for Developing Security Plans for Federal Information Systems [NIST SP 800-18, Revision 1]
• Guide for Developing the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach [NIST SP 800-37, Revision 1]
• Guide for Mapping Types of Information and Information Systems to Security Categories [NISP SP 800-60, Revision 1]
• Guide for Security-Focused Configuration Management of Information Systems [NIST SP 800-128]
• Information Security Continuous Monitoring for Federal Information Systems and Organizations [NIST SP 800-137]
• Minimum Security Requirements for Federal Information and Information Systems [FIPS Publication 200]
• Personal Identity Verification (PIV) of Federal Employees and Contractors [FIPS Publication 201-1]
• Recommended Security Controls for Federal Information Systems [NIST SP 800-53, Revision 3]
• Risk Management Guide for Information Technology Systems [NIST SP 800-30]
• Security Considerations in the System Development Life Cycle [NIST SP 800-64, Revision 2]
• Security Requirements for Cryptographic Modules [FIPS Publication 140-2]
• Standards for Security Categorization of Federal Information and Information Systems [FIPS Publication 199]
• Technical Guide to Information Security Testing and Assessment [NIST SP 800-115]

In preparation for documenting how the NIST SP 800-53 security controls for the applicable security control baseline (low-, moderate-, or high impact information systems) are implemented or planned to be implemented, the security controls contained in the baseline should be reviewed and possibly tailored. The scoping guidelines explained in Section 2.5.1 should be used when determining the applicability or tailoring of individual controls. Additionally the controls that are common among numerous systems or within the whole agency should be identified and then documented in the plan. The process of selecting the appropriate security controls and applying the scoping guidelines to achieve adequate security17 is a multifaceted, risk-based activity involving management and operational personnel within the agency and should be conducted before the security control portion of the plan is written.

• For low-impact information systems, an agency must, as a minimum, employ the security controls from the low baseline of security controls defined in NIST SP 800-53 and must ensure that the minimum assurance requirements associated with the low baseline are satisfied.
• For moderate-impact information systems, an agency must, as a minimum, employ the security controls from the moderate baseline of security controls defined in NIST SP 800-53 and must ensure that the minimum assurance requirements associated with the moderate baseline are satisfied.
• For high-impact information systems, an agency must, as a minimum, employ the security controls from the high baseline of security controls defined in NIST SP 800-53 and must ensure that the minimum assurance requirements associated with the high baseline are satisfied.

Minimum Security Controls

Security controls must meet minimum security control baseline requirements. There are security control baseline requirements for management controls, operational controls, and technical controls.

Management security controls identify the management safeguards and countermeasures in-place or planned for the information system. Management Controls are those safeguards and countermeasures that focus on the management of risk and the management of the information security system. They are actions that are performed primarily to support information system security management decisions.

Operational security controls identify the operational safeguards and countermeasures in-place or planned for the information system. Operational controls are those safeguards and countermeasures that are primarily implemented and executed by people as opposed to systems and technology.

Technical security controls identify the technical safeguards and countermeasures in-place or planned for the information system. Technical Controls are those safeguards and countermeasures that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. Upon categorizing a system as Low, Moderate, or High sensitivity in accordance with FIPS 199, the appropriate security control baseline standards are applied. Some of the control baselines have enhanced controls which are indicated in parenthesis.

Security controls that are representative of the sensitivity of the information systems are described in this section. Security controls that are designated as “Not Selected” or “Withdrawn by NIST” are not described unless they have additional FedRAMP controls. Guidance on how to describe the implemented standard can be found in NIST 800-53, Rev 3.

Systems that are categorized as FIPS 199 Low use the controls designated as Low and systems categorized as FIPS 199 Moderate use the controls designated as Moderate. A summary of which security standards pertain to which sensitivity level is found in the table that follows. If a security control has an additional requirement for FedRAMP that is above and beyond the NIST 800-53, Rev 3 standard, the additional requirement.

Instruction: In this sections describe the information security control as it is implemented on your system. All controls originate from a system or from a business process. It is important to describe where the control originates from so that it is clear whose responsibility it is to implement, manage, and monitor the control. In some cases, the responsibility is shared by a CSP and by the customer. Use the definitions that follows to indicate where each security control originates from. Note that -1 Controls (AC-1, AU-1, SC-1 etc.) cannot be inherited and must be provided in some way by the service provider.

• Service Provider Corporate – A control that originates from the CSP corporate network.
• Service Provider System Specific – A control specific to a particular system at the CSP and the control is not part of the standard corporate controls.
• Service Provider Hybrid – A control that makes use of both corporate controls and additional controls specific to a particular system at the CSP.
• Configured by Customer – A control where the customer needs to apply a configuration in order to meet the control requirement.
• Provided by Customer – A control where the customer needs to provide additional hardware or software in order to meet the control requirement.
• Shared – A control that is managed and implemented partially by the CSP and partially by the customer.
• Inherited from pre-existing Provisional Authorization – A control that is inherited from  another CSP system that has already received a Provisional Authorization.

Once the information system security plan is developed, it is important to periodically assess the plan, review any change in system status, functionality, design, etc., and ensure that the plan continues to reflect the correct information about the system. This documentation and its correctness are critical for system certification activity. All plans should be reviewed and updated, if appropriate, at least annually. Some items to include in the review are:

• Change in information system owner;
• Change in information security representative;
• Change in system architecture;
• Change in system status;
• Additions/deletions of system interconnections;
• Change in system scope;
• Change in authorizing official; and
• Change in certification and accreditation status.

This document describes the CSP’s Information Security Policy that governs the system described in the SSP.

This document describes how leveraging agencies use the system.

This template will be used to indicate if E-Authentication will be used in the cloud system and defines the required authentication level (1-4) in terms of the consequences of the authentication errors and misuse of credentials. Authentication technology is selected based on the required assurance level.

PTA – This questionnaire is used to help determine if a Privacy Impact Assessment is required.

PIA – This document assesses what Personally Identifiable Information (PII) is captured and if it is being properly safeguarded. This deliverable is not always necessary.

This document is used to define the rules that describe the system user’s responsibilities and expected behavior with regard to information and information system usage and access.

This document is used to define and test interim measures to recover information system services after a disruption. The ability to prove that system data can be routinely backed up and restored within agency specified parameters is necessary to limit the effects of any disaster and the subsequent recovery efforts.

This plan describes how changes to the system are managed and tracked. The Configuration Management Plan should be consistent with NIST SP 800-128.

This plan documents how incidents are detected, reported, and escalated and should include timeframes, points of contact, and how incidents are handled and remediated. The Incident Response Plan should be consistent with NIST Special Publication 800-61.

This document summarizes the control ownership and indicates which controls are owned and managed by the CSP and which controls are owned and managed by the leveraging agency.