How about adding: 3. It helps focus the valuable time of your external security people to the right subject and prevents audit RFPs that ask you to look for buffer overflows in systems where the authentication, authorization and role system is broken by design, but the code is written in C#.
Gunnar
· 2 years ago
I think you are confusing "don't give a damn about" with "don't know enough about"; I don't think developers want to write broken code. In my experience, the good ones will always latch on to perscriptive ways to improve authN, authZ and so on.
The real problem is that the security people and the developers are isolated from each other, and whatever knowledge the developers lack about security, the security lack at least that much wrt development practices - how many security people understand build cycles, software architecture, etc.?
I would not write off developers, in fact I think they are _far_ more likely than security people to create solutions in this space. Look at the track record and how much innovation comes out development there are new frameworks, languages, and arch. styles all the time - for one small concrete example unit testing was unheard of few years back and now it is sine qua non. Contrast this to security where you basically have two workign mechanisms (reference monitor and crypto) and think its fairly obvious where the solutions will come from. So it is all about how to pragmatically engage developers and getting them to innovate and extend on behalf of some (clearly articulated) security goals. Threat models may or may not be the best way to do this.
Adam
· 2 years ago
Glad you like the post Dave. It's the start of a series, and if there's things I don't cover, let me know. The goal is to talk about what worked and didn't, and how I've been fixing it.
Nick
· 2 years ago
We(the security guys)often only have one opportunity to review something. Threat modeling gives us an opportunity to identify the big issues that we should address.
The artifacts produced through threat modeling allows us to defend our recommendations (rather than making gut judgement calls without supporting evidence). Also, in many situations, you'll find that the developers haven't produced adequate documentation (architecture, data flow), so the development teams find it provides added value.
My team has adopted a process based off the Microsoft model. I'd be interested to know of alternative approaches exist.
Dave G.
· 2 years ago
FX:
I agree so much, I am adding it to my post!
Gunnar:
I was mostlyish joking.
FX
· 2 years ago
Wow! Thanks.
batz
· 2 years ago
I'm glad that someone of Mr. Shostak's technical background is writing from a broader security perspective. As someone who does code reviews for not just security, but for privacy (as legislated) getting developer buy-in that they are responsible for delivering secure code that ensures there are controls on the data they process - is sometimes an uphill battle.
Threat modelling using stories has been a useful way to express the scenarios we use to do our TRA, however, the broader problem is selling the notion of code quality. When an auditor publishes findings that say there is a lack of protection of the data, can we say we developed an application that provides some assurance that the data is protected?
We can't fix everything, but we can apprise people of the risk and leave it to them to either do something about it or accept it. A threat model helps security people organize their findings, but my experience has been that interpreting threats in terms of specific risk to business is what helps people "get it".
All Comments
3. It helps focus the valuable time of your external security people to the right subject and prevents audit RFPs that ask you to look for buffer overflows in systems where the authentication, authorization and role system is broken by design, but the code is written in C#.
The real problem is that the security people and the developers are isolated from each other, and whatever knowledge the developers lack about security, the security lack at least that much wrt development practices - how many security people understand build cycles, software architecture, etc.?
I would not write off developers, in fact I think they are _far_ more likely than security people to create solutions in this space. Look at the track record and how much innovation comes out development there are new frameworks, languages, and arch. styles all the time - for one small concrete example unit testing was unheard of few years back and now it is sine qua non. Contrast this to security where you basically have two workign mechanisms (reference monitor and crypto) and think its fairly obvious where the solutions will come from. So it is all about how to pragmatically engage developers and getting them to innovate and extend on behalf of some (clearly articulated) security goals. Threat models may or may not be the best way to do this.
The artifacts produced through threat modeling allows us to defend our recommendations (rather than making gut judgement calls without supporting evidence). Also, in many situations, you'll find that the developers haven't produced adequate documentation (architecture, data flow), so the development teams find it provides added value.
My team has adopted a process based off the Microsoft model. I'd be interested to know of alternative approaches exist.
I agree so much, I am adding it to my post!
Gunnar:
I was mostlyish joking.
Threat modelling using stories has been a useful way to express the scenarios we use to do our TRA, however, the broader problem is selling the notion of code quality. When an auditor publishes findings that say there is a lack of protection of the data, can we say we developed an application that provides some assurance that the data is protected?
We can't fix everything, but we can apprise people of the risk and leave it to them to either do something about it or accept it. A threat model helps security people organize their findings, but my experience has been that interpreting threats in terms of specific risk to business is what helps people "get it".