The first blog in this GuidePoint Security series focused on how Federal agencies can address the President’s Executive Order. It was pointed out that in section 1 b (iv) the EO states:

(iv)  Known but unmitigated vulnerabilities are among the highest cybersecurity risks faced by executive departments and agencies (agencies).  Known vulnerabilities include using operating systems or hardware beyond the vendor’s support lifecycle, declining to implement a vendor’s security patch, or failing to execute security-specific configuration guidance.

Common Vulnerabilities and Exposures (CVEs) are published to notify organizations of issues that should be addressed. Typically, the CVE will issue guidance on mitigation by anything from a simple patch from the vendor, to disabling services until a patch is released. Sometimes the mitigation is difficult because of legacy End of Life’d (EoL) software. What the EO warning acknowledges is that many agencies are behind in completing these CVE mitigations.

It’s a scary fact, but is easy to understand why. A typical vulnerability report includes hundreds to thousands of vulnerabilities that need mitigation. How does an organization quickly resolve all of them? Most organizations rely on prioritization strategies that result in a spread sheet of the vulnerabilities in order of which to resolve first. One of the ways agencies prioritize is how these CVEs are graded by NIST as “Critical,” “High,” “Medium,” or “Low,” depending on factors like how easy the vulnerability is to execute against and how much access the vulnerability provides the attacker.

While this might seem like a great way to prioritize which vulnerabilities to resolve, the simple fact is that all vulnerabilities cannot be resolved quickly. A large enterprise can fall weeks or months behind mitigation schedules because of the volume of vulnerabilities produced every cycle. If an application requires an EOL’d software to run, mitigation can be very difficult to resolve and involve recoding the application. This can leave some low category CVEs unresolved for a very long time. And this is what the EO is pointing out and rightly so. Why?

Here are some examples of where this type of rating system falls short. First, a low rating from NIST on a publicly facing application inside the DMZ that accesses sensitive information or information with PII on the back end. Even worse, maybe that software was EoL’d recently and there is no patch or remediation. Coders were already working on changing the code to support a newer software, but it’s three or four months away. While this may show up on a list of vulnerabilities as not-a-priority, you can easily see where this should be a high priority.

Second, a critical rating from NIST is given on a printer system that sits deep in the bowels of an enterprise network behind three different layers of firewalls. Also, the printer system is not on network connected to anything with sensitive data. This would show up in bright red in a list of vulnerabilities, but should be prioritized lower than the first example.

Finally, an HVAC system that should not, but does, sit on the same subnet as an organization’s database containing PII such as SSN or credit card information. The HVAC system requires EoL’d software to run the ICS that has just come up with a Medium NIST rated CVE rating vulnerability. On a simple list, this would show up as not important and difficult to resolve. However, a quick look at the network topology would show that the organization should firewall off this system from the network it is accidentally on. (See below how to get a “quick look”) Let’s add on to that attackers who have been actively using this vulnerability to exploit these systems.

GuidePoint Security has three recommended technologies that could significantly help better prioritize and mitigate these vulnerabilities.

Network Vulnerability Management Platform

In the first two blogs, here and here, NVM platforms were mentioned. The basic recap is that vulnerabilities are mapped to the network and a risk score is associated to it. Here’s your “quick look” referred to above. This is exactly what is needed when comparing the three cases for prioritization. There are several other valuable things NVMs add to a security infrastructure, but this value is relative to the EO specifically around which vulnerabilities to mitigate. Several customers have been able to document why a specific vulnerability might not be as critical to address as a basic NIST score might indicate and prioritize much higher risk vulnerability in context.

RedSeal Image

Vulnerability Threat Intelligence Mapping

This solution consumes an organization’s list of vulnerabilities and maps them to the activity seen in threat intelligence of threat actors. While this would not predict a new vulnerability’s sudden usage in the wild, it could help a security organization realize that a low or medium NIST rated vulnerability, that is visible to the outside, is a high risk because it is being actively used by criminal or nation-state actors.

Kenna Security Image

Application Delivery Controller/Web Application Firewall

While this might seem a default and not innovative, GuidePoint still finds organizations that do not have high quality Application Delivery Controllers (ADC) or have them and only use them as load balancers. These proxies offer a significant value to organizations when trying to mitigate applications that rely on old software or have vulnerabilities that cannot be easily resolved. By removing direct access to the application and forcing all traffic through the ADC, a vulnerability can completely disappear from the network, even while not resolved downstream inside the actual application. This allows for downtime planning or coding changes to be made on a reasonable schedule.

The best example of this was when applications were required to move from SSL to TLS (now at version 1.2). Many custom applications simply didn’t have the ability to make the change without code rewrites. By using a quality ADC/WAF, the connection from application to user could be converted to TLS, while the downstream application was scheduled for coding updates to make it possible to move to TLS natively. Restricting data traffic to just between the application and the ADC mitigates the problem.

F5 Image

There are other solutions that can help as well, however, these three are some that should be top consideration. If an organization doesn’t have them in their tool chest now, they should consider moving quickly to purchase, install and use them in order to meet the EO’s requirement to mitigate known vulnerabilities. For more about the above solutions and more choices contact GuidePoint Federal at

About the author:

Jean-Paul Bergeaux, Federal CTO, GuidePoint Security

With more than 18 years of experience in the Federal technology industry, Jean-Paul Bergeaux is currently the Federal CTO for GuidePoint Security. JP’s career has been marked by success in technical leadership roles with ADIC (now Quantum), NetApp and Commvault and SwishData. Jean-Paul focuses on identifying customers’ challenges and architecting innovative solutions to solve their complex problems. He is also a thought leader on topics that are top of mind for Federal IT Managers like Cyber Security, VDI, Big Data, and Backup & Recovery.