Hindsight is a wonderful thing and lessons learnt from Implementing a Threat Modeling program is no exception. I am curious to know how organisations from large to small have approached this.
Would love to hear your experience or of others you have worked with on what has worked or working well, or what you may perhaps do differently that you feel would drive a better outcome to your Threat modelling program?
Â
What I'm seeing is an Agile approach being the best. Constant improvement, guided by metrics. It's best to view Threat Modeling not as a point-in-time exercise, but something that can be guided and improved as more information becomes know.
This of course means there needs to be something to measure--how do you know a Threat Model is good? Or bad? How do you know it's improving? And not just lowering the calculated risk, but knowing that everything that needs to be modeled has been, and things that don't play a role are left off.
Ultimately, every organization needs to work out themselves what's important and what not. One orgs plethora of information is another's dearth.
What I'm seeing is an Agile approach being the best. Constant improvement, guided by metrics. It's best to view Threat Modeling not as a point-in-time exercise, but something that can be guided and improved as more information becomes know.
This of course means there needs to be something to measure--how do you know a Threat Model is good? Or bad? How do you know it's improving? And not just lowering the calculated risk, but knowing that everything that needs to be modeled has been, and things that don't play a role are left off.
Ultimately, every organization needs to work out themselves what's important and what not. One orgs plethora of information is another's dearth.
I hear you! Agile works here as you need to change tact quite often. As the quote goes “Everything changes but change itself” so you might as well prepare for it,… and often!
As it has been discussed here Agile methodologies align quite well. As we continue to shift left in threat modeling, we find ourselves more and more aligned to our SDLC. This means that we are going to find the need to leverage processes used by our development teams. I think we could use Retrospectives and Post-Mortems:
a. Post-Mortems:
The ultimate objective of a Post-Mortem analysis is to understand and study all the failures encountered after a project has been finished, in order to prevent these issues from happening again in the future. This diagnose will then serve to improve risk management policies and practices for other projects, and it is usually conducted by a manager or leadership team.
b. Agile Retrospectives:
Scrum.org defines Retrospectives as sessions whose main purpose is to plan ways to increase quality and effectiveness. By definition, these check-ups are hold at the end of each sprint or work cycle (every 2 or 4 weeks) to understand what went well, which issues were faced and how they were solved or not.
Â
See:Â Â https://softwaredevtools.com/blog/post-mortem-vs-retrospectives/Â
As it has been discussed here Agile methodologies align quite well. As we continue to shift left in threat modeling, we find ourselves more and more aligned to our SDLC. This means that we are going to find the need to leverage processes used by our development teams. I think we could use Retrospectives and Post-Mortems:
a. Post-Mortems:
The ultimate objective of a Post-Mortem analysis is to understand and study all the failures encountered after a project has been finished, in order to prevent these issues from happening again in the future. This diagnose will then serve to improve risk management policies and practices for other projects, and it is usually conducted by a manager or leadership team.
b. Agile Retrospectives:
Scrum.org defines Retrospectives as sessions whose main purpose is to plan ways to increase quality and effectiveness. By definition, these check-ups are hold at the end of each sprint or work cycle (every 2 or 4 weeks) to understand what went well, which issues were faced and how they were solved or not.
Â
See:Â Â https://softwaredevtools.com/blog/post-mortem-vs-retrospectives/Â
Agree, things invariably do go wrong so having a postmortem / retrospective process would be worthy to include as part of your threat modelling programme.
Not a member yet? Become a member to join forum discussions, participate in community events and apply to write articles.
Create an accountEnter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
