This article is part of our series on Zero Trust. For more information on Zero Trust, check out Zero Trust, Explained.
Zero Trust security is a powerful paradigm that can help protect resources against malicious attacks, even if the attacker has access to the corporate network. A Zero Trust administrator needs to make two key decisions for the resources that are being protected: how to authenticate an access, and how to authorize an access.
Authentication, or AuthN, refers to checking the identity of users, devices, and software. It attempts to answer the question, "are you really who you claim to be?"
Authorization, or AuthZ, refers to checking the access against some predetermined access policy. It attempts to answer the question, "are you allowed to take this action?"
At the airport, you must show government-issued identification (AuthN) and a boarding pass (AuthZ) before you are allowed to board a plane. Cybersecurity is no different - these two must be tightly integrated to enforce a Zero Trust policy.
Authentication
Users, devices, and software all different authentication methods.
Users are generally easy to identify, as there is nothing new about the concept of a user account. In fact, many companies have adopted identity and access management (IAM) systems to manage users and their identities. Examples of common IAM systems include Microsoft's Active Directory or Okta.
IAM systems should be configured to verify a user with multiple factors of authentication (MFA) - for example, something the user knows (a password or passphrase) and something the user possesses (a smartphone, or a hardware token). The purpose of MFA is to reduce the risk from compromised credentials; hackers may crack a password, but may give up if they also need to answer a biometric challenge. Credential theft has been such an issue that IAM vendors have even introduced passwordless authentication schemes that avoid passwords entirely.
Zero Trust solutions can typically leverage a company's existing IAM system. CoIP Platform, for example, integrates using standard protocols - SAML 2.0, OAuth, and LDAP to name a few - that allow a user to authenticate with MFA and leverage SSO.
However, IAM may not always be the right way to identify a user. For example, a batch job or non-interactive process on one machine may need to access a resource protected by Zero Trust. In these cases, it may be more relevant to identify the process owner or group, rather than tie the identity to a human. In these cases, CoIP Platform directly collects the necessary information and uses it as part of the authorization decision before granting access.
Device identity is also very important to Zero Trust; being able to uniquely map a user to a specific client allows the Zero Trust system to differentiate between accesses from a company-issued and BYOD/public terminals. This gives administrators the power to decide when a resource is too sensitive to be accessed from just any device.
Identifying a device typically involves building a device fingerprint. A fingerprint may include factors such as the hostname, OS, CPU/memory configuration, MAC addresses, and cryptographic certificates.
CoIP Platform combines the device identity with other attributes, such as the device's location, or whether endpoint security software is installed and active. This allows administrators to determine their risk tolerance in allowing access from that type of device.
Finally, software is authenticated by cryptographic digital signatures. This may be further augmented with context about how the software was called, as well as the network ports and protocols that the client needs, to ensure that only reputable software clients are used in the right way to access the Zero Trust-protected resource.
CoIP Platform's zLink sensor identifies software without using deep-packet inspection (DPI). While DPI remains a popular network-based method for software/application identification, DPI is extremely expensive and slow, and is not practical for pervasive identification throughout the organization. zLink is able to detect the source and destination application for all application flows, gathering the aforementioned attributes to be used in the authorization step.
Authorization
Authorization involves evaluating the identity attributes gathered in the authentication step against an access policy that govern access to a resource: who can access what, from where, and how.
Plain English examples of such policy statements might include:
"User Alice, verified by Okta with MFA and using her BYOD laptop, can access the ERP web portal using a browser on TCP port 443."
"Users in the 'ERP Admin' group, verified by Okta with a hardware token, using a company laptop with endpoint protection, and when in the continental United States, can access the ERP servers and databases using Secure Shell (ssh)."
"The Jenkins pipeline, running on servers in AWS us-west-1 as group jenkins, can pull from the internal git repository using ssh (TCP port 22), but command-line ssh is blocked."
"User Bob, verified by Active Directory and MFA, can access a secure developer environment using RDP, when copy/paste and file transfer functions are disabled."
The authorization step requires a policy engine that can compare the attributes against the programmed policy and ultimately decision whether or not to grant the access. In NIST 800-207, this engine is called the Policy Decision Point (PDP).
The policy engine must also continuously verify those attributes so that changes can result in revocation of access or a step-up in authentication.
CoIP Platform's zCenter is a powerful Zero Trust policy engine that supports flexible policies that use logical operators to combine attributes. This enables policies to be made as granular or as coarse as necessary to describe the desired policy.
Share this article
