Breached. Compromised. Infiltrated. Exposed. These are four words no CISO wants to see in their inbox. Looked at another way, however, they can be immensely valuable. How, you ask? By accepting these four words as the status quo and by assuming at all times that you have been breached (whether or not that is actually the case), decision-making becomes much simpler. Any decision made from the standpoint that the attacker is already inside your environment is straightforward, easily justified, simple to communicate and encourages a more secure posture; thus, using this concept as a decision-making tool can help companies get ahead of the game. To begin with, the reasoning behind technical security decisions can be rather opaque to non-security staff and is often put into the “because security said we have to” bucket. This in turn fosters the kind of negative sentiment often attributed to information security policies. But the concept of Assume Breach makes it very easy for both technical and non-technical staff to understand the “why” behind security leadership decisions and is an approach they can apply in their everyday work.
Let’s take the example of a team deploying a new application in a public cloud environment that will use a RESTful API to communicate between microservices. Because these components are not directly exposed to the internet, the team asked to use the plaintext HTTP protocol instead of the more secure encrypted HTTPS protocol as it is easier to deploy and manage. While the normal discussion about this could be lengthy (and probably heated), the response to the team’s request becomes very clear if it is assumed an attacker has already breached the environment. Deploying this application with some form of encrypted transport becomes the only safe choice. Whether that takes the form of HTTPS, an encrypted service mesh or some other mechanism does not matter, as long as it is not plaintext and provides some form of authentication mechanism. While there may still be some initial pushback from the application team, once they understand the concepts used to make the decision, they are more likely to understand and accept it.
When applying the Assume Breach approach it is important to take a holistic view of the security landscape in question. In the example above, this decision would form part of a more comprehensive plan of attack, including controls relating to infrastructure protection, data protection (including encryption), identity and access management (IAM), Threat and Vulnerability Management tools, logging, monitoring and configuration management. The controls chosen also need to take into account the nature of the environment being protected. For example, in a public cloud environment where we are adopting an Assume Breach mindset, it may be prudent to adopt a BeyondCorp or Zero Trust access model where we no longer trust that whole networks are secure, and instead use authentication mechanisms to determine the precise resources required by an entity requesting access.
Is always assuming a breach overly cautious? In 2018, a researcher ran a honeypot instance (see inset) on AWS, and published his results on Kaggle. Beyond the sheer range of attacks observed, there was one key metric that jumped out: there were an average of 99 attacks PER HOUR, not including those automatically absorbed by the AWS infrastructure. Considering that just one attack needs to be successful to wreak havoc, and that according to the 2018 Cost of a Data Breach Study by IBM Security the Mean Time to Identify (MTTI) a breach is 197 days, the idea that an environment might already be compromised is actually not that improbable. In this way, adopting an Assume Breach approach in your cloud security practice can not only simplify the decision-making processes, but can also be a prudent step that greatly improves the quality of your security posture.
Honeypot: In computer terminology, a honeypot is a computer security mechanism set to detect, deflect, or in some manner, counteract attempts at unauthorized use of information systems. Generally, a honeypot consists of data (for example, in a network site) that appears to be a legitimate part of the site, but is actually isolated and monitored, and that seems to contain information or a resource of value to attackers, who are then blocked. This is similar to police sting operations, colloquially known as “baiting” a suspect. [source: https://en.wikipedia.org/wiki/Honeypot_(computing)]
