![Rahul Raghavan Rahul Raghavan](https://media-cdn.kroll.com/jssmedia/kroll-images/headshots/rahul-raghavan.png?h=160&iar=0&w=140&mw=384)
Watch our webcast Breaking Down Threat Modeling Barriers in Agile AppSec. In this webcast, we explore why threat modeling is often misunderstood—or worse, neglected—in agile product engineering.
Rahul examines and breaks down common barriers that product teams have been exposed to and that have caused threat modeling to be overlooked. In course of this webcast, Rahul outlines common threat modeling mistakes, compares the two most common threat modeling approaches and shares a route to better test case design and automation.
This webcast covers:
I've been personally involved in threat modeling over the last six, seven years at least. And we've seen a lot of changes in terms of what threat modeling means, what threat modeling could do. But one common aspect that we see, that I've seen in my professional journey, is that everybody gets excited about threat modeling. Everybody wants to do it.
Because they think it's an easy thing. They're sold on the concept, but then they actually start doing it, they often face roadblocks. They face issues. They're often like, "Wait, this is not what I signed up for." Or the initial excitement kind of fades away, or they had a completely different kind of challenge that they never thought about earlier.
There's always a huge difference between the possibilities of threat modeling and the realities of threat modeling.
I think it's important that we talk about the definition of threat modeling. It's really important for us to understand what a threat model is. It’s important that we understand what threat modeling means. One thing is that threat modeling has kind of moved beyond the traditional definition of threat modeling, which is finding potential security threats at design and architecture, which still exists, yes, but it's also kind of moved away from that because of all the talks and all the other vendors and product companies and service organizations that thought about the threat modeling. Right? So threat modeling still could be something that starts off as an activity that you do to find issues in design and architecture, but it kind of moves beyond that.
Some consider threat modeling as a way to ascertain counter measures for vulnerabilities. It could be a way to kind of simulate attack vectors, a decision factor for you to choose technology competence for architects while they go ahead and build an enterprise application stack. Security testers consider threat modeling as an effective or an efficient way to a certain better coverage for their application or their pen test. And some of them could also consider this as a way to anticipate security incidents. Right? If you have a very efficient model to ascertain what potential threats are, you could use that as significant intel for you to anticipate what could happen in production.
One of the primary reasons why threat models or threat modeling fails is because often the audience don't understand why they're doing threat modeling. Now, for those of us who've been in application security for a while, all of us kind of appreciate the fact that amongst all the things in cybersecurity, software security or application security or product security, how we wanted to define that, there is no one size fits all.
The second reason, and this is feedback that we've really gotten from a lot of developer community, is really the over-emphasis on how. And this really stems from usually a lot of verbiage fatigue, if you will, in terms of what methodology should we be using. What tools should I be using? Does threat modeling actually mean huge documentation? Because one of the things that prevent developers from even taking on threat modeling, or even security testers for that matter, taking on threat modeling in the traditional sense, as we know it, is because they're usually inhibited by the need for them to have huge documentation, the need for them to really go ahead and fill up a bunch of text boxes or fill up forms or sheets that take away a lot of time. So usually the value from threat modeling, from their perspective, gets overshadowed by the logistics of performing threat modeling.
It's important that we make threat modeling more accessible. We've seen the ways and means in which threat modeling can now be used by QA, enterprise architects, developers and security engineers. There's something for everybody in the product engineering community to benefit from by threat modeling, if we just understand that threat modeling as an activity, is a risk mitigating exercise. If everybody appreciates that, it makes it more accessible and it helps in democratizing threat modeling.
Kroll’s product security experts upscale your AppSec program with strategic application security services catered to your team’s culture and needs, merging engineering and security into a nimble unit.
Kroll helps development teams design and build internal application threat modeling programs to identify and manage their most pressing vulnerabilities.
Integrated into your software development lifecycle (SDLC), Kroll’s agile penetration testing program is designed to help teams address security risks in real time and on budget.
Proactively identify your highest-risk exposures and address key gaps in your security posture. As the No. 1 Incident Response provider, Kroll leverages frontline intelligence from 3000+ IR cases a year with adversary intel from deep and dark web sources to discover unknown exposures and validate defenses.
Kroll’s multi-layered approach to cloud security consulting services merges our industry-leading team of AWS and Azure-certified architects, cloud security experts and unrivalled incident expertise.
Incident response, digital forensics, breach notification, managed detection services, penetration testing, cyber assessments and advisory.