Common Excuses for Not Fixing Security Vulnerabilities

I received a tweet today from Katie Moussouris (Twitter @k8em0) Sr. Strategist at Microsoft about their BlueHat security event.  Don’t worry about attending, it’s an invitation only security event — I’m not invited either.  And I’m not so sure they want a red Oracle sheep in the crowd of blue Microsoft sheep anyway.  The good news is, like many conferences, they post some of their materials online.

The content for this year’s BlueHat is not posted but you can view previous years materials.  I noticed a session by Jeremiah Grossman (Twitter @jeremiahg), “A Statistical Journey through the Web Application Security Landscape”[1].  Jeremiah is the founder and CTO of WhiteHat Security.  There’re some points that struck home with me in his session so I thought I should share them.  The session is last years but it’s still painfully relevant.

Some background worth mentioning, WhiteHat Security provides services and software to help businesses identify and resolve their application vulnerabilities.  WhiteHat has learned over the years to provide customers the best value, they must do more than report vulnerabilities; they must encourage customers to resolve their vulnerabilities.  Companies that don’t remediate their vulnerabilities usually cancel their subscriptions since it’s like paying for the same security reports year over year.  With the preceding in mind, WhiteHat asks it’s customers why don’t you fix your vulnerabilities?  Following are some of the top answers they receive.

Why don’t you fix your vulnerabilities?

  1. Nobody at the organization understands or is responsible for maintaining the code.
  2. The development group does not understand or respect the vulnerability.
  3. Lack of budget to fix issues (vulnerabilities).
  4. Effected code is owned by unresponsive 3rd party vendor.
  5. Web site will be replaced or decommissioned soon.  Jeremiah noted, some of these sites have been on this status for over a year.
  6. Risk of exploitation is accepted.
  7. Solution conflicts with business use cases (aka, the vulnerability is a feature)
  8. Compliance does not require fixing the issue.
  9. Feature enhancements are prioritized ahead of security fixes.  Jeremiah noted, this one of the more fundamental challenges in software security.

At first I thought I missed an excuse but I reviewed the presentation again and only counted 9 not 10.  Anyway, I don’t see these excuses going away anytime soon.  I have listened to them many times myself.  Jeremiah also mentions a 2010 survey noting a difference between where consumers perceive security problems and where they focus their IT resources and spending.  The point was that organizations are not allocating resource and spending where they should to address their security concerns.  Epic fail, sigh.  I encourage anyone interested to check out some the BlueHat presentations as well as Jeremiah’s presentation.

Rgyle. “Clipart – Hat Outline.” Clipart – Hat Outline. 13 Jan. 2008. Clipart.org. 14 Dec. 2012 <http://openclipart.org/detail/10458/hat-outline-by-rygle-10458>.

[1] Grossman, Jeremiah. “A Statistical Journey through the Web Application Security Landscape, BlueHat Security Briefings: Fall 2011 Sessions, ” Channel 9. 3 Nov. 2011. Microsoft. 13 Dec. 2012 <http://bit.ly/TWZS1m>. (url shortened)

Author: milton

For bio see, https://www.securitycurmudgeon.com/about/