How to prepare a system security plan, with template

What is a system security plan?

An SSP provides the information needed to oversee security for systems and applications by detailing the technical and operational security measures at an organization. NIST defines an SSP as a "formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements."

The document has the following purposes:

• Detailing security posture. It provides an outline of an organization's security posture to help stakeholders understand existing and planned security measures.
• Ensuring compliance. Because it is a requirement for some regulations, an SSP enables organizations to demonstrate compliance, and it provides evidence during an audit. Vendors that have already prepared System and Organization Controls 2 reports can supplement those appraisals with SSPs to provide additional evidence that their security strategies are resilient.
• Supporting security management. The security team can use an SSP as an internal tool to test and update their organization's security controls.

SSPs are valuable in the public and private sector. Many government agencies require SSPs. The U.S. Department of Defense, for example, mandates that contractors have SSPs as part of its vetting process. Private enterprises can use SSPs to help existing or prospective clients understand how they secure their operations and customer data.

Components of an SSP

As noted, an SSP is a comprehensive and detailed presentation of the security controls used to protect a specific system or application. The following is a high-level list of SSP components:

• System owner and manager details.
• System details, e.g., what it does.
• System configuration and topology.
• System components, e.g., servers, software, network elements and OS.
• Security controls, e.g., how the system assures the confidentiality, integrity and availability of the system.
• Security requirements, e.g., who accesses the system.
• Security component configuration.
• Access and authentication processes.
• Awareness and training activities.
• Security incident response and management.
• Protection of system media.
• Physical security associated with the system, e.g., a secure data center.
• Identification of security risks, threats and vulnerabilities.
• Definition of security controls.
• Transmission of system information.
• Protection of system integrity.
• Achieving compliance with specific standards, regulations and legislation.
• Frequency of reviewing the SSP.
• Using the SSP for an audit.

Each of these elements can be expanded to provide sufficient detail to prospective users, auditors and other interested parties.

How to prepare an SSP

Evidence gathering is job No. 1 when developing an SSP. This can include system documentation, event logs, day-to-day security procedures, incident response plans and results of prior incidents, prior audit reports, interviews with system subject matter experts, vendor documentation, network documentation, and any other content that delineates system security controls and event response and mitigation activities.

Once legacy data and current data have been compiled, select a relevant SSP template. A template makes the SSP process much easier, and many are available -- both manual, fill-in-the blank ones and automated systems.

The IT security team governs how detailed the SSP should be, with support from the CISO and CIO. If the level of detail is likely to be significant, it could be worthwhile to retain an experienced outside party to assist with preparing the SSP.

During the course of SSP development, establish checkpoints to review progress and identify any issues that need to be resolved. Once the draft document has been completed, perform a QA/quality control check to ensure all elements have been identified, procedures have been accurately presented, controls have been defined and security resources have been identified. Ensure employees using the systems have been trained on security attributes.

SSPs, like many other technology plans and procedures, are living documents. It is ideal to schedule periodic -- e.g., quarterly -- assessments of the SSP and perhaps even more frequent mini-reviews among security technicians, vendors and users to keep the SSP current and relevant.

Paul Kirvan is an independent consultant, IT auditor, technical writer, editor and educator. He has more than 25 years of experience in business continuity, disaster recovery, security, enterprise risk management, telecom and IT auditing.