6 ms·

Threat Modeling Manifesto

69 points by kiyanwang 6y ago

baby 6y ago
I think threat modeling is great, and not that hard (see [1]), but the problem as with everything is that it's tedious to do by hand and it's not clear how one should start or structure the output of a threat modeling exercise. This cries for better tooling. After all, tooling is here to make you a superhuman, so where's the tooling to help you create a threat model easily? I've done some with spreadsheets, but it's really not the ideal tool. If I had time on my hand, I would probably create a threat model SaaS. [1]: https://news.ycombinator.com/item?id=26059701 https://news.ycombinator.com/item?id=26059701
mikewarot 6y ago
>We have come to value: A culture of finding and fixing design issues over checkbox compliance. Design issue: Widespread failure to teach and implement the principle of least privilege. Effect: Widespread belief that computer security can't be solved.
tetha 6y ago
Hm, currently, this sets of marketing alert bells. It looks pretty, it has good points. I'd like to have some structured approaches to some internal concerns we have. However, there seem to be zero links to tools and approaches to actually do something? Most links are to articles explaining why the manifesto exists... by companies offering consulting in this area.
- alphalima 6y ago
  If you're looking for concrete resources with steps on how to perform threat modelling, I've used the Microsoft SDL Threat Modelling tool/process [1]. It's pretty Microsoft skewed (lots of references to Azure resources), but is a reasonable way to start thinking about the topic. [1]: https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling https://www.microsoft.com/en-us/securityengineering/sdl/thre...
  - baby 6y ago
    I really don't like it. Personally, I think it isn't hard to threat model your system: 1. break down your systems into smaller units 2. for each unit, figure out: - what attackers are after (e.g. stealing a database) - what attackers can do (e.g. infiltrate the network) - what's the likelihood of each attack and scenario you can think about, along with the impact - what you've done to prevent it (and is it good enough?) - what you've done to detect it (and is it good enough?) - what you would do to respond to a successful attack (and, is it good enough?)
- abarringer 6y ago
  Might want to look at https://attack.mitre.org/matrices/enterprise/ https://attack.mitre.org/matrices/enterprise/
cottsak 6y ago
could prob do with a HTTPS redirect tho :p and maybe a sprinkling of HSTS
- whirlwin 6y ago
  Yeah. Quite funny. "Do as I say, not as I do".
- alanfranz 6y ago
  Wow, I don't know if it's intentional on the part of the authors, but, on the contrary, I'd ask you: why? What is your threat model? Do you think somebody may perform a MitM to replace the information on the website? Do you think somebody could sniff your communications with that website and there could be any negative consequence for any party? The HTTPS movement, in a lot of situations, suffers from non-threat modeling issue. There's very little gain from https-protecting a page like the linked one; at the same time it's true that the cost involved is minimal.
  - goalieca 6y ago
    My old isp used to inject ads and other warnings into plain http traffic. I think it’s generally considered a good posture to be defensive and have privacy as default. Time has shown that information is power no matter how boring you think it is.
  - beermonster 6y ago
    Aside from helping mitigate MiTM, https has other benefits - Faster due to that fact HTTP/2 can be used. - Makes censorship harder as individual pages cannot be censored but rather the entire site which is more noticeable - Stops ISPs injecting content/tracking - Stops transparent proxies injecting content/tracking - Helps with page ranking as search engines prefer sites which load faster and offer improved security - Mixed content is a bit of a headache, with external resources such as JavaScript being loaded and leading to browser warnings.
    - alanfranz 6y ago
raesene9 6y ago
This is a good page, but doesn't have a lot of detail on it. A good page I found that covers threat modelling in a relatively approachable way is https://martinfowler.com/articles/agile-threat-modelling.html https://martinfowler.com/articles/agile-threat-modelling.htm...
motohagiography 6y ago
I've mostly given up on threat modelling as a solution, even after building a tool from scratch and using it in organizations, and now only do it privately on my own stuff, but the reason might be a fresh perspective. The basic problem is that the demand for security stems almost exclusively from compliance because compliance transfers risk out of the project and onto the standard/model. The idea of thinking through risks and hypotheticals and leaving a paper trail that you have acknowledged them basically converts theoretical risk into real liability within the project. In an ideal world of individual ownership and goodness, this means the incentives are aligned to create a good product, but in the real world of organizations, you've reduced the flexibility of the business to manage that risk, which means to take the risk and respond to it on the fly as it looks like it becomes realized. By problematizing the risk instead of managing it, you have destroyed potential value. Threat modelling is the exercise of problematizing risk. This is why the threat model is often the elephant in the room. Almost nobody in business wants to have the "negative" conversation about whether to block law enforcement (foreign or domestic), surveillance on users, protect against data snooping by technical staff (which is often a platform perk and feature), or institutional privacy violations and other obvious threats that a threat modelling exercise addresses. A business PM won't problematize those things because it will demand a solution that gets in their critical path. The best they can do is manage it, which means orienting themselves to risk and being ready to respond. When people buy security products, they almost exclusively buy ones that provide data to manage risk using surveillance and monitoring, which means generating data that drives conversations and enables the organization to adapt in time. If a security product does not either a) externalize a risk with compliance or b) provide data to flexibly manage risk, it's not a security product in the market today because nobody will have bought it. I realize this is a 10th man view of something these very smart people have spent a lot of time on, but in the 25 years I have been in the field, I have come to the conclusion that security people are essentially environmentalists and activists trying to make a case for internalizing an exogenous problem and cost, and the only way to get traction for it is to produce either low-level discretionary developer tools, or generate data that supports the conversations and provides that flexibility in a business' attitude to risk. Threat modelling is super powerful, but as a forcing function it can destroy value, and this is why it has encountered so much resistance. All manifestos are quixotic, and that is why I think this one may also be. I have found that the real value of a threat model is defining the business model for a security product, where the threat model is the business case for a product, but that product needs the above features, and to not be a solution to succeed. The security product provides either compliance or data for the threats you derive from your modelling exercise, and it must either transfer risk to a model or provide data to manage. If it leaves responsibility in the project, like threat modelling, it's going to fail.
GartzenDeHaes 6y ago
This is a nice slide for an executive briefing. However, to get anything useful out of threat modeling you really need a full architecture view to start with. This would include both the technology and the business processes. Few organizations are willing to put effort and resources into developing these and there are few, if any, tools to help.
easterncalculus 6y ago
> People and collaboration over processes, methodologies, and tools. This part I don't get. Processes, methodologies, and tools are how you prevent bad stuff from happening. This is exactly what you need over just whether people feel okay or are collaborating enough before they go home. You can value these things but you absolutely should not put people over your processes, methodologies, and tools. Those are there when people inevitably fail. Pretty poor advice from anything related to threat modeling I've heard before; This is corporate speak instead of security speak.
- pdpi 6y ago
  Process, methodologies and tools are the resources available to you to tackle the problem from a technical point of view, rather than a goal unto themselves. People and collaboration are how you set those goals, and how you decide whether the processes in place fulfil those goals
- jcims 6y ago
  If you read the whole manifesto it references process and consistency quite a few times. I think the point is that its easier to fix the process than the people, so prioritize participation and collaboration over sticking to a specific approach.
- wefarrell 6y ago
  It's a regurgitation of the agile manifesto's "Individuals and interactions over processes and tools"

69 points by kiyanwang 6y ago

baby 6y ago

I think threat modeling is great, and not that hard (see [1]), but the problem as with everything is that it's tedious to do by hand and it's not clear how one should start or structure the output of a threat modeling exercise. This cries for better tooling. After all, tooling is here to make you a superhuman, so where's the tooling to help you create a threat model easily? I've done some with spreadsheets, but it's really not the ideal tool. If I had time on my hand, I would probably create a threat model SaaS. [1]: https://news.ycombinator.com/item?id=26059701 https://news.ycombinator.com/item?id=26059701

mikewarot 6y ago

>We have come to value: A culture of finding and fixing design issues over checkbox compliance. Design issue: Widespread failure to teach and implement the principle of least privilege. Effect: Widespread belief that computer security can't be solved.

tetha 6y ago

Hm, currently, this sets of marketing alert bells. It looks pretty, it has good points. I'd like to have some structured approaches to some internal concerns we have. However, there seem to be zero links to tools and approaches to actually do something? Most links are to articles explaining why the manifesto exists... by companies offering consulting in this area.

alphalima 6y ago
If you're looking for concrete resources with steps on how to perform threat modelling, I've used the Microsoft SDL Threat Modelling tool/process [1]. It's pretty Microsoft skewed (lots of references to Azure resources), but is a reasonable way to start thinking about the topic. [1]: https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling https://www.microsoft.com/en-us/securityengineering/sdl/thre...
- baby 6y ago
  I really don't like it. Personally, I think it isn't hard to threat model your system: 1. break down your systems into smaller units 2. for each unit, figure out: - what attackers are after (e.g. stealing a database) - what attackers can do (e.g. infiltrate the network) - what's the likelihood of each attack and scenario you can think about, along with the impact - what you've done to prevent it (and is it good enough?) - what you've done to detect it (and is it good enough?) - what you would do to respond to a successful attack (and, is it good enough?)
abarringer 6y ago
Might want to look at https://attack.mitre.org/matrices/enterprise/ https://attack.mitre.org/matrices/enterprise/

cottsak 6y ago

could prob do with a HTTPS redirect tho :p and maybe a sprinkling of HSTS

whirlwin 6y ago
Yeah. Quite funny. "Do as I say, not as I do".
alanfranz 6y ago
Wow, I don't know if it's intentional on the part of the authors, but, on the contrary, I'd ask you: why? What is your threat model? Do you think somebody may perform a MitM to replace the information on the website? Do you think somebody could sniff your communications with that website and there could be any negative consequence for any party? The HTTPS movement, in a lot of situations, suffers from non-threat modeling issue. There's very little gain from https-protecting a page like the linked one; at the same time it's true that the cost involved is minimal.
- goalieca 6y ago
  My old isp used to inject ads and other warnings into plain http traffic. I think it’s generally considered a good posture to be defensive and have privacy as default. Time has shown that information is power no matter how boring you think it is.
- beermonster 6y ago
  Aside from helping mitigate MiTM, https has other benefits - Faster due to that fact HTTP/2 can be used. - Makes censorship harder as individual pages cannot be censored but rather the entire site which is more noticeable - Stops ISPs injecting content/tracking - Stops transparent proxies injecting content/tracking - Helps with page ranking as search engines prefer sites which load faster and offer improved security - Mixed content is a bit of a headache, with external resources such as JavaScript being loaded and leading to browser warnings.
  - alanfranz 6y ago

raesene9 6y ago

This is a good page, but doesn't have a lot of detail on it. A good page I found that covers threat modelling in a relatively approachable way is https://martinfowler.com/articles/agile-threat-modelling.html https://martinfowler.com/articles/agile-threat-modelling.htm...

motohagiography 6y ago

I've mostly given up on threat modelling as a solution, even after building a tool from scratch and using it in organizations, and now only do it privately on my own stuff, but the reason might be a fresh perspective. The basic problem is that the demand for security stems almost exclusively from compliance because compliance transfers risk out of the project and onto the standard/model. The idea of thinking through risks and hypotheticals and leaving a paper trail that you have acknowledged them basically converts theoretical risk into real liability within the project. In an ideal world of individual ownership and goodness, this means the incentives are aligned to create a good product, but in the real world of organizations, you've reduced the flexibility of the business to manage that risk, which means to take the risk and respond to it on the fly as it looks like it becomes realized. By problematizing the risk instead of managing it, you have destroyed potential value. Threat modelling is the exercise of problematizing risk. This is why the threat model is often the elephant in the room. Almost nobody in business wants to have the "negative" conversation about whether to block law enforcement (foreign or domestic), surveillance on users, protect against data snooping by technical staff (which is often a platform perk and feature), or institutional privacy violations and other obvious threats that a threat modelling exercise addresses. A business PM won't problematize those things because it will demand a solution that gets in their critical path. The best they can do is manage it, which means orienting themselves to risk and being ready to respond. When people buy security products, they almost exclusively buy ones that provide data to manage risk using surveillance and monitoring, which means generating data that drives conversations and enables the organization to adapt in time. If a security product does not either a) externalize a risk with compliance or b) provide data to flexibly manage risk, it's not a security product in the market today because nobody will have bought it. I realize this is a 10th man view of something these very smart people have spent a lot of time on, but in the 25 years I have been in the field, I have come to the conclusion that security people are essentially environmentalists and activists trying to make a case for internalizing an exogenous problem and cost, and the only way to get traction for it is to produce either low-level discretionary developer tools, or generate data that supports the conversations and provides that flexibility in a business' attitude to risk. Threat modelling is super powerful, but as a forcing function it can destroy value, and this is why it has encountered so much resistance. All manifestos are quixotic, and that is why I think this one may also be. I have found that the real value of a threat model is defining the business model for a security product, where the threat model is the business case for a product, but that product needs the above features, and to not be a solution to succeed. The security product provides either compliance or data for the threats you derive from your modelling exercise, and it must either transfer risk to a model or provide data to manage. If it leaves responsibility in the project, like threat modelling, it's going to fail.

GartzenDeHaes 6y ago

This is a nice slide for an executive briefing. However, to get anything useful out of threat modeling you really need a full architecture view to start with. This would include both the technology and the business processes. Few organizations are willing to put effort and resources into developing these and there are few, if any, tools to help.

easterncalculus 6y ago

> People and collaboration over processes, methodologies, and tools. This part I don't get. Processes, methodologies, and tools are how you prevent bad stuff from happening. This is exactly what you need over just whether people feel okay or are collaborating enough before they go home. You can value these things but you absolutely should not put people over your processes, methodologies, and tools. Those are there when people inevitably fail. Pretty poor advice from anything related to threat modeling I've heard before; This is corporate speak instead of security speak.

pdpi 6y ago
Process, methodologies and tools are the resources available to you to tackle the problem from a technical point of view, rather than a goal unto themselves. People and collaboration are how you set those goals, and how you decide whether the processes in place fulfil those goals
jcims 6y ago
If you read the whole manifesto it references process and consistency quite a few times. I think the point is that its easier to fix the process than the people, so prioritize participation and collaboration over sticking to a specific approach.
wefarrell 6y ago
It's a regurgitation of the agile manifesto's "Individuals and interactions over processes and tools"