Task 2 RMF_System and Information Integrity Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

System and Information Integrity Plan Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

i. DoD Instruction 8510.01, "Risk Management Framework (RMF) for DoD Information Technology (IT)"

ii. CJCSM 6510.01B, "Cyber Incident Handling Program"

Table of Contents

Table 1 - SP-800-53v4 Compliance Matrix 1

FOR OFFICIAL USE ONLY

{ACRONYM} {DATE}

SYSTEM AND INFORMATION INTEGRITY PLAN

Template developed by:

http://www.i-assure.com FOR OFFICIAL USE ONLY

1.0 OVERVIEW

The purpose of this System and Information Integrity Plan is to allow (SYSTEM NAME} to perform its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of its software, firmware and information.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix A, “Detailed Compliance Matrix”.

The following Assessment Procedures have not been allocated by NIST:

· SI-13 Predictable Failure Prevention

· SI-14 Non-Persistence

· SI-15 Information Output Filtering

Table 1 - SP-800-53v4 Compliance Matrix

2.0 FLAW REMEDIATION

Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified.

2.1 Flaw Remediation Process

{ACRONYM} centrally manages flaw remediation following the below process, which is also referenced in the Configuration Management Plan. During the process, {ACRONYM} tracks the time from identification through remediation based on the time/date stamps of the ACAS or SCAP scans. Flaws, inclusive of software and firmware are tested for effectiveness and potential side effects before installation to all assets. As noted in the below process, flaws that cannot be remediated are annotated in the POA&M. All fla

2.2 Host Based Security System (HBSS)

HBSS is suite of software applications used within the DOD to monitor, detect, and defend the DOD computer networks and systems.

Is {ACRONYM} GiG connected?

☐ No: HBSS is not required.

☐ Yes

If no, delete following information.

If yes, does {ACRONYM} manage HBSS?

☐ No: HBSS is inherited.

☐ Yes

If no, delete following section.

{ACRONYM} is configured to employ automated mechanisms continuously with HBSS; 30 days for any additional internal network scans not covered by HBSS; annually for external scans by (Computer Network Defense Service Provider) CNDSP to determine the state of information system components with regard to flaw remediation through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

2.3 Software Removal

{ACRONYM} removes all upgraded/replaced software/firmware components that are no longer required for operation (e.g., previous versions) after updated versions have been installed through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

2.4 Flaw Identification

{ACRONYM} utilizes the following process to identify information system flaws and update the POA&M as required:

3.0 MALICIOUS CODE PROTECTION

Malicious code includes, for example, viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within compressed or hidden files, or hidden in files using steganography. Malicious code can be transported by different means including, for example, web accesses, electronic mail, electronic mail attachments, and portable storage devices. Malicious code insertions occur through the exploitation of information system vulnerabilities.

3.1 Malicious Code Management

Malicious code protection mechanisms should be centrally managed for GiG connected systems, or configured individually for standalone or closed enclave environments. For GiG connected systems, malicious code protection should be managed through HBSS.

Is {ACRONYM} GiG connected?

☐ No: HBSS is not required.

☐ Yes: HBSS is deployed to manage malicious code protection.

If no, does {ACRONYM} utilize malicious code protection tools?

☐ No

☐ Yes: Enter tool name, i.e. McAfee, Symantec, etc...

3.2 Malicious Code Analysis

Analysis of malicious code follows the {ACRONYM} Incident Response Plan (IRP). As a Tier-2 entity, {ACRONYM} is not permitted, nor equipped with the properly trained personnel or tools to deconstruct malicious code for analysis. In the event protection tools discover malicious code, the IRP will be followed and higher authorities contacted.

3.3 Malicious Code Tool Configuration

{ACRONYM} utilizes {TOOL NAME} as its malicious code protection tool, which is configured per the following sections to ensure compliance with applicable requirements.

Malicious Code Tool Update {TOOL NAME} is configured to automatically update malicious code protection mechanisms through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

{TOOL NAME} is configured to update malicious code protection mechanisms whenever new releases are available through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

Malicious Code Tool Location {ACRONYM} has installed {TOOL NAME} on all assets within the accreditation boundary. {TOOL NAME} monitors all entry and exit point into {ACRONYM}.

Malicious Code Tool Eradication {ACRONYM} has installed {TOOL NAME} on all assets within the accreditation boundary. {TOOL NAME} is configured to eradicate malicious code when found in accordance with the appropriate STIG.

Malicious Code Tool Real Time Scans Real time scans ensure that {ACRONYM} is protected from malicious code at all times. Real time scans can be performed at the network boundary and/or on the individual asset.

Is {ACRONYM} GiG connected?

☐ No: Network based entry/exit points do not exist.

☐ Yes: HBSS is deployed to manage malicious code protection.

If no, delete following.

If yes, does {ACRONYM} manage network entry/exit points?

☐ No

☐ Yes: Enter tool name, i.e. proxy, firewall, gateway, etc...

{TOOL NAME} is configured to perform real-time scans of files from external sources at endpoints as the files are downloaded, opened, or executed through implementation of the following STIG/SRG requirements:

Malicious Code Tool Periodic Scans {TOOL NAME} is configured to perform periodic scans of {ACRONYM} every 7 days through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

Malicious Code Tool Alerts {TOOL NAME} is configured to perform block and quarantine malicious code and then send an alert to the administrator immediately in near real-time in response to malicious code detection through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS