Mitigate the Threats
Learning Objectives
After completing this unit, you’ll be able to:
- Identify mitigations to address threats.
- Explain how to develop mitigation strategies.
- Make informed decisions on how to proceed with residual risk.
Identifying Mitigations
Once you’ve defined your security objectives, your system’s architecture, and your threats, it’s time to think about how to mitigate those threats. Now is when your team works together to figure out how to fill security gaps.
Mitigations are either total or partial. Total or full mitigations make threats out of reach for attackers in some way—for example, a total mitigation might make a threat too expensive or too hard to pull off. Partial mitigations are layered or combined to reduce the overall amount of risk. However, with partial mitigations, it is important to avoid creating a weakest link. Attackers often try to exploit the easiest things first.
When you identify a weakness, take note of it. It’s also important to realize that one vulnerability can make other threats more plausible because threats take advantage of vulnerabilities. When you prioritize addressing these kinds of weaknesses, it makes the overall system more secure.
It’s important to systematically work through all of the threats that you’ve identified. Using a table or spreadsheet can help. If you’ve got multiple people thinking of mitigations, use a multiplayer collaborative editor (for example, Quip, Google Sheets, or Microsoft Word) to get the job done faster!
Let’s return one more time to the simple blogging system, described by this data-flow diagram.
For this exercise, let’s work through all the identified threats and completely fill out the mitigations column. We include both full and partial mitigations when they apply, and write “needs further investigation” for any mitigations that might require more research.
| Numbered Point | Class(es) | Threat | Mitigations |
|---|---|---|---|
|
1–4 |
Information Disclosure, Tampering |
Hypertext Transfer Protocol Secure (HTTPS) is not in use or is misconfigured, allowing the attacker to steal credentials or alter traffic by the administrator or author. |
Full: Implement HTTPS everywhere. |
|
1 |
Tampering, Elevation of Privilege |
The cookie for the admin can be tampered with or stolen to let the attacker access the administrative console. |
Full: Your application framework already has what appears to be a secure cookie setting with a cryptographic signature. Check with your product security expert to make sure. |
|
2 |
Spoofing, Elevation of Privilege |
An attacker intercepts the transmission of the reset token and uses it to set a passphrase, taking control of the author's account. |
You complete two partial mitigations.
Together, these steps mitigate the threat. |
|
3 |
Spoofing |
An attacker gets access to an old reset token in an email to an author and uses that to change the author's passphrase. |
Full: In addition to making the tokens time limited, keep the “active” tokens in a table in the database and delete them when the user's passphrase is reset, so that it also acts as a one-time code. |
|
4 |
Spoofing |
A malicious insider uses a legitimate set of credentials but spoofs the author= field in the request to make it appear as if another author wrote an incendiary blog post. |
Full: Remove the author= field. Display name is what the admin sets for authors. |
|
4, 5 |
Tampering |
An attacker injects bad JavaScript into the blog post, which is served to users to perpetuate Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and other attacks. |
Build one or more of these depending on feature requirements and estimated effort. Partial: If Hypertext Markup Language (HTML) input is required, try to use an HTML sanitizer that accepts only a subset of HTML that is known to be safe. Full: Input is in some other syntax that allows rich formatting and doesn't interpolate to HTML, making it impossible to embed scripts. (Needs further investigation) Partial: If scripts are necessary, can you try to monitor in some way or just accept risk? (Needs further investigation.) |
|
5 |
Denial of Service (DoS) |
An anonymous user floods the blog server with requests, slowing the site down for everyone. |
Partial: Use some network-level anti-DoS. Note: Your existing network has some anti-DDoS (distributed denial of service) technology already. Is this sufficient for this system or is something else needed? (Needs further investigation.) |
|
5 |
Information Disclosure, Tampering |
HTTPS is not being used, letting the attacker insert malicious JavaScript replacements for posts, redirect the user to a malicious site, and so on. |
Full: Implement HTTPS everywhere. |
Track and Build Your Work!
After you decide on mitigations, implement them! It’s imperative to track threats and mitigations, preferably with the help of a solid tracking system. If you don’t, there’s a chance you can leave gaps in your defenses for attackers to exploit.
If you use a tracking system, enter each threat as a user story (a simple description of software told from the end user’s perspective) or a set of tasks in a user story. Define the threat as something users (that is, attackers) must not be able to do. The important thing is that your team never releases the system into production mode without accounting for all identified threats—more about this a little later.
Once you track and build your secure implementation, the final step is to verify that it works. A work item associated with the threat model you’ve produced is not complete until you test it as part of the “real” application (for example, in staging).
The Design Has Problems. Now What?
You’ve thought about all of the mitigations you can implement, but there still are gaps where your design is not protected. The pressure to produce a working system is real. Your deadline is approaching and you need to decide whether it's too risky for your team to go ahead with the system or whether you have time to build in the mitigations you need. Sometimes, you might have to abandon or defer a project. But all is not lost, since you do have two paths forward: redesign or risk acceptance.
The Redesign Process
Redesign means going back to the drawing board. Get the help of an architect or security expert and try to brainstorm some new ideas that still fit your requirements. It’s possible you can use your data-flow diagram to play with different architectures. Either way, this probably means adjusting the features to add usable security or to remove problematic areas. You can even consider consulting with stakeholders to see if the requirements can be changed. On the bright side, this is your opportunity to make cool new security features and add value to your products!
The Risk Acceptance Process
The other path, risk acceptance, means deciding to live with the risk, either temporarily or permanently. Perfection is the enemy of good in practical, secure design. Achieving 100 percent security is almost impossible! So, in order to keep moving as a business, you can use risk acceptance as an assurance mechanism after threat modeling. The output of the threat modeling exercise lets you make an informed, rational decision on building systems that contain some residual risk.
The exact process of risk acceptance can depend on your team and technology and requires executive-level agreement. Always provide the granted exception in writing, captured along with your documentation of threats and mitigations in whatever system you use for tracking. If you cannot get approval for an exception, you still have two options: don’t build the system or attempt to redesign.
Risk acceptance might feel uncomfortable, but consider the ramifications of shipping your code into production and bypassing this step entirely. Such an action could have a negative effect on the release and the use of your system. Nobody wants that!
Sum It Up
You’ve now become familiar with the threat modeling process, learned how to identify threats by thinking like a hacker, and discovered how to mitigate those threats. You’ve developed a valuable skill for preventing security gaps before attackers find and exploit them to the detriment of your organization. Interested in learning more about cybersecurity best practices? Check out the Cybersecurity Learning Hub on Trailhead.
