The zero-trust architecture (ZTA) represents a much-needed (and perhaps long overdue) pivot toward a more fundamental approach to cybersecurity. As its namesake suggests, the ZTA is primarily concerned with the idea of “trust”, or more specifically, eliminating the notion altogether from the day-to-day operations considering the modern IT network.
Zero-trust in its ideation comes with an illustrious list of benefits, best encapsulated by its three core principles: “never trust, always verify, and assume breach”. However, as encapsulated by NIST SP 800-207, the formalization of the once (perhaps still) theoretical ZTA, the requirements for standing up an actualized zero-trust network ventures leagues beyond those popular core principles.
What exactly does zero trust mean, and how do you get your organization there? For the uninitiated, “zero-trust” is not just a marketing buzzword or a meaningless veil constructed to cover a business’ empty and unfulfilled promises. “Zero-trust”, as a term, is a technical qualifier – meaning that the subject with which the adjective “zero-trust” adheres to the principles, guidelines, and functional specifications defined within the foundational NIST text designed to address what makes a network architecture a ZTA.
Furthermore, these requirements — like many other normative NIST documents — are specific in terms of what sorts of functionalities are fair game in the zero-trust domain, but extremely vague regarding specific technologies and/or products which execute these functionalities. This leaves the exercise of validating, synthesizing, integrating, and maintaining separate and unique zero-trust-ready technologies and solutions (ultimately coalescing into one singular feat – standing up a full-fledged ZTA) solely to the reader. In other words, if you’re looking to reap the benefits of the zero-trust paradigm, the onus is on your organization to get yourselves there.
Now, your immediate and most natural inclination upon receiving this news (still addressing the uninitiated – experts: pipe down for about two more paragraphs) will be to utilize the free market to its utmost potential and turn this technical, even philosophical problem into a dollar-figure one. Alas, this approach falls short of truly actualizing a ZTA and in fact, is antithetical to the overall vision and long- term success of ZTAs everywhere (more on this later). If your goal is to bring the benefits of zero-trust within your organization’s own walls, the strategic planning, selection, integration, and transition of and to zero-trust technologies is largely up to the discretion of each individual enterprise/organization, an emerging phenomenon known currently by the industry as “migrating to zero-trust”.
Migrating to a zero trust architecture
Zero-trust migration is absolutely as thorny of a problem as it sounds, especially considering that every organization that functions at any level beyond braindead has at least some semblance of an IT network that most probably does not meet the criteria for being considered compatible with the zero-trust vision.
So, with existing architecture that is lagging behind, zero-trust doctrine and definitions which leave product and service adoptions up to the would-be migrator, and no “one-size fits all” ZTA solution available courtesy of the free market, where does one look? What is the ideal method for migrating to a zero-trust network? Where, as a security or technology practitioner, should I begin my hunt for actualizing zero-trust? What is square one in the hellish landscape?
Well these are all good questions; this document aims to take a really good hard look at the last one – partly because it is the most fundamentally important question to answer for achieving real results in the world of zero-trust migration, and partly because we can’t map out your zero trust strategy for you within this article.
So, with this brief introduction into the unkempt forest that is enterprise-wide zero-trust migration, let’s pick up some machetes and do some trailblazing.
Square Zero: understanding your architecture today
When considering zero-trust migration, it is of utmost importance to have a clear and cogent picture of your existing architecture as it stands today – putting a new engine in your car is no good without a blueprint of your chassis and a detailed inventory of all the required tubes and hoses. The same thing goes for your network. Understanding your existing topology as it exists today is paramount in formulating a plan and strategy for moving toward a zero-trust environment. Consider this the required prerequisite for undertaking zero-trust migration, a “square zero”, if you will.
Getting started with Zero Trust: an iterative process
Assuming that your organization has already done the legwork of analyzing your current state of affairs already, what are the available strategies for beginning the migration over to zero-trust? There are tons of requirements, potential components, protocols, services, etc., that one could look to for starting the long journey toward a ZTA.
The good news about this process is that no matter who you ask about ZTA migration, there is one consensus amongst the majority: this doesn’t necessarily have to be a start-from-scratch operation; it can be an iterative and incremental process – again, ZTA migration is more about the journey than the destination. Often, the hardest part in tackling a big problem is figuring out how to start – and if you’re sleuth-y enough to read article titles, you know where this conversation is going.
The current conversation surrounding zero-trust migration is an interesting one, albeit a little bit sparse. Although all aspects of the business enterprise have been participating in this forum, it is particularly interesting to focus in on the federal government and military sectors, as they have literally been mandated by the president to begin moving toward zero-trust adoption.
With a much more purpose-driven toward actualizing zero-trust principles, several key research sources like NIST, the Defense Industrial Board (DIB), and MIT’s Lincoln Laboratory have undertaken outlining a few potential ways organizations could choose to utilize in incrementing their existing technological environments in the direction of zero-trust.
Many resources, with an emphasis on those mentioned above, have theorized a myriad of ways in which an organization could choose to implement a network architecture that embodies the key characteristics which make ZTAs such a powerful concept: from choosing to implement architectural pieces to strategically actualize one zero-trust principle at a time, to taking a much more use-case focused approach to zero-trust security, to even an all-at-once approach (if you have the means necessary to do that).
However, there is one common theme which stems from all these sources of research & implementation suggestions: at its core, the ZTA relies upon two primary yet somewhat abstract functionalities – policy orchestration and rigid authentication and authorization (for users and devices).
ZTA Policy Orchestration
Under policy orchestration, there is some good news. The NIST documentation (and subsequent bodies of research and discussion) do an excellent job of detailing what a zero-trust policy orchestration body should look like at a high level. In a nutshell, policy orchestration in the zero-trust domain is\accomplished via three abstract components:
- Policy Engine (PE)
- Policy Administrator (PA)
- Policy Enforcement Point (PEP).
Within the guidance, the responsibilities of these three components are made clear, as well as how they are expected to interact with more traditional network components, like ICAM and transport. Check out our other zero-trust-focused piece here, which focuses on these policy-level components and how we see ourselves in that environment.
ZTA Authorization
The other side of this coin (the “coin” being the fundamentals of a zero-trust network) is identity, authentication, and authorization – all of which must serve and be served by those policy orchestration pieces. What good is configuring a dynamic body of rules and fool-proof enforcement of them if you have no subject to impose them on? In fact, this distinction is outright implied by the moniker “zero-trust” – without implicit trust in one’s name, account handle, claimed identity, etc., one must have a dynamic and reliable way to authenticate claimed identities and authorize the privileges associated with said identity profile.
Authorization is undeniably a critical component for any secure network, especially one that’s being constructed to the heightened standards of zero-trust. However, meritorious and judicial keeping and awarding of access privilege means little if the threshold to be granted those privileges is exploitable. If trust is to be totally eliminated, it must be replaced with flexible, lightweight, and rigid authentication.
Authentication and Identity
And so authentication is where we begin. Well, authentication and identity – it’s a subtle but important distinction between the two. Identity is exactly what it sounds like – who am I? The answer to this question, although philosophical, is a very subjective one when it comes to the considerations your organization needs to make. What factors must be present within an “identity”? My name? Job title? User profile? Account name? The device I’m on? The time of day? Etc… In short, defining what “identity” is in the context of your zero-trust network is up to the specific needs of your organization.
Authentication, on the other hand, is the act of proving that I (the user) am indeed consistent with the identity that I am claiming in order to traverse about the network and its various resources of varying levels of sensitivity. In other words, authentication is how users prove that they are consistent with the identity they are claiming. If you are familiar with the concept of multi-factor authentication (MFA), you know the artifacts associated with such actions are often described as:
- something you have
- something you are
- something you know
So, for example, my organization could authenticate me in part by having me give them some piece of information which comes from my employee badge – something they are reasonably sure that they gave to the real me after verifying my identity via a driver’s license or passport. This badge-supplied information would then be combined with something I specifically knew, say a PIN number. And, additionally, I may need to release a secret key via scanning my fingerprint on some device which releases said key. And voila – MFA based on my identity done in true form and fashion.
In zero-trust, this MFA thing is non-negotiable. The days of moving unencumbered about your organization’s network at the sole behest of a 6-character password are over, baby. Welcome to the future. Now, the rational amongst us should have a sinking feeling in their guts right about now – this MFA, in its concept, is obviously more secure than simple password-based authentication (or any other single factor, for that matter).
However, in this paradigm of zero-trust, we already understand that the frequency of authentication transactions between user and network will increase exponentially. This leads to the obvious problem of operational friction. Sure, it might be more secure to force someone to cough up their PIN, badge number, and fingerprint every time they need to open an email, but is it feasible? Users tend to avoid friction whenever possible, even opting to circumvent it however they can, making this a point to consider most carefully when choosing a zero-trust MFA solution. What good is a cutting edge home security system if nobody wants to undertake the seventeen-step process required to turn it on?
Enforcing policy dynamically
Another thing we can all look forward to in the zero-trust domain is the requirement to dynamically consider and enforce varying policy requirements. For example, perhaps a low-risk activity (like allowing a user to open an e-mail) requires only that the user has authenticated themselves in the prior half hour. However, allowing that user to open an e-mail marked CONFIDENTIAL may require them to authenticate themselves prior to its opening. In zero-trust, the specific requirements for this authentication are liable to change, given a considerable number of different parameters. From whom was this email sent? To whom is the e-mail intended? Is the opener on their work laptop or personal smart phone? Is it being opened during normal work hours or after-hours? Has the network experienced any unusual traffic today? How often does this person open e-mails on this device at this time? Etc., etc..
Different situations are expected to yield different security requirements, really driving the old “check- box” approach to security into obsolescence. While it is up to the policy orchestrators to drink in the input data required for these considerations, it is up to the authentication scheme to enforce the policy’s requirements. Combined with the need for as seamless-as-possible usability identified above, zero-trust in the MFA regime is a particularly tall order. However, getting this part of the ZTA paradigm completed and absolutely correct in the first place will drive adoption of the other necessary architectural pieces in a much simpler and more streamlined manner.
The ZTA is a revolutionary idea in the domain of network architecture, but it represents a much needed pivot toward built-in cybersecurity. Migration to zero-trust, no matter your current industry, is an inevitability. Eliminating the idea of trust within the bounds of a network certainly is a tall order, but can be distilled into possibility by defining two core classes of zero-trust mechanics: policy orchestration and identity, authentication, and authorization.
While critically important, the industry writ large is still shaking out what suitable zero-trust policy orchestration looks and feels like, making this area a difficult place to begin your zero-trust migration. On the other side, identity, authentication, and authorization or things that can reworked today to drive you and your organization closer to a zero-trust model of security. “Identity” is largely up to the discretion of your organization’s needs – what parts and pieces of identifying information are absolutely critical to know when considering identity? This is a question best left to be answered in the context of your policies, practices, culture, and operations. Associated with these identities are the privileges they are entitled to – again, best considered in the context of your organization’s specific needs.
Authentication: the lynchpin for starting a zero trust migration
The last available topic and the one most independent of softer contexts is authentication. In zero-trust, we now know that authentication is multi-factored in nature and will likely be occurring exponentially more frequently than some traditional architectures are used to. Similarly, we know that the highest-end ability to disseminate privileges and/or define policy requirements isn’t any good without the ability to ruggedly enforce the security benchmarks needed to serve those critical features. Zero-trust migration is indeed an overwhelming landscape of problems to consider. By framing authentication as the lynchpin to these other fundamental components, we begin to see how these abstract zero-trust ideals can be bridged together. For all intents and purposes, authentication is the most natural starting place for transitioning your current ecosystem to one consistent with zero-trust.
Start migrating to ZTA with ZKX
ZKX has recognized this intuitive and streamlined approach to zero-trust migration and our flagship product is designed specifically to be your square-one for zero-trust. The ZKX MFA software is de facto multi-factored and specifically architected to serve as both a stepping stone and a critical lynchpin for your ZTA.
ZKX has an innately high degree of agnosticism compared to other more conventional MFA drivers. Characteristics like network structure, authorization stratification, policy requirements, thresholds of confidence of trust in a user, authentication artifact(s), and transport mechanism are of no consequence to the rigidly secure MFA that ZKX provides.
ZKX is imbued with key quality-of-life features to make the stringent operational requirements of zero-trust authentication a reality in your network. With its novel key recovery method, users are able to authenticate themselves with multiple factors by undertaking only a single authenticating transaction. After users are authenticated, ZKX also utilizes a novel session management scheme to constantly scrutinize the integrity of an authenticated user’s identity.
ZKX is vastly customizable and specially constructed to make dynamic policy enforcement simple. ZKX is a round-based authentication scheme, meaning that confidence in a user’s claimed identity is built iteratively. Furthermore, ZKX requires an individual user to be tied to a specific device or authenticating credential like a smart card. In the case of a device, this allows for an organization to consider the device a user is utilizing in an inherent fashion as they traverse the network and access its resources. For example – user M. Jones on their laptop can be considered separately and distinctly from the same M. Jones on their personal smart device.
Zero trust: it cuts both ways
There is one core feature of ZKX which makes it stand out from other MFA solutions, especially in the context of zero-trust networks. In the majority of this conversation (and the majority of all ZTA-focused pieces), we have been considering zero-trust as the luxury for the network to not have to place any implicit trust whatsoever in its users. However, this is slightly disingenuous, as true zero-trust extends also to the users – why should they have to place any inherent trust in the network and its architecture?
ZKX at its core is powered by zero-knowledge proofs (ZKPs) enabling users to utilize things like PINs, badge numbers, secret keys, etc., in their authenticating transactions without ever risking those credentials for exposure or capture. Similarly, ZKX is built off of public key cryptography, which, on top of already being ubiquitous in the concepts of modern network operations, prevents the storage of any secret or identifying user information on the network. If a network storage server is compromised, users that have their authentication driven by ZKX have nothing to fear, as the data their network stores for their online profiles are public and not inherently secretive. With ZKX, zero-trust means zero-trust – for both the organization and the users it serves.
Zero-trust is a daunting but necessary undertaking for all sectors of industry: commercial and government alike. Authentication is a natural place for you to begin investigating as you plan out your first steps into zero-trust migration. ZKX has been designed with these monstrous transitions in mind, aiming to make it as easy, intuitive, and seamless as possible.