What is an SSP? What is its purpose? In simple terms, an SSP, along with its corresponding appendices, is a formal document that outlines (in detail I might add) an information system’s security requirements, the set of controls, and how they are implemented.
This vital document is not just documentation: It’s your strategy, your action plan, and your security lifeline all in one. Think of it as an outline for the overall system security posture, similar to blueprints to a building or a roadmap for a road trip that shows all the streets and highways along a route.
Learn more: Here’s Why You Should Add Dedicated Tech Writers to Your Security Team
It is not a procedure either, but it contains enough detail to demonstrate the system is secure while describing how security risks are handled to protect the confidentiality, integrity, and availability of the information system.
Before developing an SSP and its related documentation, it is imperative to identify the security framework the system aligns with. Different frameworks, such as FedRAMP, FISMA, CMMC, IRAP, or ISO 27001 have specific requirements and templates that must be followed. For instance, FedRAMP maintains strict documentation requirements and provides specific templates for the SSP and its appendices.
The following key sections should be included in an SSP regardless of the framework applied.
System Description and Architecture:
- The system description provides a detailed overview of the system’s operational environment and infrastructure. This section should clearly articulate whether the system is hosted on-premises or utilizes cloud services and specifically detail the service model being offered (Software as a Service, Platform as a Service, or Infrastructure as a Service). The description must encompass how security measures are implemented throughout the system architecture.
Security Categorization:
- A crucial element of the SSP is the system security categorization assessment, typically conducted according to established standards such as NIST SP 800-60 and FIPS 199 (Federal Information Processing Standards) for federal systems. This assessment evaluates potential security breach impacts on the system and organization, categorizing them as low, moderate, or high impact. This categorization drives the selection and implementation of security controls
Learn more: I’m a Cybersecurity Technical Writer — Here Are My Best Tips on Documentation Development
Diagrams:
The SSP should include various diagrams and schematics illustrating the following:
- Complete data flow mapping showing all ingress and egress points within the system boundary.
- Network architecture detailing all functions, ports, protocols, and services.
- Secure encryption protocols implementation.
- Comprehensive inventory of permitted functions, ports, protocols, and services within the system boundary.
Security Controls:
- Control Implementation and Status: The SSP specifies how the security controls have been implemented, alternate implementation or planned to secure the system. These controls may be based on security frameworks such as FedRAMP, FISMA, CMMC, IRAP, or ISO 27001 to name a few. *Note – FedRAMP has moved security control implementation to Appendix A instead of in the SSP itself. The implementation may also identify requirements that are inherited from other external systems outside of the framework’s boundary.
- Control Category: Common control categories include access control, audit logging, system and communications protection, configuration management, incident response, contingency planning, supply chain, and more.
Separation of Duties Matrix:
- A detailed separation of duties matrix demonstrates the implementation of least privilege principles. This section documents role-based access control implementation; access restriction policies; administrative privilege management; function-based access limitation.
Roles and Responsibilities:
- This section provides a comprehensive overview of the security organization structure and responsibilities, including individuals or teams responsible for managing, monitoring, and enforcing security controls within the system. It may include system owners, security officers, IT staff, and any external contractors or third parties.
In closing, remember this is just the beginning – there is a more exhaustive list of everything that is required or should be in the SSP. A well-crafted SSP serves as both a compliance document and a practical security management tool
The specifics of what needs to be included will vary based on the security framework your system must follow. Each framework comes with its own set of requirements, shaping the contents of your SSP and supporting documentation accordingly. The fundamental goal remains consistent: to provide a clear, comprehensive picture of how an organization protects its information systems and maintains security compliance.
Remember, the success of an SSP depends not only on its initial development but also on its continuous maintenance and updates to reflect system changes, new threats, and evolving security requirements.
