Continuous Monitoring (CM) is being replaced with Continuous Diagnostics and Mitigation (CDM). The key change is going from monitoring to mitigation and therein lies the problem. To comply with CDM, you have to “mitigate” within 72 hours. I argue that it just cannot be done today.
If you are not familiar with CDM, let me try to bring you up to speed on some of the key concepts.
The CDM system is the collection of capabilities and tools that:
-Monitors the security controls in information systems and environments of operation on an ongoing basis to determine control effectiveness, changes to the system/environment and compliance to legislation, executive orders, directives, policies, regulations, and standards.
-Provides timely (72 hours or less) and prioritized (“fix worst first”) information on security flaws that could lead to adverse impacts to mission/business functions.
-Supplies data on agency security-related performance for use by oversight entities to help identify the level of risk reduction which is both possible and beneficial for agencies.
-Reduces the effort required for agencies to report the required security-related information.
CDM is Broken Down into 4 Phases
Phase 1: “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).
Phase 2: “Who is on the network?”
Managing “Who is on the network?” requires the overseeing and control of account/access/managed privileges (PRIV), trust determination for people granted access (TRUST), credentials and authentication (CRED), and security-related behavioral training (BEHAVE). These four functions have significant interdependence and are thus managed together as part of Phase 2.
Phase 3: “What is happening on the network?”
Managing “What is happening on the network?” builds on the CDM capabilities provided by “What is on the network?” and “Who is on the network?” These CDM capabilities include network and perimeter components, host, and device components, data at rest and in transit, and user behavior and activities. These capabilities move beyond asset management to more extensive and dynamic monitoring of security controls.
This includes preparing for and responding to behavior incidents, ensuring that software/system quality is integrated into the network/infrastructure, detecting internal actions and behaviors to determine who is doing what, and finally, mitigating security incidents to prevent propagation throughout the network/infrastructure.
Phase 4: “How is data protected?”
CDM Phase 4 capabilities support the overall CDM Program goal to identify cybersecurity risks on an ongoing basis, prioritize these risks based upon potential impacts and enable cybersecurity personnel to mitigate the most significant problems first.
The Problem is Policy Enforcement, Not CDM Technology
We can do all of the technical implementation of HWAM, SWAM, VUL and CSM now. The problem has always been and continues to be mitigating what is found. Systems are identified as critical and not tolerable of any downtime to mitigate vulnerabilities. Patching windows are at the mercy of System Owners who are understandably concerned with service delivery.
The problem is that systems were not designed with CDM in mind. In fact, security has always been the last consideration. Nobody evaluated availability in terms of availability to mitigate. It is not necessarily a problem caused by the security team but they are often the ones “out of compliance.”
How Can We Fix CDM?
We need to change our policies and enforce the ones we have. If we have a 72-hour mitigation window that cannot be met then we need to hold application owners responsible for providing one.
-We need to include a patching window every 72 hours in our availability standards. Application designers and architects must design systems to that standard.
-The more critical a system is, the more available it needs to be for patching.
-If a system cannot be patched during the current patching cycle, we need to perform a root cause analysis to fix it.
-As a last resort, if we cannot mitigate a system within the required timeframe, we need to carefully evaluate the risks and develop compensating controls. In addition, we need to have a business continuity plan that includes exploitation of at risk systems as well as emergency procedures when mitigation is absolutely necessary.
CDM, as a program, is not at fault, but in order to meet mitigation objectives we need to start looking at patch availability now. We need to change the way we think about “availability” to include, instead of exclude, security needs. If a system is critical then we need to make sure mechanisms are in place to keep it secure and available. These are the things we should have been doing all along. It may be a lot harder to implement now but it’s our own fault.
Matthew Scott Eagles is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.