CISA BOD 23-01 blog series
This is part 2 of our 4-part CISA BOD 23-01 series. Check out part 1 to start at the beginning of the series.
Vulnerability scanners are great for finding vulnerabilities, bad for creating asset inventory #
Vulnerability scanners use checks to test for specific CVEs. They were not built with asset inventory in mind. Vulnerability scanners typically require credentials or an agent to function optimally. However, that’s not the best approach if you are worried about unmanaged devices.
It’s easier to explain if we get into specifics.
Vulnerability scanners focus on CVEs but don’t fingerprint devices well #
We had one specific support case with a large telecommunication customer who was doing a proof of concept of runZero on their network. Their existing vulnerability scanner had identified an asset as “CentOS Linux.” runZero identified the same asset as “F5 BIG-IP Load Balancer,” so they started an investigation on why we were showing something so different.
It turned out that runZero was much closer to the true answer. The device was indeed an F5 BIG-IP Load Balancer. While the BIG-IP firmware is based on CentOS, knowing that it’s a specific load balancer, including the model number and firmware version, was significantly more useful to the security team. This especially raised eyebrows because runZero was able to fingerprint the device more accurately without having credentials, while the vulnerability scan was authenticated.
This demonstrated to and convinced the vulnerability management team that asset inventory with their existing tooling was untenable.
Requiring credentials means you miss unmanaged devices #
When you are discovering your network, you will never have credentials for everything. Printers, HVAC systems, digital cameras, and development test boxes will not be joined to the domain. You’re also likely to have many rogue devices that you’ll want to include in the inventory. If your company has grown through acquisitions or has a federated structure, it’s going to be very hard to have a central repository for all credentials.
This is why the CISA directive requires a specialized asset inventory solution that “does not require special logical access privileges.”
Vulnerability scanners tend to knock over fragile devices #
Another challenge with vulnerability scanners is that they tend to knock over fragile devices, such as printers and print servers, PLCs, biomedical devices, and various other OT and IoT equipment. This makes vulnerability scanners inadequate to scan some parts of the network.
Many vulnerability scanners are based on nmap for network enumeration and then layer their own vulnerability checks on top. Both nmap and the vulnerability check often use security probes, including malformed packets, to identify specific operating systems or vulnerabilities. This can destabilize some TCP/IP stacks and protocols in embedded systems.
Vulnerability scanners typically also complete the scan of one device in one go, sending a flood of packets to the device that can overload it, causing it to either respond slowly or crash.
runZero was designed to safely scan fragile devices. The Explorer does not use any security probes or malformed packets, only standards-compliant network traffic. Its scan logic has special provisions for certain devices that are known to be fragile. When it scans a network, runZero will send only a handful of packets to one device before moving on to the next, going round-robin until the network is fully discovered. This avoids overloading an individual device with too much traffic. Today, runZero successfully and safely scans not only offices and data centers, but also manufacturing plants, hospitals, and utilities.
Most organizations only scan parts of their network #
We’ve seen a lot of organizations radically underestimate how many assets they have on their network. One hardware manufacturer told us that they thought they had 10,000 devices, but now they’ve found they have more than 100,000 assets. A multi-national company said they thought they only had two networks, now they’re counting more than 40.
When you manage a network that has grown organically over decades, built by generations of network administrators (and/or has grown through acquisitions), it’s very hard to know what you have. That doesn’t include any rogue networks that individuals, teams, or contractors have added to the network.
Because vulnerability scanners use a lot of vulnerability checks, they are too slow to crawl through the entire RFC 1918 addressing space so organizations can’t explore all the subnets they have.
runZero scans are about 10 times faster than vulnerability scanners because the traffic to fingerprint an asset is much lighter. runZero has a special feature called subnet discovery that enables customers to scan the entire RFC 1918 addressing space overnight. In this mode, the Explorer samples random addresses in each subnet and only scans the full subnet if hosts are found. The scans can be sped up even more by doing a ping sweep, which reduces the traffic to a single host or sample to a ping.
Consider this Capgemini case study, detailing how they helped deploy runZero at a global luxury retailer to support the security team and feed a more accurate asset inventory into ServiceNow:
“runZero scanned an entire retail store in under two minutes, sometimes completing the process in just thirty seconds. The team was also able to scan a small data center in less than six minutes and a large data center in thirty minutes. Qualys couldn’t even get the large data center done overnight.”
In addition to the technical challenges, many customers have said that they cannot afford vulnerability scanning licenses for their entire network. runZero has fair and transparent pricing that aligns better with customer budgets to ensure full coverage.
Vulnerability scanners miss many misconfigurations #
Vulnerability scanners flag known vulnerabilities. However, they don’t inherently allow you to see configurations that may be risky in your context. For example, having RDP on a publicly addressable IP address is not a vulnerability, but it’s certainly risky because it’s a common way for ransomware crews to get into your network. A dual-homed machine may not be risky in all situations, but if it concerns a machine in your cardholder data environment (CDE) that bridges to another network segment, it’s a huge deal.
Vulnerability scanners can’t satisfy the 72-hour window for zero-days #
Vulnerability management scan speeds are also a challenge for the zero-day requirement in the CISA directive:
“Develop and maintain the operational capability to initiate on-demand asset discovery and vulnerability enumeration to identify specific assets or subsets of vulnerabilities within 72 hours of receiving a request from CISA and provide the available results to CISA within 7 days of request.”
Most vulnerability scanners cannot scan an entire agency within 72 hours, let alone with a new zero-day vulnerability.
Let’s use Log4j as an example: When the Log4j vulnerability was made public, it took all three major vulnerability vendors two weeks to develop vulnerability checks for all the affected products. Once the checks were made available to their customers, they had to scan their networks. Many had to wait for their next scheduled maintenance window to do so, often another week and sometimes more.
Now let’s assume three weeks have passed since the vulnerability broke out and the first assessment is only just now able to be made. CISA’s directive requires 72 hours, which is short but necessary, because high profile vulnerabilities are quickly exploited in the wild. You need to react fast if you want to protect your network.
The solution is to decouple the scanning from the assessment. With runZero, you already have the full inventory scanned and in your database. Finding affected applications only requires running a search across that inventory, not rescanning the network. Even if it did, runZero would scan the network 10 times faster than vulnerability scanners.
To see how this works in action, check out our blog post for finding Log4j applications and other Rapid Responses.
The good news: this approach works for all zero-day vulnerabilities that are network discoverable.
The bad news: you’ll still need to keep your vulnerability scanner. runZero can dramatically speed up your zero-day search from weeks to seconds by finding affected applications, but it can’t always tell if a vulnerability is still present on a machine. Once a large part of your estate is already patched, a full vulnerability scan is still needed to identify patched versus unpatched machines. runZero works best on day one because all affected devices are unpatched.
Follow the story #
Check out Part 3 of this story.
