One of the best ways an organization can reduce the blast
radius from the threats previously mentioned is to implement
zero‑trust cloud architecture.
The five steps to zero‑trust, as exemplified by John Kindervag,
would include defining a protect surface,
map transaction flows, architect your zero‑trust network,
create a zero‑trust policy, and finally,
to be focusing on monitoring and maintaining the zero‑trust network. From
the standpoint of defining the protect surface, organizations should
think about what is their DAAS, or their data,
the applications, the assets, and the services. Knowing what's important,
what's critical to the survival of your business in these four spaces
is integral to being able to architect a zero‑trust environment.
Mapping transaction flows means that the technologist is going to have
to understand what do the major transactions in the organization
accomplish? This means that they are trading in their technology hat
for the business hat.
How well do you understand the interdependencies of
the functionality of your business?
How well do you understand the profit and loss that could occur based upon
how a transaction is successful or is not successful?
It's okay to start with an approximation of understanding what
these transactions are, but think of it being an iterative
process where you gain more clarity,
the more you go through it. When architecting the zero‑trust network,
this means that you have to think of your environment as being
one that is created for your business success.
So, in essence,
it can't be based upon just a generic schema, but has to be based
upon what it is that you do. The protect surface that you are
investigating now becomes, at a minimum, a layer‑7 examination of
everything that goes on in the network. You are going to be thinking
about the identification and authentication of applications of users,
and also of content.
Rudyard Kipling had a famous poem that said,
"I keep six honest serving men, they taught me all I knew; their names are what
and why and when and how and where and who." It is those six questions of
existence that need to be asked in the zero‑trust policy that's being
developed. The zero‑trust policy should not only think about who the asserted
id is, but what is it that's being accessed, the protect surface of that
asserted id. Here, we're getting a micro‑segmented layer of understanding of
how it's going to be used. When that user is accessing, it could be an
imperative. For instance,
if a user normally logs in between 8 a.m. and 5 p.m., but now we see that
there's activity occurring between 10:30 p.m. and 1 a.m., that may actually
be a sign to say the authentication should not be successful. Where it's
coming from and where it's going to, as far as the access goes, and here's a
deeper question to ask, almost ontological in nature: why is the id
attempting to access it?
If your zero‑trust policy engine interrogates the why, you may
actually find out that why was okay today,
but there is no justification for it tomorrow.
Also, how? Think of the amount of data that's being consumed.
The policy enforcement engine could look at something like a remote desktop
protocol and see that so much data is being pulled out or pushed in. That
could also be a sign that an attack is occurring. The final stage of
zero‑trust says to maintain and monitor.
So the analysis is continuous and what may be an overbearing and unuseful
amount of information from an event perspective would be inclusive in the
monitoring that's happening with a zero‑trust policy engine. The more, the
better. Also, introducing other types of capabilities in the monitoring that
actually can be more predictive about behavior and about threats that are
occurring in the environment.