The “five factors” used to secure systems.
Common patterns that security teams use to mitigate risk.
Risks are rarely managed with a simple “just fix it!” option.
Instead, we often find ourselves negotiating between options of time, cost, or technical debts. The following “factors” will adjust across a spectrum for each, and provide options for different situations, and is inspired by the 12 Factor App approach.
The following factors represent the commitments made by a company in order to mitigate a risk.
1. Response: We’ll be ready to respond to the threat.
Adopt an “assume breach” mentality. Instead of directly mitigating the risk, you’ll commit to building the tools and policies needed to react upon that event. You will assume the event will happen, and you are advocating the preparation for an inevitable response.
To put it another way, “they may fail frequently, but they can fix quickly”.
This factor doesn’t require substantial collaboration from others. For instance, this can be:
- An insurance policy
- A law firm, or response team on retainer.
- An incident response plan for that risk
- A drill for what could be an imminent incident.
For instance, an “at risk” product or an asset owner can be less involved with this process, compared to refactoring what they own. Maybe you have an acquisition that is completely unwilling to cooperate, or they aren’t competent enough to, or previous security teams have burned your bridge.
This “incident response” factor is a typical political backstop when you’re working with a completely unwilling organization or team. You can make some impact with zero concessions or effort from another party. It’s a way to avoid coming away with nothing in a completely toxic environment.
You can be a security leader with barely a shred of organizational support, and get some work done within this single factor.
Efforts to support rapid deployment can also fit into this factor. Your ability to quickly patch and remediate a vulnerability, or rebuild an environment that has been compromised are important ways to mitigate risk, even if they are far after the incident.
Lastly, this factor operates as a catch all. It’s difficult to envision a risk that can’t be approached with this factor. A fallback plan for overall crisis management should exist in any risk management program.
2. Evidence: We can trace the threat‘s steps.
You will not allow a risk to occur in a way that avoids the production of evidence. The event will occur while also revealing a root cause for a post-mortem, which lets you learn from mistakes.
This will accumulate enough data to only let an event happen once, because you’ll be better informed for future mitigations that are more comprehensive than what exists.
Logs and cameras are typical of this factor. But without involving other factors, this factor alone will also prevent nothing. It will, however, benefit any momentum that wants to ensure a threat never succeeds ever again, and that follow up investigations are far more effective.
This factor is usually characteristic of a low-touch approach to mitigation.
Another team may run wild with high risk behaviors, but so long as you can minimally support infrastructure to capture logs, it’s a may be a smaller ask others to push their logs to a central store you may already be maintaining than asking them to change anything substantial.
In other words, “I don’t care what you do, so long as there are logs that allow us to respond”. Obviously, this factor alone can be described allowing a lot of leftover risk, but it’s better than being totally blindsided.
Lastly, this factor carries great opportunity to invest in other factors in the future. With logs and visibility, you can usually make stronger proposals for other factors in the future with data driven arguments. IE, “You don’t even use this server. We’d like to turn it off.”
3. Containment: The threat will have limited impact.
It may be impossible to prevent an event from occurring, but you can make guarantees that damage will be limited when it does.
This factor requires greater cooperation than any factors described so far, and is farther down the “involve others” spectrum, but not entirely.
A statement like “do whatever you want, just do it in this DMZ or outside of prod” is characteristic of this attitude towards a risk.
This factor has lots of shared responsibility with others.
For instance:
- Formalization of authentication boundaries and identity.
- Network segmentation. Sandboxing.
- Maybe entire IaaS accounts detached from one another.
These are things that engineering organizations may culturally reject, and is a substantial “ask” of others. We’ve all run into teams or individuals that demand these areas lay untouched, or advocate for extremist and incorrect views of “move fast, break things”.
The best feeling is when an organization already “gets it”, and is mature enough to know these are valuable for non-security reasons. Even better, you are able to build and contribute with your own team, blurring the lines from who those who are concerned with risk with the folks intentionally producing it for a business need.
These sorts of behaviors demonstrate how an engineering culture values security. They will think of a “blast radius” in security terms, as well as the potential for a massive outage.
But, it’s not without its anti-patterns. Think of a marketing team creating hundreds of microsites on various cloud platforms with old CMS plugins, once they were kicked out of the production network. Fragmentation may result from over-containment and become a source of risk doomed by good intentions.
Those low-quality marketing sites may not exist in a production environment, but they may still be a nuisance, and harm your reputation with defacement or embarrassment. While technically a product of this factor, it is still not a complete management of the risk.
4. Prevention: The threat isn’t likely to occur.
The “Prevention” factor commits to reducing the likelihood of a risk. When completed, the possibility a threat would succeed is unlikely or not at all applicable. Or, at least not without being detected.
This is a direct, hands on approach to the risk, removing the exposure or behavior at the source. All of the previous factors are regarded as asymmetric approaches to avoid dealing with risk head on.
This factor is organizationally stressful, requires high quality relationships and involves thoughtful trade-offs.
Politically speaking, especially in a non-cooperative organization, this factor is commonly associated with “sticking your neck out” and losing. It can be hard to convince another organization to dedicate significant time to mitigating a risk when it’s easier to just accept it or work within the previous factors.
This factor is quickly eliminated in an organization that is incapable of understanding the concept of risk. It’s obviously much nicer to operate in an environment where this is less common, but this is not an article about ideal workplaces. If you’re at least working in a hospitable environment, it’s still important to come prepared with the best solutions. This can improve the workplace situation quite a bit.
But, implementing this factor is not always difficult. In fact, easy mitigation wins appear and small changes can eliminate big risks. For example: decommissioning a server no one was using, or blocking a port that didn’t require exposure to the internet.
It must be acknowledged that this factor can swing very hard the other way. Asking for a complex mitigation to a risk is where massive value / time / effort trade offs surface and opinions and emotions can run wild. It can uninvite a person (or team) concerned with risk from the table pretty quickly.
This is where security burns bridges.
5. Elimination: Mitigation through innovation.
There were days when someone said:
- “I made a boat that can go real far.” (Fifth Century BC)
- “I can hurt bacteria with this weird mold” (September 1928)
- “I can pass an encrypted message without a shared secret.” (1970)
A complete domination of a previous risk is characteristic of this factor. A whole new set of risks should displace the previous ones very quickly. No one associates a bacterial infection with the same risks anymore, because someone researched molds until they discovered modern antibiotics.
We’ll reduce the cost of mitigating a risk so dramatically that we’ll find ourselves with resources to pursue other risks.
An example of this was XHP at Facebook. When released, Cross Site Scripting bugs were pushed into a fringe occurrence wherever we could use XHP. Until then, and in any other circumstance, we leaned on nearly every other factor to reduce the risk. A framework level approach had the most resulting leverage but required the most effort to obtain, required a large refactor and participation from every engineer. Security was not the primary value of XHP, there were plenty of other reasons for it.
Every leadership team should be on the lookout for this factor in the distance.
One through Five: Defense in depth comes from multiple factors.
Introduce as many of these factors as efficiently as possible. Build infrastructure to increase that efficiency to eliminate unknown or one-off risks.
An example strategy that attempts every factor, to address a “CSRF account deletion” risk.
- Response: A crisis communications plan and go-to firm in the event of a total failure that causes customer data loss. Backups of user data. Strong advocacy for CI/CD. Fast fixes. Applicable laws already understood.
- Evidence: Logs, customer communications in support channels, and required postmortem process when we are surprised with an attack that succeeds.
- Containment: Requiring a re-authentication challenge when a user is making account deletion actions, which assumes the presence of CSRF. An attack shouldn’t cause data loss under normal circumstances.
- Prevention: Training, static analysis, code reviews, and audits to prevent coworkers introducing CSRF under odd circumstances.
- Elimination: A framework that avoids CSRF altogether.
When challenged with complex risk, or operating in a difficult environment, you want to explore these factors for the more narrowly available approaches that respect the trade-offs you have to make.
It’s OK to try and hit them all.
Conclusion
Any mitigation strategy will choose from these different factors. It’s never as easy as applying them all, except in the most exceptional risks with the most awareness and cooperation from a group of people who care. Even mature organizations vary in how cooperative they are towards certain risks, and falling back on multiple factors of mitigation can help you pursue a measured approach to the best solution.
Note: I have opinions about articulating and scoping risk in other articles.
Ryan McGeehan writes about security on medium.
