Hearing Witness Doesn't Understand CDM
On Wednesday 24 June a Subcommittee of the House Committee on Homeland Security held a hearing titled DHS’ Efforts to Secure .Gov.
A second panel (starts in the Webcast around 2 hours 20 minutes) featured Dr. Daniel M. Gerstein, a former DHS official now with RAND, as its sole witness.
During his opening statement, and in his written testimony, he made the following comments:
"The two foundational programs of DHS’s cybersecurity program are EINSTEIN (also called EINSTEIN 3A) and CDM. These two systems are designed to work in tandem, with EINSTEIN focusing on keeping threats out of federal networks and CDM identifying them when they are inside government networks.
EINSTEIN provides a perimeter around federal (or .gov) users, as well as select users in the .com space that have responsibility for critical infrastructure. EINSTEIN functions by installing sensors at Web access points and employs signatures to identify cyberattacks.
CDM, on the other hand, is designed to provide an embedded system of sensors on internal government networks. These sensors provide real-time capacity to sense anomalous behavior and provide reports to administrators through a scalable dashboard. It is composed of commercial-off-the-shelf equipment coupled with a customized dashboard that can be scaled for administrators at each level." (emphasis added)
All of the text in bold is false. CDM is not "identifying [threats] when they are in inside government networks." CDM is not "an embedded system of sensors on internal government networks" looking for threat actors.
Why does Dr. Gerstein so misunderstand the CDM program? The answer is found in the next section of his testimony, reproduced below.
"CDM operates by providing
federal departments and agencies with capabilities and tools that 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. Congress established the CDM program
to provide adequate, risk-based, and cost-effective cybersecurity and
more efficiently allocate cybersecurity resources." (emphasis added)
The indented section is reproduced from the DHS CDM Website, as footnoted in Dr. Gerstein's statement.
The answer to my question of misunderstanding involves two levels of confusion.
The first level of confusion is a result of the the CDM description, which confuses risks with vulnerabilities. Basically, the CDM description should say vulnerabilities instead of risks. CDM, now known as Continuous Diagnostics and Mitigation, is a "find and fix flaws (i.e., vulnerabilities) faster" program.
In other words, the CDM description should say:
"CDM gives federal departments and agencies with capabilities and tools that identify cybersecurity vulnerabilities on an ongoing basis, prioritize these vulnerabilities based upon potential impacts, and enable cybersecurity personnel to mitigate the most significant problems first."
The second level of confusion is a result of Dr. Gerstein confusing risks with threats. It is clear that when Dr. Gerstein reads the CDM description and its mention of "risks," he thinks CDM is looking for threat actors. CDM does not look for threat actors; CDM looks for vulnerabilities. Vulnerabilities are flaws in software or configuration that make it possible for intruders to gain unauthorized access.
As I wrote in my CDM post, we absolutely need the capability to find and fix flaws faster. We need CDM. However, do not confuse CDM with the operational capability to detect and remove threat actors. CDM could be deployed across the entire Federal government, but it would be an accident if a security analyst noticed an intruder using a CDM tool.
Essentially, the government needs to implement My Federal Government Security Crash Program to detect and remove threat actors.
It is critical that staffers, lawmakers, and the public understand what is happening, and not be lulled into a false sense of security due to misunderstanding these concepts.
Tweet
Comments
I disagree that CDM should be used to find vulnerabilities in known software. Unauthorized laptops, outdated versions of Windows XP and zero-day malware don't have CVEs associated with them, yet they can all be reported on in near realtime with popular CDM vendor providers, such as Tenable's SecurityCenter.
Ron
- a running process that has an unknown hash (Nessus plugin 70768 or one of our agents)
- a malicious windows autorun or task found from sandbox testing (Nessus plugin 74442)
- a host with a radically different config (new browsed port, open port, service, .etc) [Nessus plugin 70943 tells you this from scan to scan for Windows for example]
- a host communicating to a known botnet, performing DNS lookups to known bots, .etc or IOC
- a change in the user-agent string (I don't like that, but some folks think that is useful)
- having a system configured to speak with a known boted DNS server (plugin 58429)
- a change in the active DNS server used (seeing you have 1000 systems using your internal DNS server and one making queries directly to the Internet)
- a host dramatically changing the ratio of clients and servers it communicate with
- a web site distributing known bad executables (plugin 52670)
We see lots of examples where a customer will say its's "zero day" malware, but its' been on their network for a while and detected by AV software not on their network.
We also see lots of examples where the insider is moving though the network with regular tools like psexec or valid credentials. Finding psexec where you don't expect it is really zero-day malware, but the sort of reason why you have a compliance standard and then look for deviations.
These are good comments -- I would characterize what you listed as "indicators of compromise." These would be useful indeed.