Attachment 0029 - System Security Plan (SSP) Template.doc

Attachment 29

[ORGANIZATION NAME]

[ORGANIZATION LOGO]

Department of Defense (DoD)

Information Assurance Certification and Accreditation Process (DIACAP) [System Name]

SYSTEM SECURITY PLAN (SSP)

[DATE]

[Version] [Organization Name] [Address 1] [Address 2] change log

This record shall be maintained throughout the life of the document. Each change and published update shall be recorded.

CHANGE / REVISION RECORD

Table of Contents Introduction

11.1 Purpose

11.2 Applicability and Scope

21.3 The [System Name] DIACAP

System identification & Operational Status system Description

43.1 Purpose

43.2 System Environment

43.3 Accreditation Boundary

43.4 System Baseline

53.5 Information System Type

53.6 Information Classification and Sensitivity

53.7 System Capabilities

System Architecture

64.1 High-Level Architecture

64.2 Detailed Architecture

74.3 System Resources

System Interfaces and External Connections personnel security

96.1 IA Responsibilities

96.2 IA Awareness & Training

IA Acquisition

Department of Defense Information Assurance Controls

Recommended Security technical implementation guides (STIGs) for information assurance

REFERENCES

figures

4Figure 1: System Environment

4Figure 2: Accreditation Boundary

6Figure 3: High-Level Architecture

6Figure 4: Detailed Architecture

Tables

1Table 1: DoDI 8500.2 IA Controls Satisfied by this SSP

7Table 2: System Resources

9Table 3: Security Responsibilities

17Table 4: [System Name] DoDI 8500.2 IA Controls

1 Introduction

1.1 Purpose

This System Security Plan (SSP) documents the information assurance (IA) requirements for the accreditation of the [System Name] information system (IS). It satisfies the following DoDI 8500.2 IA controls:

Table 1: DoDI 8500.2 IA Controls Satisfied by this SSP This SSP is a living document that requires periodic review and modification. Procedures should be in place outlining who reviews and keeps the plan current. This SSP references all of the 8500.2 IA controls that are relevant to the security baseline for [System Name].

1.2 Applicability and Scope

The information in this document provides information owners, system managers, developers, and security certification officials with a baseline for measuring the effectiveness of the security design and managing design changes that impact security throughout the IS lifecycle. This SSP describes the technical, administrative, and procedural IA program and policies that govern the [System Name] IS, and identifies all IA personnel and specific IA requirements and objectives (e.g., requirements for data handling or dissemination, system redundancy and backup, or emergency response). All appointments to required IA roles are established in writing, to include assigned duties and appointment criteria such as training, security clearance, and IT-designation.

This document also references the security safeguards associated with external system interfaces and/or remote access solutions that are considered an integral part of the IS. The IS includes all hardware and software components that comprise the DoD Information Assurance Certification and Accreditation Process (DIACAP) accreditation boundary. This includes security mechanisms involved in hardware, firmware, and software, all of which are involved in the successful operation of the IS. These safeguards are used to implement and enforce the [Agency and/or System Name] security policy.

1.3 The [System Name] DIACAP

According to DoDI 8510.01p, DoD Information Assurance Certification and Accreditation Process (DIACAP), the Designated Accrediting Authority (DAA) might only request to see the DIACAP Executive Package, which contains the minimum information for an accreditation decision. The DIACAP Executive Package contains the System Identification Profile (SIP), the DIACAP Scorecard, and the IT Security Plan of Action and Milestones (POA&M), if required. The SIP is a compiled list of system characteristics or qualities required to register an IS with the governing DoD Component IA program. The DIACAP Scorecard is a summary report that succinctly conveys information on the IA posture of a DoD IS in a format that can be exchanged electronically. It shows the implementation status of a DoD IS’s assigned IA controls (i.e., compliant (C), non compliant (NC), or not applicable (NA)) as well as the C&A status. The POA&M is a permanent record that identifies tasks to be accomplished in order to resolve security weaknesses. The POA&M specifies resources required to accomplish the tasks enumerated in the plan and milestones for completing the tasks. It is also used to document baseline IA controls that are not applicable and non-compliant IA controls that have been accepted by the DAA.

Depending on guidance from the DAA, the DIACAP Executive Package may also include the DIACAP Implementation Plan (DIP), which includes the implementation status, responsible entities, resources, and the estimated completion date for each assigned IA control. The plan may reference applicable supporting implementation material and artifacts.

The DAA may require the DIACAP Comprehensive Package, which contains all of the information connected with the certification of the IS. It includes the System Identification Profile (SIP), the DIACAP Implementation Plan (DIP), the Supporting Certification Documentation, the DIACAP Scorecard, and the IT Security POA&M, if required. Supporting Certification Documentation may include the System Security Plan (SSP), the Configuration Management Plan (CMP), the Continuity of Operations Plan (COOP), and other artifacts that satisfy the applicable 8500.2 IA controls for the IS.

Based on instructions from the [Organization Name] DAA, [System Name] has a [Executive/Comprehensive DIACAP Package]. Full up-to-date details of [System Name] vulnerabilities are listed on the Vulnerability Management System (VMS).

2 System identification & Operational Status [Site Name and/or System Name; System Development Life Cycle (SDLC) stage]

3 system Description

3.1 Purpose

[The purpose of the information system; system capabilities and how it relates to the organizational mission]

3.2 System Environment

[Describe the system environment; provide a diagram if possible] Figure 1: System Environment

3.3 Accreditation Boundary

[Describe the accreditation boundary; provide a diagram if possible] Figure 2: Accreditation Boundary According to the Committee on National Security Systems Instruction No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006, the accreditation boundary identifies the information resources covered by an accreditation decision, as distinguished from separately accredited information resources that are interconnected or with which information is exchanged via messaging. The personnel that manage and utilize [System Name] are considered part of [System Name]’s Accreditation Boundary, though they are not considered part of the system itself.

3.4 System Baseline

[Describe the system baseline. Below is merely an example you could expand upon.]

The key to managing the configuration in the production facilities, including changes/updates and security fixes, is having the Production Facility Baseline emulated in the Lab. All development and testing is performed in the Lab for verification and approval of the baseline. Once testing has been completed and the Configuration Control Board (CCB) has approved the configuration/changes, the approved baseline architecture is replicated initially in the production baseline sites. When approved, the production baseline established at [Site A] will be replicated at [Site B]; and the [Site A] production baseline will be replicated at each of the activated locations. Security updates issued under the IAVA Management Guidelines, promulgated by JTF-GNO, will be tested in the Lab and released to the IAO for centrally-managed implementation at the [Sites] concurrently. In addition to holding the master copy of the [system] architecture, the Lab will perform evaluation of proposed modifications, upgrades, and engineering refresh to the video service architecture. Also, the Lab will evaluate components to be used by customer sites for interoperability with the [system] architecture.

3.5 Information System Type

[Enclave, AIS application, outsourced IT-based process, or platform IT interconnections (in accordance with DoDD 8500.01)]

3.6 Information Classification and Sensitivity

[Describe information classification and sensitivity; i.e. unclassified, FOUO, and classified (Secret/Collateral), Allied Secret Releasable, etc.; Command & Control (C2) information; intelligence information; business operations information; other DoD missions information; non-DoD missions information]

3.7 System Capabilities

[Describe the high-level capabilities of the system; What do the components and how] 4 System Architecture [Describe the system architecture; provide diagrams whenever possible]

4.1 High-Level Architecture

Figure 3: High-Level Architecture

4.2 Detailed Architecture

Figure 4: Detailed Architecture

4.3 System Resources

[List the kind of equipment, software/firmware, functional role, what it connects to, the functional role of that equipment, and protocols transiting the link] All IA and IA-enabled products need to be National Information Assurance Partnership (NIAP) approved, and must be currently on the Unified Capabilities Certification Office (UCCO) Approved Products List (APL). The Reference section at the end of this SSP contains links to the NIAP and UCCO APL Web sites.

Table 2: System Resources 5 System Interfaces and External Connections

[Describe the operating system(s), database management system(s), and applications. Describe the features of any security packages. Describe the target software and its intended use. Identify whether the software is Commercial off-the-shelf (COTS), government off-the-shelf (GOTS), or on the Ethernet Private Line (EPL). This includes manufacturer supplied software, other COTS software, and all program generated applications software.

Describe all connections to [System Name]. Include external connections such as remote access for telecommuters and connections for contractors performing maintenance tasks. All connections involving components within the accreditation boundary should be covered here.

Define all network interfaces, the connection medium used {ISDN, NIPR, SIPR, etc.}, and any security features employed over those links. Include information regarding the applications requiring the interface.

Include network diagrams depicting the connections as described.] 6 personnel security

6.1 IA Responsibilities

SAMPLE TEXT: Everyone with security responsibilities for [Site Name and/or System Name] meet the trustworthiness investigative levels for users with IA management access to DoD ISs as established in Section E3.4.8 of DoDI 8500.2. Only individuals who have a valid need-to-know that is demonstrated by assigned official government duties and who satisfy all personnel security criteria (e.g., IT position sensitivity background investigation requirements) are granted access to information with special protection measures or restricted distribution as established by the information owner. All individuals requiring access to classified information are processed for access authorization in accordance with DoD personnel security policies. This includes maintenance personnel, since they also need to be cleared to the highest level of information on the system. [Organization Name] has entrusted the following people with information security responsibilities for [Site Name and/or System Name]:

[List people with security responsibilities for the information system and the security roles they perform]

Table 3: Security Responsibilities

6.2 IA Awareness & Training

SAMPLE TEXT: All personnel are certified for their roles in accordance with DoDD 8570.01-M. A program is implemented to ensure that upon arrival and periodically thereafter, all IA personnel receive training and familiarization to perform their assigned IA responsibilities, to include familiarization with their prescribed roles in all IA related plans such as Incident Response, Configuration Management and COOP or Disaster Recovery. A program is implemented to ensure that upon arrival and periodically thereafter, all authorized users receive IA awareness training.

7 IA Acquisition SAMPLE TEXT: There is a discrete line item for IA in the program and budget documentation. Acquisition or outsourcing of dedicated IA services (e.g., incident monitoring, analysis and response; operation of IA devices, such as firewalls; or key management services) is supported by a formal risk analysis and approved by the DoD Component CIO. The Acquisition or outsourcing of IT services explicitly addresses government, service provider and end user IA roles and responsibilities.

8 Department of Defense Information Assurance Controls

[Populate the table below with the appropriate DoDI 8500.2 IA controls for your system.] This section lists all the DoDI 8500.2 IA requirements for this system and shows which ones are inherited or not applicable. The [System Name] DIACAP Scorecard records the status of compliance with these requirements.

Number

(Y/N) N/A?

Table 4: [System Name] DoDI 8500.2 IA Controls 9 Recommended Security technical implementation guides (STIGs) for information assurance

Which STIG Security Checklists should be utilized in the assessments depends on what resources are inside the accreditation boundary. DISA recommends that assessments are conducted utilizing the following STIG Security Checklists, as appropriate:

These DISA STIG Checklists are available at: http://iase.disa.mil/stigs/checklist/.

10 REFERENCES

Here are some references pertaining to this System Security Plan and to the information assurance posture of this system:

1. DoD Directive (DoDD) 8500.01p, “Information Assurance (IA),” dated 24 October 2002. Certified current 23 April 2007

2. DoD Instruction (DoDI) 8100.3, DoD Voice Networks, dated January 16, 2004

3. DoDI 8500.2, “Information Assurance (IA) Implementation,” dated 6 February 2003

4. DoDI 8510.01, “DoD Information Assurance Certification and Accreditation Process,” dated 28 November 2007

5. DoDI 8551.1, “Ports, Protocols, and Services Management (PPSM),” dated 13 August 2004

6. DoDI 8560.01, Communications Security (COMSEC) Monitoring and Information Assurance (IA) Readiness Testing, dated 9 October, 2007

7. DoD 5220.22-M, National Industrial Security Program, dated 28 February, 2006

8. Committee on National Security Systems Instruction (CNSSI) No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006

9. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6215.01C, Policy for Department of Defense (DOD) Voice Networks with Real Time Services (RTS), dated 9 November, 2007

10. CJCSI 6211.02C, Defense Information System Network (DISN): Policy and Responsibilities, dated 9 July 2008

11. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-18, Guide for Developing Security Plans for Federal Information Systems, Revision 1

12. Defense Information Systems Agency (DISA) Field Security Operations (FSO) Security Technical Implementation Guides (STIGs): http://iase.disa.mil/stigs/

13. DISA FSO Security Checklists: http://iase.disa.mil/stigs/checklist/

14. National Information Assurance Partnership (NIAP) Web site: http://www.niap-ccevs.org/

15. Unified Capabilities Certification Office (UCCO) Approved Products List (APL) http://www.disa.mil/ucco/

16. Unified Capabilities Certification Office (UCCO) Approved Products List (APL) Removal List: http://www.disa.mil/ucco/apl_removal.html

17. DISA, Joint Interoperability Test Command (JITC) DoD Unified Capabilities (UC) Requirement, Process and Test Documents: http://jitc.fhu.disa.mil/apl/dsn.html

[CLASSIFICATION]

[Add appropriate classification marking]