What more you can do with vulnerability data?
In an earlier article, I spoke about how you can set up a vulnerability scanning and reporting program, a program to enrich and complete your CMDB. And what you need to do to deal with data avalanche. But why stop there? With vulnerability data, you can do so much more. In this article, I will mention some of the other things you can achieve with vulnerability data.
--
Incident Response Process
Vulnerability information is an excellent source of information during incident response because one of the steps during incident response is to verify the alert. Did the attacker use a known vulnerability or not? And for example, is lateral movement possible from the host the attacker has under control? And no to any of these questions is not a negative answer, it just reveals something about the attacker and how he/she operated.
If you are using advanced incident response software like Demisto, you can use the vulnerability data to automatically validate and verify the raised incident, and/or you can use this information to optimize the incident response process itself. And therefore, you can reduce the time to remediate the incident.
SOC monitoring/response use cases
Vulnerability data can also be used as an input during use case development. For example, adjusting the severity level of a raised alert is such a use case. Especially if you want to monitor vulnerable assets more closely.
Behavior analytics
If you combine behavior analytics with vulnerability scanning data with IDS/IPS and/or WAF alerts, you can create some advanced behavior analytics use cases and/or use the vulnerability data as a risk indicator between hosts which are displaying similar behavior.
A high amount of false-positive alerts from the same source may indicate probing and/or reconnaissance activity while a high amount of true-positive alerts to the same destination may indicate a targeted attack. You can use the vulnerability data as a risk behavior indicator.
Breach and Attack Simulation
Once you know your vulnerabilities, you can emulate how an attacker could walk through your environment. This will help you to identify potential weaknesses in your defense posture.
While dealing with the Log4J vulnerability, many companies implemented one or more network or host IPS rules to protect themselves while the remediation for the Log4J vulnerability is/was underway. And as long as you know your environment quite well, there is nothing wrong with the approach but with breach and attack simulations you can verify this assumption.
Architecture
Vulnerability data is also a significant source of information when you are validating architectural designs. For example, based upon the vulnerability data, you can decide to isolate vulnerable assets to a separated zone and extremely limit the in- and outgoing traffic.
Based upon the architectural designs, you can also evaluate if a discovered vulnerability can be exploited and how difficult this exploitation in fact is. Therefore, if you combine these two, you can decide which vulnerability needs to be remediated first.
Software development
Virtually every vulnerability is assigned to a common weakness enumerator. If you analyze this data over time, you can observe trends emerging in software development.
If you analyze the Top 25 most dangerous software weaknesses, you can identify a considerable number of times input validation/neutralization causes. In other words, software engineers do not include code to validate incoming data. And this information can be shared with in-house software development teams to further improve the reliability of the developed software.
Pentest/Ethical hacking
A pentest or ethical hacking assignment is not the same thing as a vulnerability scan. Therefore, if you see in the pentest or ethical hacking report the same vulnerabilities listed as in the vulnerability scans, you can wonder if the pentest or ethical hacking assignment was executed correctly.
