System Name (System Acronym)

[[System Name (System Acronym)]]

Security Assessment Plan (SAP)

[[System Name (System Acronym)]]

Data System Designator (DSD) XXX

SECURITY ASSESSMENT PLAN (SAP)

[[System]] Release: vX.X

Xx XXX 2016

Prepared by

[[Organization]]

Distribution limited to U.S. Government agencies and U.S. DoD contractors only.

Requests for this document must be referred to [[system PMO]]

Revision History

Description / Date / Author

Table of Contents

1. Introduction

1.1 Overview

1.2 System Summary

2. As-Is and To-Be Architecture

3. Changes to Configuration

4. System Security Architecture Impact

4.1 Hardware Software Changes

5. Schedule

6. test Plan

6.1 Scope

6.2 Objectives

6.3 Test Approach and Strategy

6.4 A&A Team Roles and Responsibilities

6.4.1 Test Environment

6.5 Security Test Tools and Assessments

6.6 Test Sequence

6.7 Defect Management

6.8 Test Design

6.9 Test Scripts

6.10 Non-Technical Tests

7. Traceability Matrix

8. Security Assessment Results

8.1 Risk Management Framework (RMF)

Tables

Table 1: DISA Transition Schedule

Table 2: [[SYSTEM]] A&A Team Roles and Responsibilities

FOR OFFICIAL USE ONLY

[[System Name (System Acronym)]]

Security Assessment Plan (SAP)

1. Introduction

1.1Overview

This document details the Security Assessment Plan (SAP) for the [[SYSTEM]]RMF Baseline. The SAP affirms that implemented security safeguards, countermeasures, and assurances are sufficient to maintain system risk at an acceptable level as [[SYSTEM]] operates as an Risk Management Framework (RMF) “Moderate, Moderate, Low” system, while handling Controlled Unclassified Information (CUI).

This SAP will be used to establish the RMF baseline for the system.

This SAP includes an implementation schedule, testing to be accomplished, and information regarding the hosting environment.

1.2System Summary

[[SYSTEM]] is categorized Moderate (Confidentiality), Moderate (Integrity), Low (Availability) under Risk Management Framework (RMF).

[[SYSTEM Information]]

This SAP is to establish the RMF Baseline for [[SYSTEM]] at the [[hosting environment]].

2. As-Is and To-Be Architecture

There is no change to the current [[SYSTEM]] architecture, this SAP is being used to establish the initial RMF Baseline.

[[Insert “as is” topology here]]

3. Changes to Configuration

[[There are no changes to the existing development, pre-production, and production environments.]]

4. System Security Architecture Impact

[[There are no changes to the existing development, pre-production, and production environments.]]

4.1Hardware Software Changes

[[There are no changes to the existing development, pre-production, and production environments.]]

[[Insert hardware and software list here]]

5. Schedule

Table 1: DISA Transition Schedule(If applicable)

Program Management Office (PMO) Schedule / Duration (days) / Start Date / Finish Date
[[System Name]]
System Acronym / [[SYSTEM]]
Version Number
Authority to Operate (ATO) Expiration Date: DIACAP
Release Implementation Date
System Security Plan (SSP) Initiative - [[SYSTEM]] SSP v1 Signed 8 May, 2015
Change Impact Assessment (CIA) Event
Security Assessment Plan (SAP) Submission
Assessment Type :
Authorization – Initial RMF Baseline
Security Control Assessor Representative (SCAR) Requirement
SCAR Performs Independent Review of SAP
SCAR Concur w/SAP
w/recommendation concurrence date, if any
Authority Official Designated Representative (AODR) Requirement
AODR Performs Independent Review of SAP
AODR Approve SAP
w/recommendation approval date, if any
Program Management Office (PMO) Requirement
PMO Upload Approved SAP to A4PA SharePoint site
Security Control Assessment
(Planned) Perform Security Testing and Evaluation (ST&E)
(Planned) Implement Security Controls Test Results in eMASS
(Planned) Security Control Submission to SCAR
(Planned) SCAR Evaluation of Security Control Start Date
(Planned) SCAR Security Control Completion Date
Post Security Assessment
Assessor Validates Security Controls in eMASS {Occurs after SAR Completion}
SCA Submit SAR to A4 AODR
AODR SAR Review
A4 AO Mission Risk Assessment Briefing (MRAB)
Remediation of SAR Findings (if directed by A4 AO) {2 Days ONLY for PMO}
ATO Decision (AF AO)
ATC to AFIN Decision (AFIN AO)

6. test Plan

6.1Scope

The SAP will focus on validating security features of [[SYSTEM]] under the RMF process for the initial 35 controls required by the AO. PMOs will ensure all of the applicable 35 controls are tested first, followed by the applicable control enhancements. Any control enhancements not tested by the end of the testing period will be placed on the POA&M to be tested within 6 months of ATO issuance. All remaining NIST controls will have POA&M’d for testing within 18 months.

Validate[[SYSTEM]] configuration
Examine, analyze, and document the effectiveness of the implementation of security features and measures to ensure system confidentiality, integrity, availability, and accountability
Examine, analyze, and document the non-technical security safeguards and procedural controls implemented to determine if an appropriate level of protection is provided in the new pre-production environment
Examine, analyze, and document inherent system weaknesses (due to design or operational constraints), mitigating factors and residual risk

6.2Objectives

The primary purpose of the [[SYSTEM]] SAP is to evaluate the [[SYSTEM]]compliance with RMF requirements in regards to the system environment and impacts to the security baseline. The [[SSP Security Control Implementation spreadsheet]] links the security objectives to the security capability to the security controls. Some tests are non-technical in nature, and will require information gathered through interviews or documentation examination instead of hands-on technical testing.

6.3Test Approach and Strategy

The system testing strategy may include automated scanning tools, evaluation/validation of assigned security controls, positive/negative testing as applicable, boundary testing, use case/scenario tests, and review of documentation. Paragraph 6.5 through 6.10 outline the tools and procedures that will be used for this assessment.

6.4RMFTeam Roles and Responsibilities

The assessment team is responsible for planning, executing, and documenting the results of the SAP. Table 1provides a list of the team members, including their role(s) and a short description of their responsibilities.

Table 2: [[SYSTEM]]RMF Team Roles and Responsibilities [[update with applicable system roles]]

Name / Organization / [[SYSTEM]] Role / Responsibility
Program Manager
Deputy Program Manager
Functional User/SME Lead
Information Systems Security Manager (ISSM)
Cybersecurity SME
Cybersecurity SME
Software Engineer / Developer Lead
Operations Lead
System Administrator
Database Lead

6.4.1Test Environment

Testing of the system entails the assessment of the security features (technical test procedures), as well as a review of the policies and procedures that govern the operation and use of the system (non-technical test procedures). The technical test procedures will be conducted at the NGIS Facility by support contractor personnel or by [[SYSTEM]]Cybersecurity personnel. Non-technical test procedures will be conducted at the PMO, developer facility or other suitable location where the required information can be obtained and assessed.

Testing will be conducted by the [[SYSTEM]]support contractor with oversight and review conducted by the [[SYSTEM]] ISSM/ISSO(s).

6.5Security Test Tools and Assessments

Testing will occur in the[[SYSTEM]]pre-production and production environments within the [[testing environment]]. Testing will use resources from the following agencies and publications to provide criteria for evaluating the security of this system:

NIST SP 800-53Rev. 4, Risk Management Framework Controls for: Confidentiality: Moderate, Integrity: [[Moderate, Availability: Low]]

The following tools may be utilized during testing and will be included as artifacts in eMASS:
Static Code Analysis (e.g. HP/Fortify) Scans
Dynamic Code Analysis Scans
Application Penetration Testing Scans
Assured Compliance Assessment Solution (ACAS)

The following DISA STIGs may be used to assess system compliance: [[update with applicable system STIGs]]
Apache STIG
Application Server
Oracle Database STIG
Red Hat Linux STIG
VMWare ESXi STIG
Web Server STIG
Windows 20XXServer STIG
DISA Application Security and Development Checklist

6.6Test Sequence

The RMF Team will make every effort to test the security controls based on capability and security control family, with Continuous Monitoring controls being tested first. Keeping the [[SYSTEM]] RMF categorization in mind, controls identified in the [[SYSTEM]]Continuous Monitoring Strategy will be tested first, followed by Controlsfor [[Confidentiality and Integrity, finally those assigned for Availability]]. This provides an opportunity for remediation of the more critical elements if necessary.

There may be instances where regression testing may need to be accomplished. In the event that a bug or flaw has been identified, regression tests will be accomplished to ensure that bugs or flawshave been fixed; previously working functions remain functional; and newly added features have not created new bugs or flaws.

6.7Defect Management

[[Information on system CCB process for defect management]] The Program Manager, ISSM/ISSO, and [[other applicable personnel]] are responsible for tracking and monitoring progress.

6.8Test Design

The test scripts will be identified by applicable Cybersecurity control, DISA STIG and/or DISA Application Security and Development Checklist rule number. Automated scripts are run if available, otherwise manual checks will be completed.

6.9Test Scripts

The attached [[SYSTEM]] Security Test Plan contains a completed set of test scripts associated with the [[M-M-L]] Controls identified in NIST SP 800-53. The test scripts will be used to meet or support meeting the security control procedure objective(s). The test scripts will be modified as necessary if more detailed testing is required. Completed security test results will be included as an artifact in eMASS.

6.10Non-Technical Tests

Information obtained to support the implementation of a specific security control (e.g., documentation, evidence artifacts) will be documented in the eMASS control and attached as an artifact.

7. Traceability Matrix

Traceability between the required security capability (confidentiality, integrity, and availability), the required security controls enabling this capability and the methods used to confirm security control implementationare documented in the [[IA Control Implementation spreadsheet]] in the [[SYSTEM]] SSP.

8. Security Assessment Results

The technical and non-technical findings associated with testing will be identified via the information-gathering and testing techniques described in the para 6.5, Security Test Tools and Assessments. The Test Team will review the test results for [[SYSTEM]], and evaluate them against the specific test objectives and the applicable security requirements of the test performed.

The assessments for each security control will be documented within eMASS. The compliance status (compliant, non-compliant or not applicable), implementation status (inherited, implemented, planned), narrative, and attachments will be completed for each security controltested. Any security control found to be non-compliant will be identified in the Plan of Action and Milestones (POA&M).

Automated system scan results and evaluations will be uploaded to the applicable security control (e.g., CM-6, Configuration Settings, RA-5, Vulnerability Scanning, etc.). Any unresolved findings will be identified in the Mission Risk Assessment Briefing (MRAB) and POA&M.

Once eMASS is updated and the security control submitted, the ISSM will notify the SCA or SCAR team,who will complete the eMASS validation and Security Assessment Report (SAR).

8.1Risk Management Framework (RMF)

RMF has three components; risk mitigation, risk assessment, and risk management. “Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations’ missions.”[1]

The RMF allows the Authorizing Official (AO) to balance risk of operation against available resources; a useful tool in managing system risks. The connection between the POA&M and the RMF is theMRABproduced by the PMO, ISSM and SCAR team based on the SCA Security Assessment Report and finding from the assessment. The MRAB is designed to communicate mission risks and likelihood of the vulnerability being exploited. It is essential the AO understand the system, the type of information the system handles, how the system supports the mission, and the measures in place to mitigate risk. The MRAB briefing will document all identified system weaknesses found during testing, documentation review and security control evaluation/validation.

FOR OFFICIAL USE ONLY

[1] National Institute of Standards and Technology Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments