Let’s take the example of a team deploying a new application in a public cloud environ-
ment 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 plain-
text 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 under-
stand 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 protec-
tion, data protection (including encryption), identity and access management (IAM),
34 | THE DOPPLER |
FALL 2019
2019