A few months ago many of us were alerted to the news that one of the three major credit reporting agencies had been breached by an unknown attacker and that 143 million personal records were taken.
As time has passed and details have emerged, there is a very alarming cause for this breach. Equifax failed to patch a serious vulnerability in their external facing web server for over four months.
Apache Struts CVE-2017-5638 was the vulnerability leveraged in this attack.
Often when I talk to customers about proper risk-based vulnerability and patch management, the question always leads to "How can we possibly patch everything?" For companies that are behind the maturity curve in vulnerability management, they struggle to see through all the noise.
What do I mean? They run their first set of scans after having never done so before and come up with thousands of findings. This typically leads to some sort of paralysis, after all this red how can we proceed. For very mature companies, they struggle with how quickly to roll out patches. They will follow a very safe and methodical approach to the problem, start by patching a test environment, or even a subset of test, move to QA, then to production. Each group will get several days to "soak" and hopefully flush out any unintended issues that arise due to patching.
Any of us who have ever spent time in IT Operations knows the dangers of patching, I spent 10 years on the IT Operations side of the house and sometimes a patch broke something. This type of approach is very logical and safe from an availability standpoint.
So how do we achieve a positive end result while dealing with both issues – too many vulns and too much fear of breaking something? The answer is surprisingly simple, although the implementation might not be: you take a risk-based approach. I will take the Equifax breach as example of how we would look at this vulnerability from a risk-based approach. We know the vulnerability exists on an external facing web server and that this server is used to process sensitive customer information. This gives us a starting point that any vulnerability on this server will get extra scrutiny due to the fact that it is both external and interacts with sensitive data.
Now we review the NIST details about this particular vulnerability. The full report is here.
First place to look is the Impact section
CVSS Base score is a 10 - the highest
The Metrics tell the rest of the story.
Attack Vector (AV): Network
Attack Complexity (AC): Low
Privileges Required (PR): None
From that we know it is a remote (over the internet in this case) vulnerability with a very low complexity to exploit and it is Pre-Auth, which means attackers don't need credentials. Most companies can stop right there – we have an external facing, sensitive system with a remotely exploitable, easy to trigger, pre-auth vulnerability. This meets criteria of something that needs to be patched ASAP, if not taken offline until it can be patched. Sometimes we can't patch right away and it can't be taken offline. This, while problematic, can be at least mitigated to some point by turning up monitoring and being extra alert to anything that occurs on this box. In these situations, make sure logging is turned up, your IPS/IDS is triggering on this specific vulnerability, have your SIEM or other log management platform email upon any high priority alert. The key here is to be quick but don't hurry.
This example shows us how we can weed through the noise. If you have a very large number of vulnerabilities and you are trying to figure out how to chip away at them, you do this exact same thing. Start with the most critical vulnerabilities on the most critical systems and work your way down the list.
Let's look again at the Equifax example. If the system were internal only (no outside access) we could lower the risk some, if the system hosted static content only and no customer data, we could drop the risk some more. We do this with all our systems and their vulnerabilities until we find the ones that are most at risk for loss of sensitive data and start there. In mature organizations that have a good patching process and are just doing maintenance patching, not every vulnerability should wait for the normal patching process. Some very high risk ones need to be patched sooner.
This exercise was very manual and for many companies not practical at large scales. That's fine; any vulnerability management tool worth owning can assist in this process. LRS recommends Tenable's suite of products, SecurityCenter, Tenable.io and Nessus. In Any one of their VM products, you can simply run a report to get a list of the most critical findings on the most critical systems and begin your patching efforts.
About the author
Greg Hetrick is our Security Solutions Technical Advisor and Penetration Testing Lead, and he focuses on helping customers identify gaps and achieve security goals. Prior to joining LRS Greg held roles as a red and blue team leader in a large financial services company and a large academic medical research hospital. He holds multiple certifications in the area of Information Security including: CISSP, GISP, GPEN, GXPN, and CISSP.