PL-2 System Security Plan (L) (M) (H)

NIST 800-53 (r4) Control:

The organization:

a. Develops a security plan for the information system that:

1. Is consistent with the organization’s enterprise architecture;

2. Explicitly defines the authorization boundary for the system;

3. Describes the operational context of the information system in terms of missions and business processes;

4. Provides the security categorization of the information system including supporting rationale;

5. Describes the operational environment for the information system and relationships with or connections to other information systems;

6. Provides an overview of the security requirements for the system;

7. Identifies any relevant overlays, if applicable;

8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions; and

9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;

b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];

c. Reviews the security plan for the information system [FedRAMP Assignment: (L)(M)(H) at least annually];

d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and

e. Protects the security plan from unauthorized disclosure and modification.

NIST 800-53 (r4) Supplemental Guidance:

Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays.

Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17.

References: NIST Special Publication 800-18.

NIST 800-53 (r5) Discussion:

System security and privacy plans are scoped to the system and system components within the defined authorization boundary and contain an overview of the security and privacy requirements for the system and the controls selected to satisfy the requirements. The plans describe the intended application of each selected control in the context of the system with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control. The control documentation describes how system-specific and hybrid controls are implemented and the plans and expectations regarding the functionality of the system. System security and privacy plans can also be used in the design and development of systems in support of life cycle-based security and privacy engineering processes. System security and privacy plans are living documents that are updated and adapted throughout the system development life cycle (e.g., during capability determination, analysis of alternatives, requests for proposal, and design reviews). Section 2.1 describes the different types of requirements that are relevant to organizations during the system development life cycle and the relationship between requirements and controls.

Organizations may develop a single, integrated security and privacy plan or maintain separate plans. Security and privacy plans relate security and privacy requirements to a set of controls and control enhancements. The plans describe how the controls and control enhancements meet the security and privacy requirements but do not provide detailed, technical descriptions of the design or implementation of the controls and control enhancements. Security and privacy plans contain sufficient information (including specifications of control parameter values for selection and assignment operations explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented.

Security and privacy plans need not be single documents. The plans can be a collection of various documents, including documents that already exist. Effective security and privacy plans make extensive use of references to policies, procedures, and additional documents, including design and implementation specifications where more detailed information can be obtained. The use of references helps reduce the documentation associated with security and privacy programs and maintains the security- and privacy-related information in other established management and operational areas, including enterprise architecture, system development life cycle, systems engineering, and acquisition. Security and privacy plans need not contain detailed contingency plan or incident response plan information but can instead provide—explicitly or by reference—sufficient information to define what needs to be accomplished by those plans.

Security- and privacy-related activities that may require coordination and planning with other individuals or groups within the organization include assessments, audits, inspections, hardware and software maintenance, acquisition and supply chain risk management, patch management, and contingency plan testing. Planning and coordination include emergency and nonemergency (i.e., planned or non-urgent unplanned) situations. The process defined by organizations to plan and coordinate security- and privacy-related activities can also be included in other documents, as appropriate.

38North Guidance:

Meets Minimum Requirement:

• The organization maintains a complete system security plan, as required by part (a)

• The plan is reviewed and updated at least annually, or to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments

• Plan is maintained in a location where authorized personnel have access, but is protected from unauthorized disclosure and modification

• Updates are communicated and distributed to personnel with a need to know

• Security controls clearly define HOW a control is implemented, pointing directly to system specific documentation, tools, or other relevant information.

• Security control requirements are NOT repeated to justify control implementation

• Security controls clearly identify control inheritance, as applicable, from other authorized systems or environments

• Planned activities to satisfy a control requirement are clearly described

• Plan references other system documents, as necessary, but describes how the specific control is addressed in the documentation to meet security requirements

• All -1 controls (MP-1, AC-1, SC-1, etc.) need to be addressed in every SSP and cannot under normal circumstances be inherited from another SSP. For example, the same Media Control Policy and Procedures can be used for multiple SSPs, but the control should reference how the CSP manages those documents regardless of whether the remaining MP controls are inherited or in scope

Best Practice:

• Cloud Service Provider (CSP) FedRAMP Authorization Boundary Guidance

• FedRAMP ABD Guidance Consolidated

• Architecture Boundary Diagram Job Aid Packet

• ABD Training Exercise - Answer Sheet

• ISSO Training - Controls Exercise

• Refer to 38North Lunch and Learn Session on Diagramming:

  • 1. PowerPoint presentation on Diagramming 101: https://docs.google.com/presentation/d/1QwXs4wjLjyNX2yYaaDSrh0qABLBOp2zF/edit?usp=sharing&ouid=108715282318167560179&rtpof=true&sd=true

    2. Video presentation on Diagramming 101: https://drive.google.com/file/d/1STfc9dl0rrh04juSva0LqvEjiaxLp_9p/view?usp=sharing

• Organization definition: When it comes to developing the SSP, the "organization" is always the CSP. For larger CSPs, it's the CSP as a whole, inclusive of the service teams within the CSP. This is how other larger CSPs are interpreting the term '"organization." What this means is the CSP is responsible for ensuring the control is properly implemented. This may be through one or all service teams depending on the service at hand. The service teams must do their part to implement an applicable control for their service

• Larger CSPs can document their SSP in one of two ways: (1) They can do separate service-level SSPs for applicable security controls or (2) they can do one large SSP that encompasses all services in one. If they do (1), it's easier to read and know how each service does something. Downside is they do not have the aggregate look and requires a lot of overhead to maintain and keep current. If they do (2), then it becomes a pretty large document. But it's all in one. They can differentiate what's what by putting sub headers over how specific service teams implement the control for their service. If it's similar to another service, they can group those services together with a bold header with the service name above. Each control's implementation detail would be quite lengthy, but it's all in one place and they see the aggregation immediately. 9 times out of 10, CSPs elect for (2) as it's a struggle to maintain 20+ SSPs and becomes a burden on the compliance team. Also easier to hand over to an auditor for the assessment when it's in one SSP

• Now when it comes to ISVs (independent software vendor), this can get a little tricky as this is outside of the "organization" now. If they lump it into the main SSP, then they're somewhat taking ownership on how that control is implemented for the ISV when they very well have no control over it. Auditors personally like the idea of separate SSPs for the ISVs as that helps show the differentiation from the CSP. References to "organization" in the ISV SSP should be defined as the ISV only and not the CSP

• Target SSP Completion:

  • In a FedRAMP Agency authorization, the environment (isolated from commercial customers) should be fully built and functional by 7-8 months prior to target ATO date, with a draft SSP. Customers are not required at this time. The SSP does not need to be completed prior to establishing a partnership with an Agency, but it does need to be completed 6 months prior to target ATO date, and fully reviewed by the Agency prior to the full 3PAO security assessment. The Agency partner should approve and sign off on the SSP prior to beginning testing

  • In a JAB P-ATO Authorization, the SSP should be completed and finalized once the offering is deemed FedRAMP Ready

Unofficial FedRAMP Guidance: None

Assessment Evidence:

• System Security Plan

• System Inventory (including containers and workspaces, since they need to be scanned)

• Architecture Diagrams (and artifacts from Control PL-8)

• List of personnel to which the system security plan is distributed

• Email/communication that was sent notifying personnel that the plan had been updated

• Screenshot/location where system security plan is maintained

• Version History showing plan review and update

• Access control list, or encryption information to show that the plan is protected from unauthorized disclosure and modification

CSP Implementation Tips:

• Amazon Web Services (AWS):

  • • AWS Customer Instructions for FedRAMP System Security Plan (SSP) Templates

    • AWS Architecture library: https://aws.amazon.com/architecture/icons/

• Microsoft Azure:

  • • Azure Architecture library: https://docs.microsoft.com/en-us/azure/architecture/icons/

• Google Cloud Platform:

  • • GCP Architecture library: https://cloud.google.com/icons

• OCI:

  • • OCI Architecture library: https://docs.oracle.com/en-us/iaas/Content/General/Reference/graphicsfordiagrams.htm

• IBM:

  • • IBM Architecture library: https://www.ibm.com/cloud/architecture/architectures/edit/architect-assistant