Q&A

Ask Me Anything about Threat Modeling!


Userlevel 4
Badge

Hi, Threat Modeling Connect community!

I’m Chris Romeo, CEO of Kerr Ventures and self-described “threat modeler to the stars.” I previously co-founded Security Journey and have participated in numerous initiatives, conferences, and community projects to drive application security and threat modeling in organizations of all sizes. I also host the award-winning “Application Security Podcast” with @RobertHurlbut (we’re both founding members of Threat Modeling Connect 😎).

I’ve taught threat modeling and rolled it out across the Enterprise at Cisco. I’m excited to share my thoughts, approaches, and experiences with you through this AMA.

Ask me anything about threat modeling!

Here's how it works:

  • Reply to this post with your question(s) any time before or during the AMA.
  • Look at other community members’ questions and like those that you find interesting.

On Friday, January  27th, 11:00-noon ET, I’ll be answering your questions live!

 

Cheers,
Chris


17 replies

Userlevel 3
Badge

Greetings Chris - Thank you for being willing to host an AMA. I would like to ask about your approach to Change Management with regard to implementing a new threat modeling process (or overhauling an existing one). Change management can be so critical in ensuring the success for new initiatives and I know that planning and preparation with strong change management can be so critical. Thank you in advance!

Userlevel 1
Badge

This will be fun!

  1. Thinking about when you first started threat modeling, how has the industry changed since then?
  2. What’s your earliest memory of threat modeling?

Talking about threat modeling a software application would you rather do it at a high level or will go deep into threats regarding the technology/language planned on the software architecture?

And following this, what about devs and Threat Modeling?, should be they implied into Threat Modeling or should it be a task only for security professionals?

Hello Chris!


If you have one security champion per team, how would you support them, with periodic meetings where doubts are raised or by attending each threat modeling in the different teams?

Userlevel 3
Badge

What are your thoughts on threat modeling as a compliance activity vs a best practice in the organization? How much formality (and subsequent support/constraints from the policy/standard perspective) do you do feel creates the right balance? 

 

 

Badge

Hi Chris!

 

Thanks very much for doing this. My question is the following:

What have been some skills you picked up along the way that would’ve been really helpful for you to have when you started?

Userlevel 2
Badge

Hey Chris,

If you have a budget to spend on Threat Modeling, and you can only choose ONE option, would you choose:
(1) A Threat Modeling tool/app to assist with automation and guidance for people TM

OR

(2) Educational materials and training for TM participants (and instead use existing tooling - eg standard drawing apps and/or spreadsheets etc).

And of course, why would you choose #1 or #2?

Nigel Hanson.

 

Userlevel 2

I’d love to hear your thoughts on how to scale threat modelling and any constraints that puts on the threat modelling approach used?  Are there factors that affect your approach to scaling, like organizational structure or solution architecture (e.g. monoliths vs microservices)?

Userlevel 4
Badge

Kicking the AMA off with the question from @JamesR:

“I would like to ask about your approach to Change Management with regard to implementing a new threat modeling process (or overhauling an existing one). Change management can be so critical in ensuring the success for new initiatives and I know that planning and preparation with strong change management can be so critical.”

Change management is crucial for programmatic success -- when implementing a new threat modeling process or overhauling an existing one, we will disrupt some folks who are used to doing things “how we always do them.” As I am fond of saying, we’re going to break some eggs. If you want an omelet, you need to break some eggs.

I first think about defining the idea (or the change) and then socializing it with the right folks. Half the battle with change is allowing folks the time to process the change and accept it. From Executive Management to the Developers who will be performing the threat modeling, everyone needs time to absorb the new idea.

The second thing is to ensure that you have a clear ask of what you want people to do. Clearly define the process and the expected outcomes. Nothing is more frustrating with change than an unclear definition of what I am supposed to do. Developers especially want to know what they are supposed to do.

The third thing is to acknowledge and reward those that do the right thing according to the new process. We are so quick in security in using the stick instead of the carrot. As people do the new process you ask for, acknowledge them. Let others see that this new program is not disruptive and that there are positive outcomes for participating.

And that, is my take on change management with a new or refined program!

Userlevel 4
Badge

This will be fun!

  1. Thinking about when you first started threat modeling, how has the industry changed since then?
  2. What’s your earliest memory of threat modeling?

Process improvement! I learned how to quote using the Editor. 😂 Threat modeling is all about process improvement.

Wow, how the industry has changed! So much and so little. I got my start in security in 1997 with Arca Systems. I stood on the shoulders of giants in the industry, and at the time, I had no idea how lucky I was. They taught a group of us to understand threats and adversaries truly. They challenged us to think about how anything we designed could be compromised. As far as how the industry has changed, attackers have become far more sophisticated since my early days.

On the other hand, when I think about the OWASP Top Ten, I realize how little has changed in our industry. So many of the items on the Top Ten have drifted around for the past two decades and have yet to have a resolution. (Okay, we have mitigated CSRF for the most part, so we have SOME progress.)

Things have changed, but for the most part, they have stayed the same. In 1997, I thought we would have the threats whipped by now. Now, I realize that we are only beginning the journey and have so much further to travel.

My earliest memory of threat modeling is around 1995 or so. I used threat modeling without knowing what it was, and it was while doing a post-mortem on the compromise of my first-ever Linux machine that was connected to the Internet. A friend and I “brainstormed” about what could have happened. I realize now that we were threat modeling without knowing what we were up to.

 

Userlevel 4
Badge

Talking about threat modeling a software application would you rather do it at a high level or will go deep into threats regarding the technology/language planned on the software architecture?

And following this, what about devs and Threat Modeling?, should be they implied into Threat Modeling, or should it be a task only for security professionals?

I preach the importance of scoping threat models at the feature level. The complexity of a high-level view of an application will catch those newer to threat modeling and will be a barrier to them completing anything of value in a reasonable amount of time.

If I’m working with a group of seasoned modelers, then we may work from a high-level view of the system. Even then, we’ll dive deep into areas we don’t understand and will model features on the fly.

For me, threat modeling must be performed by the developers. We’ll never have enough security professionals to keep up with the demand. In the “Threat Modeling Manifesto,” the team and I warned against the “hero threat modeler.” We went as far as to call this an anti-pattern. The hero threat modeler could be a single person that does all the threat modeling. If you follow this anti-pattern, you miss out on all the experience from the rest of your team. Threat modeling is a team sport, and we all bring unique perspectives. Collaboration is key.

I want a program to focus on teaching the developers to model and ingrain threat modeling into the way software is built. By empowering developers, we can keep up with the speed of building software in a DevOps world.

Userlevel 4
Badge

Hello Chris!


If you have one security champion per team, how would you support them, with periodic meetings where doubts are raised or by attending each threat modeling in the different teams?

I would approach this scenario differently. I’d have one office hour per week, where anyone can dial in, show me their model, and then ask for help, questions, or whatever.

I would also audit the various threat modeling meetings the teams perform. When I join those meetings, I’ll stay quiet unless someone asks me a question directly. I don’t need to take those meetings over. Instead, I want to check how the team is doing and see if they need a push.

Don’t sleep on the importance of the monthly general security champion meeting. During that meeting, I’d have a “threat modeling corner” session to present excellent and well-done threat models I’ve seen and teach some new things about threat modeling.

Userlevel 4
Badge

What are your thoughts on threat modeling as a compliance activity vs a best practice in the organization? How much formality (and subsequent support/constraints from the policy/standard perspective) do you do feel creates the right balance? 

 

 

I am an anti-compliance person, which drifts into how I approach any programmatic security improvement. I strive for threat modeling to be a best practice and a center of excellence inside any engineering organization. All too often, compliance activities are done to check the box without the vigor that generates the right amount of value for the invested effort. If we put in the effort, we might as well get something valuable.

We need formality by way of the process and methodology the organization agrees upon. We do need to grow into a governance function for threat modeling. However, governance is not the right step for day one, as you must gain some organic growth before swinging the hammer of governance.

My advice is to start informally and grow the formality of the effort over a year.

Userlevel 4
Badge

Hi Chris!

 

Thanks very much for doing this. My question is the following:

What have been some skills you picked up along the way that would’ve been really helpful for you to have when you started?

Here is a list of skills that I picked up along my journey that would have been helpful when I started:

  1. All humans know how to threat model -- credit this to my friend Tony Vargas, who taught me this principle. Every human being inherently knows how to threat model -- we do it every time we leave our houses or walk our kids to school. We view threats and mitigate them on the fly. Part of successfully teaching threat modeling is tapping into students' existing knowledge and experience.
  2. The ability to follow or keep the KISS method, keep it simple silly. The simplicity of thought and design is a superpower. It is easy to overcomplicate things, but keeping things simple takes much more effort.
  3. Knowing when to expand an element into smaller component pieces -- Sometimes, with a threat model, you create a DFD with a processing element, and the process has way too much stuff. Knowing when to split up a process into its four component pieces is a learned skill
  4. The Socratic method of teaching threat modeling -- when I lead a threat modeling session with a team, I ask many questions. I have an idea of the answer to some of those questions, and I have yet to learn from others. So I’m asking to get the team thinking.
  5. The 30-minute threat modeling rule and workshops -- I’ve learned that threat modeling is an active learning experience. I could lecture on threat modeling for a week, but if I don’t get you to do it quickly, you will not learn it. So I now follow the 30-minute rule of threat modeling -- I can only talk about threat modeling for 30 minutes before we need to threat model something. I’ve also adopted the workshop approach, where I present you with active threat model experiences and let you apply your real-world knowledge to threat modeling.
Userlevel 4
Badge

Hey Chris,

If you have a budget to spend on Threat Modeling, and you can only choose ONE option, would you choose:
(1) A Threat Modeling tool/app to assist with automation and guidance for people TM

OR

(2) Educational materials and training for TM participants (and instead use existing tooling - eg standard drawing apps and/or spreadsheets etc).

And of course, why would you choose #1 or #2?

Nigel Hanson.

 

In my experience, tools are great, but they do not unlock their potential if people don’t know how to threat model. I choose option #2 every time -- people and collaboration over processes, methodologies, and tools. I need people to understand the essence of threat modeling. I must teach them the manual method to unlock the tool's power. Once they know how to threat model manually, the tools can accelerate their threat modeling velocity.

I teach STRIDE -- I’ve had a love/hate/love relationship with STRIDE. When I first started threat modeling, STRIDE was great. It was simple to understand and reflect on a feature and simple to explain to new threat modelers. Then I got too mature, and I lost my way. I thought STRIDE was too simple and developers needed more data and complexity. Then I wisened up after watching developers struggle with too much data and no solid foundation. Hence, I’m back to loving STRIDE. A tool can model STRIDE, but can it truly teach it?

As with all things, I do what I do because of my experience. I followed option #2 at Cisco and successfully got people to threat model. We followed up with a tool only after the foundation had been laid.

Userlevel 4
Badge

I’d love to hear your thoughts on how to scale threat modelling and any constraints that puts on the threat modelling approach used?  Are there factors that affect your approach to scaling, like organizational structure or solution architecture (e.g. monoliths vs microservices)?

For me, scaling threat modeling is a people challenge, not a technology problem. I have built a scalable solution when I empower an organization full of developers with the knowledge and ability to threat model the things they make with limited oversight from central security.

Having a security champion as the developers' first line of connection is a scalable practice. Pour into your advocates and teach them everything you know about threat modeling -- hold nothing back! When developers on their teams have issues, they start with the Champion, and nine times out of ten, they will resolve the issue without getting to the central security team.

The threat modeling approach must be simple, and it must be ingrained into the existing development process. Creating another repository or place developers must interact with to perform threat modeling adds unnecessary friction. Limit friction! If you use Jira for user stories and tracking development, integrate your threat modeling process into Jira. Limit the barriers that the developers have to participate in your approach.

After the modeling moves, we need governance to ensure that the threat models are being performed at the correct velocity for the right products and features.

Userlevel 4
Badge

Thanks, everyone, for the excellent questions! I had a blast answering these, and I look forward to the next AMA!

Remember, make threat modeling fun, and threat model everything in sight!

Reply


V2