Tips for Writing Your System Security Plan

These days, it’s not easy to be in charge of your organization’s IT security. With cyberattacks increasing in frequency, severity, and reach, it’s more important than ever to develop a plan for achieving, managing, and documenting the security of all of your systems.

It’s Not Only Good Practice to Have a System Security Plan, but It’s Also a Requirement

NIST SP 800-17, Revision 1 recently added requirement 3.12.4 to the Security Assessment control family stating that organizations 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.”

This one-sentence requirement is based on NIST SP 800-18 – Guide for Developing Security Plans for Federal Information Systems.

Identify What Systems Need a System Security Plan

Now it’s time to figure out which systems in your organization require a System Security Plan (SSP). Each SSP should be focused on an information system, which is defined as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.” An application, information or technology service, platform, and infrastructure are all considered systems, and their security must be formally planned according to the NIST SP 800-171 requirement for in-scope systems.

Compile your list of systems needing an SSP and start uncovering all the information you will need to write them. Each SSP will need two types of information, both of which can be a challenge to compile. These include:

  1. System details documenting how the system operates
  2. Details about how the NIST SP 800-171 Revision 1 controls requirements are met for that particular system. Note that the control statement responses are a granular system-specific response to the 110 control requirements.

Once you have your inventory of systems that store, process, or transmit Controlled Defense Information (CDI) or Controlled Unclassified Information (CUI), it’s time to start planning.

First, create a system security planning template. The appendix to NIST SP 800-18 – Guide for Developing Security Plans for Federal Information Systems has a template, which provides a great starting point for creating your organization’s SSPs.

Next, assemble your team for the planning process, making sure to include these roles:

  • System Owner – This role is critical to the system security planning process as this person has deep knowledge about the systems and understands what the system does, how it works, and how it is controlled. The system owner owns the security plan for the system and is responsible for providing diagrams and explanations that articulate where the sensitive data is stored at rest, where and how it is transmitted, and what system interfaces exist, especially those interfacing systems that transmit the sensitive (CDI and CUI) data.
  • IT/Security Support Staff – Depending on the size of your organization, your support team may provide a set of core IT services that provide control to the broader network and computing environment. Inheritable controls could include authentication services, firewalls, network segmentation, secure system baselining, access management, and change management. A system owner will work hand-in-hand with the support team to understand how and if the controls apply to his or her particular system.
  • Administrative/Business Operations Support Staff – Some controls that apply to systems may not be technical. Administrative and/or business operations staff will need to provide input into how non-technical controls, such as background screening processes, facility security mechanisms, training and awareness programs, and staff management controls, are addressed. The people who have ownership of these functional business capabilities will need to weigh in on the security planning effort so that controls are adequately defined.

Once you have the right people involved, it’s time to get to work and write the plan. It’s a laborious process, but the intent is to provide defensible information and responses as to how a system works and how security controls are applied. An auditor or contracting official will want to know how you safeguard their sensitive data, and the information you document along with control responses should provide assurance of that protection.

Create a Master SSP

Every system used for the storage, processing, and transmission of CDI/CUI should have a security plan. Think about the roles above and the functional areas they represent. If these roles exist as a core, corporate function that is applied consistently across the organization, then consider creating a master system security plan that documents a core set of controls meeting the NIST 800-171 requirements.

A Master SSP helps you define a standard across the enterprise for inheritable controls, which provides guidance to the system owners about how they may be consuming controls that are broadly applied to the organization. The effectiveness of using the master system security planning concept depends on how effective those broad controls are applied by mandate.

  • For those organizations who strictly apply their standards, the master system security planned controls would be thoroughly applied and relied on.
  • For those organizations looser about applying standards and mandates, a master system security plan makes a good reference, but system owners should pay close attention to whether they actually inherit the standard control offering, or if a system-specific control response is required.

Build Proactive Measures into Your SSPs

Developing your System Security Plan(s) will provide a systems-focused macro-view of how your security controls are being applied. The process also helps identify non-compliance and uncover insecure practices, alerting you and helping you create a plan to resolve issues.

Consider building your Plan of Actions & Milestones (POAM) into your SSPs, and track compliance deficiencies to resolution. This helps you be proactive in your remediation and corrective action planning and moves you closer to a mature state in managing security controls.

The CyberSheath team is experienced at helping organizations like yours create System Security Plans. Contact us to learn how we can help you.