By taking the red pill responsible management would instantly see all these risks, but it cannot be "unseen", so they would have to act to reduce them to acceptable levels (taking away resources that would otherwise be devoted to business functionality). Suppose there exists a complete risk analysis that provides insight into every aspect of risk for a company.
#Sdl threat modeling tool for mac movie
I often think about a theoretical situation related to the movie the Matrix. Maybe your comment is related to something I have experienced. How else would you be able to manage risk if you are not even aware of it? If you're aware of a risk you may choose to detect problems instead of prevent them from happening. "you've reduced the flexibility of the business to manage that risk": Why? Again, risk identification does not automatically mean risk mitigation. The best they can do is manage it": If you identify a risk you can still choose to accept it and do nothing to mitigate it. "A business PM won't problematize those things because it will demand a solution that gets in their critical path. So how does it transfer risk out of a project? "compliance transfers risk out of the project and onto the standard/model": If I choose to be compliant to a standard, some of the risks are mitigated, not transferred some risks I have that are not covered by the standard are not mitigated or transferred, but still unknown, because I chose not to look into the threats (but just comply with some standard). Your comment resonates with me but I'm not sure I fully understand it: If it leaves responsibility in the project, like threat modelling, it's going to fail. 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. 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. All manifestos are quixotic, and that is why I think this one may also be. Threat modelling is super powerful, but as a forcing function it can destroy value, and this is why it has encountered so much resistance. 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.
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. 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. The best they can do is manage it, which means orienting themselves to risk and being ready to respond. A business PM won't problematize those things because it will demand a solution that gets in their critical path. 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. This is why the threat model is often the elephant in the room. Threat modelling is the exercise of problematizing risk.
By problematizing the risk instead of managing it, you have destroyed potential value. 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. 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. 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. 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.
0 kommentar(er)
