30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
I do like the Grugq comment at the top - threat modelling sounds hard, so when it does get done it becomes the starting point for a lot of advice that then gets cargo culted by the tools brigade.
I would recommend having a go at it though, the Wikipedia page is a pretty decent introduction.
Identify who your threat actors are, at work we use the following classifications: Non-criminals ('script kiddies'), Lone criminals / insiders, Organised crime, State sponsored actors. These are IT focussed, yours may differ depending on your domain.
Identify assets at risk, this could be data assets, people (you!), systems (eg: emergency services).
Consider the motivations and capabilities of each actor towards each asset, estimate the impact (cost) of their successes, prioritise them.
Consider the attack vectors towards each asset, I like Bruce Schneier's Attack Trees method. Estimate 'cost' to the attacker and prioritise those routes that impact higher priority assets at lowest cost.
That's it - you have a threat model, now you can look at mitigations to the identified risks through controls against the attack vectors eg: telephone network failure impacting emergency services - provide an alternative communication system.
Typically a threat model for one of our products at work is a one-page document in confluence.
To follow up the Schneier quote about never-ending process: put a threat model review into your development lifecycle, they'll thank you in the end :)
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
I have lived this. And I'm still trying to get myself dishonorably discharged from the tools brigade.
Gotta critique you on this, though:
Identify who your threat actors are, at work we use the following classifications
It's hard to get across how low, really low, the confidence should be in those identifications, which I've rarely seen based on much beyond past history, the results of garden variety monitoring tools, and intuition. I'm speaking from bitter personal experience here, and from my on and off reading of Hubbard and Seiersen.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Good point on how fuzzy/loose actor classification is - there is a vast array of motivations and personalities out there that this very crude slicing cannot reflect. I find it's a useful process to categorise your own assets though, asking 'who would be interested in this, and why'?
I have more recently started to consider if this 'outside -> in' approach is always appropriate, as there are other 'inside -> out' approaches that start with what we know about our own systems and their weaknesses, then consider if it's worth mitigating those, rather than the attackers view.
Thanks for excellent comment, Phil! In fact I am little ashamed that I did not make this post more comprehensive and holistic, but even some basics are sometimes hard to grasp for ordinary people. Also thanks for notice on threat modelling, yes, one should definitely put a threat model review into the development lifecycle, and think about it at the first place. Maybe (if there'll be enough time), I'll write more comprehensive post later, but I am really not sure if whether it belong here, on forum focused primary on development.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Welcome to being a poster here :)
I do like the Grugq comment at the top - threat modelling sounds hard, so when it does get done it becomes the starting point for a lot of advice that then gets cargo culted by the tools brigade.
I would recommend having a go at it though, the Wikipedia page is a pretty decent introduction.
That's it - you have a threat model, now you can look at mitigations to the identified risks through controls against the attack vectors eg: telephone network failure impacting emergency services - provide an alternative communication system.
Typically a threat model for one of our products at work is a one-page document in confluence.
To follow up the Schneier quote about never-ending process: put a threat model review into your development lifecycle, they'll thank you in the end :)
I have lived this. And I'm still trying to get myself dishonorably discharged from the tools brigade.
Gotta critique you on this, though:
It's hard to get across how low, really low, the confidence should be in those identifications, which I've rarely seen based on much beyond past history, the results of garden variety monitoring tools, and intuition. I'm speaking from bitter personal experience here, and from my on and off reading of Hubbard and Seiersen.
Good point on how fuzzy/loose actor classification is - there is a vast array of motivations and personalities out there that this very crude slicing cannot reflect. I find it's a useful process to categorise your own assets though, asking 'who would be interested in this, and why'?
I have more recently started to consider if this 'outside -> in' approach is always appropriate, as there are other 'inside -> out' approaches that start with what we know about our own systems and their weaknesses, then consider if it's worth mitigating those, rather than the attackers view.
Thanks for excellent comment, Phil! In fact I am little ashamed that I did not make this post more comprehensive and holistic, but even some basics are sometimes hard to grasp for ordinary people. Also thanks for notice on threat modelling, yes, one should definitely put a threat model review into the development lifecycle, and think about it at the first place. Maybe (if there'll be enough time), I'll write more comprehensive post later, but I am really not sure if whether it belong here, on forum focused primary on development.