To write secure code, you do have to think like an attacker

admin
October 6, 2008


A security checklist for a developer might make it look like writing secure code is kids stuff, but even kids think like attackers sometimes.
Microsoft are doing some interesting work on SDL – Secure Development Lifecycle. I’m just not sure I agree with dumbing it all down to a checklist and letting developers work without attacker hard hats.
Today,  we got an email out of the blue from a security consulting firm asking for a phone call to discuss  “deep technical information for a client who is buying a threat modeling tool”.   A little poking around clarified  the motivation. First – the proximity to the Microsoft pre-announcement of their SDL 3.0 (Microsoft to Share Its Secure Development Blueprint, Threat Modeling Tool) on September 19, 2008 (the tool will be released some time in November). Then a visit to the GRC (governance risk and compliance) firm’s Web site showed some pre-announcements of their own for a IT risk assessment tool that seemed to have a good deal of similarity in it’s marketing messaging to PTA – Practical Threat Analysis – our free risk assessment tool.
I think they say imitation is a form of flattery but when a competitor (a big one like Microsoft or a smaller one like this GRC consultancy) copies ideas without sharing and attributing (as in Creative Commons sharing and attribution) it is annoying.
Still – it isn’t enough to copy ideas – you do actually have to have some original ideas of your own, as Microsoft definitely do.
Adam Shostack – who is Program Manager at Microsoft for SDL was quoted in Dark Reading that
“This [tool] allows us to start from the point of view of the software engineer… and to pull them through the process that doesn’t require them to think like an attacker or delve into anything they don’t know.”
I don’t think so.
If you want to develop secure code – start thinking like an attacker. If anything, use tremendous resources of the Microsoft Developer community to HELP them delve into stuff they don’t know. The more you learn about how your code can be used (or mis-used) – the better code you will write.
I just don’t think there is any other way to do it.

More Articles