It goes
without saying that companies migrating IT systems and operations to the cloud
face a growing number of challenges related to security. From securing
cloud-native applications in a continuous release environment to managing
digital identity and remote access to sensitive data, virtually every aspect of
day-to-day IT and cybersecurity operations is changing rapidly. 

With
Gartner forecasting $124 billion in
worldwide cybersecurity spending this year, it’s clear that organizations are
racing to find a model that works. There’s just one problem: far too many are
trying to shoehorn legacy security models into a cloud-native world – and it’s
not working. In fact, some of the best security teams in the world today even
struggle to keep their systems secure, including Facebook, Google, Microsoft and a growing list of
others. 

What’s
going on here? It’s quite simple, actually: Just as the move to cloud forces
organizations to undergo fundamental shifts in their business and IT
operations, it also demands they make equally substantial changes to
their core assumptions about cybersecurity. 

In
response, many IT and security experts are quick to proclaim, “the perimeter is
dead.” While it’s certainly true that the old dichotomies of inside/outside or
attackers/trusted parties have become less clear, the notion that perimeters
are altogether gone is a dangerous misconception. In today’s cloud-first world,
the perimeter isn’t gone – it’s ephemeral. Instead of being fixed and
centrally organized, perimeters are just like every other aspect of the cloud
now — they are distributed and ever-shifting as conditions change. 

What’s
needed is a cloud-native security model. The good news is that it already
exists, and it’s been around for nearly a decade: zero-trust. 

Zero
trust is a radical change from pre-cloud security models. Instead of assuming
it’s possible to create a central perimeter that protects everything inside
(the “hard shell, soft center” approach), zero trust is all about: (1) reducing
an organization’s security risk by minimizing the probability of an attack via proper
identification and authentication, and (2) minimizing the impact of successful
attacks by microsegmenting authorization. That is, if someone steals a user’s
credentials, they can no longer slip through the organization’s defenses
undetected. As the user moves through a system, they must continuously verify
that they are who they say they are, with the level of verification required
scaling alongside the sensitivity of the access and the task they are
requesting or performing. 

Where do
you start? While every organization is different, there are three core
principles that guide all zero trust implementations: 

There
is No Distinction Between “Insiders” and “Outsiders”

While
most organizations today recognize that the line between “insiders” and
“outsiders” is blurring, most still follow the same model and view an employee
on an “authenticated” device as trusted. But BYOD, phishing and rogue insiders
demolish that distinction.Everyone should be considered hostile. No
implicit trust should be attributed to the location of the user, the network or
the device they are using. 

For
example, Mobile Device Management (MDM) tools give the IT team control over the
use of a personal device in the network like a tablet, but doesn’t provide true
security, only the illusion of it. If the user clicks on something that the MDM
agent on the device can’t see, the network can be easily compromised. For
instance, employees in the HR department receive and open emails with
attachments containing resumes all the time. However, MDM doesn’t protect
against attachment-borne malware that installs a trojan agent on the employee’s
device. If the security control is to treat every device under management as
trusted, then this trojan agent can simply hide in plain sight.  

Discrete
One-time Super Authentication Must End

Most
organizations have implemented 2FA, which is good, but the problem is its use
is too far reaching. Once a user is verified with 2FA they can access all sorts
of systems because the model considers their identity as confirmed going
forward. However, identification and authentication are contextual, and the
results should be valid only for the duration of the specific transaction for
which they are requested. One successful spear phishing campaign can turn a
user’s device from safe to risky if malware is downloaded on it.  Very few
organizations do transaction-level verification. Banks do it for certain types
of high-level transactions, but outside of that, it’s rare. Two-factor
authentication shouldn’t grant you elevated privileges indefinitely; it’s a
discrete event. 

We
understand this in other contexts. For instance, when flying. You don’t just
buy a ticket and then walk right onto the plane. You have to check in at the
airline desk, go through security with your boarding pass and ID, and then show
your boarding pass again at the gate. Each new level of verification allows
deeper access but not carte blanche access. A boarding pass in conjunction with
a valid ID gets you past security, but not into sensitive areas of the airport.
Similarly, a boarding pass gets you onto a plane, but does not allow you to
access the flight deck. Another example is the medical field. Certain
prescriptions, like narcotics, require patients to provide ID and take extra
steps to ensure against fraud. 

Use
Dynamic Policies With Broad Inputs

Too
often, organizations treat policies as static and rely on too few inputs,
partially out of habit and partially due to historical limits on compute power
and inability to ingest and process a multitude of signals. But to be effective
policies need to be dynamic and to be evaluated with the largest possible set
of inputs. This means that trust in the identification and authenticity of the
user, and the risk associated with the task they are attempting to perform, are
constantly evaluated.

For
example, you can have static policies that say if a user is authenticated, then
let them in. Or, if a user is authenticated and has done biometric, let them
in. And, if the user is authenticated but it’s after 5 pm, ask for biometric
then let them in. Requests from managed devices provide more inputs to use to
establish the level of trust. But static policies break because they cannot
process new information or interpret new context, so they fall back to a
default rule which might or might not be the right approach.  Dynamic policies
allow systems to act on incomplete information and provide an answer that is a
trust level on a continuum, rather than binary yes/no trust level. 

Such
security policies aren’t reliable; their lack of sophistication enables a false
sense of security and/or interferes with productivity needlessly. As humans, we
make dynamic decisions and judgment calls all the time — walking down the
street and assessing the riskiness of a neighborhood at certain times of day,
or deciding what to wear by checking the weather forecast and looking at the
sky. Security policies need to allow for similar degrees of input and to
reflect the reality of changes in users, devices and contexts. 

In a
hyperconnected world, there is no such thing as absolute security and zero risk.
Now more than ever, security is about continuously evaluating trust and making
decisions to minimize risk. Zero trust principles offer clear and actionable
guidance. They ensure protection of data no matter what users or devices are
attempting to access them by operating under the assumption that all devices
and systems might be compromised.  

Baber Amin, CTO West, Ping Identity