Approved Continuous Monitoring Annex v1.1.0 PDF

COMMERCIAL SOLUTIONS for CLASSIFIED (CSfC) Continuous Monitoring Annex 1.1.0 Version 1.1.0 2 March 2021  CHANGE HISTORY Title Version Date Change Summary Continuous Monitoring (CM)...

COMMERCIAL SOLUTIONS for CLASSIFIED (CSfC) Continuous Monitoring Annex 1.1.0 Version 1.1.0 2 March 2021  CHANGE HISTORY Title Version Date Change Summary Continuous Monitoring (CM) 1.0 4 August 2021  Initial release of CSfC Continuous Monitoring Annex Annex. Continuous Monitoring (CM) 1.1.0 2 March 2023  Added requirement for logs and SIEM to be Annex review at least once a week.  Added Campus WLAN Tactical use case to the Tactical Appendix i  Table of Contents 1 Introduction.......................................................................................................................................... 6 2 Purpose and use.................................................................................................................................... 6 3 Legal Disclaimer.................................................................................................................................... 7 4 Continuous Monitoring Solution Overview.......................................................................................... 7 4.1 Monitoring Solution Overview...................................................................................................... 8 4.2 Monitoring Data Sources.............................................................................................................. 9 4.3 Security Information and Event Management (SIEM)................................................................ 12 4.3.1 Gray Management SIEM..................................................................................................... 13 4.3.2 Red Management SIEM....................................................................................................... 14 4.4 Dataflow Model.......................................................................................................................... 15 5 Monitoring Points............................................................................................................................... 16 5.1 Monitoring Point 1 (MP1): Black Data Line................................................................................. 17 5.1.1 WIDS/WIPS.......................................................................................................................... 17 5.2 Monitoring Point 2 (MP2): Gray Data Line................................................................................. 18 5.3 Monitoring Point 3 (MP3): Gray Data Line................................................................................. 19 5.4 Monitoring Point 4 (MP4): Red Data Line................................................................................... 20 5.5 Monitoring Point 5 (MP5): Red Data Line................................................................................... 21 5.6 Monitoring Point 6 (MP6): Gray Management........................................................................... 22 5.7 Monitoring Point 7 (MP7): Red Management............................................................................ 23 5.8 Monitoring Point 8 (MP8): End User Device (EUD)..................................................................... 24 5.9 Deployment of Monitoring Points Supporting Multiple-CPs...................................................... 25 6 Consolidated Monitoring.................................................................................................................... 26 6.1 Black Network............................................................................................................................. 27 6.2 Gray Network.............................................................................................................................. 28 6.3 Red Network............................................................................................................................... 29 7 Multiple Inner Enclaves....................................................................................................................... 29 8 Multi-Site Environments..................................................................................................................... 30 8.1 Standalone Configuration........................................................................................................... 30 8.2 Centrally Managed Configuration............................................................................................... 31 9 Monitoring In a High Availability Environment................................................................................... 32 ii  10 Continuous Monitoring Requirements............................................................................................... 33 10.1 Threshold and Objective Requirements..................................................................................... 34 10.2 Requirements Designators.......................................................................................................... 35 10.3 Matrix of CP and Required Monitoring Points............................................................................ 35 10.4 CM Monitoring Point Requirements........................................................................................... 36 10.5 Network Monitoring Requirements............................................................................................ 36 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).............................................................. 40 10.11 MP6 Requirements (Gray Management Network)..................................................................... 41 10.12 MP7 Requirements (Red Management Network)...................................................................... 43 10.13 MP8 Requirements (End User Device)........................................................................................ 46 10.14 Logging Requirements................................................................................................................ 47 10.15 General Requirements................................................................................................................ 48 10.16 SIEM Requirements..................................................................................................................... 50 10.17 Multi-Inner Enclave Requirements............................................................................................. 51 10.18 Multi-Site Requirements............................................................................................................. 52 10.19 Consolidated Monitoring Requirements.................................................................................... 53 Appendix A. Acronyms............................................................................................................................ 54 Appendix B. Definitions............................................................................................................................... 55 Appendix C. References.............................................................................................................................. 57 Appendix D. Tactical Solution Continuous Monitoring Implementations.................................................. 58 Tactical Implementation Continuous Monitoring................................................................................... 59 Table of Figures Figure 1. Continuous Monitoring Solution – MA CP..................................................................................... 8 Figure 2. Continuous Monitoring Solution – Multi-Site Connectivity CP...................................................... 9 Figure 3. Continuous Monitoring Solution – Campus WLAN CP................................................................... 9 iii  Figure 4. Examples of Monitoring Functions.............................................................................................. 12 Figure 5. Gray Management SIEM.............................................................................................................. 13 Figure 6. Red Management SIEM................................................................................................................ 14 Figure 7. Data Lifecycle............................................................................................................................... 15 Figure 8. Monitoring Point 1: Black Data Line............................................................................................ 18 Figure 9. Monitoring Points 2 and 3: Gray Data Line.................................................................................. 19 Figure 10. Monitoring Points 4 and 5: Red Data Line................................................................................. 21 Figure 11. Monitoring Point 6: Gray Management Line............................................................................. 23 Figure 12. Monitoring Point 7: Red Management Line............................................................................... 24 Figure 13. Monitoring Point 8: EUD............................................................................................................ 25 Figure 14. Deployment of Multiple CPs...................................................................................................... 25 Figure 15. Consolidating Monitoring.......................................................................................................... 27 Figure 16. CDS Black Network..................................................................................................................... 27 Figure 17. CDS Gray Network...................................................................................................................... 28 Figure 18. CDS Red Network....................................................................................................................... 29 Figure 19. Multiple Inner Enclaves.............................................................................................................. 30 Figure 20. Centralized Management........................................................................................................... 32 Figure 21. High Availability Environment.................................................................................................... 33 List of Tables Table 1. Monitoring Function Overview..................................................................................................... 10 Table 2. Capability Package Descriptions.................................................................................................... 33 Table 3. Requirement Digraphs.................................................................................................................. 35 Table 4. Required MP Deployments for CSfC Solutions.............................................................................. 35 Table 5. CM Monitoring Point Requirements............................................................................................. 36 Table 6. MP1 Requirements........................................................................................................................ 36 Table 7. MP2 Requirements........................................................................................................................ 37 Table 8. MP3 Requirements........................................................................................................................ 38 Table 9. MP4 Requirements........................................................................................................................ 39 Table 10. MP5 Requirements...................................................................................................................... 40 Table 11. MP6 Requirements...................................................................................................................... 41 Table 12. MP7 Requirements...................................................................................................................... 43 iv  Table 13. MP8 Requirements...................................................................................................................... 46 Table 14. Logging Requirements................................................................................................................. 47 Table 15. General Requirements................................................................................................................ 48 Table 16. Security Information and Event Management (SIEM) Requirements......................................... 50 Table 17. Multi-Inner Enclave Requirements............................................................................................. 51 Table 18. Multi-Site Requirements............................................................................................................. 52 Table 19. Consolidated Monitoring Requirements..................................................................................... 53 Table 20. Tactical Implementation Continuous Monitoring Overlay Requirements.................................. 59 v  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 [email protected]. Solutions adhering to this guidance must also comply with Committee on National Security Systems (CNSS) policies and instruction. 6  For any additional information on Cross Domain Solutions (CDS) contact the National Cross Domain Strategy Management Office (NCDSMO) at [email protected]. 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). 7  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 8  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 9  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 A device or software application that monitors a network or system for System (IDS) / Intrusion malicious activity or policy violations. Includes network-based Intrusion Prevention System (IPS) 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 [email protected]. 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 10  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. 11  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 12   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 13  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). 14  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. 15  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. 16  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. 17  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 18  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 19  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. 20  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. 21  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. 22  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. 23  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 24  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 25  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 26  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 27  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 28  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 Component types have a tailored set of CM MP requirements to implement. Regardless of chosen CP, the CM Annex requires network traffic monitoring to occur at MP3, MP6, and MP7 for multiple Inner Enclave solutions. At a minimum, one MP in each Inner Enclave (at MP4 or MP5), and one MP located in either the Black Enclave (MP1) or Gray Enclave (MP2) are also required. Key components within each Inner Enclave may vary based upon the services implemented, but must include the Inner Firewall, Inner Encryption Component, separate monitoring points, and associated Management Services. As Seen in Figure 19, all security event data within each destination enclave must be sent to a collection server located within its respective enclave (e.g., Orange, Red, and Blue). Network flow data from the Inner VPN Encryption Component and/or Inner Firewall must be sent to a collection server within its respective enclave. A separate SIEM within each Inner enclave must be deployed to monitor each local enclave network. When multiple Inner Enclaves are interconnected, implementation of multiple SIEM components and disparate collection devices may result in a CSfC CM solution that becomes increasingly difficult to 29  manage. In order to support event correlation and provide an enterprise-wide CM capability, data from Inner Enclaves (e.g., Orange, Red, and Blue) can forward data to Inner Enclaves of higher classification levels, or enclaves higher in the hierarchy (Orange and Blue forwarded to Red) through an approved CDS. Figure 19. Multiple Inner Enclaves 8 MULTI-SITE ENVIRONMENTS This section provides guidance for CM implementations of the Multi-Site Connectivity (MSC) CP. MSC solutions connect more than one CSfC solution to each other in a hub and spoke, or mesh configuration. Two monitoring design options are presented below for customers to consider in managing MSC Environments: Standalone or Centrally Managed CM configuration. Customers may also consider using a hybrid design, consisting of a standalone and centralized managed CM configuration. Customers should use configurations and structures that best meet mission needs and levels of risk acceptable to the AO. 8.1 STANDALONE CONFIGURATION Standalone CM configurations require deploying monitoring capabilities locally within the Management Network of each site. Standalone CM configurations are typically administered on-site. Advantages:  Standalone CM solutions are less likely to be affected by communication outages to other sites for shared resources, since they are designed to operate independently  Local personnel have more options to respond to incidents than centrally managed solutions  Standalone CM solutions can be tailored to fit the specific needs of CSfC sites and operations 30  Disadvantage:  Customer CSfC solutions must implement requirements from the CM Annex at each site, which may take valuable resources away from local operations 8.2 CENTRALLY MANAGED CONFIGURATION In the Centrally Managed CM configuration, customers have one or more Main Sites that monitor, maintain, and administer one or more remote sites. In order to support correlation and a better overall picture for remote sites, the Gray Network storage servers at the remote sites must forward data to the Gray Network storage server at the Main Site(s). Similarly, the Red Network storage servers at the remote sites must forward data to the Red Network storage server(s) at the Main Site. This monitoring allows customers to detect, react to, and report any attacks against their CSfC solutions in addition to detecting any configuration errors within infrastructure components from a customer’s centralized watch floor or operations centers. Advantages:  Valuable local resources can focus on mission requirements, while a centralized watch floor can oversee the health and operation of remote sites. Using local personnel only when required  Centrally Managed CM solutions are typically standardized across multiple remote sites  A broader view of the health of remote sites in a central location or watch floor Disadvantage:  Centrally Managed CM solutions are likely to be affected by communication outages to other sites for shared resources like DNS, Certificate Distribution Point (CDP), or Authentication Authorization and Accounting Services Geographically remote sites may experience low bandwidth, intermittent connectivity, or other issues that limit the transfer of data to a Main Site, resulting in a degraded ability to detect, report, and react to attacks on the remote site. In these situations, users may store logs and CM data locally for remote security administrators to review alarms from an incident when network connectivity is restored or when authorized personnel arrive to audit CM data and/or provide incident response. For networks with limited bandwidth availability, customers should consider forwarding such data during non-peak hours. Customers should consider deploying a Centrally Managed Configuration to integrate IPS capabilities at remote sites. In the absence of having onsite administrative personnel or reliable remote management access capabilities, an IPS allows the remote site to protect itself by automatically detecting and reacting to anomalous network behavior while connectivity to a Main Site is degraded. 31  Figure 20. Centralized Management 9 MONITORING IN A HIGH AVAILABILITY ENVIRONMENT Customers scaling their CSfC solutions architecture to implement high availability requirements, such as hot or cold failover, redundancy, or load balancing, must extend the monitoring architecture to account for the increased network footprint. The following must be considered when deploying any high availability capabilities:  Verification and monitoring of traffic transiting cross links  Additional bandwidth and computational power may be required to transmit data and management traffic, as well as processing within deployed SIEM solutions No specific requirements are levied for customers deploying CM capabilities within a high availability environment. Customers must meet the intent of the requirements as defined for each respective MP and ensure all communications paths are monitored. Customers should develop notifications within their monitoring infrastructure to detect event triggering failover conditions. Expected network behavior of the system in a ‘normal’ state and a ‘failover’ state should be defined. Customers should monitor for unexpected changes within the solution that may otherwise indicate an issue in any of the systems component’s operation or anomalous behavior within the solution’s network when in either of the previously mentioned states. Figure 21 represents a sample high availability architecture and points within the network architecture that must be evaluated for CM capability deployment for MP2. 32  Figure 21. High Availability Environment 10 CONTINUOUS MONITORING REQUIREMENTS Sections 10.1 through 10.3 specify the necessary requirements for the implementation of an Enterprise Gray solution compliant with this annex. Interconnecting CSfC solutions will follow the requirements of the CPs being deployed. Guidance provided in this annex is for the implementation of a CM capability to monitor a CSfC solution. Although most requirements apply to all CSfC solutions, some requirements only apply to implementations whose high-level designs implement certain features. Table 2. Capability Package Descriptions Capability Package Designator Description Multiple CPs All This CM Annex comprises all three data-in- transit CPs and describes how to protect classified data in transit while simultaneously interconnecting scalable and centrally manageable solutions across geographically large distances and leveraging existing infrastructure and services Mobile Access MA Requirements pertinent to the Mobile Access CP only. This CP describes how to protect classified data (including Voice and Video) in MA solutions transiting Private Cellular Networks and Government Private Wi-Fi networks. 33  Capability Package Designator Description Multi-Site Connectivity MSC Requirements pertinent to the MSC CP only. This CP describes how to protect classified data in transit across an untrusted network using multiple encrypted tunnels implemented with IPsec. Campus WLAN WLAN Requirements pertinent to the Campus WLAN CP only. This CP describes how to protect classified data (including Voice and Video) in a WLAN solution transiting Government Private Wi-Fi networks. Enterprise Gray EG Requirements pertinent to the Enterprise Gray Implementation Requirements Annex only. This CSfC EG Annex describes additional options for CSfC deployments and allows for centralized management of the Gray Management Network. 10.1 THRESHOLD AND OBJECTIVE REQUIREMENTS In some cases, multiple versions of a requirement may exist within this document. Such alternative versions of a requirement are designated as either a ‘Threshold requirement’ or an ‘Objective requirement’:  A Threshold (T) requirement specifies a feature or function that provides the minimal acceptable capability for the security of the solution  An Objective (O) requirement specifies a feature or function that provides the preferred capability for the security of the solution When separate Threshold and Objective versions of a requirement exist, the Objective requirement provides more security for the solution than the corresponding Threshold requirement. However, in some cases, meeting the Objective requirement may not be feasible in some environments or may require components to implement features that are not yet widely available. Solution owners are encouraged to implement the Objective version of a requirement, but in cases where this is not a feasible solution, owners may implement the Threshold version of the requirement instead. These Threshold and Objective versions are mapped to each other in the “Alternatives” column. Objective requirements that have no related Threshold requirement are marked as “Optional” in the “Alternatives” column. In most cases, there is no distinction between the Threshold and Objective versions of a requirement. In these cases, the “Threshold/Objective” column indicates that the Threshold equals the Objective (T=O). 34  Requirements that are listed as Objective in this annex may become Threshold requirements in future guidance. Solution owners are encouraged to implement Objective requirements where possible to facilitate compliance with future guidance. 10.2 REQUIREMENTS DESIGNATORS Each requirement in this annex is identified by a label consisting of the prefix “CM” a two-letter category, and a sequence number (e.g., CM-MP1-3). Table 3. Requirement Digraphs Digraph Description Section Table MP Monitoring Point Requirements Section 10.4 Table 5 MP1 Monitoring Point 1 Requirements Section 10.6 Table 6 MP2 Monitoring Point 2 Requirements Section 10.7 Table 7 MP3 Monitoring Point 3 Requirements Section 10.8 Table 8 MP4 Monitoring Point 4 Requirements Section 10.9 Table 9 MP5 Monitoring Point 5 Requirements Section 10.10 Table 10 MP6 Monitoring Point 6 Requirements Section 10.11 Table 11 MP7 Monitoring Point 6 Requirements Section 10.12 Table 12 MP8 Monitoring Point 8 Requirements Section 10.13 Table 13 LN Logging Requirements Section 10.14 Table 14 GR General Requirements Section 10.15 Table 15 SM SIEM Requirements Section 10.16 Table 16 MI Multi-Inner Enclave Requirements Section 10.17 Table 17 MS Multi-Site Requirements Section 10.18 Table 18 CD Consolidated Monitoring Requirements Section 10.19 Table 19 10.3 MATRIX OF CP AND REQUIRED MONITORING POINTS A set of required MPs must be deployed for each CP along with at least two other remaining monitoring points. For the two MPs, these cannot be within the same network exclusively. For MA CP deployments using the government private wireless use case a WIDS/WIPS is required. For requirements see CSfC WIDS/WIPS Annex. Table 4 below denotes this use case with *WIDS. Table 4. Required MP Deployments for CSfC Solutions Choose One MP in Black or Gray Choose One MP in Red CP Required Networks Network MA MP6, MP7, MP8, and *WIDS MP1, MP2, MP3 MP4, MP5 WLAN WIDS, MP6, MP7, and MP8 MP2, MP3 MP4, MP5 MSC MP6 and MP7 MP1, MP2, MP3 MP4, MP5 35  10.4 CM MONITORING POINT REQUIREMENTS Based on the CP implementation, only certain requirements from Table 4 apply within a customer solution. In addition, CM-MP-3 through 5, require customers to choose specific MPs to use and then only implement those requirements that relate to that MP. Table 5. CM Monitoring Point Requirements Threshold/ Capability Req # Requirement Description Alternative Objective Package CM-MP-1 Conduct network monitoring at MP6 and MP7. T=O All CM-MP-2 Conduct device monitoring at MP8. T=O MA, WLAN Conduct network monitoring on one of the CM-MP-3 following monitoring points: MP1, MP2, or T=O MA, MSC MP3. Conduct network monitoring on one of the CM-MP-4 T=O WLAN following monitoring points: MP2, or MP3. Conduct network monitoring on one of the CM-MP-5 T=O All following monitoring points: MP4, or MP5. A WIDS must be deployed to monitor a Campus WLAN CP, and an MA CP using CM-MP-6 Government Private Wireless use case. All T=O WLAN, MA requirements for a WIDS are located in the CSfC WIDS/WIPS Annex. 10.5 NETWORK MONITORING REQUIREMENTS Depending on the MP chosen to implement within the solution, only apply those requirements that directly apply to the given solution. See the specific MP requirements tables for additional requirements on information that needs to be logged and notified on within the solution. 10.6 MP1 REQUIREMENTS (DATA NETWORK BETWEEN OUTER FIREWALL & OUTER ENCRYPTION COMPONENT) Only apply these requirements to the solution if MP1 is implemented. Table 6. MP1 Requirements Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log all traffic outside expected traffic of the Outer Encryption CM-MP1-1 Component (i.e., non-UDP 4500 or UDP 500 for T=O MA CP, MSC Internet Key Exchange /IPsec, 443 TLS or MACsec tunnel). The monitoring capability must log all traffic CM-MP1-2 which has a destination other than the Outer T=O MA CP, MSC Encryption Component or Outer Firewall. 36  Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log any CM-MP1-3 unauthorized attempts to scan the Outer T=O MA CP, MSC Encryption Component or Outer Firewall. The monitoring capability must log CM-MP1-4 unauthorized IPs attempting to connect to T=O MSC Outer Encryption Components. The Outer Firewall must log any configuration CM-MP1-5 T=O MA CP, MSC changes. The Outer Firewall must log attempts to CM-MP1-6 perform an unauthorized action (e.g., read, T=O MA CP, MSC write, execute, delete) on an object. The Outer Firewall must log all actions CM-MP1-7 performed by a user with super-user or T=O MA CP, MSC administrator privileges. The Outer Firewall must log any escalation of CM-MP1-8 T=O MA CP, MSC user privileges. CM-MP1-9 The Outer Firewall must log changes to time. T=O MA CP, MSC The monitoring capability must log when a CM-MP1- system generates an excessive number of short T=O All 10 packets (e.g., a system sending over 60% of packets containing 150 or less bytes). The monitoring capability must log when a CM-MP1- system receives an excessive number of short T=O All 11 packets (e.g., a system sending over 60% of packets containing 150 or less bytes). 10.7 MP2 REQUIREMENTS (DATA NETWORK BETWEEN OUTER ENCRYPTION COMPONENT & GRAY FIREWALL) Only apply these requirements to the solution if MP2 is implemented. Table 7. MP2 Requirements Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log all traffic outside expected traffic passing CM-MP2-1 T=O All through the Outer Encryption Component to the Gray Firewall. The monitoring capability must log all traffic which has a source or destination other than the EUD/Encryption CM-MP2-2 Components, Outer Encryption T=O All Component, Gray Firewall/Encryption Component, Inner Encryption Component, or Gray Data services. 37  Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log any attempt to scan the EUD/Encryption Components, Outer Encryption CM-MP2-3 T=O All Component, Gray Firewall/Encryption Component, Inner Encryption Component, or Gray Data services. The monitoring capability must log CM-MP2-4 T=O MA CP, WLAN communication between EUDs. The monitoring capability must log any DNS CM-MP2-5 request for any domain or name not T=O All included in the Gray Data domain. The monitoring capability must log when a system generates an excessive number of CM-MP2-6 short packets (e.g., a system sending over T=O All 60% of packets containing 150 or less bytes). The monitoring capability must log when a system receives an excessive number of CM-MP2-7 short packets (e.g., a system sending over T=O All 60% of packets containing 150 or less bytes). 10.8 MP3 REQUIREMENTS (DATA NETWORK BETWEEN GRAY FIREWALL & INNER ENCRYPTION COMPONENT) Only apply these requirements to the solution if MP3 is implemented. Table 8. MP3 Requirements Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log all traffic outside expected traffic passing CM-MP3-1 T=O All through the Gray Firewall to the Inner Encryption Component. The monitoring capability must log all traffic which has a source or destination other than the EUD/Encryption CM-MP3-2 T=O All Components, Outer Encryption Component, Gray Firewall, or Inner Encryption Component. The monitoring capability must log any attempt to scan the EUD/Encryption CM-MP3-3 Components, Outer Encryption T=O All Component, Gray Firewall, or Inner Encryption Component. 38  Threshold/ Capability Req # Requirement Description Alternative Objective Package The monitoring capability must log CM-MP3-4 T=O MA CP, WLAN communications between EUDs. If the Inner Encryption Components use certificate-based authentication, the monitoring capability must log invalid or CM-MP3-5 O Optional All expired certificates used to attempt a connection to the Inner Encryption Component. The monitoring capability must log when a system generates an excessive number of CM-MP3-6 short packets (e.g., a system sending over T=O All 60% of packets containing 150 or less bytes). The monitoring capability must log when a system receives an excessive number of CM-MP3-7 short packets (e.g., a system sending over T=O All 60% of packets containing 150 or less bytes). 10.9 MP4 REQUIREMENTS (DATA NETWORK BETWEEN INNER ENCRYPTION COMPONENT & INNER FIREWALL) Only apply these requirements to the solution if MP4 is implemented. Table 9. MP4 Requirements Threshold/ Req # Requirement Description Alternative Capability Package Objective The monitoring capability must log unusual data CM-MP4-1 T=O All movement within or out of the network. The monitoring capability must log any attempt to CM-MP4-2 connect to any external T=O All domain or IP address from the Red Network. The monitoring capability must log when a system that generates an excessive CM-MP4-3 number of short packets T=O All (e.g., a system sending over 60% of packets containing 150 or less bytes). 39  Threshold/ Req # Requirement Description Alternative Capability Package Objective The monitoring capability must log when a system that receives an excessive number CM-MP4-4 of short packets (e.g., a T=O All system sending over 60% of packets containing 150 or less bytes). The monitoring capability must log detection of any protocol or port outside of CM-MP4-5 T=O All those specifically allowed by the Inner Firewall and/or Inner Encryption Component. The monitoring capability must log any attempt to scan the EUD/Encryption CM-MP4-6 Components, Inner T=O All Encryption Component, Inner Firewall or Red Data Network. 10.10 MP5 REQUIREMENTS (DATA NETWORK AFTER RED FIREWALL) Only apply these requirements to the solution if MP5 is implemented. Table 10. MP5 Requirements Threshold/ Req # Requirement Description Alternative Capability Package Objective The monitoring capability must CM-MP5-1 log unusual data movement T=O All within or out of the network. The monitoring capability must log any attempt to connect to CM-MP5-2 T=O All any external domain or IP address from the Red Network. The monitoring capability must log when a system generates an excessive number of short CM-MP5-3 T=O All packets (e.g., a system sending over 60% of packets containing 150 or less bytes). The monitoring capability must log when a system receives an excessive number of short CM-MP5-4 T=O All packets (e.g., a system sending over 60% of packets containing 150 or less bytes). 40  Threshold/ Req # Requirement Description Alternative Capability Package Objective The monitoring capability must log the detection of any protocol or port outside of CM-MP5-5 T=O All those specifically allowed by the Inner Firewall and/or Inner Encryption Component. The monitoring capability must log any attempt to scan the EUD/Encryption Components, CM-MP5-6 T=O All Inner Encryption Component, Inner Firewall or Red Data Network. 10.11 MP6 REQUIREMENTS (GRAY MANAGEMENT NETWORK) Applies to all CSfC solutions. Table 11. MP6 Requirements Threshold/ Capability Req # Requirement Description Alternative Objective Package The Gray Authentication services, Gray CM-MP6-1 Network components and Gray Management T=O All services must log any failed login attempt. The Gray Authentication service supporting CM-MP6-2 the Gray Management services must log T=O All whenever a new user is created. The Gray Authentication services supporting CM-MP6-3 EUDs must log whenever a new EUD user is