In a blog I wrote about a year ago entitled How the New Workplace Paradigm Challenges Cybersecurity, I scrutinized the new workplace paradigms and guided you to the conclusion that “A legacy, perimeter-based approach to security simply no longer protects organizations from the increasingly common and destructive identity- and credential- based attacks.”
Well, I unfortunately must bring some more bad news… this last year has only added to the mountain of proof that the network security perimeter is gradually disintegrating. Both internal and external attacks are on the rise in this age of massively distributed computing, leading inevitably to the failure of the traditional perimeter-based security architecture and the inevitable need to migrate to the Zero Trust security architecture.
Gartner research shows that by 2025, 60% of organizations will use cybersecurity risk as a significant determinant in conducting third-party transactions and business engagements. [1] That’s a lot of potential suppliers, partners and customers using your cybersecurity success as a decision factor on whether to be in business with you.
In this latest article, we’ll spend a little time exploring what the Zero Trust concept is, look at the NIST 800-207 guidelines, and explore which Zero Trust principles could–and probably should–appear in the security strategy for your organization.
As Zero Trust awareness continues to grow after the U.S. White House’s Executive Order was released in May 2021[2], and after a year plagued by one disastrous cybersecurity incident after another, new research reveals that only 1 in 5 security stakeholders are confident in their organizations’ understanding of Zero Trust. One Identity released global survey findings that unpack the current state of Zero Trust awareness and adoption across the enterprise.
Their research shows that while 75% of organizations recognize Zero Trust as being critically or very important to strengthening overall cybersecurity posture, however, only 14% report that they have fully implemented a solution. One of the key barriers to widespread Zero Trust success is a lack of clarity on just how to achieve it.
Digital transformation efforts have driven a rapid evolution of information technology. Pervasive adoption of cloud computing, mobile internet and increasing use of SaaS, to name just a few examples, have driven enterprise staff and enterprise data outside the digital walls of our security perimeter. In the reverse direction, the use of technologies such as Big Data, IoT, and VDI has made it necessary for outside staff and their tooling to require access (at exponentially increasing levels) to the core of our digital castle. The modern enterprise network infrastructure has no single, well-recognized and clear security perimeter anymore.
Faced with this increase in perimeter complexity, industry security teams have reacted. Security budgets are up across the board. However, the extra investment in the traditional security has not been all that successful. Internal and external incidents are still on the rise.
So, you will ask, what is the root cause of the failure of traditional security architecture? The tenet of security architecture is to deal with the loopholes of the underlying infrastructure. I call them “loopholes”, although most security literature will elevate the language a bit to “risks”. What is the loophole that the traditional perimeter-based security architecture underestimates? The answer is TRUST.
The traditional security architecture assumes that the perimeter defense guarantees that the people and devices in the internal network are trustworthy. However, we need to recognize that there are always undiscovered or unpatched flaws in the perimeter, that internal systems may already be compromised and that insiders are not de facto trustworthy.
In their book “Zero Trust Networks”, Evan Gilman and Doug Barth postulate Zero Trust is built on five fundamental assertions: [3]
· The network is always assumed to be hostile.
· Internal and external threats are always present on the network.
· Network locality should not be a factor in deciding trust in a network.
· Every device, user, and network flow must be authenticated and authorized.
· Policies must be dynamic and calculated from as many sources of data as possible.
In short, by default, no person, device or application operating on the internal or external network should be trusted. In a more recently published “Zero Trust Architecture (NIST.SP.800-207)”, NIST provides the following operative definitions: [4]
· Zero Trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.
· Zero Trust Architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes Zero Trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a Zero Trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a Zero Trust architecture plan.
These definitions focus on the heart of the issue, which is the goal of preventing unauthorized access to data and services, underscoring the importance of fine-grained access control.
To take this one step further, let’s substitute the word resource for data in the previous sentence. In reality, ZTA is about resource access and not just data access. To lessen uncertainties–as it is impossible to eliminate them completely–the focus must be on authentication, authorization, and shrinking implicit trust zones, while maintaining availability and minimizing temporal delays in authentication mechanisms. Access rules need to be made as granular as possible to enforce the least privileges needed to perform the action at the request.
In the access model shown below, a subject needs access to an enterprise resource. Access is granted through a policy decision point (PDP) and a corresponding policy enforcement point (PEP).
.png)
The system must ensure that the subject is authentic and that the request is valid. The PDP/PEP passes proper judgment to allow the subject to access the resource. This illustrates that Zero Trust applies to two basic areas: authentication and authorization. What is the level of confidence in the subject’s identity for this unique request? Is access to the resource allowable given the level of confidence in the subject’s identity? Does the device used for the request have the proper security posture? Are there other factors that should be considered and that change the confidence level (e.g., time, location of subject, subject’s security posture)?
Overall, enterprises need to develop and maintain dynamic risk-based policies for resource access and set up a system to ensure correct and consistent enforcement of these policies for each resource access request. This means that an enterprise should NOT rely on implied trustworthiness. For example, if the subject has met a base authentication level (e.g., logging into an asset), then all subsequent resource requests should not be assumed equally valid.
There are as many interpretations of ZT as there are fish in the sea. I admit, I probably have mistaken my limited ability to keep up with them to mean that there are an infinite number of articles out there. Many of these definitions and discussions of ZT touch on the concept of removing wide-area perimeter defenses. While strictly speaking the “wide-area” perimeter is undeniably not as effective as it used to be, the real message is not about this defensive layer disappearing, but about the fact that the premise must be taken in the context of the security perimeter shrinking to the level of micro-segmentation or micro-perimeter.
The following list of 7 tenets describes goals when your organization embarks on the journey of creating its first Zero Trust strategy, though it must be acknowledged that not all tenets may be fully implemented in their purest form for a given strategy.
1. All data sources and computing services are resources.
A network may be composed of multiple classes of resources representing multiple security needs, but all devices, applications, APIs, functions, as well as data are considered resources.
2. All communication is secured, regardless of network location.
Network location alone does not imply trust. The model has an assumption of breach, therefore assuming the bad actors are already inside the network.
3. Access to individual enterprise resources is granted on a per-session basis.
Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task.
4. Access to resources is determined by dynamic policy and may include other behavioral and environmental attributes.
The rules and attributes are based on the needs of the business process and an acceptable level of risk. Resource access and action permission policies can vary based on the sensitivity of the resource/data. Least privilege principles should apply to restrict both visibility and accessibility.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
The “assets” of the enterprise encompass many things, the general rule is that no asset is inherently trusted. The enterprise evaluates the security posture of the asset when evaluating a resource request.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
This strict enforcement of access control is an absolute requirement. It is a constant cycle of obtaining access, scanning, and assessing threats, adapting, and continually reevaluating trust in ongoing communication.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.
Visibility is the key to success. An enterprise should collect data about asset security posture, network traffic and access requests, process that data, and use any insight gained to improve policy creation and enforcement. This data can also provide a context for access requests from subjects.
While ZTA clearly goes deeper than just network defense, it doesn’t hurt to look at the architecture from a network perspective as well. A lot of enterprise security teams find this view very comforting at first because it corroborates that the network-focused skills and principles–that were always so important to this team–are still an important part of the equation.
There are some basic assumptions for network connectivity for any organization that uses ZTA in network planning and deployment. Some of these assumptions apply to enterprise-owned network infrastructure, and some apply to enterprise-owned resources operating on non-enterprise-owned network infrastructure (e.g., public Wi-Fi or public cloud providers). These assumptions are used to direct the formation of a ZTA. The network in an enterprise implementing a ZTA should be developed with the ZTA tenets outlined above and with the following assumptions.
1. The entire enterprise's private network is not considered an implicit trust zone.
Assets should always act as if an attacker is present on the enterprise network, and communication should be done in the most secure manner available. This entails actions such as authenticating all connections and encrypting all traffic.
2. Devices on the network may not be owned or configurable by the enterprise.
This includes both visitor, contractor and employee bring-your-own-device (BYOD) policies that allow enterprise subjects to use non-enterprise-owned devices to access enterprise resources.
3. No resource is inherently trusted.
Every asset must have its security posture evaluated before a request is granted to an enterprise-owned resource. This evaluation should be continual for as long as the session lasts.
4. Not all enterprise resources are on enterprise-owned infrastructure.
Resources include remote enterprise subjects and cloud services.
5. Remote enterprise subjects and assets cannot fully trust their local network connection.
Remote subjects should assume that the local network is hostile.
6. Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture.
Assets and workloads should retain their security posture when moving to or from enterprise-owned infrastructure. This includes devices that move from enterprise networks to non-enterprise networks and workloads migrating from on-premises data centers to non-enterprise cloud instances.
The former security mindset, where we trust the subjects inside the castle wall, is broken in the world of digital business, which requires anywhere, anytime, any device access to services that may not be located “inside”.
The new security model presents an approach in which a trust broker mediates connections between applications and users. This model starts with a default deny posture of zero trust. The result is a much more resilient environment with improved flexibility and better monitoring.
There is no reason not to look into the adoption of Zero Trust principles as you expand and modernize your business. I am the first to acknowledge that the product market is still nascent in a few areas, but it is growing and maturing quickly.
There are also lots of mature product offerings that can be implemented immediately and without undue risk. All cloud and hybrid cloud providers have embraced the micro-segmentation principles that are needed for the ZT architecture.
If you are still unconvinced about the need and urgency around Zero Trust, seek me out and I’ll gladly buy you a cup of coffee and talk to you one-on-one about your concerns.
[1] Gartner, Predicts 2022: Cybersecurity Leaders Are Losing Control in a Distributed Ecosystem (ID G00757928, Jan 2022)
[2] The White House, Executive Order on Improving the Nation’s Cybersecurity, May 2021
[3] Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks (O’Reilly Media, 2017)
[4] NIST, Zero Trust Architecture, 2020.08, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
