Like that old maxim that “you need to stop fighting fires long enough to tell the architects to stop building things out of wood”, thinking like a bad guy is just the first step to developer security.
It’s a necessary step, but it’s not the final goal.
It’s a start – in fact, it’s a great start, and I think every developer needs to go through that phase. Many have yet to do so – particularly, it seems, those fresh out of college or programming school.
But I think it’s really a catch-phrase for the beginning of becoming a secure developer. It’s what you have to tell yourself when you’re used to writing code for the sole purpose of implementing features, so that you can get over that mind-set and into the sort of thinking that accepts that your code can be attacked.
But the bad guy has it easy.
He only has to find one way in. He can afford to become an expert on one part of your software, and zero in on it.
Thinking like a bad guy will widen your awareness to the point that you know that incursions can and will happen, and you’ll occasionally take better care in your coding. That’s a good thing.
But what if you start thinking like someone building a defensive structure?
The defence builder has to find (and limit) all the ways in, and just in case he missed one, he has to find all the ways you can get further in once you’re in – he has to become an expert on all parts of the software, as well as something of an expert on the external dependencies – libraries, network equipment, database components, etc.
[After all, we’ve seen this past week how many sites can get exploited through SQL Injection attacks – and the primary cause for those seems to be web developers who don’t know SQL, yet who send SQL statements to be executed at the database.]
You could start thinking like a defender – what alarms should signal the presence, or possibility, of an intruder? What information could an active defender use to verify the intent of a potential intruder? How could you slow down a possible attacker to the point where it’s feasible for a human responder to outpace a mechanical attacker?
Maybe you could start thinking like an investigator – once you believe someone has got in, what clues would you like to be left, showing you where the holes were? How can you tell what defences have been useful and what defences were useless? Where was the attacker actively assisted or resisted by your system and software?
Perhaps you could even think like a defence component builder – how can you ensure that you learn lessons from tried and true defences in order to build those lessons in to the next system, or to teach the next set of builders?
Think like the architect of a mediaeval castle – we’ve gotten used to the idea that mediaeval castles were places of defence, that they sought to be impenetrable bastions behind which the local king, thane, lord or whatever could take refuge and survive. Yet they were also places of business, places of government, places with a function. We need to design programs like mediaeval castles – capable of functioning for business as well as for defence.
SecureDeveloper.com hasn’t really gone beyond the first stage of its launch yet, so it will be a while before these advanced topics will be discussed – and I am eager to see that happen.