System Security Plans are Part of the DFARS Cybersecurity Requirement
Ok, ready to start getting DFARS 7012 compliant? As a contractor processing CDI, your organization is required by the DoD to have a System Security Plan (SSP). The information here is lesson 2.1 of our online Cybersecurity 101 educational resource for DoD contractors and will help educate you on how to create a System Security Plan for your organization.
So, how do you start getting compliant with DFARS 7012? Compliance means three things:
- Develop and implement an organizational cybersecurity program. The program needs a blueprint, and that blueprint is the System Security Plan (SSP), which we talk about in this week’s lessons.
- Determine what aspects of your cybersecurity program have yet to be implemented and chart a course of action to get the program fully up and running. This course of action is called a Plan of Actions and Milestones (POA&M) in cybersecurity parlance. We’ll discuss POA&Ms next week.
- Develop the organizational capability to respond to cybersecurity incidents, and report those incidents involving CDI to the DoD. Luckily, by implementing your System Security Plan you’ll create an Incident Response Plan (IRP), so #3 is covered by executing #1 and #2. We’ll cover Incident Response in Week 4.
System Security Plan Basics
To continue with the analogy offered above, the System Security Plan is the blueprint for your organization’s cybersecurity program. Similar to how a blueprint contains drawings and instructions for the construction of your home, the System Security Plan will contain all the details and specifications for how to build and run your program. But these details and instructions are confined by parameters—for example, you can’t build your home on the side of a cliff without certain structural elements; nor can you place electrical sockets wherever you want or use insufficient wiring for the sockets. So, in addition to outlining the building structure, your home blueprint needs to comply with certain codes and regulations.
It’s the same with your System Security Plan. In regard to building an System Security Plan to align with the DFARS, those codes and regulations are the NIST SP 800-171 controls. The good thing for folks with little System Security Plan experience is that NIST 800-171 outlines a nice framework around which to construct our System Security Plan. Sort of like purchasing customizable floor plans from an architectural design firm—most of the work is already done for you, and you just have to make some tweaks to personalize the plan to fit your needs. You can use 800-171 as the basic plan and add some customization to fit your organization.
To comply with DFARS, at a minimum your System Security Plan will need to address all 110 controls in the 800-171. However, when the DoD or prime contractor auditors come to inspect your plan for compliance (see the Auditing sidebar), they’ll rely on the Assessment Objectives in NIST 800-171A. You can think of these Objectives as Organizational Actions (OA), things the organization must do to “meet”—comply with—the control. There are 320 total OA associated with the 110 controls (see Lesson 1.1). To be fully sufficient therefore, your System Security Plan needs to address all 320 OA.
The System Security Plan is the medium that contains the descriptions of the managerial policies, operational procedures, and technical components that the organization plans to implement to meet the requirement of each control. That medium—Word document, Excel spreadsheet, web form, whatever—is up to the contractor to determine. While NIST offers a Word document System Security Plan template, at Totem.Tech we actually built a cloud-based tool to manage our clients’ System Security Plan. Just a matter of preference. If you are a sub-contractor, your prime may have a format they prefer the System Security Plan in, but in all reality the System Security Plan should be in a meaningful format usable by your organization.
How to develop a System Security Plan that addresses security controls and organizational actions?
In the System Security Plan, some OA will be addressed by crafting a policy statement, some will be addressed by describing a technology or process, and some will be addressed by a mix of policy and technology/process, in what we call a “hybrid” approach. All-in-all, the ratio of all 320 OA is about an even 1/3 policy, 1/3 technology/process, and 1/3 hybrid.
Let’s look at an example control to see how to effectively address it in an System Security Plan. Keep in mind this is just an example and should not necessarily be used as boilerplate for your organization. Control 3.10.6 in the Physical Protection family requires organizations to:
Alternate worksites may also be known as “telework” sites, and can include employees’ homes, as indicated in the Discussion for 3.10.6:
There are two Organizational Actions for 3.10.6:
[Bold emphasis added by us] You see OA 3.10.6[a] uses the word “defined”, which indicates you probably should address this OA via a policy statement. The word “identified” is often another indicator of a policy-related OA.
There are a couple of key attributes in a well-crafted cybersecurity policy statement: scalability and auditability. Here are some questions related to these two attributes to ask yourself as you craft your policy statements:
Scalability
- Is this statement simple and concise?
- Is this statement repeated in another document?
- Does this statement limit technology options, growth, or expansion?
Auditability
- Can an auditor verify implementation by:
- interviewing organizational personnel?
- examining or inspecting systems or documentation?
- testing safeguards, processes, configurations, systems?
Using the guidelines above, we may choose to address 3.10.6[a] with the following policy statement:
We can see this statement is concise (<100 words), readable (no legalese), and scalable, in that it doesn’t limit the organization in possible technology options. This statement is also auditable. The auditor could interview employees that work remotely to verify that they have a company-owned workstation. The auditor could interview supervisors to ensure they have a process for authorizing remote work and inspect the documents that outline that process. The auditor could also test to ensure remote access is channeled through the VPN.
Alternatively let’s say this policy was included in the company’s Acceptable Use Policy (AUP) that all employees are required to sign. If that were the case, we wouldn’t need to repeat the statement in the System Security Plan, we’d just refer to the AUP with a statement like this:
Now on to OA 3.10.6[b], which uses the word “enforced”. “Enforced”, “prevented”, or “implemented” often indicate the System Security Plan should contain a description of a technology to meet this OA. The following description details the technology implementation that could enforce the policy stated in 3.10.6[a]:
This is a thorough description of the technology used to enforce the policy established by OA 3.10.6[a]. (The “attached screenshot” would be a picture provided by the company and isn’t literally attached to this lesson. See below discussion of “compelling evidence”.)
Some OAs that use words like “controlled”, or “protected” might be addressed with a “hybrid” statement that both describes a policy as well as a technology/process by which the policy is implemented. For example:
A hybrid statement to address this OA could look something like this:
A key to describing a technical or hybrid control implementation is to reference “compelling evidence” the auditor can use to verify that the technology has been implemented as stated. In the above two statements you can see we referenced a screenshot of configuration settings as the compelling evidence.
There you have some examples that should get you started crafting your System Security Plan. In our experience, it takes about five working days to develop an System Security Plan sufficient to describe a cybersecurity program worthy of the DFARS requirements.
What’s next after the System Security Plan is finished?
The System Security Plan is a blueprint for the organizational cybersecurity program. But before the program can be put into action, it needs blessing and support from the executive level. To beat this “house” analogy to death (haha get it): before you move into your new home you do a walk-through to ensure everything meets your expectations. Then you sign acceptance papers, or a contract, etc. and can start using the home. In other words, you “authorize” the home for your occupation.
It’s the same for the System Security Plan and cybersecurity program: your organization’s executives need to sign off on the plan—what’s known as “Official Authorization” by cyber pros—and understand the resources they will be expected to allocate to make the program function. In Week 6 of this class we’ll dive a little bit deeper into why it’s so important to have executive support for the cybersecurity program.
Once the System Security Plan is Authorized, it’s time to start implementing the cybersecurity program, executing the processes and configuring the technology to meet the policy requirements. Keep in mind there are multiple 800-171 controls that require continuous monitoring of the program to ensure the System Security Plan remains relevant.
Realistically, implementing the System Security Plan will take place sequentially over time; very few organizations are equipped to fully implement a cybersecurity program from scratch. In the next lesson we’ll cover how to prioritize the cybersecurity program implementation, starting with the “FAR 17”—the 17 OAs that you must immediately meet to remain on contract. If you found this information valuable in understanding System Security Plans, then be sure to grab a seat in one of our DFARS/NIST 800-171/CMMC Workshops and checkout our Totem™ software. Or, just drop us a line. We love talking about all this stuff!
–Adam Austin
Cybersecurity Lead
Updated 5/25/2022
