Jul
22.
I book marked this article quite a while back and only now got to have a read of it. The 8 Simple Rules for Developing More Secure Code by Michael Howard over on the msdn is a list of habits of secure developers. I know it’s a little old now, but oh well.
Paraphrased to:
- Take responsibility of your code
- Never trust data
- Use threat modelling against your code
- Stay one step ahead – or keep up to date with emerging vulnerabilities and threats
- Use fuzz input testing
- Don’t write insecure code (I found this point rather over-arching but his comments are good)
- Recognise the strategic asymmetry – be aware that an attacker can spend much more dedicated time finding weaknesses than you can provide 100% secure code
- Use the best tools you can
What I like about Michael’s list is that is applicable to any software development environment using any methodology. From PHP apps developed by a sole-developer for a small company to large, multi-tier, thick-client apps developed by a team of developers. It’s all good.
# Never trust data
# Use threat modeling against your code
# Use fuzz input testing
These are about the only good things he has to say. I mean really ‘write secure code’?
Stay one step ahead – This is silly! 90% of the attacks on [badly written] applications are due to poor input validation. He could at least talk to the software development lifecycle and introduce aspects of security within such a framework, rather than the 8 half arsed steps to looking like you know both security and software development. At what point does MH get the security requirements for his application? Where does he assess the risk of the threats he has identified? I could carry on but I’m lazy and you can do your own research!
Tools tools tools… liek if we fuzz the shit out of the application we will have secure code coz the leet haxors wont be able to break it! Sure fuzzing is the flavour of the month and has helped many a hacker, security professional and code monkey find flaws that would have previously taken vast amounts of time to find but it is not a panacea.
Now you say that these principals apply to everyone from you one man band to your big Indian development houses. Do you really envisage a one man band to go get the latest fuzzing tool to test on their dodgy PHP application? Do you think that apart from the aforementioned three salient points that a big software shop is going to tell its developers “don’t write insecure code”? For crying out loud he even uses a double negative! I would rather we as security professionals tell people to write secure code. It is almost like telling Ralph not to pick his nose!….Fucking futile endevour if you ask me.
Check out SP 800-64, it might be a bit longer than a blog post on the official MSDN blog but it will be more worthwhile.