Looking for a way to make security a core part of your DevOps process?

The benefits of doing a Threat Modeling empower teams to proactively manage security risks and improve the overall robustness of their solutions. In short a Threat Modeling process:

• Helps gather all critical information regarding application security risks.
• Enables informed decision-making by evaluating potential security threats.
• Develop a prioritized list of enhancements for your concept, requirements, design, or implementation, ensuring you first address the most critical security issues.

When to start Threat modeling?
Now, while it's technically possible to threat model your product later in its development (like after it's already in production), the reality is that fixing vulnerabilities at that stage can be much more costly. And let's be real - everyone wants to save time and money.
I strongly suggest starting your threat modeling journey once your project concept is nailed down. By "conceptual level," I mean having a clear understanding of the product's main purpose and use cases (basically, why you're building it) and crafting software architecture diagrams (that show how you're going to bring it to life).

And... the fun part begins: it's workshop time!

🧠 Planning
The beauty of threat modeling is that there's no limit to who can join the fun! However, to ensure productive discussions, I recommend starting with a lean team. The essential participants should include:

• Threat Modeling Lead
• Threat Modeling Co-Lead
• Development Architect of the product
• 1–3 (Lead) Developers of the solution

Also, I like to plan threat modeling workshops well in advance - about a month ahead of time is my sweet spot. This gives everyone the chance to clear their calendars and be fully present. For smaller projects, the workshop typically requires around 3 hours. For medium to large projects, you might need to set aside 6 to 9 hours. My personal preference is to avoid booking a full day, as that can lead to participant fatigue by the end of the workday. Keeping it to a maximum of 3 hours per day is the way to go!

🛠️ Workshop Pt. 1 - Breaking the ice

1. Set the Stage
   Let's kick things off! Remember, not every participant may be familiar with the threat modeling process, so take a moment to give a brief overview. This shouldn't take more than 10 minutes, but it will help everyone get on the same page and ready for the fun ahead!

2. Introduce the scenario & discuss the architecture
   Next up, it's time to dive into the nitty-gritty! Typically, the development architect or lead will guide us through the architecture and detail the scenarios. Since we're still in the conceptual phase for most projects, a high-level overview is perfect at this stage. Encourage everyone to jump in with questions or comments about architectural decisions, scenarios, use cases, and the consumers or clients of your solution.
   This is also the moment to chat about key topics like trust boundaries, how the components communicate, and the data sources and storage options. Expect this discussion to last around 20 to 30 minutes, filled with collaborative insights!

3. Define Assets, Assumptions, and Personas
   Now, let's get specific! We'll identify our critical assets, assumptions, and the key personas involved in the project. This step is crucial for building a solid foundation for our threat modeling efforts. Expect this to take at most 10–15 minutes.

🛠️ Workshop Pt. 2-Evil Brainstorming
This is where the fun (and some serious thinking) begins! In this stage, we walk through various threat categories to see where our system might be vulnerable. I'm a fan of using the STRIDE model, which breaks down threats based on key system properties.

Heads up - this part of the workshop can be a bit time-consuming, so don't stress if you can't get it all done in one sitting. Once you hit that 3-hour mark, call it a day and pick up where you left off tomorrow.

To make life easier, I've split each evil brainstorming section into bite-sized pieces, along with a few handy questions to guide the discussion. These aren't exhaustive lists, but they should spark some great conversation. And remember - it's a workshop, not a quiz! Don't grill your participants; the goal is to encourage open dialogue and exploration.

Authentication

• Do we have credentials lying around in GitHub or config files? One password for all with no rotation?
• Is there a weak X.509 implementation or sloppy certificate management?
• Are we using multi-factor authentication (MFA)?
• Do we have any protection in place for cross-site request forgery (XSRF)?

Authorization

• Are we relying on a homegrown authorization solution (yikes!)?
• Is the agent running with more privileges than it needs?

Logging

• Can critical actions (failed logins, deployments, parameter changes) happen without being logged?
• Could attackers tamper with logs, or are we lacking proper log handling (like running out of disk space)?
• Are we exposing sensitive system info (traces, backend errors, version numbers)?
• Are we logging confidential or personal data?

Communication

• Can an attacker view, modify, or delete data as it's being transferred?

Data Protection and Privacy

• Is GDPR-relevant data deleted securely according to the retention policy?
• Is there a risk of customer data being disclosed?
• Do we have secure deletion practices for stored personal data?
• Is personal data stored on blockchains or keychains?

Input Validation

• Any SQL/command/script/XML/log/DLL injection risks?
• Could service interruption or data tampering occur?
• Could attackers use overlay UIs to trick users into privileged actions?
• Is cross-site scripting (XSS) protection in place?

Multi-Tenancy

• Is there proper isolation between tenants?

Insecure Data Storage

• Do we have access control, authorization, and user off-boarding properly handled?
• Is the storage protected from high loads or resource exhaustion attacks?

Prevention

• Are we using recommended libraries for UI/encryption?
• Do we use containerized apps, and are the containers securely maintained?
• Have we proven that our disaster recovery/business continuity plans work?
• Are security configurations part of the code and tested?
• Is our security guide up-to-date?

🛠️ Workshop Pt. 3 - Feedback
After the workshop, it's time to gather feedback! Give everyone a chance to share what they liked and what could be improved. This is your golden opportunity to fine-tune the process and make the next workshop even better. Ask for their thoughts on everything from the structure to the content - every bit helps you improve and grow.

📄 The Threat Modeling Report
Now that the Threat Modeling workshop is done, it's time for the Security Expert(s) to craft the report. But here's the great news: most of the content for this report comes straight from the workshop itself! No need to reinvent the wheel.

At a bare minimum, your report should include the following:

• Participants and Contact Info: Make sure to list everyone involved and how to reach them.
• Diagrams, Use Cases, and Scenarios: Include the architecture diagrams, a quick overview of the use cases, and the scenarios your solution addresses.
• Assets, Assumptions, Personas, and Technologies: Outline the key assets, assumptions, personas, and technologies discussed during the workshop.
• Findings and Recommendations: Detail each vulnerability, explaining why it's an issue and how it can be mitigated. Add your recommendation on how to fix it. Lastly, make sure to score the issue based on its criticality (factoring in both risk impact and ease of attack).

And there you have it!
Conducting a Threat Modeling workshop is not only insightful but also a fun, collaborative experience. By the end, you'll have a clearer understanding of your security risks and actionable steps to mitigate them. It was a rewarding process for me, and I highly recommend giving it a shot in your next project.