Press Release
If your organization participates in contracts with the US Department of Defense (DoD), the Defense Federal Acquisition Regulation Supplement (DFARS) in your contract requires you to have a System Security Plan (SSP) in place, see CMMC practice, CA.2.157, and NIST 800-171 security requirement, 3.12.4.
The point of your SSP is to give anyone looking into your cybersecurity posture a readable overview of your security requirements and the controls you have in place to meet those requirements.
Per the DoD’s compliance assessment guidance, a review of your SSP is intended to be step one in ensuring compliance with your DFARS prior to contract award.
In this regard, it’s pretty simple… No SSP? No DoD contracts!
The SSP has been part of the NIST 800-171 security requirement, set forth by DFARS 7012, all along, and the DoD’s newer Cybersecurity Maturity Model Certification (CMMC) also mandates it. CMMC Practice CA.2.157 (that is, CMMC Practice 157 in the Security Assessment (CA) Domain, applicable to CMMC Levels 2 and higher) specifies that you must:
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.
What does CA.2.157 mean, exactly? CMMC’s Appendix B explains:
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.
Do we “really” need to have a System Security Plan at this point?
Most suppliers in the US Defense Industrial Base (DIB) know by now that the CMMC is the DoD’s response to the lax security that resulted from self-attestation to NIST 800-171, with no threat of audits and thus little incentive to close out Plans of Action & Milestones (POA&Ms).
But the DoD isn’t waiting for the full-scale CMMC rollout to up the security ante. As of November 30, 2020, DoD contractors and subcontractors must post a score indicating their progress toward full NIST 800-171 compliance in a federal database prior to contract award or renewal of an existing contract.
What information needs to be part of our System Security Plan?
As you probably know, both NIST 800-171 and CMMC are all about protecting Controlled Unclassified Information (CUI) so your SSP should focus on CUI. Some of the information your SSP should clearly communicate includes:
Clear definition of your business and A&D boundaries
The kinds of CUI your business handles, and what you do with it
Where, when and via what specific processes you store, process and/or transmit CUI
All the controls you have in place to protect CUI, including procedures that people should follow
Known gaps in your compliance posture, if any
POA&Ms to close those gaps
In short, your SSP is a compilation of documents that collectively paint the picture of your CUI environment, the associated cybersecurity requirements, and the controls you have in place or planned to safeguard CUI.
How do we create a System Security Plan?
For most firms, creating an SSP takes four basic steps:
Gather all the documentation, policies, procedures, etc. that describes the current security posture for your system that is “in scope” for a CMMC or NIST 800-171 compliance assessment. This could be your whole IT environment or a subset of it.
Get input from the people responsible for system security, e.g., system managers, system operators, data owners, etc. to ensure the documentation matches your environment’s current state.
If there are gaps in your documentation, you will need to fill those based on interviews, research, etc.
Per DoD recommendations, put all components of your SSP into a template to make sure it is correct, complete and well organized. There is no “official” or required SSP template, so we created one for you that is easy-to-use to help ensure compliance.
Assuming you have sufficient expertise and bandwidth, your in-house IT/security staff can fill in your SSP template. A disadvantage with that approach can be a lack of objectivity to identify gaps that an auditor might later find.
Another option is to engage a third-party expert to help with the process. This can not only take less time and money than a DIY approach but also ensures the result complies with requirements and is useful to auditors.
To talk over your needs for an SSP and how we can help, contact Pivot Point Security.
