COMMERCIAL SOLUTIONS for CLASSIFIED

(CSfC)

Continuous Monitoring

Annex 1.1.0

Version 1.1.0

2 March 2021 i

CHANGE HISTORY

Title Version Date Change Summary

Continuous Monitoring (CM) Annex

1.0 4 August 2021 Initial release of CSfC Continuous Monitoring

Annex.

Continuous Monitoring (CM) Annex

1.1.0 2 March 2023

Added requirement for logs and SIEM to be review at least once a week.

Added Campus WLAN Tactical use case to the Tactical Appendix ii

Table of Contents

1 Introduction

2 Purpose and use

3 Legal Disclaimer

4 Continuous Monitoring Solution Overview

4.1 Monitoring Solution Overview

4.2 Monitoring Data Sources

4.3 Security Information and Event Management (SIEM)

4.3.1 Gray Management SIEM

4.3.2 Red Management SIEM

4.4 Dataflow Model

5 Monitoring Points

5.1 Monitoring Point 1 (MP1): Black Data Line

5.1.1 WIDS/WIPS

5.2 Monitoring Point 2 (MP2): Gray Data Line

5.3 Monitoring Point 3 (MP3): Gray Data Line

5.4 Monitoring Point 4 (MP4): Red Data Line

5.5 Monitoring Point 5 (MP5): Red Data Line

5.6 Monitoring Point 6 (MP6): Gray Management

5.7 Monitoring Point 7 (MP7): Red Management

5.8 Monitoring Point 8 (MP8): End User Device (EUD)

5.9 Deployment of Monitoring Points Supporting Multiple-CPs

6 Consolidated Monitoring

6.1 Black Network

6.2 Gray Network

6.3 Red Network

7 Multiple Inner Enclaves

8 Multi-Site Environments

8.1 Standalone Configuration

8.2 Centrally Managed Configuration

9 Monitoring In a High Availability Environment iii

10 Continuous Monitoring Requirements

10.1 Threshold and Objective Requirements

10.2 Requirements Designators

10.3 Matrix of CP and Required Monitoring Points

10.4 CM Monitoring Point Requirements

10.5 Network Monitoring Requirements

10.6 MP1 Requirements (Data Network Between Outer Firewall & Outer Encryption Component) 36

10.7 MP2 Requirements (Data Network Between Outer Encryption Component & Gray Firewall) .. 37

10.8 MP3 Requirements (Data Network Between Gray Firewall & Inner Encryption Component) ... 38

10.9 MP4 Requirements (Data Network Between Inner Encryption Component & Inner Firewall) .. 39

10.10 MP5 Requirements (Data Network After Red Firewall)

10.11 MP6 Requirements (Gray Management Network)

10.12 MP7 Requirements (Red Management Network)

10.13 MP8 Requirements (End User Device)

10.14 Logging Requirements

10.15 General Requirements

10.16 SIEM Requirements

10.17 Multi-Inner Enclave Requirements

10.18 Multi-Site Requirements

10.19 Consolidated Monitoring Requirements

Appendix A. Acronyms

Appendix B. Definitions

Appendix C. References

Appendix D. Tactical Solution Continuous Monitoring Implementations

Tactical Implementation Continuous Monitoring

Table of Figures

Figure 1. Continuous Monitoring Solution – MA CP

Figure 2. Continuous Monitoring Solution – Multi-Site Connectivity CP

Figure 3. Continuous Monitoring Solution – Campus WLAN CP iv

Figure 4. Examples of Monitoring Functions

Figure 5. Gray Management SIEM

Figure 6. Red Management SIEM

Figure 7. Data Lifecycle

Figure 8. Monitoring Point 1: Black Data Line

Figure 9. Monitoring Points 2 and 3: Gray Data Line

Figure 10. Monitoring Points 4 and 5: Red Data Line

Figure 11. Monitoring Point 6: Gray Management Line

Figure 12. Monitoring Point 7: Red Management Line

Figure 13. Monitoring Point 8: EUD

Figure 14. Deployment of Multiple CPs

Figure 15. Consolidating Monitoring

Figure 16. CDS Black Network

Figure 17. CDS Gray Network

Figure 18. CDS Red Network

Figure 19. Multiple Inner Enclaves

Figure 20. Centralized Management

Figure 21. High Availability Environment

List of Tables

Table 1. Monitoring Function Overview

Table 2. Capability Package Descriptions

Table 3. Requirement Digraphs

Table 4. Required MP Deployments for CSfC Solutions

Table 5. CM Monitoring Point Requirements

Table 6. MP1 Requirements

Table 7. MP2 Requirements

Table 8. MP3 Requirements

Table 9. MP4 Requirements

Table 10. MP5 Requirements

Table 11. MP6 Requirements

Table 12. MP7 Requirements v

Table 13. MP8 Requirements

Table 14. Logging Requirements

Table 15. General Requirements

Table 16. Security Information and Event Management (SIEM) Requirements

Table 17. Multi-Inner Enclave Requirements

Table 18. Multi-Site Requirements

Table 19. Consolidated Monitoring Requirements

Table 20. Tactical Implementation Continuous Monitoring Overlay Requirements

1 INTRODUCTION

The Commercial Solutions for Classified (CSfC) Program within the National Security Agency’s (NSA’s)

Cybersecurity Directorate (CSD) publishes guidance to empower its customers to implement secure communications solutions using independent, layered Commercial-off-the-Shelf (COTS) products. This guidance is product-neutral and describes system-level solution frameworks documenting security and configuration requirements for customers and/or integrators.

CSD delivers guidance to meet the needs of customers implementing Continuous Monitoring (CM) of data in transit solutions using approved cryptographic algorithms and National Information Assurance

Partnership evaluated components.

2 PURPOSE AND USE

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-137 defines information security continuous monitoring as, "maintaining ongoing awareness of information security, vulnerabilities, and threats to support organization risk management decisions.” With respect to CSfC solutions, CM enables the following:

Defines a baseline set of expected system and network behavior within a CSfC solution environment

Detects improperly configured products within solutions to achieve a level of assurance sufficient for protecting classified data in transit

Analyzes system activities to identify unauthorized activity within a CSfC solution network

CM is implemented as part of a holistic, risk management and defense-in-depth information security strategy integrated into CSfC architectures. Organizations designing CSfC solutions and implementing

CM capabilities should leverage information gathered from CM capabilities to take appropriate risk mitigation actions and make cost-effective, risk-based decisions regarding the operation of CSfC systems.

Guidance provided in the CM Annex references architecture and corresponding high-level configuration information to help customers develop a CM solution to meet CSfC CM requirements. To implement a

CM solution based on this guidance, all Threshold requirements, or the corresponding Objective requirements, must be implemented as described in Section 10.

The requirements in this document supersede existing CM requirements in published CSfC Capability

Packages (CP). Future CP revisions will direct customers to this annex for CM implementation.

Please provide comments on the usability, applicability, and/or shortcomings of this guidance to an NSA

Client Advocate and the CM guidance maintenance team at CSfC_CM_team@nsa.gov. Solutions adhering to this guidance must also comply with Committee on National Security Systems (CNSS) policies and instruction.

mailto:CSfC_CM_team@nsa.gov

For any additional information on Cross Domain Solutions (CDS) contact the National Cross Domain

Strategy Management Office (NCDSMO) at ncdsmo@nsa.gov.

3 LEGAL DISCLAIMER

This guidance is provided “as is”. Any express or implied warranties, including but not limited to, the implied warranties of merchantability and fitness for a purpose are denied. In no event must the United

States Government be liable for any direct, indirect, incidental, special, exemplary or consequential damages (including, but not limited to, procurement of substitute goods or services, loss of use, data, or profits, or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this guidance, even if advised of the possibility of such damage.

The user of this guidance agrees to hold harmless and indemnify the United States Government, its agents and employees from every claim or liability (whether in tort or in contract), including attorney’s fees, court costs, and expenses, arising in direct consequence of Recipient’s use of the item, including, but not limited to, claims or liabilities made for injury to or death of personnel of User or third parties, damage to or destruction of property of User or third parties, and infringement or other violations of intellectual property or technical data rights.

This guidance is not intended to constitute an endorsement, explicit or implied, by the U.S. Government of any manufacturer’s product or service.

4 CONTINUOUS MONITORING SOLUTION OVERVIEW

This CM Annex provides guidance for the collection and analysis of network and security data to enable

CM within a deployed CSfC solution. Given CSfC’s data-in-transit multi-layered approach to encryption, failure of one or more components may result in observable network behavior that significantly deviates from established baselines. For example, these deviations may manifest as unexpected protocols, port usage, packet size, or Internet Protocol (IP) addresses.

CSfC CM capabilities are designed with a multi-layer approach to compliment the functional architecture of a CSfC solution. CSfC CM solutions provide high visibility across the monitored network, allowing analysts to validate the operational status of encryption components by observing network activity both before and after encryption points and within management networks.

Eight (8) distinct Monitoring Points (MPs) are defined within the CSfC CM architecture. These MPs are positioned in strategic locations across the Black, Gray, and Red Networks (see Figures 1, 2, & 3). Each

MP represents a critical point within the CSfC infrastructure where monitoring capabilities grant visibility into system and network behavior; but does not necessarily represent a physical point where monitoring will be deployed. Customers have the flexibility to deploy solutions that will meet their needs.

An MP may be comprised of one or more monitoring capabilities. A monitoring capability is the implementation of a specific monitoring system that feeds data to collection, analysis, and notifying systems for CSfC solutions operators (see Section 5).

mailto:ncdsmo@nsa.gov

Comprehensive data collection and aggregation from each MP into centralized monitoring Security

Information and Event Management (SIEM) systems provide security administrators with the capability to monitor data sources from within a network. SIEM solutions present security administrators with the collective data set to monitor the security posture of the CSfC solution and report on security relevant events within the infrastructure. These tasks are often accomplished through a defined set of automated notifying capabilities and dashboards built to identify targeted information of interest.

Additional information about SIEMs is discussed in Section 4.3.

In addition to technical CM implementation, broader CM success relies on the implementation of site-specific policies and procedures for managing the CM infrastructure. Security administrators should have defined roles and responsibilities to review and generate timely meaningful analysis of the data.

Organizations should have defined policies and procedures for managing findings and making a sound risk-based decision during incident response/remediation. The scope of this document does not delve into these components in detail, however customers are expected to develop their own policies and procedures in accordance with local policies and Authorizing Official (AO) guidance.

4.1 MONITORING SOLUTION OVERVIEW

The diagrams that follow, reference MP placement for each CSfC CP solution.

Figure 1. Continuous Monitoring Solution – MA CP

Figure 2. Continuous Monitoring Solution – Multi-Site Connectivity CP

Figure 3. Continuous Monitoring Solution – Campus WLAN CP

4.2 MONITORING DATA SOURCES

Data for the CM solution can come from many application, network, and security sources, including but not limited to: Network Taps, network security monitoring tools such as Intrusion Detection

System/Intrusion Prevention System (IDS/IPS), host-based security monitoring tools, network vulnerability scanning, system event logging, and Wireless Intrusion Detection System (WIDS)/Wireless

Intrusion Prevention System (WIPS). Network Monitoring Data is information about network traffic traversing the solution. This data can include full packet captures or meta-data about traffic, comprised of information gathered from Network TAPs, Port Mirrors, Network Flow, or IDS/IPS.

Table 1. Monitoring Function Overview

Monitoring Functions Description

Network Tap In-line “bump in the wire” which copies all network traffic. End targets for this data are typically a data collection server or IDS/IPS to monitor for unauthorized network traffic.

Port Mirroring Configured on network devices, port mirrors duplicate network traffic on the device to a destination on a specified network port. Provides similar functionality as a Network Tap.

Network Flow Network protocol providing IP traffic information for monitoring purposes.

System Logging Local system event logging functionality providing logs generated from services such as application, security, and host operating systems.

Intrusion Detection System (IDS) / Intrusion Prevention System (IPS)

A device or software application that monitors a network or system for malicious activity or policy violations. Includes network-based Intrusion Detection System (IDS) and host-based IDS solutions.

Network Scanning The collection of tools providing Vulnerability and Network Scanning capabilities.

WIDS/WIPS A component or group of components that monitors the WLAN Access System wireless connects for malicious activity or policy violations.

Network Taps are standalone devices deployed within an infrastructure to copy all network traffic, known as raw network traffic, and send to another system for analysis and retention. Network Taps are most useful when integrated with an IDS/IPS to provide real time monitoring, inspection, and notification generation on unexpected or anomalous network traffic. Network tap data can be stored on a collection server to maintain a history of all network activity. For customers implementing network taps, consideration may be made for a solution utilizing one-way cyber tap or a NSA evaluated diode to transmit directly to higher classification networks from these tap points. This option enables consolidation of network data without requiring the data flow to transmit through a CDS to monitoring solutions analyzing the data. Cyber Taps must be compliant with the NCDSMO document "Cyber One-

Way Taps Technical Requirements" v1.0 or higher and deployed within the manner described in this document. This document can be obtained by emailing the NCDSMO at ncdsmo@nsa.gov.

Port mirroring provides a similar capability as a Network Tap; however, this functionality is deployed on network devices verses standalone devices. Network devices implementing port mirroring include both physical and virtual switching devices. A port mirror capability should direct traffic to a dedicated port mirror interface to a collection server or IDS/IPS. When considering implementation of this capability, customers should assess their expected network volumes to ensure port mirroring can be reliably performed.

Network flow data (e.g., NetFlow, J-Flow, IPFIX, NetStream) is generated from network devices, such as routers, switches, and standalone probes. Network flow data provides characterization of network traffic flow that includes information such as IP protocols, source and destination IP addresses, source and destination ports, and traffic volume on a per session basis. Conducting analysis of network flow mailto:ncdsmo@nsa.gov data requires establishing a baseline for network behavior, updating it on a continual basis, and developing triggers for notification generation when customer-defined thresholds have been exceeded.

Network flow data should be reviewed regularly to identify anomalies such as systems generating excessive amounts of traffic, devices trying to connect to improper IP addresses, and clients trying to connect to closed or undefined ports.

System logging capabilities are broad and include operating system, application and security relevant events, generated health and status notifications, and any other data generated by a system.

Granularity needs of system logging may vary from customer to customer. Customers should become familiar with system logging severity levels to determine what level of logging is appropriate for their monitoring needs. To protect the confidentiality and integrity of the data, all system logging data should be encrypted with Secure Shell (SSH), Transport Layer Security (TLS), or Internet Protocol Security (IPsec) when sent to the collection server.

End User Devices (EUD) can be configured with host-based solutions, often referred to as endpoint detection systems or endpoint applications. To complement system logging, endpoint detection systems allow for collection of endpoint and network events to analyze and detect whether anomalous activity is present. Endpoint solutions may provide for local notification and technical preventative actions in the event an alarm is triggered. Customers may choose to feed this back to a central collection server within the enterprise for analysis.

An IDS monitors network behavior or systems for malicious activity or policy violations. IDSs are implemented in one of two configurations: either they are configured to receive network traffic from a

Network Tap or port mirror interface, or deployed inline on the network. IDSs should be configured to generate notifications when unknown or unexpected traffic is observed. A complementary technology to IDSs are Intrusion Prevention Systems (IPS). An IPS carries out automated actions such as dropping malicious packets, blocking traffic, or resetting connections through the use of signature-based and/or statistical anomaly detection in addition to the functions provided from an IDS.

Network Scanning tools encompass the suite of solutions performing Vulnerability Scanning and

Network Device enumeration. These systems allow continuous scanning of systems within a network to search for known vulnerabilities, document system configurations to confirm configuration compliance is maintained, or identify unexpected systems connected to the network.

A WIDS monitors the behavior, infrastructure and clients of a WLAN Access System for malicious activity or policy violations. WIDSs should be configured to generate notifications when unknown or unexpected events are observed. A complementary technology to WIDSs is a WIPS. A WIPS carries out automated actions such as dropping malicious clients blocking unauthorized clients, or resetting connections to the WLAN Access System through the use of signature-based and/or statistical anomaly detection in addition to the functions provided from a WIDS. For more information and requirements see CSfC WIDS/WIPS Annex.

Figure 4 is an example of the monitoring functions that a customer may consider for placement within a

CSfC network architecture to collect relevant data for CM.

Figure 4. Examples of Monitoring Functions

4.3 SECURITY INFORMATION AND EVENT MANAGEMENT (SIEM)

Security Information and Event Management, or "SIEM" systems, are designed to collect, aggregate, correlate, and analyze security event data from CSfC components. Data should be sent to the SIEM from the following sources: hardware devices, virtual machines, security appliances, and software and services running within the solution network(s). Within a CSfC solution network, a properly configured

SIEM can provide near real-time support for data-driven risk management decisions via reporting dashboards and security administrator querying capability across all data sources. The term ‘SIEM’ covers both proprietary and open-source solutions, which can be hosted within the solution or on a separate network outside the solution, protected at the highest security that the solution supports.

When configured correctly, this functionality presents customers with a holistic view of the status of their solution network to detect anomalies and system events that may impact performance or security posture of the environment.

CSfC customers, integrators, and solution owners standing up new, or adding to existing SIEM capabilities, can expect the following benefits:

Increased data confidentiality, integrity, and availability

Greater visibility of security-related network events

Improved network resilience, despite the ever-changing cyber threat landscape

Easier tracking of hardware and software information technology assets throughout the enterprise

Enhanced support for organizational change management processes

SIEMs enable a ‘big picture view’ for observing expected system and network behavior, and defining thresholds for reportable events. Over time as event data is collected, security administrators should be able to better identify behavioral changes which may indicate a failure of security components, misconfiguration, subversion, or attempted subversion of implemented security controls.

SIEMs should provide notification when anomalous behavior is detected. Security administrators should monitor and review monitoring dashboards on a frequency determined by the AO or relevant governing policy, but done at least once a week (7 Days). Implementation of automated notifications is encouraged to enable security administrators to hone in on metrics operating outside of expected thresholds. To verify compliance and adjust given operational risk decisions made within customer organizations baseline controls and tolerance thresholds should be reviewed on an as needed basis as determined by the AO.

Results from SIEM reporting mechanisms should directly support Incident Response activities for an organization. The metrics gathered and ability to search through historical data should enable security administrators to review event data.

4.3.1 GRAY MANAGEMENT SIEM

Figure 5. Gray Management SIEM

The Gray Management SIEM collects and analyzes log and network monitoring data from the Outer

Encryption Component, Gray Firewall, and other Gray Service components in both the Data and

Management lines. Log data may be encrypted while traversing the Gray Network to maintain its confidentiality and integrity. Gray Management SIEM notifications must be reviewed by a security administrator at regular intervals defined by the mission, and approved by the AO, or governing policies but must be done at least once a week (7 Day).

The SIEM is configured to provide notifications for specific events. For example: if the Outer Encryption

Component or Gray Firewall receives and drops any unexpected traffic, it could indicate a compromise of the Outer Firewall or Outer Encryption Component. A Gray Management SIEM may be used to aggregate log data from Black components when used in conjunction with an approved CDS (see Section

6.2). When an approved CDS is used, the data collected from Gray Network systems can be sent to the

Red Network where these functions can be performed on a Red Management SIEM (see Section 6.3).

4.3.2 RED MANAGEMENT SIEM

Figure 6. Red Management SIEM

The Red Management SIEM collects and analyzes log and network monitoring data from the Inner

Encryption Component, Inner Firewall, and other Red Management Service components in both the

Data and Management lines. Log data may be encrypted while traversing the Red Network to maintain confidentiality and integrity. Red Management SIEM notifications must be reviewed by a security administrator at a regular interval defined by the mission and approved by the AO or relevant governing policies but must be done at least once a week (7 Days).

Customers are encouraged to leverage existing enterprise SIEM capabilities if available within their network architecture. A Red Management SIEM may be used to aggregate log data from Black and/or

Gray Network components when used in conjunction with an approved CDS (see Section 6.3).

4.4 DATAFLOW MODEL

Figure 7. Data Lifecycle

A CM data lifecycle model is a process, customers should define as part of their systems development, integration, and maintenance plans. This document defines three primary activities within the CM lifecycle dataflow for integrator consideration. In addition to the below guidance, customers should consult existing best practices for storing, maintaining, and aging off data used for monitoring purposes.

Data Collection

Collection of monitoring data within a CSfC solution takes many forms as referenced in Section

4.2.Consideration must be made to balance expected monitoring data collected against network bandwidth and available storage for monitoring data, especially for customers performing remote logging and centralized management functions. Appropriate logging levels required from network devices and services, EUDs, and other log generating elements must be determined by customers’ requirements outside of meeting specified logging events as defined in the CM Requirements. Most network devices allow privileged users to configure logging facilities at different logging levels, such as

‘debug,’ ‘informational,’ and ‘warning.’ Some logging levels repeat data or may prove to be overly verbose for customer’s needs. Superfluous information fills data storage and triggers data reallocation more frequently. Proper data hygiene is critical to maximizing available storage.

Data Retention

Data retained from collection activities should be backed up at regular intervals. Data can be aggregated in higher classification networks through the use of an approved CDS. Data retention should be analyzed for data sent to CM collection points and local device storage. In the event network-based solutions fail – security administrators must be able to fall back to local logging facilities to view event data. Retention policies must be defined in the data lifecycle plan as approved by the AO but is recommended to store logs for a minimum of one year.

Data Reallocation

With a limited amount of data storage, a data reallocation strategy must be addressed. To prevent processes from encountering completely full storage devices, old data should be erased at regular intervals and backed up per local data storage policies. In addition, processes should be restarted at regular intervals to flush memory, stop memory leaks, and clear temporary files. Older data that is no longer required to provide meaningful results to on-demand queries may be considered for longer term storage.

Consolidated Monitoring

The CM solution architecture is designed to maintain separation of Black, Gray and Red monitoring data within each security domain. Dividing monitoring data into discrete sectors presents a challenge to track and correlate system and network events across each of the domains and requires the implementation of separate infrastructure components to collect and manage monitoring data.

Consolidated monitoring within CSfC is the process by which monitoring data is moved into a single environment to track and manage. This “single pane of glass” environment enables security administrators to monitor their infrastructure from a single location and reduce the monitoring footprint within the Black and Gray domains at the expense of implementations of data transfer solutions (see Section 6).

5 MONITORING POINTS

Each subsection below expands upon the intent of each MP, defines the scope of traffic transiting the

MP, expected MP functionality, and types of notifications generated by MP systems.

MPs are a collection of one or more monitoring functions (See Table 1). Each MP is designed to give visibility into a particular network segment and detect malicious activity or misconfigured components.

While customers are only required to implement a subset of all possible MPs (see Section 6), each additional MP over the minimum required will increase network visibility and enhance the security posture of the customer. It is strongly encouraged to implement as many MPs as the customer can reasonably support.

5.1 MONITORING POINT 1 (MP1): BLACK DATA LINE

MP1 is located within the Black Network to monitor the data network between the Outer Firewall and

Outer Encryption Component. Monitoring solution(s) should be configured to generate a notification upon detection of any traffic that should have been blocked by the Outer Firewall. These notifications may indicate a failure of the Outer Firewall’s filtering functions and may be evidence of either an improper configuration, a potential compromise, or attempts to make unauthorized connections to the

Outer Encryption Component(s).

The two key components within the Black Network segment are the Outer Firewall and MP1. The recommended solution receives data from both devices on a single Black Data collection server. In addition, flow data from the Black Network can be collected from the Outer Firewall and sent to a Black

Network collection server. If MP1 is implemented, then network monitoring data must be collected from the chosen monitoring solution.

Normal traffic at MP1 is well-defined. Traffic traversing the Black Firewall to the Outer Encryption

Component should be limited to the ports and protocols required to support the outer encryption layer:

IPSec, Media Access Control Security (MACsec), and a limited number of control plane protocols as required per customer implementation. Inbound traffic should only be destined for the Outer

Encryption Component IP address, all outbound traffic not matching preexisting inbound sessions should be blocked and only traffic sourced from the outer encryption IP address should be allowed.

Since nearly all traffic traversing MP1 is encrypted, network monitoring capabilities are limited to analyzing IP addresses, MAC Addresses, ports, protocols, and flow data. Management of MP1 components occurs within the Black Network.

5.1.1 WIDS/WIPS

For Campus Wireless Local Area Network (WLAN) CP solutions, MP1 does not exist in the traditional sense as deployed in “Wired” CSfC CP in the Black Network Infrastructure. MP1 for WLAN solutions consists of Wireless WIDS capabilities within the wireless infrastructure. For more information and requirements on WIDS see CSfC WIDS/WIPS Annex.

For MA CP solutions using the government private wireless a WIDS must be used to monitor the

Wireless Access System. For more information and requirements on WIDS see CSfC WIDS/WIPS Annex.

Figure 8. Monitoring Point 1: Black Data Line

5.2 MONITORING POINT 2 (MP2): GRAY DATA LINE

MP2 is located within the Gray Network to monitor the data network between the Outer Encryption

Component and Gray Firewall.

Normal traffic at MP2 is not as narrowly defined as MP1, however a restricted set of traffic is expected.

This set of traffic includes, but may not be limited to, IPsec, TLS, MACsec, data plane traffic encrypted with TLS or Secure Realtime Transport Protocol (SRTP), and customer defined control plane traffic (e.g., client Domain Name System (DNS) requests, Hypertext Transfer Protocol (HTTP) requests for Certificate

Revocation List (CRL), Address Resolution Protocol, Spanning Tree Protocol). The network address at

MP2 should be well known and easy to monitor for any anomaly and should resemble the following: IP traffic from clients or remote encryption components will have their IP addresses defined client IP address pools assigned from Outer Encryption Components or statically assigned and will only communicate with Gray Data Services Network components and/or Inner Encryption Components.

The monitoring infrastructure should be configured to generate a notification upon detection of any traffic that should have been blocked by the Outer Encryption Component or Gray Firewall. These notifications may indicate a failure of the Gray Firewall or Outer Encryption Component’s filtering functions and may be evidence of either an improper configuration or a potential compromise. All security event data must be sent to a collection server located within the Gray Management Network and may be fed into the SIEM solution.

If MP2 is implemented, then network monitoring data must be collected from the chosen monitoring solution. Network flow data from the Gray Network should be collected from the Outer Encryption

Component and Gray Firewall and sent to a collection server in the Gray Management Network. If additional network devices are deployed between these two components, it is recommended that network flow data be sent to the collection server as well. This method of data collection may aggregate data in such a way that MP2 and MP6 requirements may be satisfied. Customers should evaluate for MP compliance when designing their monitoring architecture.

Nearly all traffic traversing MP2 is encrypted with IPsec, MACsec, TLS, or SRTP, which prevents deep packet inspection of client data traffic. Management of MP2 occurs within the Gray Management

Services Network.

Figure 9. Monitoring Points 2 and 3: Gray Data Line

5.3 Monitoring Point 3 (MP3): Gray Data Line

MP3 is located within the Gray Network to monitor the data network between the Gray Firewall and

Inner Encryption Component(s).

Normal traffic at MP3 should be a subset of data transiting MP2. Traffic observed at this MP should only include communications with the Inner Encryption Components. Types of traffic include IPSec, TLS, MACsec, data plane traffic encrypted with TLS or SRTP, and control plane traffic necessary for network health and management. Source IP addresses from inbound client traffic should be restricted to assigned Outer Encryption IP address pools and destination IPs should be to Inner Encryption

Components.

The monitoring infrastructure should be configured to generate a notification upon detection of any traffic that should have been blocked by the Gray Firewall or sent by the Inner Encryption Component(s) that is not expected. These notifications may indicate a failure of the Gray Firewall’s filtering functions and may be evidence of an improper configuration or a potential compromise of the Firewall or Inner

Encryption Component. All security event data must be sent to a collection server located within the

Gray Management Network and may be fed into the Gray SIEM solution.

If MP3 is implemented, then network monitoring data must be collected from the chosen monitoring solution. Network flow data from the Gray Network should be collected from the Gray Firewall and sent to a collection server in the Gray Management Services.

Nearly all traffic traversing MP3 is encrypted either with IPsec, MACsec, TLS, or SRTP, which prevents deep packet inspection of client data traffic. Management of MP3 occurs within the Gray Management

Services Network.

5.4 Monitoring Point 4 (MP4): Red Data Line

MP4 is located within the Red Network to monitor the data network between the Inner Encryption

Component and Inner Firewall.

Expected traffic for MP4 must be defined by the customer and should be limited to only those required for end users to perform their mission. Ports, protocols, and destination IP addresses should be documented within the solutions registration package and implemented into Red Network security components to restrict traffic flow to allowed services only. Source IP addresses should be well defined from the IP address pool assigned by the Inner Encryption Component.

Monitoring capabilities should take into consideration the defined set of allowed traffic and develop appropriate reporting and notification mechanisms to identify anomalies within their network. The monitoring infrastructure should be configured to generate a notification upon detection of any traffic that should have been blocked by the Inner Encryption Component or the Inner Firewall. These notifications may indicate a failure of the Inner Encryption Component’s or Inner Firewall filtering functions and may be evidence of an improper configuration or a potential compromise. All security event data must be sent to a collection server located within the Red Management Services Network and may be fed into the Red SIEM solution.

If MP4 is implemented, then network monitoring data must be collected from the chosen monitoring solution. Network flow data from the Red Network must be collected from the Inner Encryption

Component and Inner Firewall and sent to a collection server in the Red Management Network.

Deep packet inspection is feasible for MPs deployed in the Red Network. The customer may consider deploying solutions to collect and analyze client traffic at this point in the network. Management of the

MP4 monitoring point occurs within the Red Management Services.

Figure 10. Monitoring Points 4 and 5: Red Data Line

5.5 Monitoring Point 5 (MP5): Red Data Line

MP5 is located within the Red Network to monitor the data network between the Inner Firewall and the

Red Data network.

Expected traffic for MP5 must be defined by the customer and should be limited to only those required for end users to perform their mission. Ports, protocols, and destination IP addresses should be documented within the solution’s registration package and implemented into Red Network security components to restrict traffic flow to allowed services only. Source IP addresses should be well defined from the IP address pool assigned by the Inner Encryption Component.

Monitoring capabilities should take into consideration the defined set of allowed traffic and build appropriate reporting and notification mechanisms for security administrator to identify anomalies within their network. The monitoring infrastructure should be configured to generate a notification upon detecting any traffic that should have been blocked by the Inner Firewall or detecting unexpected traffic sent from the Red Network destined for the EUD or Inner Encryption Component. These notifications may indicate a failure of the Inner Encryption Component’s, or Inner Firewall filtering functions and may represent an improper configuration or a potential compromise. All security event data must be sent to a collection server located within the Red Management Network and may be fed into the Red SIEM solution.

If MP5 is implemented, then network monitoring data must be collected from the chosen monitoring solution. Network flow data from the Red Network must be collected from Inner Firewall and sent to a collection server in the Red Management Network.

Deep packet inspection is feasible for MPs deployed in the Red Network. The customer may consider deploying solutions to collect and analyze client traffic at this point in the network. Solutions such as proxies may be considered to inspect encrypted traffic at MP5 or within the Red Network. If deployed in

MP5, is it recommended to configure notifications and analysis capabilities where feasible with the Red

SIEM. Management of the MP5 monitoring point occurs within the Red Management Services.

5.6 Monitoring Point 6 (MP6): Gray Management

MP6 is located within the Gray Management Network to monitor the management network deployed in the Gray Network. MP6 is required in all CSfC CM Solutions. The aggregate of data collected for MP6 must provide security administrators visibility of all network and system behavior on the Gray

Management Network to meet specified MP6 requirements.

Data collected at MP6 may include but is not limited to: system log data, network flow data from the

Outer Encryption Component and Gray Firewall, Network Tap traffic, IDS/IPS notifications, inline IDS/IPS traffic/notifications, and span port or port mirroring. All traffic source and destination address should be within the subset of management network IP addresses. All data should be destined to the data collection system and ultimately the SIEM solution for aggregation and analysis. Gray Management

Network traffic destined for the Outer Encryption Component, Gray Firewall, or other network devices

(e.g., data switches) should be restricted for management access via defined protocols and ports to known IP addresses.

Monitoring capabilities in MP6 include Vulnerability Scanning Tools, Network Scanning Capabilities, and similar tools to monitor security posture and configuration compliance. Reports generated from these tools should be sent to SIEM solutions and reviewed on an as AO defined interval.

Monitoring solutions should be configured to generate notifications for non-expected traffic transiting the Gray Management Network, identify traffic that should have been blocked by the Gray Firewall, and enable security administrators to query system event log data for components connected to the Gray

Management Network. Notifications generated in the Gray Management Network may indicate a failure of the Gray Firewall’s filtering functions or may be evidence an improper configuration or potential compromise of the Outer Encryption Component, Gray Firewall, or Gray Management

Network components.

Data Network traffic is forbidden on the Gray Management Network. Collection of EUD logs within the

Gray Network must maintain separation unless transmitted using authorized data transfer mechanisms between the Data and Management networks (see Section 6). Management of MP6 occurs from within the Gray Management Services.

Figure 11. Monitoring Point 6: Gray Management Line

5.7 Monitoring Point 7 (MP7): Red Management

MP7 is located within the Red Management Network to monitor the management network deployed in the Red Network. MP7 is required in all CSfC CM Solutions. The aggregate of data collected for MP7 must provide security administrators visibility of all network and system behavior on the Red

Management Network to meet specified MP7 requirements.

Data collected at MP7 may include but is not limited to: system log data, network flow data from the

Outer Encryption Component and Inner Firewall, Network Tap traffic, IDS/IPS notifications, inline IDS/IPS traffic/notifications, and span port or port mirroring. All traffic source and destination addresses should be within the subset of management network IP addresses. All data should be destined to the data collection system and ultimately the SIEM solution for aggregation and analysis. If existing SIEM solutions are deployed within an existing Management Network within the Red Network, these solutions can be leveraged in place of deploying a separate solution for the CSfC SIEM. Red

Management Network traffic destined for the Inner Encryption Component, Inner Firewall, or other network devices (e.g., data switches) should be restricted for management access via defined protocols and ports to known IP addresses.

Monitoring capabilities in MP7 include Vulnerability Scanning Tools, Network Scanning Capabilities, and similar tools to monitor security posture and configuration compliance. Reports generated from these tools should be sent to SIEM solutions and reviewed on an as AO defined interval. If existing enterprise capabilities for performing these scans are already deployed within customer sites, these solutions can be leveraged where available.

Monitoring solutions should be configured to generate notifications for non-expected traffic transiting the Red Management Network, identify traffic that should have been blocked by the Inner Firewall, and enable security administrators to query system event log data for components connected to the Red

Management Network. Notifications generated in the Red Management Network may indicate a failure of the Inner firewall’s filtering functions or may be evidence an improper configuration or potential compromise of the Outer Encryption Component, Inner firewall, or Red Management Network components.

Data Network traffic is forbidden on the Red Management Network. Collection of EUD logs within the

Red Network must maintain separation unless transmitted using authorized data transfer mechanisms between the Data and Management networks (see Section 6).

Management of MP7 occurs from within the Red Management Services.

Figure 12. Monitoring Point 7: Red Management Line

5.8 Monitoring Point 8 (MP8): End User Device (EUD)

MP8 is located on the EUD and collects system and application event log data from the device. Sources of EUD monitoring data include but are not limited to: operating system event log data, Host Intrusion

Detection System, remote attestation solutions, Mobile Device Manager, and enterprise Data-at-Rest agents. Implementation of MP8 capabilities are directly influenced by the EUD's form factor and architecture design to implement two layers of encryption.

Logging from the Inner Virtual Private Network (VPN) Tunnel provides status of the VPN tunnel, software/firmware updates, hardware status, misconfigurations, and/or intrusion-related event data.

Data transmitted from an EUD lives in the Data Network. Customers deploying remote log collection should take this into consideration when designing monitoring architectures. Consolidating EUD log data with infrastructure log data requires data transfer between the Data and Management networks

(see Section 6).

Figure 13. Monitoring Point 8: EUD

Customers must configure MP8 capabilities to send EUD log data to a Red Data Network collection server. The logs and notifications generated may show evidence on the EUD of either an improper configuration or a potential compromise. Managing MP8 may occur from within the Red Management

Network, Red Data Network, via boundary Inner Encryption Components, or locally on EUD platforms when protected by Administrator access.

5.9 DEPLOYMENT OF MONITORING POINTS SUPPORTING MULTIPLE-CPS

Figure 14. Deployment of Multiple CPs

For deployments of multiple CPs within the same network architecture, customers can take advantage of reusing CM capabilities to meet applicable CM requirements. Each CSfC solution must meet the functional requirements specified in each respective CP, as well as all applicable CM requirements as specified in each CP annex.

Customers should consider tailoring SIEM solutions with individual and combined common operating pictures of their network operations to monitor and observe network activity and systems operations for each CP implementation. Notification and reporting mechanisms should be built in to verify network segregation is enforced as defined by the customer’s site requirements.

6 CONSOLIDATED MONITORING

The CM Annex allows for the implementation of CDS capabilities to transfer data from the Black and

Gray Networks to either the Gray and/or Red Management Networks to co-locate monitoring event data into a single SIEM. Consolidated monitoring can be accomplished through the implementation of “low-to-high,” one-way data transfers from the Black and Gray Networks into the Gray or Red Network through an approved CDS. Using a CDS to aggregate the data may eliminate the need for a Gray SIEM depending on customer monitoring requirements. With all data accessible from a single SIEM, security administrators will no longer need to work across multiple networks to perform event detection and correlation. Additionally, a one-way cyber tap or a NSA evaluated diode, as described in Section 4.2, may be used to transfer raw network traffic to higher protection levels without a CDS for ingestion into an

IDS, SIEM or other CM capability. This use of one-way cyber tap or a NSA evaluated diode is limited to only raw network capture of the solution and cannot be used for the transfer of logs or any other processed data to a higher level of protection.

Figure 15 describes an approach to implementing CDS capabilities to move data between security domains within a CSfC solutions network. There is no requirement for customers to implement data transfer capabilities within their solution.

For customers deploying consolidated monitoring functionality, the requirements specified in Table 18, Multi-Site Requirements, must be met. Implementers must consider two caveats:

Data must only be transferred in the “low to high” direction within a CSfC solutions network

Data from higher classification levels cannot pass to a lower classification level

Data and Management plane traffic is considered to be on separate security/administrative domains within each respective network

Customers and integrators must adhere to all applicable data transfer policies for their organization when designing and implementing these capabilities within their CSfC solution architecture. For example

DoD custemers must follow DoDI 8540 when deploying a CDS within a CSfC solution. If discrepencies are found between the guidence in this document and DoDI 8540 report according to the instruction found in Section 2.

Figure 15. Consolidating Monitoring

6.1 BLACK NETWORK

The Black Network is not permitted to receive data from a higher classification network such as the Gray or Red Network. Data received from devices and stored on the Black collection server in the Black

Network can be forwarded to the Gray collection server in the Gray Management Network, or to the

Red collection server in the Red Management Network through an approved CDS. In addition, one-way cyber tap or a NSA evaluated diode must be used between the Black Network and the CDS.

Figure 16. CDS Black Network

6.2 GRAY NETWORK

The Gray Collection Server is permitted to collect data from the Black Network through an approved

CDS. The recommended solution would store data from all devices in the Gray Network on a Gray data collection server. If authorized by an AO, data from the Gray collection server in the Gray Network can be forwarded to the Red collection server in the Red Network through an approved CDS. In addition, one-way cyber tap or a NSA evaluated diode must be used between the Gray Network and the CDS.

Figure 17. CDS Gray Network

6.3 RED NETWORK

The Red Management collection server is permitted to collect data from the Black and Gray Networks through an approved CDS. The recommended solution would store data from all devices in the Red

Network on a Red Management collection server.

Figure 18. CDS Red Network

7 MULTIPLE INNER ENCLAVES

Customers deploying multiple Inner Enclaves to provide access to Red Networks operating at different classification levels, groups, or Inner Encryption…