Vulnerability Management in a Data Warehouse
Have you ever been asked, “How long has that vulnerability been in our systems?”
Have you ever wondered if your patch management process is keeping up with the number of new vulnerabilities being identified? Keep reading…
Let’s start by considering the following chart to answer these questions:
The green line represents the number of new vulnerabilities being discovered in the test environment. The blue line represents vulnerabilities fixed and removed compared to previous scans. The purple line represents the total number of vulnerabilities present. As we can easily ascertain, even though I am mitigating the risks (blue), my pace is not fast enough to keep up with the total number of new vulnerabilities (green) being identified and my environment is progressively getting worse (purple).
This type of data, albeit rather fundamental, eludes many organizations due to the lack of a data warehouse for vulnerability management data and the ability of a vulnerability scanner to properly identify when a vulnerability is truly fixed verses just no longer present.
To further our discussion, please consider this table:
The data warehouse used to produce this table clearly shows that the time to fix the vulnerabilities from first identification to patching exceeds 30 days for the month of August. For regulatory compliance initiatives such as PCI, this exceeds the guidelines of PCI DSS 1.2 (30 days) and would technically make your environment non-compliant. Now, if we remap the same data into the proper specification for severity and age as the PCI DSS mandates, we can clearly see that we are not in compliance:
A total of 145 severity 5 vulnerabilities are older than 30 days in my sample for the same month. Now imagine being able to produce reports, tables, charts, and other data using the same information for months and years at a time. In addition, consider that all the values support multiple layers of drill down capabilities (values that are underlined) to isolate the root cause of deviation that created these metrics. This supplements any remediation report that they already have. That is the primary strength of storing vulnerability management information in a data warehouse.
When working with vulnerabilities, I have heard many clients state that old vulnerability data is stale and does not reflect the current state of my systems; so why keep it? While that may have some truth, the time, date, and severity of the identified information is crucial for a data warehouse. When stored for long periods of time, these types of charts are easy to generate. In addition, they can reveal key functions to the business as to whether the process put in place for vulnerability management and regulatory compliance are actually working as implemented. From the example of PCI above, they clearly are not.
So the next time you work with your vulnerability management solution, ask yourself if you can get more than just a vulnerability report from the product? Is the data available for more than 90 days? Can I match that data to regulations such as PCI, HIPAA, SOX, or GLB and frameworks like COBiT or ITIIL?
Vulnerability management is more than just trying to keep your systems secure. The data can be used to make intelligent business decisions, guide you through regulations, and indicate which processes are working, and which are not, over long periods of time.
If you are looking for this type of information from your vulnerability management system, look no further than Retina.
(All charts and tables in this blog where generated using real data from Retina Insight.)