Editor’s note: Element #1 of the Seven Elements of Highly Successful Zero Trust Architecture verifies identity, which requires determining who is making the connection.
Common security wisdom states that “nothing, absolutely nothing, should ever implicitly happen.” No person or thing should be allowed to access or view anything, not even the front door of the building, without first being verified and their access rights assessed.
In other words, the requester must always be verified before access is granted. Each requester should be treated individually and only granted access to what their identity allows. It’s this initial identity verification that determines if a requester is able to proceed farther down the zero trust path.
Today, at least outside of the enterprise context, identity is a mechanism of individualization. Within the enterprise, however, employees are identified not only by who they are but also by the groups into which they fit. This alignment of identity and identity-based access led the computing industry to the revolutionary idea of least privilege–individuals should be granted access to specific resources based on their role’s specific needs.
Zero trust architecture is designed so that access is completely blocked until explicitly allowed. This differs from most traditional environments where network access was implicitly granted and managed via antiquated network controls. When an initiator presents the correct identity, then access may be granted only to the specific set of allowed services and nothing more. This “never trust, always verify” approach is the underpinning of zero trust architecture.
Therefore, it is imperative enterprises ensure correct integration with a trusted IdP provider. The requesting entity’s identity and profile are considered based on granular policy implemented in the policy enforcement stage (the last element of zero trust architecture).
For example:
A verified user with the correct profile values
- would need access to SAP;
- would not need access to an IoT sensor; and
- could need access to YouTube.
Whereas a verified IoT/OT device with correct profile values
- would need access to an IoT engine; and
- would not need access to YouTube.
In addition, a verified workload
- would need to access a comparable workload; and
- could need access to the internet.
In this simplified example, access policies can be ascertained solely by differentiating the type of initiator. Subsequently, identity can be further assessed and enriched with context, e.g., a valid user logging in from a company device, to deliver a more complete statement of identity (What is the access context?). At this point, authentication moves from simply a contextual yes/no into an authorization stage, where values related to the authenticated identity such as role, responsibility, location, etc., can be used to further validate the initiator.
By combining these values, identity control becomes quite powerful and each identity should be unique at the moment of authorization (re-assessment will be discussed in Element 4 with dynamic risk scoring).
Technology and architecture considerations
A large hurdle enterprises face when getting started with zero trust is technical debt or environmental complexity. An enterprise may have laudable goals, but when it comes time to execute, these factors can obscure the starting point.
Luckily, most organizations already have the baseline technology in place to begin this journey in the form of an IdP with the context of an enterprise IAM.
By reviewing the types of users and role definitions within an IdP platform, IT admins can create an initial sketch of different roles within an organization. This is not to say that a zero trust identity is solely a value delivered by an IdP. As the illustration below shows, identity should consider multiple values by both asking who the entity is and also evaluating the profile of the entity. Nevertheless, an IdP platform should be every enterprise’s first step along the zero trust journey. After all, with least privilege, nothing happens without validating identity.
This element of the zero trust process is dependent on the functionality of the IdP, including how identity is determined, managed, organized, and updated. As such, the level of identity differentiation will be unique to each company and should commonly be tied to roles as defined by HR.
For workloads and IoT/OT devices, architecting identity verification is quite different and varies widely depending on the deployments. The basic level of categorization will come from the underlying architecture, e.g., “Manufacturing Site A” and “Machine A.” Additionally, each workload and/or IoT/OT service has a unique set of communication methods, such as destination application requests, unique headers, or other content, as part of the traffic flow that allow for device classification.
Workload and IoT/OT identity verification using site architecture is generally based on network settings and defined trust zones within a network. In other words, “Manufacturing Site A” will have different trust settings than “Manufacturing Site B.”
Further granular identity assessments are possible depending on the tools and machines in use. However, it’s best for enterprises to begin categorization with data and risk classification systems unique to each company.
Zero trust progress report
At the conclusion of identity validation, the zero trust process will submit the following values for risk assessment, inspection, and ultimately enforcement.
Download the Seven Elements of Highly Successful Zero Trust Architecture eBook and stay tuned for more installments of our accompanying commentary.