By now, you most likely have heard of the announcement of the Heartbleed vulnerability in versions of OpenSSL. Actually, by this time, your executives, your front line managers and your mother-in-law have probably heard of the Heartbleed vulnerability given it has hit every major new source (WSJ, CNET, CNN) While this ubiquitous software is a foundation for many web applications, most people will relegate this as “someone else’s problem”. However, many companies utilize OpenSSL within their own infrastructures to secure internal applications. Even if you aren’t affected by this specific vulnerability, the noise created by Heartbleed should again prompt you to think about your own vulnerability management program.
I have written quite a bit in the past on the importance and various aspects of vulnerability risk management. (See my latest series on VRM – 1, 2, 3). My key point is managing vulnerabilities has (and always will be) a critical part of a dynamic security strategy. Creating a plan to stay on top of vulnerabilities as they emerge (like Heartbleed) can be a challenge. I outlined one scenario not too long ago in this blog entry regarding the 22 year old X Windows vulnerability. With proper processes and the right enabling technologies, companies can quickly respond to emerging threats.
When we took a look at Heartbleed, Jason Creech, our product manager for the RSA Archer Vulnerability Risk Management (VRM) module, provided some excellent insight into how VRM fits into this picture. Vulnerability Scanners can and often provide a list of installed software on devices. Some, but not all, can check for what version is installed as a “potential exposure list”. VRM’s data warehouse can store data from multiple scan vendors and, when coupled with the Vulnerability Analytics (VA) Query Engine, can be a key differentiator for your vulnerability risk program.
For example, in the case of Heartbleed, versions of OpenSSL 1.0.1 before “g” are susceptible to this new vulnerability. Since VRM’s Vulnerability Analytics Data Warehouse stores previously gathered scan data for the device inventory, security administrators can use the VA query engine to search for devices using the installed software version criteria. Using a simple query (installed_software:openssl), VA can check for systems that have openssl installed if the data has been provided by the scan vendors. More sophisticated queries (e.g. ‘installed_software: openssl NOT installed_software:"openssl 1.0.1g" NOT installed_software:"openssl 0.9.8e") can drill into the data to find those systems with the exact impacted versions. Coupled with the business context coming from RSA Archer, security teams can quickly identify criticality HIGH systems.
Using the alert functions within VA, notifications can also be enabled to notify system owners based on this query. Very quickly, the security team can identify vulnerable systems, fire off notifications to system owners and begin implementing response or mitigating controls.
In my previous blogs on vulnerability risk management, I spoke of the need to track key metrics (Metrics that Matter). An additional metric to add to the list is the speed at which a security team can link an emerging threat, like Heartbleed or the many other vulnerabilities that seemingly parade non-stop at us, to internal affected systems. That speed will directly affect the company’s ability to reduce exploit surfaces and drive tangible actions to manage emerging security risks. Having the ability to quickly mine existing scan data – like the process I just described using VRM - eliminates the time needed to build and execute singular scans to identify affected systems. The ability to fuse business context to potentially vulnerable systems drives priority and is one of the short cuts to identifying risk in a heartbeat.
Watch this video to find out how our Vulnerability Risk Management solution helps organizations manage vulnerabilities and implement processes to stay on top of emerging issues like Heartbleed.
