The Assumed Breach Model - A Practical Approach Part 1
This is something I have been socializing for a while now, but I thought it was time to start putting some of thoughts down in writing.
So what is the assumed breach model of security? To put it simply, it is a security strategy that assumes any given endpoint is breached and controls risk as such. That is an oversimplification, of course, as taking that approach would be an enormous amount of effort and impractical for many attack vectors. An integral part of this approach is to be able to accurately understand and identify risk. This can be accomplished through any number of methods. It is essential to be able to understand the threats to a system, the risks those threats introduce and the controls that can mitigate those risks. Another model in the industry is zero trust, which is also the right approach. However, my take is that zero trust is a misnomer in that you must trust everything to some extent, but ultimately they are very closely related.
The goal of this series is to introduce people to this security model and to provide a practical approach to implementing it.
What is the goal of security?
Traditional security says protect all the things; who cares if you can do your job quickly or not, the data is safe and users can't break any of the things! New terms such as DevOps and SecDevOps say "I need to do things very quickly and in a certain way, and if I can't then everything will fail. We will build security into it as we go."
Obviously, I added a bit of hyperbole to those examples, but the point is that any model that is one sided or selfish doesn't accomplish the goal of information security. The real goal of information security is not to protect all the things, it’s not to prevent a data breach, and it's not to set the standards for everyone else. The real goal of information security is to help business leaders of all levels understand risk and balance that with operational resilience. In other words, what good is security if users can't work and what good is it if users can work, but an organizations data is unprotected. What good is centralized log storage if you aren't threat hunting and what good is a firewall if your users have administrative access to servers with the same account that they check email with?
Changing our mindset to assumed breach
All of these are questions that should be considered when moving to the assumed breach model. It’s time we start looking at foundational security concepts in a different light. Microsoft's Immutable laws of security start with:
Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
To translate this into the assumed breach model, it could be stated like this:
Assumed Breach Law #1: If you can check email or browse the internet, assume that a bad guy is running his or her program on the device
Why? Because any one of us can be phished. No one is immune. There isn't a tool that can protect us from this; this is human problem for which there is no solution without restricting access to email or the internet. If we agree that when it comes to phishing 'it just takes one' to potentially compromise a network, then stop testing to see if your users will be phished. Just assume they will be and put controls in place to protect the network. It will save a lot of time and effort and help keep executives from thinking that because there was only a 6% click rate this month the organization is safe from phishing. How many organizations testing their users have a 6% click rate that is less than 1 user?
It's time to stop pretending we are secure
Because pretty charts and low percentage rates create complacency or a false sense of security, I'll go so far as to say testing users with fake phishing emails is detrimental to security. When we hire companies to perform penetration tests, why consider a 'blackbox' pen test (unless you are using a full red team approach and are prepared)? This essentially says, I’m not going to give you any information about my organization, but I want you to test us and tell us what we are missing.
If we agree that given time and motivation, the attacker will find the information, why not just give the tester everything and let them use their expertise; it will save you money and show you your real threats. Otherwise, an organization gets a report that the only shows a small picture of their risks.
Making these assumptions about threats can save organizations a lot of time and money on tools that may or may not protect them. Instead, if we focus our efforts on architecting networks in a way that we can control an attacker's actions, detect their movements, and restrict human behavior without restricting business operations, then we can refocus our efforts on potentially fewer tools and more actionable intelligence.
What next?
The ability to take action on the information available is the type of discussions that should be taking place between security and operations teams as well as with executives. In part two, I will go into some high level areas where assumed breach should focus such as network segmentation, tiered accounts, logging and log management, and security baseline standards. In part 3, I will offer a few specific suggestions of some baby steps to take. For now, ask yourself, is what I am calling security actually reducing risk and actionable intelligence or is it just producing pretty charts for reports or checking boxes for compliance?