- No one at the organization understands or is responsible for maintaining the code.
- Features are prioritized ahead of security fixes.
- Affected code is owned by an unresponsive third-party vendor.
- Website will be decommissioned replaced "soon".
- Risk of exploitation is accepted.
- Solution conflicts with business use case.
- Compliance does not require it.
- No one at the organization knows about, understands, or respects the issue.
Saturday, May 02, 2009
8 reasons why website vulnerabilities are not fixed
Some reasons I've heard over the years. In no particular order...
Subscribe to:
Post Comments (Atom)
27 comments:
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
A lot less equals ... uh... more. OK
11) Organization ignored AppSec Consulting Service's industry best practice recommendation and tried to fix it their own way.
they didn't know application existed :)
LOL Anurag, that's a good one! :)
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
Vulnerabilities are misunderstood.
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
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."
@Jason, what scanner technology backs your service? Couldn't seen to find a reference on the website.
IT Managers loose kickbacks from Security Software providers if they patch every hole.
We don't disclose who our partner is, but it is a large vendor that we have licensing with.
Jason
Another one:
there is no budget to fix the holes
"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."
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.
One of my personal favs:
'Its always been done this way'
wow:
McAfee: Enabling Malware Distribution and Fraud
http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php
Risk is reduced by having a app firewall rule instead of a code fix.
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)!
#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!?
9) App is written in PHP
Wow, some of these are really good! Funny even! :)
"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.
12) "Oh, our users are too dumb to be able to exploit that, not to worry."
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.
We are using SSL :)
And some time Develper just comment that line of code...lol.....which is having vulnerabiltiy....:)
Post a Comment