Welcome to the second post in Sente Security’s series – Simple Secure Development Lifecycle for Startups. In this series, Sente Security’s Jarred White and Security Engineer Gabriel Marquet discuss some background on why having a Secure SDL is important to implement from the very beginning, and how to implement basic, efficient security activities as part of your development lifecycle.
READ THE FIRST POST IN THE SERIES: Secure Software Development Lifecycle and Why You Need It
In today’s post, we’re going to get into the good stuff! We’ll jump into the first of three core activities that make up the most basic Secure SDL: threat modeling.
Security is most cost-effective and beneficial when considered at the design and architecture stages. This is where the value of security activities is highest, since you are identifying insecure designs before the code is ever written. If you perform no other security activities as part of your development process, you should engage in the exercise of threat modeling at this step.
The Open Worldwide Application Security Project (OWASP, which changed from ‘Web’ to ‘Worldwide’ in 2023) defines threat modeling as “a structured representation of all the information that affects the security of an application.” This is a good definition, though threat modeling can be performed on many types of systems and activities – networks, disaster recovery processes, camping trips, store layouts – and can be viewed through different lenses (end-user privacy and physical security for example).
In large organizations, this can be a complex process. One of us once worked at a major retailer where the threat model was a literal diagram printed on a 2-by-4-foot sheet of paper and hung in the Security Architect’s office. Each time something significant changed, they’d re-run the threat modeling exercise and re-print the diagram.
It was madness. But the process doesn’t have to be crazy or time consuming to provide value, and you do not need to have the participation of a security engineer – though it will help if you can.
Threat modeling means asking yourself some basic questions about how functionality might be abused. There are many factors to consider when evaluating how a system might be abused, including details like network topology and access controls. And certainly, it helps to understand an attacker’s range of methodologies and capabilities (this is where having a security engineer comes in handy). But don’t worry about that for now – you want to begin by thinking about the most basic ways that you would abuse the system to cause something unexpected or undesirable to happen.
We recommend creating documented “abuse cases” for new features, just as one might create documented “use cases.” Ask yourself the following questions:
- What is the value of abusing this feature/component? In other words, what could an attacker gain from abuse/misuse: mild annoyance? Unauthorized access or data? Disabling the app for other users?
- How would I abuse/misuse the feature or component? Could I do it without being authenticated?
- If no abuse or misuse is possible, why not?
Now, document a brief response to each question. If time permits, it may be helpful to pair with someone on your team to check your assumptions. For any abuse cases that result in a lack of response or a clear gap, open a bug. Link to any diagrams, architecture specs, or use cases you used to form your conclusion. Maybe you don’t fix it this release. But just by going through this exercise, you will have accomplished two important things: performing threat modeling at a granular level and documenting the threat modeling outcomes.
This is important as it demonstrates a repeatable and documented process for considering security risks during design stages, which is key to a Secure SDL and required by many cybersecurity and compliance frameworks. It’s going to save you time and money down the road by ensuring that security considerations are part of your product’s design. It also achieves the outcome of documenting your controls, since you answered the question “why not?”, you have described the control or mitigating factors in place to address a given threat. This will be very important at later stages of maturity when you are called upon to describe your controls in detail. Congratulations!
Over time, the body of knowledge your team has accumulated about your system or application’s security controls becomes your product’s threat model. At some point, you should have enough information to produce a high-level visual representation of the overall set of security controls. Be sure to include mitigating factors where appropriate, and you get mega bonus points if you can detail security considerations that your customers need to keep in mind because they are not covered by your product or service’s threat model.
You may feel compelled to rush to this step, but the detailed information you accumulate over time will be worth the wait. Socialize your model with everyone in your organization to help them understand the security controls you manage (tip: if there’s something in your model that you wouldn’t feel comfortable sharing with other people in your company, you may have a major gap or risk that needs to be addressed. In general, a security control should not rely on ‘secrecy’ to be effective). This information will be of major value to your product and engineering teams but will also benefit field and support teams in being able to articulate which controls are your responsibility versus those controls which are a customer’s responsibility.
Before we wrap up, we wanted to call out a few additional resources that you should evaluate to improve your threat modeling process.
The first is Adam Shostack’s Four Question Framework, which comes from his seminal book Threat Modeling: Designing for Security. Adam literally wrote the book on threat modeling, and many of today’s techniques come directly from the threat modeling methodologies he implemented while at Microsoft. You will notice that the methodology recommended above is like the Four Question Framework. If you find that the Four Question Framework better supports your needs, use it! Adam’s book is an excellent starting point for a deeper dive into threat modeling and we can’t recommend it enough.
The second resource is a new threat modeling tool released by AWS (Amazon Web Services) called Threat Composer. There are many tools for threat modeling, but it’s rare to find one that effectively creates valuable threats at a component or feature level. Threat Composer looks promising and would seem to integrate well into agile development processes. Since we haven’t had too much hands-on time with this tool, we would welcome feedback from readers on whether they found the tool to be effective.
Final Thoughts
We hope you found this background on Secure SDL informative and can immediately implement some of the threat modeling activities we’ve described. It will go a long way to both producing secure applications, educating customers, and anticipating compliance demands. Remember that just asking these simple questions will encourage your teams to think about secure design and build applications with security controls that are right-sized and practical. This means less retrofitting down the road when modifications to address security gaps will be more costly.
In our next post, we will describe some practices you can implement to vet open source software and components and discuss the indicators you should evaluate to select components that will support your security objectives.