Skip to content

Commit aa178a9

Browse files
committed
zero trust update
1 parent adf2871 commit aa178a9

File tree

1 file changed

+20
-16
lines changed

1 file changed

+20
-16
lines changed

firewall.rst

Lines changed: 20 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -466,15 +466,16 @@ access to a lot more resources—other machines and data—than is necessary to
466466
its job. One of the main approaches to improve this state of affairs
467467
is known as "zero trust security".
468468

469-
The term "zero trust" was coined by the analyst firm Forrester in
470-
2009, and continues to be widely used in the industry today. The
471-
central idea behind zero trust is that, by default, every device and
472-
user should be untrusted. Each user and device then needs to
473-
authenticate itself to gain access to a precise set of services. There
474-
is no blanket "trust this device to access anything" policy. Zero
475-
trust stands in contrast to the old "perimeter security" model in
476-
which there is the idea of a trusted region within a perimeter
477-
protected by firewalls and an untrusted region outside the perimeter.
469+
The term "zero trust" has been in use for decades, but started to
470+
enter widespread use around 2009, helped by the analyst firm
471+
Forrester. The central idea behind zero trust is that, by default,
472+
every device and user should be untrusted. Each user and device then
473+
needs to authenticate itself to gain access to a precise set of
474+
services. There is no blanket "trust this device to access anything"
475+
policy. Zero trust stands in contrast to the old "perimeter security"
476+
model in which there is the idea of a trusted region within a
477+
perimeter protected by firewalls and an untrusted region outside the
478+
perimeter.
478479

479480
Zero trust is sufficiently well accepted that NIST has written a
480481
specification (see Further Reading below) which provides this helpful
@@ -507,18 +508,21 @@ to only the systems that are needed for them to do their job.
507508

508509
Micro-segmentation, described above, was one of the early technologies
509510
created to help in the implementation of zero trust. Rather than
510-
allowing all machines in a large network segment communicate freely,
511-
as was the case previously, micro-segmentation allows precisely
512-
defined policies to limit communication among a set of devices to just
513-
what is needed to deliver their intended function. For example, the
514-
systems related to heating and cooling don't need access to
515-
the systems where customer credit card details are stored.
511+
allowing all machines in a large network segment to communicate
512+
freely, as was the case previously, micro-segmentation allows
513+
precisely defined policies to limit communication among a set of
514+
devices to just what is needed to deliver their intended function. For
515+
example, the systems related to heating and cooling don't need access
516+
to the systems where customer credit card details are stored. A
517+
default policy of no access can also be established, with explicit
518+
configuration then required to create precisely specified allowable
519+
commuincation patterns between specific devices.
516520

517521
The VPN example above provides motivation for a different approach to
518522
handling users and devices outside of the confines of a traditional
519523
office and outside the perimeter defenses. A well-known and
520524
comprehensive approach to rethinking the perimeter defense and VPN
521-
model is Google's Beyond Corp, described in a 2014 paper in the further reading
525+
model is Google's BeyondCorp, described in a 2014 paper in the further reading
522526
section below. It is both an approach used to implement zero trust at
523527
Google for employees accessing corporate resources and a service that
524528
enterprises can implement themselves.

0 commit comments

Comments
 (0)