We can't write secure code

David Lacey makes the important point that writing secure software is “not just about cutting secure code or developing better testing tools. We need to get things right much earlier in the development process.” It’s a subject I’ve been harping on about for some time, with many references to excellent resources such as OWASP, and great leaders on the subject such as Mark Curphey.

Over the last few years I’ve heard many solutions proposed to fix the problem of insecure software, ranging from sacking the developers to improving the software development lifecycle so that security requirements are stated from outset and followed through into production and beyond. The evidence is that none of it works. OK, the folk at Microsoft, for example, will say that security is now embedded in their culture, and they’ve certainly generated a nice new stream of revenue for themselves out of all the books, tools and journals on the subject. But they are still releasing security patches with a frequency and schedule that the I wish the rail company I use each day could achieve with their trains. And other vendors are coming up with clangers at an alarming rate. For example, this latest one from leading CMS vendor RedDot. An SQL Injection vulnerability in an enterprise level CMS system – what were they playing at with their quality control?!

So, here’s the thing. We can’t write secure code. It’s true. Can you show me any decent commercial, consumer focused product (that people actually want to use – not just techies who haven’t seen daylight in 12 years and live on a diet of digestive biscuits) that is secure from the off as soon as it’s exposed to the Internet and where 12 months later it hasn’t required a patch of some sort? Systems are simply too complicated with too many lines of code for anyone to expect that they can be released without containing bugs and security holes. That doesn’t mean that we shouldn’t try, it just means that we should take a different approach. That approach, in my opinion, is to take a leaf out of the new edition of the PCI standards and stick a ruddy great application firewall in front of everything. That doesn’t make the code secure, it’s a sticking plaster over a wound. But – to continue the analogy – a plaster stops the bleeding, prevents germs getting in, and while it’s not a cure, it’s good enough.

I’m not knocking OWASP et al. It’s the first resource I recommend developers go to and will remain so. Just that the business expects more functionality, cheaper costs, more complexity, better performance, and a more rapid deployment for its products. Chucking in security with all that lot is like rubbing your belly and patting your head at the same time, while riding a motorbike. So, let’s make it easy on ourselves. Application firewalls!

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

This reminds me of an excellent debate about the information system attributes of scale, complexity and security. The thesis was that you could only ever have two of these attributes at any one time (i.e. you could have scale and complexity, but not have security). Thus if our primary aim is a secure information system then a choice has to be made between scale or complexity. Like most things in life, security is about trade offs :-)
Cancel
Curphey would blow his stack if he saw his name mentioned in a blog recommending we move to web application firewalls. You are insane. WAFs do not make security easier. You can't use a WAF to fix your encryption, or logging, or access control, or object references. If you need a partial XSS detector, then maybe you should get one. WAFs seem like a solution, but only if you don't really understand the problem. It's like recommending Advil for diabetes. Find a clue at http://www.owasp.org.
Cancel
Insane? You should meet the rest of my family. OWASP is an excellent resource, if everyone took all the published advice and used it to best effect then web security problems would be a thing of the past. Over the past ten years or so that I've been looking at web product security the only thing that has changed is the severity of the consequences. Despite all the best intentions of OWASP and everyone else putting energy into web application security, I can still find common vulnerabilities in just about every website that I end up looking at. As to my own views, Mr. OWASP, you are preaching to the converted. I don't disagree with anything in your comment however, a new approach is needed. Security at the application layer clearly isn't working.
Cancel

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close