Level 5 CMMC - CMMC Practices

CA.2.157  

Reference: CMMC 1.02

Family: CA

Level Introduced: 2

Practice:
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

CMMC Clarification:
A system security plan (SSP) is a document that outlines how an organization implements its security requirements. An SSP outlines the roles and responsibilities of security personnel. It details the different security standards and guidelines that the organization follows. An SSP should include high-level diagrams that show how connected systems talk to each other. The organization should outline in its SSP its design philosophies. Design philosophies include defense-in-depth strategies as well as allowed interfaces and network protocols. All information in the SSP should be high-level. Include enough information in the plan to guide the design implementation of the organization’s systems. Reference existing policies and procedures in the SSP.

Example
You are in charge of system security in your organization. As part of your job, you develop a system security plan (SSP). The SSP tells all employees how they can meet the organization’s system security goals. The information in the SSP should explain how you should handle your important information. Examples include who can access important information, where you should store it, and how you can transmit it. By defining a clear SSP, you can design and build your network to ensure that it meets the SSP-defined goals. You can also use your SSP to outline the organization’s:
• security requirements;
• the current status of the requirements; and
• your plan to meet the requirements in the future.

3.12.4

Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

Discussion:
System security plans relate security requirements to a set of security controls. System security plans also describe, at a high level, how the security controls meet those security requirements, but do not provide detailed, technical descriptions of the design or implementation of the controls. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk if the plan is implemented as intended. 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.

Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.

[SP 800-18] provides guidance on developing security plans. [NIST CUI] provides supplemental material for Special Publication 800-171 including templates for system security plans.

*There is no prescribed format or specified level of detail for system security plans. However, organizations ensure that the required information in 3.12.4 is conveyed in those plans.

Source: NIST Special Publication 800-171 Rev. 2

PL-2

SYSTEM SECURITY PLAN

Description:
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 [Assignment: organization-defined frequency];
    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.

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.

Source: NIST Special Publication 800-53 Rev. 4

Source: CMMC v1.02