2 ms·

I disagree with his "start from the technology," standpoint, since that view is what enables the hall of mirrors effect in security, where vulnerabilities and r

I disagree with his "start from the technology," standpoint, since that view is what enables the hall of mirrors effect in security, where vulnerabilities and risks exist in a vacuum, and you get drawn into the rabbit hole of compliance. If you have developers who, by design, have no idea about the value or meaning of the data they are processing, or the business they are supporting, then empty compliance rituals are fine, GIGO applies. But, if you can use threat modelling to bring your developers into the fold of why they are developing a given feature and what makes it valuable, it makes better developers while ensuring they build security features into their work. The direction of this is business side inward, not technology outward as the author seems to recommend. The threat model is the counter-case of your business model, that is, when a factor fails. Having developers absorb the latest in vulnerability research and threat intelligence is not useful when you can just tell them, "I need you to make sure that a competitor's sales engineer can't pull this apart and humiliate us in a bake off," or, "given we're in payments, we've got both compliance hurdles and significant criminal threats." There is more value in educating product owners and product managers about how to identify and mitigate the counter-cases for their products' business models than externalizing risk by foisting it on developers who are neither equipped to handle it nor cognizant of it. In a product I developed, I defined threat scenarios as feature level Epics that developers use their skills to build for because people tend to know their own business needs and how it fails better than a corporate security group ever will. Startups typically don't need security outside of the bare minimum of compliance rituals because growth really does solve everything, see Zoom as an excellent example of this. I'm even having trouble recalling a startup that was killed by a security breach. Security is a product level problem. Start with the thing people want, ask what facilitates them getting it, and then as what happens when parts of that fail. IMO, this will solve %95 of security issues out of the gate.

Swannie 6y ago
I wholeheartedly agree. I was very surprised to see the Technology first perspective. This is a path to band-aids and incongrueties. When I read the worked example, I see something quite a bit different. The worked example seems to suggest integrating basic threat modeling practices into product/feature development user stories/use cases. This is a bit better, and I'd suggest a bit more aligned to your "value in educating product owners" comment. For me, it's quite straightforward ... what is the revenue generating aspect of your product/service? Let's assume mal intent, ignorance, user error, etc. are all likely, but not equally so, and come up with ways the service can be broken. Top down look at the options to protect against those - which are often a combination of people/process/technology, and then weigh up the additional complexity that introducing them adds. You basically end up with a threat/risk register, with mitigations, etc.

Swannie 6y ago

I wholeheartedly agree. I was very surprised to see the Technology first perspective. This is a path to band-aids and incongrueties. When I read the worked example, I see something quite a bit different. The worked example seems to suggest integrating basic threat modeling practices into product/feature development user stories/use cases. This is a bit better, and I'd suggest a bit more aligned to your "value in educating product owners" comment. For me, it's quite straightforward ... what is the revenue generating aspect of your product/service? Let's assume mal intent, ignorance, user error, etc. are all likely, but not equally so, and come up with ways the service can be broken. Top down look at the options to protect against those - which are often a combination of people/process/technology, and then weigh up the additional complexity that introducing them adds. You basically end up with a threat/risk register, with mitigations, etc.