Exhibit_F_-Security_Assessment_Plan.doc

FOR OFFICIAL USE ONLY

System Name

(FISMA #)

Security Assessment Plan

(SAP)

Prepared for

U.S. Immigration & Customs Enforcement (ICE)

[Component address not provided]

30 March 2015

DOCUMENT CHANGE HISTORY

Table of Contents

1.0 Introduction

1.1 Scope

1.2 Assumptions/Limitations

1.2.1 Assumption

1.2.2 Limitations

2.0 Assessment Tools

3.0 Scanning Authorization

4.0 Team Composition

5.0 Schedule

6.0 Security Assessment Procedures

6.1 Process Overview

6.2 Test Procedures

6.3 Component Identification

6.3.1 Hardware

6.3.2 Software

6.3.3 Operating Systems

6.3.4 Network Interfaces

6.3.5 Access Methods

6.4 Automated Scans

6.5 Requirements Traceability Matrix

6.6 Results Documentation

Acronyms

Appendix A. Scanning Authorization Letter

Appendix B. RTM

1.0 Introduction

1.1 Scope

This Security Assessment Plan (SAP) was developed using the guidance contained in NIST SP 800-37, Guidelines for Applying the Risk Management Framework to Federal Information Systems, and incorporates policy from the Department of Homeland Security (DHS) Management Directive (MD) 4300, Department of Homeland Security Information Technology Security Program Publication, Volume I, Policy Guide. Documentation contained in this plan will be used in support of the Security Assessment and Authorization efforts for System Name by the Authorizing Official (AO).

This SAP calls for a series of system assessments and tests to exercise the security features and procedures of the System Name against all applicable security requirements of MD 4300; vulnerability testing of the operational system is also planned. A site assessment of the facilities (building and rooms) will be performed to evaluate the security safeguards and controls of the operating environment. Additional tests will be devised as needed to assess newly identified vulnerabilities during the security assessment. Elements to be tested are defined within the authorization boundary described in Section 1 of the System Name Security Plan. The specific system security controls and security requirements to be satisfied by this system are listed in Sections 2 through 19 of the System Name Security Plan.

1.2 Assumptions/Limitations

1.2.1 Assumption

{Assumptions place rules of conduct, expectations, and communications on testing and observations for the security assessment. The following assumptions are examples of assumptions:

· The security assessment will be conducted in a controlled development/test environment.

· The security assessment team will have access to all relevant documentation for the system.

· The security assessment automated scans are configured to be the prevent interruptions in network and system services.

· Both the hardware and software is configured for operational use throughout the duration of the testing.}

1.2.2 Limitations

{Limitations should include a discussion of any system elements or locations that are not planned to be part of this test and evaluation}

2.0 Assessment Tools

List the assessment tools to be used during the security assessment.

Assessment Tools

3.0 Scanning Authorization

Any scans performed by the assessment team must be approved in advance by the system owner. The letter in Appendix A must be signed by the system owner and forwarded to the Assessment Team prior to conducting the assessment. This letter will authorize the Assessment team to use the tools indicated to perform scans on System Name

4.0 Team Composition

Identify the members of the Test Team.

Test Team Composition

Identify the Management Personnel (e.g. Information System Security Officer [ISSO], Component Chief Information Security Officer [CISO]/Information System Security Manager [ISSM], AO)

Management Personnel

Identify the System Personnel (e.g. System/Database Admin., System Owner)

System Personnel

5.0 Schedule

Document the major actions and activities associated with the assessment of System Name

Security Assessment Schedule

{e.g., Test Objectives Established

Assessment Procedures are Developed

Scanning Authorization Letter Signed

Execute Assessment Procedures

Security Findings Analyzed and Documented}

6.0 Security Assessment Procedures

The assessment of the information system's security features will range from a series of formal tests to a vulnerability scan of the information system. The following types of test plans and results were required and the results/recommendations from this test will be summarized in the Security Assessment Report. The verification of system controls was accomplished by means of:

· Technical testing (software/hardware)

· Technical automated tools (scripting)

· Physical assessments and/or inspection

· Documentation and procedural reviews

· Walk-through inspections; and

· Interviews with key personnel.

6.1 Process Overview

The general process used for conducting the security assessment will be:

· Assessment/test procedures are defined using:

· System Name Requirements Traceability Matrix (RTM) derived from RMS

· Vulnerability Scans

· DHS Configuration Guidelines

· System security controls and security requirements to be satisfied by this system will be defined, verified, and annotated by the reviewer in the RTM.

· The RTM and security scan results will be used to document and verify the system security features are implemented in accordance with SP and serve as the basis of system certification.

6.2 Test Procedures

1. Gather tools as identified in Assessment Tools (Section 3).

2. Collect preliminary and site data; such as operating systems, software versions, hardware serial numbers, etc.

3. Use DHS Configuration Baseline to baseline the system. The major system components will be evaluated against the DHS security checklist for each product.

6.3 Component Identification

6.3.1 Hardware

6.3.2 Software

6.3.3 Operating Systems

6.3.4 Network Interfaces

Lists the network interfaces for the System Name

Network Interfaces

6.3.5 Access Methods

List the access methods for the System Name

Access Methods

6.4 Automated Scans

· Conduct automated scans against the system using [TOOL].

· Discuss findings with System Administrator to ensure validity. It is permissible for the SA to correct findings on-the-spot (if applicable) or provide justification to mitigate the finding.

6.5 Requirements Traceability Matrix

1. Generate an RTM using the RMS tool. A copy of the System Name RTM is provided in Appendix B.

2. Execute RTM test cases.

3. Discuss findings with the ISSO to ensure validity. It is permissible for the ISSO to correct findings on-the-spot (if applicable) or provide justification to mitigate the finding.

6.6 Results Documentation

The results of all security testing will be tabulated in the RTM. The results of testing the security requirements will be summarized in the System Name Security Assessment Report.

Acronyms

Security Plan

Appendix A. Scanning Authorization Letter

MEMORANDUM FOR ALL PERSONNEL

FROM: ICE Integrated Decision Support (IIDS) System, System Owner

SUBJECT: Security Assessment Team Authorization

1. I have asked [COMPANY CONDUCTING ASSESSMENT] personnel to conduct a security assessment for the ICE Integrated Decision Support (IIDS) System. The following individuals will be on station from [START DATE] to [END DATE] conducting physical and electronic penetration testing, interviews, and equipment testing while performing this assessment.

2. I expect all personnel to comply with their requests and to extend all necessary courtesies to them in order to ensure an accurate and timely assessment. These individuals are authorized 24-hour daily access to the following unit buildings, facilities, and access point:

3. If any questions should arise concerning this memorandum or the survey assessment execution, contact [CONTACT NAME] at [CONTACT PHONE DURING DUTY HOURS] during duty hours or [CONTACT PHONE DURING NON-DUTY HOURS] during non-duty hours.

SIGNATURE

PRINT NAME

TITLE

DATE

Appendix B. RTM

The RTM for System Name is included in this appendix.

The definition of the fields in the RTM are provided in Table B-1.

Table B-1. RTM Field Definitions

· Common. If the requirement is designated to one or more information systems.

· Hybrid. If the requirement is identified with two security control types: common and system-specific; i.e., a part of the requirement is identified as common type and another part of it is system-specific.

· System-Specific. If the requirement is assigned to a specific information system.

· Inherited. If the requirement is inherited from another system.

· Not Specified. If the requirement does not require any security control.

· I. Interview.

· E. Examine.

· T. Testing.

· In. The control was tailored in.

· Out. The control was tailored out.

· Met - Requirement fully satisfied.

· Not Met - Requirement not satisfied.

· Not Applicable - Requirement not applicable.

FOR OFFICIAL USE ONLY