Information system development, use, and eventual decommissioning requires a lot of paperwork – reports, signatures, manuals, approvals, and more. Amongst this mountain of documentation, the System Security Plan (SSP) may well be the granddaddy of them all. It is the encyclopedia and guidebook of all security aspects related to the system from components and agreements to requirements, updates, and procedures. Keep reading to learn more about these critical documents, how you can complete one, and how you might be able to save yourself some effort in the process through templates and automation.

What is a System Security Plan (SSP)?

A system security plan (SSP) is a comprehensive summary of the myriad security-related elements of an individual Information System (IS) that manages Information Resources (IR). This includes all the system’s hardware, software, relevant personnel, etc. An SSP describes the security requirements of the system and the controls that have been put in place (or are planned) to meet those requirements. It also defines individuals’ roles in planning and operating the system, and auditing its performance. An SSP should also be a ‘living’ document that personnel periodically review and update whenever system events (e.g., identified and resolved vulnerabilities; added hardware, software updates, staff role adjustments, etc.) warrant it – and at a minimum every three years.

Ultimately, the SSP serves as the authoritative and exhaustive reference of a system’s security effectiveness yesterday, today, and for tomorrow. 

Who do SSPs apply to?

SSPs apply to all federal agencies and all systems those agencies own and manage. Title III of the E-Government Act of 2002 (FISMA) mandates that all federal agencies develop, document, and implement an agency-wide information security program for the IR and systems that support their operations. Under FISMA, agencies must categorize each system’s security requirements relative to its operational mission (Federal Information Processing Standards [FIPS] 199) and they must maintain a sufficient security baseline to meet those requirements (FIPS Publication 200).

Along with Risk Management Frameworks (RMF), Plans of Action and Milestones (POAM), accreditation decision letters, and other documents, the SSP is a key component of a System Development Life Cycle (SDLC) because it provides the clear, up-to-date, and relevantly exhaustive documentation of security baseline needs and compliance.

What needs to be included in an SSP (with examples)

The National Institute of Standards and Technology (NIST) issued Special Publication (SP) 800-18 to guide agencies as they develop SSPs for federal information systems. NIST wrote SP 800-18 to be adaptable to a range of information systems, organizational structures, and personnel assigned to completing SSPs. Each organization can tailor their SSP content and format but they should cover certain key information areas and be thorough.

The more detailed and exhaustive the SSP, the better. It will make updates easier, ensure that your controls are comprehensive and operating properly, and validate that you are maintaining baseline.

Let’s imagine that a Department of the Interior (DOI) agency plans to install new digital, self-service, sales kiosks at the public parks it manages and needs to prepare an SSP for system authorization. The general public can use these kiosks to pay entrance fees with their credit cards or register for tours through a digital registration form that stores Personally Identifying Information (PII). Park personnel can review occupancy and registrations by logging into the kiosks or connecting to a cloud-based reporting platform over the internet.

Before the DOI sets off in developing the SSP, they must take system scoping and boundary identification into account. What components are part of the system which ones are not? Tighten your net to those components that specifically function toward the system’s distinct purpose. In our example, the DOI would include (among many others) the credit card reader, the POS tablet device, and the registration reporting software, but they likely would not want to include park personnel’s workstations or the parks’ LAN within the actual system because these systems don’t solely support the POS system.

As you read, bear in mind that the SSP items below are not an exhaustive list of everything that NIST recommends. You can refer to SP 800-18 for more details about the additional items and download the SSP template.

1. System Identification

OMB Circular A-11 requires that all agencies assign a unique name and identifier to each system. The agency completing our example SSP has elected to call their system “Sales-O-Matic” and give it the identifier “20221201.DOI.Parks” (the eight-digit numerical code corresponds with the year, month, and day that system development formally began). You can name and identify your system however you would like as long as it’s unique to that system.

2. System Categorization

Personnel must evaluate each IS against the risk categorization standards outlined in FIPS 199 (see also, NIST SP 800-60). What are the impacts (“low”, “moderate”, “high”) to the agency’s mission if information Confidentiality, Integrity, and/or Availability were compromised?

The POS would likely be categorized as “moderate” to “high” under FIPS 199 standards because it briefly records and transmits financial information (credit card information) and it stores PII (e.g., visitors’ registration credentials and contact information).

3. Information System Type

NIST breaks IS into three main type categories:

The park admission POS system would likely be categorized as a “Major Application” because it transmits financial information and it stores PII.

4. System Environment

In one to three paragraphs, describe the technical system in which the IS will be operating. These are typically listed as “Standalone”, “Managed/Enterprise”, or “Custom”. Include any unique factors that might increase security concerns.

Park staff would probably categorize the POS System as “Managed/Enterprise” because they expect that these kiosks will be deployed across all their parks and be controlled from their central offices in Washington. Park staff may also state that the kiosks will be used by the general public and they will store PII, because these factors would raise security concerns.

5. System Interconnection/Information Sharing

Systems rarely act entirely alone; they most often interconnect with other systems. These interconnections introduce potential vulnerabilities into the subject system that are conceivably beyond the system owner’s control. Accordingly, system interconnection is a highly scrutinized component of an SSP. In this section, list important details, like authorization vehicle (e.g. MOU, etc.) and accreditation status, about each of your system’s interconnections with other systems.

Park staff would likely list this needed details for the park’s LAN network on which the kiosks will be installed, as well as the credit card processing security agreements with the banks and the Department of the Treasury (among other interconnections). They likely would also list the Federal Risk and Authorization Management Program (FedRAMP) certification of the cloud-based reporting system that hosts the staff reports.

6. Ongoing SSP Maintenance Records

SSPs are supposed to be ‘living’ references to the system’s security over its full life cycle. Include all records of system audits, firmware updates, hardware changes, etc. as SSP appendices so that future workers can refer back and make better-informed maintenance decisions.

SSPs and “Rules of Behavior”

One of the key supplemental components of a thorough SSP is a clear and concise description of the system’s “Rules of Behavior” (ROB). ROBs are also required in the Office of Management and Budget (OMB) Circular A-130 (Appendix III) and their documentation is a listed control in NIST SP 800-53.

The ROB should be a high-level summary of every individual’s roles, responsibilities, and expected behavior who interacts with the system. It should paint the picture of what the ‘right thing’ should look like – everyone contributing positively to a properly functioning and secure system – and outline the consequences – both to the individual and to the system itself – of deviating from those expectations.

You may find that developing ROB helps with SSP documentation, and vice versa. 

Use templates to write an SSP

It’s important to note that NIST does not mandate a specific SSP format; they only advise the content that should be included. In theory, an SSP could come in the form of a comic book as long as the right information was presented. (I’m not sure the latest issue of The Adventures of CAC-Man and the Pairwise Pseudonymous Identifiers would be a real page-turner, but ya’ never know!)

Typically, organizations use an SSP template to streamline the development process and ensure that they are recording the right information and not missing anything. 

Many organizations use the NIST SSP template, which they download from SP 800-18 (Appendix A) and repurpose to meet their needs.

For an even more detailed and adaptable starting point, click HERE to download the FedRAMP SSP Template.

Save time and be more secure through automation with IPKeys

As you can see, manually preparing an SSP is a significant undertaking. There are potentially hundreds of components, subcomponents, personnel, interconnections, etc., each to be exhaustively reported. Excluding the immense volume of documentation alone, the smallest missed security detail in an SSP could leave a significant vulnerability open to compromise.

NIST encourages automation to make SSP development more efficient and more thorough. They developed the Open Security Controls Assessment Language (OSCAL), an open-source, common programming language (XML, JSON, YAML) reporting format to support automation. The OSCAL SSP model rapidly and accurately assesses systems at a granular level and generates SSP content (e.g., points of contact, system characteristics, system boundaries, hardware/software inventory, attachments, enacted and recommended controls for a system’s recommended baseline, etc.) with little human labor or intervention.

IPKeys embraces OSCAL and developed their Cyber Lab-as-a-Service (CLaaS) system to fully harness its benefits.

Automated Assessments

With IPKeys’ CLaaS, you can eliminate hours of analysis and tedious manual work in developing an SSP. Use an intuitive and flexible AI-powered data analysis system to find and record seemingly imperceptible weaknesses and data connections in your own system.

Familiar Reporting Formats

Cutting-edge, automated systems like CLaaS can digitally document systems by converting machine-readable (OSCAL) datasets into human-readable formats like HTML and PDF for review and signature, dramatically improving overall report accuracy and efficiency.

Experienced Team

The skilled specialists at IPKeys focus on cybersecurity that is tailored for government organizations. They developed their distinct suite of security tools and smart strategies for the DOD to meet their rigorous specifications. These same tools can keep your data safe and your systems running.1.