Transcription
Continuous Diagnostics andMitigation (CDM)Technical CapabilitiesVolume TwoRequirements CatalogVersion 1.4May 11, 2018
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4Table of ContentsREVISION SUMMARY . 6I - Introduction . 7I - 1 CDM Key Cross-References . 8II - CDM Detailed Requirements . 9II - 1 Requirements Common to All CDM Capabilities . 9II - 1.1Common Actual State . 9II - 1.2Common Interoperability. 9II - 1.3Common Scaling. 10II - 1.4Common Securing . 10II - 1.5Common Timeliness and Completeness . 10II - 1.6Common Grouping . 10II - 1.7Common Policy Decision Point . 11II - 2Requirements to Manage “What is on the network?” . 11II - 2.1II - 2.1.1HWAM Operational Requirements . 12II - 2.1.2HWAM Functional Requirements . 12II - 2.1.3HWAM Tool Functionalities . 12II - 2.2SWAM Requirements . 12II - 2.2.1SWAM Operational Requirements. 13II - 2.2.2SWAM Functional Requirements . 13II - 2.2.3SWAM Tool Functionalities . 14II - 2.3CSM Requirements . 14II - 2.3.1CSM Operational Requirements . 15II - 2.3.2CSM Functional Requirements . 15II - 2.3.3CSM Tool Functionalities. 15II - 2.4II - 3HWAM Requirements . 11VUL Requirements . 16II - 2.4.1VUL Operational Requirements . 16II - 2.4.2VUL Functional Requirements. 16II - 2.4.3VUL Tool Functionalities. 16Requirements to Manage “Who is on the network?” . 17II - 3.1TRUST Requirements . 17II - 3.1.1TRUST Operational Requirements . 18II - 3.1.2TRUST Functional Requirements. 18II - 3.1.3TRUST Tool Functionalities. 182
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II - 3.2II - 3.2.1BEHAVE Operational Requirements. 19II - 3.2.2BEHAVE Functional Requirements . 20II - 3.2.3BEHAVE Tool Functionalities . 20II - 3.3CRED Requirements . 20II - 3.3.1CRED Operational Requirements . 21II - 3.3.2CRED Functional Requirements . 21II - 3.3.3CRED Tool Functionalities . 22II - 3.4II - 4BEHAVE Requirements . 18PRIV Requirements . 22II - 3.4.1PRIV Functional Requirements. 23II - 3.4.2PRIV Tool Functionalities. 23Requirements to Manage “What is happening on the network?” . 23II - 4.1Manage BOUND, or “How is the network protected?” . 24II - 4.1.1BOUND-F Requirements . 24II - 4.1.1.1 BOUND-F Operational Requirements . 25II - 4.1.1.2 BOUND-F Functional Requirements . 26II - 4.1.1.3 BOUND-F Tool Functionalities . 27II - 4.1.2BOUND-E Requirements . 27II - 4.1.2.1 BOUND-E Operational Requirements . 28II - 4.1.2.2 BOUND-E Functional Requirements . 28II - 4.1.2.3 BOUND-E Tool Functionalities . 29II - 4.1.3BOUND-P Requirements . 29II - 4.1.3.1 BOUND-P Operational Requirements . 30II - 4.1.3.2 BOUND-P Functional Requirements . 30II - 4.1.3.3 BOUND-P Tool Functionalities . 30II - 4.2Manage Events (MNGEVT) Requirements . 31II - 4.2.1MNGEVT Operational Requirements . 31II - 4.2.1.1 Incident Response . 31II - 4.2.1.2 Privacy . 31II - 4.2.1.3 Contingency Planning . 31II - 4.2.1.4 Audit Data Collection . 32II - 4.2.1.5 Ongoing Assessment . 32II - 4.2.2MNGEVT Functional Requirements . 333
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II - 4.2.2.1 Incident Response Monitoring . 33II - 4.2.2.2 Privacy Monitoring . 33II - 4.2.2.3 Contingency Planning Monitoring . 33II - 4.2.2.4 Audit Data Collection . 34II - 4.2.2.5 Ongoing Assessment Monitoring. 34II - 4.2.2.6 MNGEVT Tool Functionalities . 34II - 4.3Operate, Monitor and Improve (OMI) Requirements . 35II - 4.3.1OMI Operational Requirements. 35II - 4.3.1.1 Ongoing Authorization . 35II - 4.3.1.2 System and Information Integrity . 36II - 4.3.1.3 Risk Assessment . 36II - 4.3.1.4 Security Assessment and Authorization . 36II - 4.3.2OMI Functional Requirements . 37II - 4.3.2.1 Ongoing Authorization . 37II - 4.3.2.2 System and Information Integrity . 37II - 4.3.2.3 Risk Assessment . 38II - 4.3.2.4 Security Assessment and Authorization . 38II - 4.3.2.5 OMI Tool Functionalities . 38II - 4.4Design and Build in Security (DBS) Requirements . 39II - 4.4.1DBS Operational Requirements . 40II - 4.4.1.1 DBS Design . 40II - 4.4.1.2 DBS Development . 40II - 4.4.1.3 DBS Deployment . 40II - 4.4.1.4 SCRM . 41II - 4.4.2DBS Functional Requirements. 41II - 4.4.2.1 DBS Design . 41II - 4.4.2.2 DBS Development . 41II - 4.4.2.3 DBS Deployment . 42II - 4.4.2.4 DBS Tool Functionalities . 42II - 5Requirements to Manage “How Is Data Protected?” . 43II - 5.1Common Data Protection Requirements . 44II - 5.2Data Discovery/Classification (DATA DISCOV) Requirements . 45II - 5.2.1DATA DISCOV Operational Requirements . 454
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II - 5.2.2DATA DISCOV Functional Requirements . 46II - 5.2.3DATA DISCOV Tool Functionalities . 46II - 5.3Data Protection (DATA PROT) Requirements . 47II - 5.3.1DATA PROT Operational Requirements . 47II - 5.3.2DATA PROT Functional Requirements . 48II - 5.3.3DATA PROT Tool Functionalities . 49II - 5.4Data Loss Prevention (DATA DLP) Requirements . 49II - 5.4.1DATA DLP Operational Requirements . 50II - 5.4.2DATA DLP Functional Requirements . 51II - 5.4.3DATA DLP Tool Functionalities . 52II - 5.5Data Breach/Spillage Mitigation (DATA SPIL) Requirements. 52II - 5.5.1DATA SPIL Operational Requirements . 53II - 5.5.2DATA SPIL Functional Requirements . 54II - 5.5.3DATA SPIL Tool Functionalities . 55II - 5.6Information Rights Management (DATA IRM) Requirements . 56II - 5.6.1DATA IRM Operational Requirements . 56II - 5.6.2DATA IRM Functional Requirements . 57III - References . 59IV - Appendix A: Acronyms, Terms, and Definitions . 61V - Appendix B: NIST Cybersecurity Framework Crosswalk . 72Table 1: Acronyms, Terms and Definitions . 61Table 2: CDM Volume Two Functional Requirements to NIST CSF Crosswalk . 72Figure 1: Phases of CDM . 75
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4REVISION SUMMARYVersion Number1.01.4Date7/18/20174/27/2018Table of ChangesRevised bySectionCDM PMOAllCDM PMOIntegrate CDM Phase 4 “How is dataprotected?” requirements.6
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4I-IntroductionStrengthening the security posture of Federal networks, systems, and data is one of the mostimportant challenges we face as a nation. Therefore, the Department of Homeland Security(DHS) seeks to provide agencies with the Continuous Diagnostics and Mitigation (CDM)program to safeguard, secure, and strengthen cyberspace and the security posture of Federalnetworks in an environment where cyber attacks are continuously growing and evolving.This document describes the requirements for the CDM program that are consistent with theoverarching goal of enabling U.S. Government entities to assess and improve the securityposture of an Agency’s information systems. These requirements will be used for the CDMsolicitations called Dynamically Evolving Federal Enterprise Network Defense (DEFEND)program as well as the Schedule 70 CDM-SIN Approved Product List (APL).The companion volume (Volume One) “CDM Technical Capabilities - Defining Actual andDesired States” should be used in conjunction with this document.Since the cybersecurity space is inherently complex, the CDM approach is to address theproblem space in phases, as shown in Figure 1:Figure 1: Phases of CDMThe CDM requirements to support these phases are grouped into the following:1. Requirements to manage “What is on the network?”7
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.42. Requirements to manage “Who is on the network?”3. Requirements to manage “What is happening on the network?” are decomposed into foursub-areas:a. Managing Events (MNGEVT)b. Operate, Monitor, and Improve (OMI)c. Design and Build in Security (DBS)d. Boundary Protection (BOUND) – addressing “How is the network protected?”4. Requirements to manage “How is data protected?”I-1CDM Key Cross-ReferencesSection II of this document will also reference to the following parts of the Companion:1. CDM Architecture (Companion I-1)2. CDM and the Cybersecurity Framework (CSF) (Companion I-2)3. CDM and the National Institute of Standards and Technology (NIST) Risk ManagementFramework (RMF) (Companion I-3)Users of this document should be familiar with the contents of the Companion volume.8
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II -CDM Detailed RequirementsBased on the above enhanced CDM phase definitions, this section describes CDM requirementsin terms of those requirements that are common to all phases and then describes the detailedrequirements for each area of focus.While these requirements are for the entire scope of the CDM solution ecosystem, the primaryarea impacted would be Layer A and B in the CDM Architecture.1 The CDM Dashboard playsan active role in providing visibility to the outcomes of these requirements and providing thepolicy orchestration if applicable. There are additional specific requirements to the dashboards(both Federal and Agency) that are managed through the CDM Dashboard-specific developmentprocess.These requirements are also applicable and cover other operational environments, such as cloudand mobile, while the method of execution could differ between environments.Appendix B provides a mapping of the CDM capabilities to the NIST Cybersecurity Framework(i.e., CSF).II - 1 Requirements Common to All CDM CapabilitiesThe requirements in this section are common and mandatory, and apply universally across allCDM capabilities. These requirements are in addition to operational and functional requirementscovered in sections II - 2 through II - 5.References to data protections within Section II are applicable to all types of sensitiveinformation, including privacy data.2 References to security data protections include protectionsand safeguards that may be unique to a given type of sensitive information. For example,personally identifiable information (PII) security checks will need to include assessing how thedata is allowed to be used.II - 1.1Common Actual StateC AS OP-1-1: Should interpret all references to security to include data protections andsafeguards applicable to all type of sensitive information (e.g., privacy data).C AS OP-1-2: Should interpret all requirements for security capabilities and functionalities toapply to all operational environments.C AS FR-1-1: Shall have a date/time associated with each instance of Actual State informationand identify the collection source.II - 1.2 Common InteroperabilityC Interop OR-1-1: Shall deliver information to the CDM Dashboard using standardized datastructures and/or API (application program interfaces).1Found in CDM Architecture Companion section I-1.1.Privacy data includes any data subject to the Privacy Act of 1974, as amended. This includes PersonallyIdentifiable Information (PII), Protected Health Information (PHI), and Federal Tax Information (FTI) among others.29
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4C Interop OR-1-2: Shall support data interchange and sharing between all CDM capabilitiesusing standardized formats.C Interop FR-1-1: Shall receive and collect relevant data via a standard interface and in astandard format to the CDM Dashboard and other solution subsystems using CDM datastructure(s), including use of MUR, MDR, MIR, and MSR.3II - 1.3Common ScalingC Scale FR-1-1: Shall store, process, and provide data for large Federal organizations (usingthe threshold of up to one million devices) while maintaining adequate timeliness, completeness,and accuracy for applicable capabilities.C Scale FR-1-2: Shall minimize the use of network bandwidth and end point system resourcesto limit potential impact to mission/business operations.II - 1.4Common SecuringC Secure FR-1-1: Shall support Federal Information Processing Standard (FIPS) 140-2approved algorithms to encrypt data, both in transit and at rest, consistent with Federal andAgency policies.C Secure FR-1-2: Should provide source integrity verification for all tool components, such asdigital fingerprints for each software file used within the system.4II - 1.5Common Timeliness and CompletenessC Time-FR-1-1: Shall support the requirement that attribute information associated with anobject is within the 72-hour data currency goal coupled with the 90% coverage goal for allobjects.C Time-FR-1-2: Shall retain assessment results for an Agency-defined period to enableenterprise security posture reporting and trending.II - 1.6Common GroupingC Group OR-1-1: Shall include the mechanism to define risk scores for the difference betweenactual and desired states (including scores that reflect a reduction in risk) dependent on objectcontext (e.g., Organizational Unit [OU] and Federal Information Security ManagementModernization Act [FISMA] container linkage) and the scope of the capability’s attributes.C Group-OR-1-2: Shall include the mechanism to define actual state dependent on objectcontext and the scope of the capability’s attributes.C Group-OR-1-3: Shall include the mechanism to define the desired state for an objectdependent on the object context (e.g., OU and FISMA container linkage) and the scope of thecapability’s attributes.3Found in CDM Architecture Companion section I-1.2.4Dependent on the ongoing formulation of Federal policies directing increased activities for Supply Chain RiskManagement (SCRM).410
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II - 1.7Common Policy Decision PointC PDP FR-1-1: Shall include Policy Decision Point (PDP) capabilities to support the ingestionof machine-readable policies to measure the actual state against the desired state for ongoingassessment of security controls.C PDP FR-1-2: Shall support the MUR, MDR, MIR, and MSR in conjunction with PDP,specific to the determination of actual versus desired state function of the PDP.II - 2 Requirements to Manage “What is on the network?”Managing “What is on the network?” requires the management and control of devices (HWAM),software (SWAM), security configuration settings (CSM), and software vulnerabilities (VUL).These four functions are briefly summarized below, and the requirements are separatelyspecified later in the HWAM, SWAM, CSM, and VUL sections. HWAM discovers and manages Internet Protocol (IP) addressable devices on thenetwork. SWAM discovers and manages the software installed on devices on the network. CSM identifies and manages the security configuration settings for devices (and theassociated installed software) on the network. VUL discovers and supports remediation of the vulnerabilities in software installed ondevices on the network.Note that while the scope of HWAM is to capture the entire Agency “attack surface,” the scopeof SWAM, CSM, and VUL is specific to the subset of HWAM that is under the accountabilityand therefore control of the Agency. This is determined by the Agency’s overall riskmanagement strategy and as articulated in the Agency’s Information Security ContinuousMonitoring strategy.II - 2.1HWAM RequirementsThe HWAM capability discovers IP-addressable hardware on a network.HWAM establishes and maintains a hardware inventory baseline, unique identifiers forhardware, and other properties, such as the manager of the hardware.HWAM also establishes and maintains the actual inventory of hardware in accordance with datacurrency requirements, along with information needed to assess the risk to and locate thehardware.The capability to maintain and update the inventory needs to allow for decentralizedadministration, using appropriate access and audit controls to ensure that only authorizedpersonnel with appropriate privileges can modify authorized inventories, and only for assets forwhich they are accountable. Data in the authorized hardware inventory baseline must bevalidated continuously through automated hardware discovery. Manual processes, such asassigning hardware to the baseline, are expected to integrate with and be supported by automatedprocesses.11
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4II - 2.1.1HWAM Operational RequirementsHWAM OR-1-1: Shall identify and track hardware devices (physical and virtual) that are onthe network, authorization status, and who (by individual, access group, or organization)manages each device.HWAM OR-1-2: Shall allow manual or batch creation of Agency approved device data (e.g.,through integration with external asset information repositories or through business rules).II - 2.1.2HWAM Functional RequirementsThis capability requires CDM solutions to collect information about attributes in the OU andFISMA containers and the MDR. This capability is related to CSM to ensure that hardwareconfiguration settings are correctly maintained. If cryptography is used, this capability is relatedto BOUND-E.HWAM FR-1-1: Shall:a. Provide a unique identifier (which may vary by device type) that supports devicepersistence across network location changes for each device on the network.b. Identify and collect hardware inventory information on all IP addressable devices on thenetwork on a scheduled and ad hoc basis as specified by authorized users.c. Collect appropriate data to match actual to authorized Agency approved (i.e., authorizeddevices) hardware inventory, including when detected and if the device is in desired state.d. Document and record Agency approved (i.e., authorized devices) hardware inventoryinformation, including device type (e.g., router, workstation, firewall, printer),owner/manager, and operational status.HWAM FR-1-2: Should:a. Collect data to enable staff to locate the hardware devices.b. Collect additional data (e.g., subcomponents, attached peripheral devices, local accountinformation) for managed and properly configured devices and with credentials sufficientto validate actual inventory data.c. Detect the type of each hardware device based upon its network behavior.II - 2.1.3HWAM Tool FunctionalitiesThe following is a non-exclusive list of tool functionalities that support the HWAM capability: Passive detection tools Tools to interrogate network infrastructure to detect devices Active scanning tools Tools that provide packet filtering for device identificationII - 2.2SWAM RequirementsThe SWAM capability discovers software installed on managed network hardware devices.Since unauthorized software may be vulnerable and exploited as a pivot to other network assets,there is a need for unauthorized software to be removed or managed. In addition, a complete,12
CDM TECH CAP-REQ CATALOG VOL TWO -2018-v1.4accurate, and timely software inventory is essential to support awareness and effective control ofsoftware vulnerabilities and security configuration settings. Malware often exploitsvulnerabilities to gain unauthorized access to and tamper with software and configurationsettings to propagate throughout the enterprise.SWAM establishes and maintains a software inventory, unique identifiers for software, and otherproperties such as the manager of the software.SWAM also establishes and maintains the actual inventory of all software in accordance withdata currency requirements, along with information needed to assess the risk to and physicallylocate the software.The capability to maintain and update the software inventory needs to enable decentralizedadministration, using appropriate access and audit controls, to ensure that only authorizedpersonnel with appropriate privileges can modify authorized inventories, and only for softwarefor which they are accountable.The authorized software inventory baseline is established through some process involving actualinventory data and business rules that determine assignment of default responsibility. Data in theauthorized software inventory baseline should be validated continuously through automatedsoftware discovery. Manual processes, such as assigning software to the baseline, are expected tointegrate with and be supported by automated processes.II - 2.2.1SWAM Operational RequirementsSWAM OR-1-1: Shall identify and track software pr
C_AS_FR-1-1: Shall have a date/time associated with each instance of Actual State information and identify the collection source. II - 1.2 Common Interoperability C_Interop_OR-1-1: Shall deliver information to the CDM Dashboard using standardized data structures and/or API (application program interfaces).
