Task 2 RMF_System and Communications Protection Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

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

Department of the {SERVICE}

{LOGO}

System and Communications Protection 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. DODM 5205.02-M, "DoD Operations Security (OPSEC) Program Manual"

iii. DoDI 8520.02, "Public Key Infrastructure (PKI) and Public Key (PK) Enabling"

iv. DoDI 8520.03, "Identity Authentication for Information Systems"

Table of Contents

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

FOR OFFICIAL USE ONLY

{ACRONYM} {DATE}

SYSTEM AND COMMUNICATIONS PROTECTION PLAN

Template developed by:

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

1.0 OVERVIEW

The purpose of this System and Communications Protection Plan is to manage the {ACRONYM} system and communications security infrastructure, and to protect its 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:

· SC-3 Security Function Isolation

· SC-6 Resource Availability

· SC-9 Transmission Confidentiality

· SC-11 Trusted Path

· SC-14 Public Access Protections

· SC-16 Transmission of Security Attributes

· SC-24 Fail in Known State

· SC-25 Thin Nodes

· SC-26 Honeypots

· SC-27 Platform-Independent Applications

· SC-29 Heterogeneity

· SC-30 Concealment and Misdirection

· SC-31 Covert Channel Analysis

· SC-32 Information System Partitioning

· SC-33 Transmission Preparation Integrity

· SC-34 Non-Modifiable Executable Programs

· SC-35 Honeyclients

· SC-36 Distributed Processing and Storage

· SC-37 Out-Of-Band Channels

· SC-40 Wireless Link Protection

· SC-41 Port and I/O Device Access

· SC-42 Sensor Capability and Data

· SC-43 Usage Restrictions

· SC-44 Detonation Chambers

SC-3

Table 1 - SP-800-53v4 Compliance Matrix

2.0 SYSTEM AND COMMUNICATIONS PROTECTION POLICY AND PROCEDURES

The following personnel have been provided a copy of this System and Communications Protection Plan (SCPP):

The SCPP covers {ACRONYM} and is required to be reviewed and updated yearly.

3.0 APPLICATION PARTITIONING

Information system management functionality includes, for example, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical. {ACRONYM} implements separation of system management-related functionality from user functionality through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.0 INFORMATION IN SHARED RESOURCES

{ACRONYM} prevents information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. {ACRONYM} implements object reuse through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

5.0 DENIAL OF SERVICE PROTECTION

A variety of technologies exist to limit, or in some cases, eliminate the effects of denial of service attacks. For example, boundary protection devices can filter certain types of packets to protect information system components on internal organizational networks from being directly affected by denial of service attacks. Employing increased capacity and bandwidth combined with service redundancy may also reduce the susceptibility to denial of service attacks. The following type of denial of service attacks have been defined:

· Volumetric - Also known as “floods,” the goal of this type of attack is to cause congestion and send so much traffic that it overwhelms the bandwidth of the site.

· TCP State-Exhaustion Attacks - This type of attack focuses on actual web servers, firewalls and load balancers to disrupt connections, resulting in exhausting their finite number of concurrent connections the device can support

· Application Layer Attacks - Targets weaknesses in an application or server with the goal of establishing a connection and exhausting it by monopolizing processes and transactions Only GiG connected systems are susceptible to denial of service attacks.

Is {ACRONYM} GiG connected?

☐ No

☐ Yes

If no, delete the content of Sections 5.1 – 5.6 and add the following statement for each section, “{ACRONYM} is not GiG connected, therefore it is not susceptible to denial of service attacks.”

If yes, does {ACRONYM} manage boundary devices?

☐ No

☐ Yes

If no, delete the content of Sections 5.1 – 5.6 and add the following statement for each section, “{ACRONYM} inherits boundary devices, which provide safeguards for denial of service attacks.”

If yes, complete Sections 5.1 – 5.6

5.1 Safeguards, Monitoring Tools and Internal Restrictions

{ACRONYM} utilizes the following safeguards, monitoring tools and internal restrictions:

Firewall – ACL IPS - Block Router Logs Firewall Logs IPS Logs User complaint

Firewall Logs IPS Logs

Firewall – ACL IPS - Block Router Logs Firewall Logs IPS Logs User complaint

5.2 Denial of Service Attack Protection or Limitation

{ACRONYM} utilizes the following safeguards to protect or limit denial of service attacks through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

5.3 Denial of Service Attack Internal Restrictions

{ACRONYM} utilizes the following safeguards to restrict the ability of individuals to launch denial of service attacks against other information systems through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

5.4 Denial of Service Excess Capacity, Bandwidth, or Redundancy {ACRONYM} utilizes the following safeguards to manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of denial of service attacks through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

5.5 Denial of Service System Resources

{ACRONYM} has defined the following system resources that will be monitored to ensure sufficient resources exist to prevent denial of service attacks:

5.6 Denial of Service Monitoring Process

In the event {ACRONYM} determines they are under a denial of service attack, the {ACRONYM} Incident Response Plan (IRP) will be initiated and the following process executed. Some activities in the below process cannot be directly executed by {ACRONYM}, therefore close coordination with {ACRONYM} is mandatory.

1) Identification

a. Detection and alerting:

i. Search for traffic patterns to expose known attacks (signature detection)

ii. Compare parameters of the observed network traffic with normal traffic (anomaly detection)

iii. Contact USCYBERCOM for early warnings and indicator notices

b. Attack analysis:

i. Identify the abused systems and services

ii. Understand if you are the target of the attack or a collateral victim

iii. Get a list of attacking IPs by tracing them onto the log files

iv. Define the attack’s profile by using network monitoring and traffic analysis tools

c. Mitigation acquirement /refinement:

i. Contact CNDSP to report the attack

ii. Ask for assessment and visibility into the attack

2) Containment

a. Network modifications:

i. Switch to alternative sites or networks using DNS or other mechanism

ii. Route traffic on scrubbing services and products

b. Content delivery control:

i. Use Caching/Proxing

ii. Enable alternative communication channels (VPN)

c. Traffic control:

i. Terminate unwanted connections or processes on servers and routers

ii. Configure outbound filters for reducing DDoS response footprint

iii. Control content delivery based on user and session details

3) Remediation

a. Bandwidth prioritization and blocking:

i. Deny connections using geographic information

ii. Deny connections based on IP and traffic signatures

iii. Place limits on the amount of traffic, maximum burst size, traffic priority on individual packet types

b. Sinkholing:

i. Attract DDoS traffic on the IP blocks advertised by the sinkhole to apply specialized analysis (MUST BE COORDINATED WITH CNDSP)

4) Recovery

a. Normal state verification:

i. Verify that traffic is nominal with no sharp increases. Let a period of time since last violation before the traffic flow is considered normal

ii. Ensure that the impacted services can be operational again

iii. Ensure that your infrastructure performance is back to your baseline

iv. Ensure that there are no collateral damages

b. Rollback:

i. Initiate suspended services, applications and modules

ii. Rollback the mitigation measures

iii. Announce the end of the incident

iv. Revert to your original network

5) Aftermath (Utilize the {ACRONYM} IRP After Actions Report Template)

a. Incident review and information Disclosure:

i. Evaluate the effectiveness of response

ii. Review the measures that could be taken to better address the incident response

iii. Review and refine attack-handling tools and procedures taken during the incident

iv. Create an incident review

v. Measure the operational impact

6.0 BOUNDARY PROTECTION

Any connections to the Internet, or other external networks or information systems, occur through managed interfaces consisting of appropriate boundary protection devices (e.g., proxies, gateways, routers, firewalls, guards, encrypted tunnels) arranged in an effective architecture.

Is {ACRONYM} GiG connected?

☐ No: Boundary Protection is not required.

☐ Yes

If no, delete the content of Sections 6.1 – 6.6 and add the following statement for each section, “{ACRONYM} is not GiG connected, therefore boundary protection is not required.”

If yes, does {ACRONYM} manage boundary devices?

☐ No: Boundary Protection is inherited

☐ Yes

If no, delete the content of Sections 5.1 – 5.6 and add the following statement for each section, “{ACRONYM} inherits boundary devices, which provide safeguards for denial of service attacks.”

If yes, complete Sections 5.1 – 5.6 {ACRONYM} prevents the unauthorized exfiltration of information across managed interfaces; defines the authorized sources of incoming communications and defines the authorized destinations for routing inbound communications through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1 Host Based Security System (HBSS)

{ACRONYM} manages the HBSS deployment and configuration, which implements McAfee Host Intrusion Prevention (HIPS) on all information system components.

6.2 Key Information Security Tools

{ACRONYM} manages the following key information security tools, which are isolated by implementing physically separate subnetworks with managed interfaces to other components of the system:

DELETE N/A Tools

6.3 Traffic Flow Policy

{ACRONYM} has established a traffic flow policy for each managed interface for each external telecommunication service. The policy protects the confidentiality and integrity of the information being transmitted through the use of source/destination filters. The configuration implements a deny all, permit by exception policy.

Does {ACRONYM} utilize VPN technologies?

☐ No: VPN not used.

☐ Yes

If yes, is {ACRONYM} configured to prevent the device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks?

☐ No

☐ Yes

Is {ACRONYM} configured to route protocols as designated by PPSM guidance (e.g. HTTPS, HTTP, FTP, SNMP) to any network external to the authorization boundary through authenticated proxy servers at managed interfaces?

☐ No

☐ Yes

6.4 Outgoing Traffic

Outgoing communications can pose a threat to other systems.

Is {ACRONYM} configured to detect outgoing communications traffic posing a threat to external information systems?

☐ No

☐ Yes

Is {ACRONYM} configured to deny outgoing communications traffic posing a threat to external information systems?

☐ No

☐ Yes

6.5 Auditing and Monitoring

Auditing and monitoring is crucial to the implementation of boundary protection mechanisms.

Is {ACRONYM} configured to audit the identity of internal users associated with denied outgoing communications traffic posing a threat to external information systems?

☐ No

☐ Yes

Does {ACRONYM} monitor and control communications at the external boundary of the system and at key internal boundaries within the system?

☐ No

☐ Yes

6.6 Boundary Configuration

The {ACRONYM} boundary is configured with the following requirements:

7.0 TRANSMISSION CONFIDENTIALITY AND INTEGRITY

This section applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and/or integrity of {ACRONYM} information can be accomplished by physical means (e.g., by employing protected distribution systems) or by logical means (e.g., employing encryption techniques).

Is {ACRONYM} network connected?

☐ No

☐ Yes

If yes, complete Sections 7.1 – 7.4 If no, delete the content of Sections 7.1 – 7.4 and add…