[BreachExchange] What You Need to Know About Zero Trust Security

Destry Winant destry at riskbasedsecurity.com
Thu May 30 10:21:27 EDT 2019


https://www.darkreading.com/vulnerabilities---threats/what-you-need-to-know-about-zero-trust-security/d/d-id/1334751

If your network has a perimeter, it will someday be breached. That's
both the lesson the "real world" works so hard to teach and the
premise behind a key security model: zero trust.

"Don't trust, and verify" might be a nutshell description of the zero
trust model — "don't trust" because no user or endpoint within the
network is considered intrinsically secure, and "verify" because each
user and endpoint accessing any resources of the network must
authenticate and be verified at every point, not just at the perimeter
or large network segment boundaries.

This often-repeated authentication throughout the network and
application infrastructure relies on the concept of
"microsegmentation," in which boundaries are defined around individual
applications and logical network segments. This kind of frequent check
point can go a long way toward putting an end to lateral infection in
malware outbreaks, and it doesn't have to be as cumbersome to users as
it sounds — as long as technology is used to deal with some of the
logins and authentications along the way.

While the concept behind the zero trust model is simple,
implementation can be anything but. Before a company decides to invest
in the technology and processes, it should understand what is involved
in the model and its application. Dark Reading has identified seven
issues to resolve before launching into a zero trust environment.

Decide Who Drives

Zero trust and its enabling technology, microsegmentation, require
changes to both security and networking infrastructure. Given that,
one of the first questions to be answered is which group will own the
project.

Depending on precisely how your application environment is configured
before beginning the project, changes may be required to switches,
routers, firewalls, authentication servers, and the application
servers themselves. In many organizations, responsibility for changing
those infrastructure components could fall well outside the
responsibility of the security group, in which case the options boil
down to expanding the security team's brief for this purpose or having
security write the requirements that will be put into action by the
network and application maintenance teams.

The multiple responsibilities and components of zero trust make it an
instigating factor for a move to DevSecOps for some organizations.
Treating every part of the infrastructure as software to be constantly
authenticated against, monitored, and improved makes sense for zero
trust security, and it may ease some of the issues around which group
is going to drive the change process.

Build Least-Privilege Policies

How much does access privilege cost? Does your company see it as a
cheap line of code in an access table? Is it better to give users the
privilege they might need rather than risk having them run into an
access denial issue when their responsibilities expand? If so, your
users have a serious attitude adjustment to come when you move to zero
trust.

Least-privilege security is based on a very simple concept: The
network (and application) infrastructure is most secure when users
have only the access privileges required to do their jobs. This kind
of privilege management has many benefits, with one being the limited
harm employees can do when they wander out of the tools required for
their jobs. Another huge benefit is the limited harm hackers can do if
they steal the credentials of users. It is much more difficult for
low-level employees with low-level privileges to provide the stepping
stone for a network takeover if their access to far-flung network
segments and applications is limited.

Least privilege requires a change in philosophy for many
organizations, and it can feel awkward if the reason behind the shift
isn't explained fully and carefully. Coupled with zero security,
though, least privilege can be a powerful tool for limiting attackers'
ability to expand their attacks and create damage inside the network.

Get Small

This is the crux of zero trust security. When you logically and
physically segment your network and application infrastructure into
very small pieces, with authentication required for each transit from
one segment to another, then you have placed some very hard limits on
how far an intruder's access can easily go.

Those small segments should be thought of in both logical space and
time. If a user (especially a highly privileged user, such as an
administrator) occasionally needs access to a particular system or
function, then he or she should be granted access for the time needed
to work on the issue, not always.

If you assume your network has been breached, then the logical
response is to make sure the breach can do as little damage as
possible. Keep any single attack confined to a single logical segment,
and you limit the damage to that segment. And that does a number of
very good things for your overall security.

Secure Everything, Everywhere

If you assume that the network has been breached and attackers are
running around inside the perimeter, then the last thing you want to
do is leave a segment or component unprotected. This is not just for
the security of the protected piece of network, but to keep the
unprotected components from becoming a launching pad for attacks on
other segments of the infrastructure.

Now, security experts may start to ramp up arguments about
prioritizing assets for protection and the inadvisability of
protecting everything equally. That's true, but remember that the
ideal is layered security, so it's critical to understand the layer
that's being discussed here.

That layer is the access layer — who, or what, has been authenticated
as legitimate so they can properly access a particular asset. At that
layer should never be an unprotected network segment or application
component. Secure everything, everywhere, and you will minimize the
access-based risk to your IT infrastructure.

Be Nosy — Very Nosy

Microsegmentation should make it easier to stay on top of whatever is
happening on your network, but to know who's doing what you have to
first be looking. And if you want to be secure, you should be taking a
very close look at many different facets of network behavior.

With segmentation showing the way, it can be more straightforward to
instrument a zero trust network than one with traditional
authorization models. And to bring the prioritization question back to
the fore, the question becomes not one of where to monitor, but which
factors to monitor in each segment.

Once you identify strategic network segments or application
infrastructure components, you can establish deep inspection of
network flows and behaviors with less concern about swamping data
storage or human analysts because you will be taking data from a
limited network segment. In general, though, you want to be quite
aggressive in monitoring segments so that security architects can
follow attacker and employee behaviors, as well as help evolve
security rules and processes to keep pace.

Add Factors

If authentication to each network segment is key to total network
security, then the process of authentication becomes critical. And
until we reach the science-fiction future, user authentication means
strengthening the factors you use and adding others to make user
identification more certain.

Surveys of passwords in use inevitably produce depressing results,
with strings like "12345" and "qwerty" consistently topping the list
of most-used passwords. So task one is establishing strong password
policies for everyone in the organization and then enforcing those
policies.

Next, add factors. The current list of factors is something you have,
something you know, and something you are. This multifactor
authentication is becoming more common, but it has started from a
total market penetration near zero, so many companies are still
willing to try anything more robust than the classic user
name/password pair for authentication.

Keep It Modern

There is no security model that is "set it and forget it." Zero trust
security is not an exception to this rule — and may be one of the
least forgettable security models out there. That's because keeping up
with threats and knowing how they might try to thwart authentication
schemes is critical when authentication plays such a significant role
in the overall scheme.

Beyond the authentication issue, security professionals much keep up
with threats and the mechanisms they use for lateral movement and
bypassing network segmentation. No one in security can assume that the
methods and technology that work today will always be effective, so
security practitioners will need to keep up with industry trends and
spend time analyzing incidents captured in monitoring to see where
breaches of segmentation have been tried — and where they might have
been successful.

There's no question that zero trust security can be the basis for
successful information and asset protection. But just because a method
is effective doesn't mean it can be launched without careful thought
and planning. Ask questions, plan ahead — and remember to trust no
one.


More information about the BreachExchange mailing list