The Basics of Designing A System Security Plan

The Basics of Designing A System Security Plan

The DFARS 252.204-7012 clause requires that all contractors and subcontractors of the US Department of Defense maintain an up-to-date system security plan (SSP). You will likely be asked to provide this plan before you can sign any contract with the DoD as evidence showing that your organization has achieved an adequate level of security. Your SSP should align with the requirements of the NIST 800-171 framework.

What is a system security plan?

An SSP is a document that outlines all the features and functions of a system, including the people tasked with overseeing them. An SSP comprises three main parts:

  • System identification: This section contains the basic information about the system, including responsible individuals, a general description of the system, the number of end users and privileged users, and a general description of the controlled unclassified information (CUI) handled by the system.
  • System environment: This section is a detailed topology of the entire system. It must include an overview of system boundaries, key devices, and any connections between them. For example, it should include a list of all operating systems, virtual machines, web servers, and other assets to form a complete inventory of your data environment.
  • Requirements: The requirements you need to meet to become DFARS-compliant are all listed in the NIST Special Publication 800-171. The NIST 800-171 framework lists 110 controls across 14 domains. The SSP must include a list of all these requirements and state whether they have been implemented or not.

You can download a template from the official website. However, in order to actually implement these requirements, you either need to have a dedicated security and compliance team that fully understands them or work with a consultancy firm that does. The latter is easily the most affordable and easiest solution for small- to medium-sized businesses. It is, after all, vital that those developing and implementing your plan are familiar with the requirements.

Starting with an audit

Unfortunately, writing an SSP is not quite as simple as filling in a template. Given the disparity and complexity of today’s business computing environments, it can be difficult to identify every component that makes up the system. This may include virtual machines hosted in the cloud, on-premises servers, workstations and laptops, and mobile devices belonging to employees. Your plan must cover every asset, virtual or physical, that makes up your interconnected data environment.

Only once you have made a complete and up-to-date inventory of your environment can you determine whether or not each component of the system meets the requirements of NIST 800-171. This is why a thorough audit of your existing environment is an essential first step. This audit will also reveal any potential security holes giving you the opportunity to remediate before something goes wrong.

Reviewing your plan

An SSP is not something you simply write once and then file it away in a cabinet. It is a living document that must be kept up to date at all times. For example, if you add a new component or end user to the system, then you will need to update your plan accordingly. Similarly, if you implement new controls according to the NIST 800-171 framework, you will also need to update the plan. After all, a plan is only relevant if it is current, which is why it is important to get into the habit of regularly reviewing your SSP, particularly after you make any changes to your environment.

Your SSP also serves as evidence of your current security posture. Potential clients, including the DoD and its own contractors, may ask you to provide this evidence before they will sign a contract. As such, having an up-to-date SSP is an important document to have when bidding on requests for proposals (RFPs), and it can open up new lines of business.

Of course, the plan must align with the real situation in your organization. To enforce these measures, the DoD may send Cybersecurity Maturity Model Certification (CMMC) auditors to your organization. Naturally, if the reality differs from the statements in your SSP, you could find yourself in breach of your contracts and potentially facing litigation.

Charles IT can help you get up to speed with regulatory compliance and provide the services you need to maintain the highest possible standards of cybersecurity. Schedule your first gap assessment today to get started!

Most tech consulting starts with “Press 1”

We just like to start with “Hello.”