Threat modelling
Wednesday, 30. January 2008, 13:46:59
I have a very difficult task those days: defining guidelines to ensure the security of a distributed application.
Despite the Oxford study that shows that engineers have a way of looking at the world that is similar to terrorists (?????), thinking as a hacker is not straight forward. And that's exactly what I have to do.
More than this, it's a job that involves great responsibility. It's important to review and validate all the assumptions and to test the results.
Anyway, I'm using the threat modelling methodology, which basically means the following steps:
Of course, in real life things are more complicated; for example data needs to be partitioned in sensible information (for example private data, commercial data etc.) and non-sensible information (for example lists of countries). Data Flow Diagrams are also very useful in order to follow exactly where the data is going, and so on.
Those steps should always be followed by many reviews, by training developers to follow the guidelines and by enforcing the guidelines.
I like this methodology because it starts from real world questions: What can an attacker do? How difficult is for him to do that? What are the effects of an attack? It also forces the analyst to learn about software vulnerabilities.
There is however another facet of any attempt to security: it always involves the human factor. I won't go in this subject now, but I recommend Bruce Schneier's blog for a very smart and insightful view on security, especially when it involves the human factor.
Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu
Despite the Oxford study that shows that engineers have a way of looking at the world that is similar to terrorists (?????), thinking as a hacker is not straight forward. And that's exactly what I have to do.
More than this, it's a job that involves great responsibility. It's important to review and validate all the assumptions and to test the results.
Anyway, I'm using the threat modelling methodology, which basically means the following steps:
- Imagine all the possible attacks to your system (of course, there are already lots of papers describing possible attacks; I am using them as a starting point)
- For each possible attack, evaluate its probability and the effects if it happens
- For each possible attack, decide if preventing it is necessary and/or possible
- For the remaining attacks, define the prevention measures
- For all attacks define the contingency plan (what to do if it happens)
- Translate the prevention measures in coding guidelines, test scenarios and maintenance procedures
Of course, in real life things are more complicated; for example data needs to be partitioned in sensible information (for example private data, commercial data etc.) and non-sensible information (for example lists of countries). Data Flow Diagrams are also very useful in order to follow exactly where the data is going, and so on.
Those steps should always be followed by many reviews, by training developers to follow the guidelines and by enforcing the guidelines.
I like this methodology because it starts from real world questions: What can an attacker do? How difficult is for him to do that? What are the effects of an attack? It also forces the analyst to learn about software vulnerabilities.
There is however another facet of any attempt to security: it always involves the human factor. I won't go in this subject now, but I recommend Bruce Schneier's blog for a very smart and insightful view on security, especially when it involves the human factor.
Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu
