As I wrote in my article Risk Reduction for Legacy Systems, half of all security breaches are due to fundamental software defects (like buffer overflows, hardcoding arrays, disclosing database table names in error messages etc..)
I've gotten some feedback on the article and quite a range of responses from: "Heah, that all sounds familiar" to, "Wow, I didn't think that application security was such a big deal".
So just to put the record straight:
If a company is more concerned about marketing their product than making sure it's secure, then they shouldn't bother with my methodology. Two years ago, a client of mine received an extremely detailed and draconic set of security requirements from their integrator in Europe, Alcatel. The client asked me to review the document and I told him that he was walking on thin ice since the Alcatel security spec exposed them to the entire liability for a security breach. It turns out that the client hadn't even noticed that particular clause.
This is an Achilles heel for software development organizations of all sizes, so I am sure is room for an agile methodology that reduces software defects in order to reduce OPERATIONAL RISK especially for those young high-startups that don't take the time to read the fine print.
Some readers commented that fundamental software defects can be eliminated by proper QA and decent code review. Yup, and if your grandma had balls, she'd be your grandpa.
A good point made by my colleague Chava Leviatan, is that many companies assume that buying an off-the-shelf-ERP system absolves them of exploitable security breaches created by buggy software. It's a good insight, but let's not forget that these are all large software system with huge amounts of legacy code written by developers that didn't know beans about secure software development practices.
Most of the firms that have security breaches run ERP systems like SAP or Oracle applications, and they still get bitten. The vulnerabilities in an ERP system are even more acute since than home-grown applications since: (a) the data model is centralized and (b) most vulnerabilies are created in the custom interfaces written by the ERP integrator.
Sunday, August 27, 2006
Subscribe to:
Post Comments (Atom)
1 comment:
Good one regarding not having to do a software security assessment of Oracle ERP Applications - a client told me today that there was no point even trying since they don't have source (or maybe they do but don't want to spend money)
Danny Lieberman - Israeli Software
Post a Comment