State of Insecurity: Challenges to Addressing Discovered Vulnerabilities
- Feb 19, 2015
- Guest Author
Penetration Testing, Red Team Operations, Exploit Development, Vulnerability Management, Brute Forcing, Advanced Persistent Threats and even BEAST, CRIME, Zeus, Code Red, Sandworm, Heartbleed, WireLurker, ShellShock – all the many buzzwords used in glamorizing the offensive side of security or even to name devastating and complex malware and vulnerabilities in the 21st century.
Consider the remediation for the HeartBleed vulnerability on Dell’s Global Management System (GMS) – Apply Hotfix 144490 to GMS 7.2 Windows. That’s how sexy, seductive and motivational the state of defending the enterprise is mired in several layers of bureaucracy in getting any remediation carried out. It’s gotten to a stage where offensive security tools have taken a cue from the Machiavellian strategy of “an active defense is the only real defense” to rebrand themselves as a means of defense just to break into new markets.
Consider the following scenario of professionals on opposing sides have a quiet end of day discussion with their significant others (SO).
So my short rant aside, what are the key challenges that remediation teams face in spite of the advances in vulnerability detection technologies?
Vulnerability assessment exercises spew out hundreds or thousands of vulnerabilities per scan or penetration test. Some organizations blur the line between real-time monitoring and scan-based detection to constantly be on top of their awareness of how vulnerable they are with no clear SLA or even basic plan on actually fixing vulnerabilities in place. With mountains of vulnerability information available, focusing on remediation can be a daunting task, and the thought of even starting somewhere with the fear of regression related bugs and vulnerabilities can make the most proactive blue team expert strung up on caffeine and wanting to call in a sick day.
Vulnerability scans often report vulnerabilities with a severity rating based on the CVSS2 base score. However, this fails to put the severity in context of business criticality. For example, a Java related vulnerability found on a web server and a workstation will have to be addressed differently. Other factors such as the availability of exploits, automated exploitability by malware and even availability of patches enables security analysts and teams to make more informed decisions based on how vulnerable their most critical assets are and on how fast they can be secured. This very important contextual information is missing from the results of many vulnerability assessments via automated tools.
The key problem about discovered vulnerabilities is the lack of context provided to the main stakeholder i.e. the remediation and patching teams. A vulnerability scanner typically generates scan results in terms of lingo that offensive security experts are acquainted with. Probably the result of glamorization of hacker culture or just that it communicates to the blue team that they suck but doesn’t give them more information on how to actually fix things. As a former software developer, hearing terms like SQL injection and cross-site scripting did not make me any wiser as opposed to just informing me about best practices in terms of parameterized queries, input validation and sanitization. Scan results have references for security teams to research the solution without really giving straight answers leading to a higher learning curve.
Remediation teams lack the very intelligent and sophisticated platforms that Red Teams use to stay current on their risk posture and security awareness. In a world of cloud powered big data intelligence and analytics, remediation teams often find themselves behind the trend.
NopSec Unified VRM resolves these key vulnerability management challenges to help design and support your remediation efforts. Schedule a demo today.