You can optimize your application's security architecture and design by first considering the threats most likely to target your app. In this video, learn about the basics of threat modeling.
- [Instructor] In order to develop a secure application, the teams involved first need to understand how attackers might exploit security weaknesses. That understanding will help them build controls into the app to prevent those attacks from succeeding. You can equip your teams with this knowledge by introducing them to threat modeling. Threat modeling is the process of identifying the people or things that might damage your app, as well as the techniques they might use to inflict that damage so you can put the right controls in place to get ahead of them. Yes, these threats include cyber criminals. But what else might be on that list? Disgruntled insiders, earthquakes, the hosting provider filing for bankruptcy. If your app can be harmed, either intensionally or unintentionally, then that threat is in scope. One of the most well-known threat modeling techniques is STRIDE. STRIDE was developed by Microsoft in the early 2000s. Even though they don't maintain it anymore, the model has found a following in the infosec industry. STRIDE encourages you to identify threats based on the following categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Each threat category maps to a positive security attribute. For example, information disclosure is a threat to confidentiality. Denial of service is a threat to availability, and so on. When you hear STRIDE mentioned in threat modeling conversations, you're almost certain to hear DREAD as well. Another artifact from Microsoft, this model instead uses five categories to help security pros like you identify and prioritize threats to your apps. Those categories include damage, reproducibility, exploitability, affected users, and discoverability. As you identify threats, you can answer questions related to each of these categories to help you prioritize those threats. For example, when considering damage, how bad would it be for your organization if the attack were successful? Who would be impacted? How hard is it for an attacker to succeed? Although OCTAVE may come up as another threat model, it's used in a different manner. When you use STRIDE and DREAD, you'll get into the technical weeds regarding the security of your apps. When you use OCTAVE, you'll observe those risks from a higher level. Using STRIDE, you might identify a denial of service risk related to insufficient or outdated app infrastructures. To mitigate that risk, you might determine to upgrade that infrastructure. OCTAVE would take that conversation one step further, exploring the organizational conditions that lead to the risk in the first place. OCTAVE would ask why the infrastructure wasn't properly maintained, so you could address the root cause with your leadership team. STRIDE, DREAD, and OCTAVE are just a few of the threat models available to you. As you prepare for your CSSLP exam, you'll definitely want to spend time exploring these three models in detail. Throughout your career, though, you may find one of these other models more to your liking. When that time comes, head on over to the Carnegie Mellon University's Software Engineering Institute blog and give this article a read. It provides a basic understanding of each of these different threat models as well as a springboard where you can launch into a deeper dive of each one. With all these threat models to choose from, how do you choose the right one for your organization? I've got a three-step process that I've used with consistent success throughout my own career. Start by exploring how your dev team operates. Observe their processes and procedures for writing and deploying code. Then compare those dev processes to your existing security program. How do you prioritize confidentiality, integrity, and availability? Equipped with that blended understanding, you'll want to consider how mature your application security processes are today. If your team is just getting started, run through a DREAD exercise with them. If they're already somewhat comfortable with application security, jump right into a STRIDE exercise. As you learn more about the other models available to you, you can weigh your team's engagement and experience against those models to ultimately find the best fit for your organization. When it comes to running a threat modeling exercise, it can be as simple as a conversation, a whiteboard, and a spreadsheet. Get representatives from your security and development teams in a room and post questions about how attackers might break your apps. Use the STRIDE and DREAD categories to guide that conversation. Do this early in the app dev process and return to it throughout so you can update your list of threats and your mitigating controls. Use publicly available information to help kickstart these exercises. NIST Special Publication 800-30 has an entire list of both threat events and threat sources in its appendices. Download that resource and refer to those lists throughout. By getting the right people together to walk through a structured threat modeling exercise, you can save a lot of time and money by identifying the security design controls that will have the biggest impact on your app.
- Threat modeling
- Identifying and prioritizing controls
- Cloud architectures
- Component-based systems
- Designing network, sever, and data controls
- Secure design principles and patterns
- Data modeling and classification