Administrative Vulnerability Management - Special Guest Customer Post!
Written by: Jamie Herman, C|CISO, CISM, CISSP
By now many of you have taken a stab at BYOD, IPS or IDS (or both), and have begun the journey into making the business more aware of their surroundings, from an information security perspective of course. Many have likely implemented some type of vulnerability management program, complete with a scanner and a few hundred page report on the risks present in your enterprise. But while this technical locomotive has been barreling forward into the underworld of granularity and over-analyzation, there might be some very basic opportunities right in front of our noses. Looking at how we manage business assets rather than how we protect them could ultimately improve our security posture, and offer a great deal of insight into managing vulnerabilities and evolving threat landscape surrounding some of the most frequently and widely exploited software today.
We have typically seen software such as Java, Flash, Adobe Acrobat, IE, and a handful of others exposed and exploited for their seemingly endless vulnerabilities, managed by an applications group or desktop experience team. But have we crossed some imaginary threshold where we should be re-thinking how we approach software management? Is there some balance we could achieve by managing applications within a security team, which would not only free up resources for peer technical groups, but allow the information security team to maintain a tighter control over more vulnerable software and react with the appropriate sense of urgency and prioritization? There are likely competing views on this topic, but if one of them is the security team doesn’t have the knowledge to package and deploy applications, please write that on a post-it note and put it next to you until you finish reading this.
It’s extremely likely that with the appropriate amount of effort, a CISO can quantify an actual cost per incident or event through a few varying ROSI methods, or the cost incurred by not implementing some type of mitigating control. I’m not asking for that, what I’m asking is for you to take some time and calculate how many engineers or analysts it takes, and how much of their time is utilized for each incident relating to a software patch that is meant to fix a rather high profile vulnerability that becomes available, one that is likely to end up in the Blackhole exploit kit or Dragon toolkit before the day’s end. Take the time it takes to package, test, and deploy to the enterprise, and multiply it by the 27 updates of Java (including the initial release of version 7), which have introduced over 170 security fixes in the process. That was over the last 23 months alone, and one of the software platforms I’m referring to. As you can imagine, the dilemma grows exponentially as you expand out to Flash, Adobe, IE, Quicktime, etc., devouring resources in its wake.
I’m not making a case that your security teams should be the size of the desktop engineering team (well maybe, but that’s just me being selfish), I’m simply saying we need to rethink our strategy with regards to how we’re managing these software platforms that seem to keep us up at night, and as my boss put it so eloquently, terrified all day. Training and enabling security engineers to manage specific software platforms in use in the organization can go a long way towards mitigating risks, long gone are the days where we can sit idly by, wondering when that defining “we should have” moment is going to rear its ugly head. Shifting responsibilities in this manner would not be possible in many smaller organizations, I realize that, but it doesn’t mean that the appropriate attention to updating the frequently-vulnerable software packages shouldn’t garner a bit more attention in a different way than they already have.
Something to think about…