Menu
close
Implementing threat modeling at the start of your development process can save time, money, and frustration down the road. It can also support later security measures such as pentesting or compliance assessments. If you’re serious about developing secure software, you may consider threat modeling as an integrated part of your secure SDLC.
Threat Modeling is the process of identifying security threats or system vulnerabilities, then understanding and prioritizing those threats to mitigate them. There are many frameworks for threat modeling available, which will be discussed in another section below.
This type of security assessment is unique in that it is:
Structured
Threat modeling follows a specific methodology designed to help an organization capture specific information relevant to their business.
Systematic
Threat modeling moves through your entire system methodically. As it does so, it can help you discover new vulnerabilities.
Contextual
Threat modeling leverages the relevant ways a specific asset may be compromised in the event of certain actions or scenarios. Both the structure and methodology from above are based on your unique business logic. Together, they help to create the ‘attack scenarios‘ that you could most likely encounter.
Unlike a security assessment, threat modeling is usually done during the design stage. As such, it’s primarily conjectural rather than concrete and it’s applicable to a variety of situations. You may encounter it in business, software applications, cybersecurity, networks, etc. Almost any system or environment containing assets or resources can be modeled.
As mentioned above, a many frameworks exist. For example, The National Institute of Standards and Technology (NIST) has the Special Publication 800-154 which looks at threat modeling in a cybersecurity context. Others, like STRIDE, take an application-centric approach. STRIDE emphasizes the idea of “attack trees” and was first popularized by Microsoft employees in the late 1990s.
Whichever framework you choose, all share certain themes or steps in common. These tend to include:
Identification of Assets
First, any assets or resources that the system or software includes should be documented. These may include hardware, databases, customer information, user accounts, credentials, or other resources that hackers may target.
Infrastructure Survey
It’s important to survey and map the architecture to identify security gaps. Developing a sense of where or how attacks may occur is important for tracking progress on improvements.
Process Decomposition
Once the system or application has been surveyed, it can be broken down into its individual processes. For example, an e-commerce app might have the following processes: customer-facing transactions, communication with the credit card processor, or supply and inventory automations. Pay particular attention to processes within your software or applications that interact with different parts of your business.
Threat Identification
With architecture and processes documented, begin to identify and catalog threats to review.
Threat Assessment
Next, threats should be assessed in terms of likelihood of occurring and severity of potential damage. It is important here to have an understanding of security theater, to know what is really a threat and what isn't.
Learn more on challenges of implementing threat modeling into your SDLC!
Finally, create the recommended steps or actions required to mitigate or prevent the identified threats. As you build out your next steps, leverage informed creativity and incorporating varied viewpoints. These are some of the successful patterns included in the Threat Modeling Manifesto.
What are we building?
Your application is being designed for a specific purpose, and your chosen threat model framework will need to align with that purpose. Think of the type of application, the use cases and the people who will be using it regularly.
Breaking this down into smaller pieces will help you build out your own framework.
What can go wrong?
When you think about all the ways that your application’s users could engage with your application, what are the most likely scenarios?
In each scenario, what could go wrong? Try to generate as many design vulnerabilities as possible in each scenario. These may be surface-level vulnerabilities that are easy to exploit, or they could be far-off ‘what if’s’ that would take a high level of skill to break through. Even far away possibilities should be accounted for here.
How can we prevent things from going wrong?
Now that you know where your potential weak spots are, how could these be mitigated? What prevention techniques can you apply to each vulnerability?
Keep in mind that there is not one solution for anything. Threat modeling is a creative process, and the more new ideas you can think of for mitigation, the better.
Is our solution good enough?
Recap your framework. Double check that you’ve been thorough in walking through your possibilities. Did you check all areas of the application? Did you take into consideration other perspectives, such as what another access level or user type may experience in the application? Working with a team will bring more ideas onto the table and ensure a more thorough review.
Even with confident solutions, you will want to circle back with your team regularly to review and update the threat model. As your application updates, so should your threat model.
A solid threat model will have definitive answers to all four questions.
For our purposes, we’ll look at threat modeling in the context of the software development lifecycle, or SDLC.
Threat modeling involves thinking through every potential scenario that could lead to an application being compromised. Therefore, it’s a good idea to include a threat model in your SDLC as early as possible. This can help ensure:
Secure Design
Security is best handled proactively rather than as an afterthought. Your team will produce more secure software when development and security are merged. As the gap between security and development closes, it becomes easier to manage both from a single vantage point.
Efficient Resource Usage
Recognizing and fixing critical vulnerabilities in the later development stages requires more time, energy and budget from your development team. As such, implementing threat modeling at the design stage (before development) keeps the entire pipeline efficient.
Security-oriented Work Culture
In 2019, 100% of IT decision makers said security and development needs to be in closer contact. Integrating security right into the SDLC keeps it top-of-mind for your developers. Soon enough, the security-first attitude will transfer to other departments too.
Improved Compliance
A documented threat model is an excellent tool for proving compliance and defeating potential claims of negligence. For many Software Secured clients, this is an essential tool in closing future business negotiations.
Enhanced User Experience
Threat modeling will naturally improve the user experience of a piece of software. For example, a model may identify where controls are unnecessary, or reveal instances where architecture may be made easier to use or more secure through a specific change.
With all the advantages that threat modeling in the SDLC delivers, it might seem surprising that many companies still don’t implement it into their DevOps pipeline. That’s because many stumble across the challenges of implementation and struggle to find their way around them. In 2019, this meant that, on average, 50% of applications were vulnerable to exploitation in organizations that had not yet adopted DevSecOps.
Here are three of the biggest challenges faced when implementing threat modeling in the SDLC, plus our best tips on how to solve them.
Any time you implement a new process or system, the possibility of pushback exists. This is true across all industries and departments. Research shows that employees often resist change out of fear of the unknown, the potential for additional responsibilities, or the potential that such a change may negatively affect their livelihood.
A DevOps team may initially resist the introduction of threat modeling. They may feel that it disrupts their personal workflows too much, or that it is an added workload to their already busy schedule.
To combat pushback, emphasize efficiency. Frame implementation as a strategy for reducing post-release debugging. Show your developers how threat modeling early in the SDLC will let them stay focused on doing more of what they love – developing.
Get everyone on the same page. Make documentation which answers to frequently asked questions, or develop readily available resources to reference. Also, threat-model “little and often” within your team to keep sessions focused and help build the habit.
With dozens of frameworks available for a team to implement, determining only one framework to work with can be a struggle for any AppSec manager.
Reduce confusion and inconsistency by implementing a consistent approach across the entire organization. This may mean investing in a threat modeling platform or standardizing a framework.
Threat Dragon is one example of an open-source modeling tool that development teams can use. It can further improve consistency through rules-based automated generation of threats using the parameters you provide.
Likewise, reinforce consistency by setting a schedule or identifying milestones in your development process for starting threat modeling. In turn, it will make threat modeling a seamless part of the process that doesn’t get skipped because of inconvenience or workload.
Agile methodology has all but taken over the development world. That doesn’t mean legacy processes still exist in cobwebbed corners of your development environment. Rather, we find these often crop up in security processes (like penetration testing).
Keeping manual processes in areas like the software design stage can slow down your SDLC. If you find that your developers are mapping things out on paper, using Excel to track issues, or have built notes scattered across Slack, your threat modeling may suffer simply because information isn’t readily available or organized efficiently.
To solve this, engage in a full review of your DevOps tool stack. Identify what your developers are using to meet each of their unique needs. Then, create a means to centralize, observe, and digitize information so it’s easily accessible and ready to be modeled.
Threat modeling as a security assessment tool seeks to discover what could go wrong given a current architecture. It also helps to build strategic ways to mitigate or prevent vulnerabilities earlier in the SDLC. As an integrated assessment in the development pipeline, threat modeling also empowers your team to ask better questions about secure design, efficient resource usage and more. And ultimately, you will build a strong and future-forward internal security culture.
301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4
