Headline grabbing vulnerabilities, like SolarWinds and Log4Shell, target management software and end hosts, but if you search for “most exploited vulnerabilities” on Google, you will quickly learn that some of them directly target network and security devices as well as server load balancers.
These are the 3 most exploited CVEs in the last couple of years:
Would you be surprised to learn that network device operating systems can be vulnerable to security flaws like any other software? To remediate this risk, network and security administrators need a vulnerability management program in place. Having the right processes and technology in place can save time while protecting the network security posture.
A common approach is to split vulnerability management into two phases:
Publicly disclosed security vulnerabilities have an assigned CVE (Common Vulnerabilities and Exposures) ID number and a severity level based on their impact. CVEs help you to coordinate the efforts to prioritize and address these vulnerabilities to make systems and networks more secure. Most enterprise networks have evolved over time and include devices from several vendors running multiple versions of operating systems. Knowing that a vulnerability was announced doesn’t give a clear picture of the organization's correlative risk.
Large enterprises do their best to keep an accurate inventory of devices and their state, but given that most companies have experienced mergers, IT department turnover, and are resource constrained, this inventory is rarely current. Because networking vendors typically fix security vulnerabilities by issuing a new OS version, a detailed and up-to-date inventory is paramount. Trying to conduct this analysis manually is expensive, time-consuming, and error prone.
To make the analysis easier, faster, and more reliable, Forward provides a network devices vulnerability analysis that automatically compares the CVE information from the NIST National Vulnerability Database (NVD) with OS version running on the devices in your network.
This analysis provides a list of all possibly affected devices and related vulnerabilities. “Why possibly affected?” you might ask. Keep on reading and you will find out why.
The following screenshot shows an example of network vulnerability analysis in the Forward UI.
The summary at the top shows the number of CVEs detected as well as the number of devices impacted.
The table shows a summary view of the CVEs including CVE ID, Severity, Description, Impacted OS, Impacted versions, and the number of Possibly impacted devices.
The Details page shows you information about devices that are impacted by that CVE like Device, Model, OS version, and Management IPs.
One of the fundamental issues is that the number of vulnerabilities and devices affected can be overwhelming, making it difficult to prioritize which devices should be updated first. Filtering vulnerabilities by severity provides some help but typically the number of Critical and High severity vulnerabilities is still so high that it‘s challenging to determine a starting point. This is where the notion of “possibly affected devices” becomes pertinent. Some vulnerabilities can impact a device only if specific configurations are present, a specific feature is turned on, or they are deployed in a way that is explained in the CVE. This information is not in the NIST database, network engineers have to research vendor sites such as the Cisco Security Advisory repository to get this level of detail.
There’s a better way
Monitoring the latest descriptions and automatically checking them against the device configurations in your network is best performed by software — it frees up highly skilled engineers to spend time on proactive strategic initiatives and is far more accurate. For many NOC teams, this capability would be A dream come true, or Like Christmas came early, right?
Well, that is exactly what Forward Enhanced Vulnerability Analysis provides!!
No more manual, tedious, and error-prone hunting for those configs on every single “possibly affected” device, one by one, that would take forever.
Just an always accurate, always updated list of devices that are actually vulnerable! Remediation efforts can be prioritized based on risk severity to ensure effort is directed to keeping the network as safe as possible.The screenshot below shows the Detected based on field. This field indicates that there is an at-risk device in the network that matches the OS version only (OS version match) or is running the impacted OS version and matches the vulnerable configuration (Config match).
Read the use case to learn more about how Forward Enterprise can help limit your CVE exposure. Stay tuned with Forward Networks announcements because some great new innovations about vulnerabilities are...coming soon...
Last week, on June 30, 2020, F5 revealed a serious vulnerability in its BIG-IP product line that allowed attackers to completely compromise systems, intercept traffic and even steal encryption keys used to secure web traffic. F5 also released the corresponding fixes, but by late last week heading into the 4th of July weekend, the US Computer Emergency Readiness Team (USCERT) and CyberSecurity Command were sounding the alarm about the impact of the vulnerability and the prevalence of attacks already surfacing in the wild.
Wired magazine highlighted the news and the severity of the issue in a report on Monday, noting that many IT security practitioners had spent the holiday weekend in a race against time to patch vulnerable systems or risk having vast security breaches of internet traffic throughout their enterprises.
The result is that anyone who can find an internet-exposed, unpatched BIG-IP device can intercept and mess with any of the traffic it touches. Hackers could, for instance, intercept and redirect transactions made through a bank’s website, or steal users’ credentials. They could also use the hacked device as a hop point to try to compromise other devices on the network. Since BIG-IP devices have the ability to decrypt traffic bound for web servers, an attacker could even use the bug to steal the encryption keys that guarantee the security of an organization’s HTTPS traffic with users, warns Kevin Gennuso, a cybersecurity practitioner for a major American retailer. “It’s really, really powerful,” says Gennuso, who declined to name his employer but said that he’d spent much of the holiday weekend working to fix the security vulnerabilities in its F5 devices. “This is probably one of the most impactful vulnerabilities I’ve seen in my 20-plus years of information security, because of its depth and breadth and how many companies use these devices.”
When confronted with new vulnerabilities and zero-day attacks, it, indeed, can be a race against time to identify vulnerable systems and apply remediation. This is an ideal use case for the Forward Networks NQE feature, where we can convert a tedious search for impacted systems into a simple database query of your network details to return a list of vulnerable devices.
How can we do this? If you aren’t yet familiar with Forward Enterprise, and well, by now, you should be, one of our main strengths is to convert your network information into a normalized, vendor- and device-agnostic database that can be queried much like any SQL database. Sophisticated search tasks to identify policy and compliance issues that used to take weeks or months of scripting can now be done in a few minutes.
In our case of identifying impacted F5 devices, we refer again to the F5 field notice and the list of impacted OS versions and the current patch levels that address the vulnerability.
From here, our main objective is to identify relevant devices in our network. Our network database contains device names, vendor information, OS level, model type, as well as all the forwarding tables, security rules and policy information, plus a lot more. We will focus on the vendor information, model types and OS details in building our query.
The full query, written in our NQE query language, is easy to follow and allows users to specify how information is filtered, and how it is presented in a results report. The full query is shown below:
The opening statements set local variables as lists of affected OS versions and current patched versions. The foreach clause loops through all network devices and identifies the F5 devices across the network where either there is no model specified (unknown product) or in the BIG-IP family, including virtual load balancers.
Next we identify devices from the selected F5 device list and identify which ones potentially match the vulnerable OS version list. We have to be flexible in evaluating the OS release details because we may not be given the official patch level, or the OS release information may not be present. If not present, or if current patch level is unknown, we need to flag these devices for further evaluation in the report. Vulnerable devices are flagged as not having been known to be patched to current levels of the major OS release as the F5 field notice identifies.
Finally, we select (and output into our report) the list of affected devices and the information details that we need to report, as shown in the select statement.
For our demo network, we have two affected F5 devices running at the earliest major OS release level that show up in the sample report below:
If your network is global, consisting of thousands of devices, and no single team has visibility to all these levels of details, you could have a real time-consuming task on your hands. With Forward Networks, you could write this network data query in a few minutes and assess the impact to your organization immediately. When it’s a race in time against hackers, every minute is going to count.
These are the types of queries we and our customers typically share through our github sample repository. So, even if you didn’t have a few minutes to write it yourself, you could grab a copy in even less time! Want to learn more about NQE and how Forward Networks can accelerate your remediation efforts? Check out this video… or sign up for a guided demo of the whole platform here.