Saturday, May 02, 2009

8 reasons why website vulnerabilities are not fixed

Some reasons I've heard over the years. In no particular order...
  1. No one at the organization understands or is responsible for maintaining the code.
  2. Features are prioritized ahead of security fixes.
  3. Affected code is owned by an unresponsive third-party vendor.
  4. Website will be decommissioned replaced "soon".
  5. Risk of exploitation is accepted.
  6. Solution conflicts with business use case.
  7. Compliance does not require it.
  8. No one at the organization knows about, understands, or respects the issue.
Any others?

27 comments:

Jason Remillard said...

9) lack of prioritization of the issues. Give someone 250 vulnerabilities, and they'll die. Give them 4 immediate issues, 54 mid-level etc. and its absorbable

10) more security scanning solutions are too expensive. Thus making a 'onetime' scan a 'once a year if I remember to' event.

We offer some simple, and effective solutions to these issues

Jason - www.54f3.com

Jeremiah Grossman said...

A lot less equals ... uh... more. OK

Anonymous said...

11) Organization ignored AppSec Consulting Service's industry best practice recommendation and tried to fix it their own way.

Anurag Agarwal said...

they didn't know application existed :)

Jeremiah Grossman said...

LOL Anurag, that's a good one! :)

Nilesh Kumar said...

Hi Jeremiah,

Just few days ago I was posting on my blog (http://nileshkumar83.blogspot.com/2009/05/1-or-11-still-works.html) wondering what may be the reasons that people make blunder mistakes on major websites also.
I gave an example also that just entering 1 or 1=1 broke the authentication of a major Airlines' website!!! Blunder isn't it?
Today I got the answers on your post what might be the negligences behind these incidents.
I very much agree with you.

Thanks,
Nilesh

Jerry Mangiarelli, ASS.. :) said...

Vulnerabilities are misunderstood.

Jason Remillard said...

Jeremiah..

Perhaps you misunderstood.. I didn't say less, I said presentation counts, as does priority. Of course, we all shudder when we find *anything* exposed, but from a business perspective (large or small), there is only a certain amount of capacity for change.

The same definately applied in my Identity Management customers. Of course we wanted to do everything, but we had to focus on the basics first, then move on from there.

Jason

dunsany said...

Nothing to add but comment on "Features are prioritized ahead of security fixes."

Sometimes this prioritization is done by the customer and not the application owner/fixer. "I want all these new features. Oh and fix those holes while you're at it too."

Jeremiah Grossman said...

@Jason, what scanner technology backs your service? Couldn't seen to find a reference on the website.

webmaster said...

IT Managers loose kickbacks from Security Software providers if they patch every hole.

Jason said...

We don't disclose who our partner is, but it is a large vendor that we have licensing with.


Jason

Erwin Geirnaert said...

Another one:
there is no budget to fix the holes

Unknown said...

"It's an important feature of the application" said the application manager.

"A what? This is SQL injection. How can that be a design requirement?" asked I.

"Well, it wasn't. But, you see, we don't have much of an API so some of our big partners have written screen scrapers and they use SQL injection to efficiently extract large amounts of data. If we fix your SQL injection thing, we'll break their business."

Anonymous said...

Just finished a incident response for a breach at a MAJOR cc processor. When when first arrived onsite we found 2 snort boxes running that no one knew how to log into or who stood them up. They were just there for PCI compliance. I have found that if someone is not paid to care, no one will.

Jason said...

One of my personal favs:

'Its always been done this way'

Jason Remillard said...

wow:

McAfee: Enabling Malware Distribution and Fraud

http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php

Sachin Shetty said...

Risk is reduced by having a app firewall rule instead of a code fix.

Niranjan said...

some more:
- No one asked us to change it for last 50 products we developed with same code, why you now!?
- No one will hack our product/site (its always others)!

Daniel said...

#15...er I lost count)

The issue you have identified is an application feature and not a vulnerability.

There's nothing to fix crazy security man, why are you trying to make us non compliant!?

Anonymous said...

9) App is written in PHP

Jeremiah Grossman said...

Wow, some of these are really good! Funny even! :)

phatman said...

"It's too hard." They never actually say that of course. But when you strip away all the commentary that's what it often boils down to. I've been ISSO/IASO/CISM with 3 letter gov't agencies. Last year found significant sql injection vulnerabilities in test environment for major gov finical application. Head of development org, knowing that I wouldn't be allowed to pen-test production system during grant season, out-right lies and asserts that vulnerability didn't exist in production, despite being the same code. However, that's the lie the OCIO wanted to hear. When I confronted parties on this I was told that we'd revisit the issue after 'busy' season.

shrdlu said...

12) "Oh, our users are too dumb to be able to exploit that, not to worry."

Anonymous said...

My favorites (some of which have been posted):

- We've always done it like this before.

- Our customer service reps don't validate with this much detail.

Marcin said...

We are using SSL :)

Preeti said...

And some time Develper just comment that line of code...lol.....which is having vulnerabiltiy....:)