The world changed significantly over the last year. The pandemic forcefully launched many organizations into a proof-of-concept for remote work that some were not prepared for. With this change in the way we are all operating, the concept of zero trust is now making a strong resurgence in conversations around security architecture.
What is Zero Trust?
Zero trust is a security architecture concept that helps organizations respond to the disintegrating network perimeter. In a non-zero trust architecture, it was previously assumed that most assets (e.g., users, devices, and services) are safe by way of location – inside your network. While that was never really a secure way of operating, it became even more apparent when organizations started using applications outside of their network via Software-as-a-Service (SaaS) solutions where internal network security defenses didn’t follow assets outside of the network. In addition to SaaS solutions, users are now more mobile than ever – they are using 4G/5G hotspots, coffee shop Wi-Fi, VPN tunnels, laptops, smartphones, tablets, and more.
The idea behind zero trust is that the network, any network, is hostile. Another term that goes hand-in-hand with zero trust is “assume breach,” where it is assumed that the network, devices, users, and services have been compromised. When you can’t trust anyone, organizations must follow the core tenet of zero trust – “never trust, always verify.”
Principles of Zero Trust
1. Understand your architecture – users, devices, services, applications, and data
Understanding what users are doing, what devices exist in your environment, how services/applications interact with each other, and where data is flowing is more important than ever in a zero trust architecture. Understanding your organization’s current environment will allow you to determine what approach for security architecture works best for you. Zero trust may not work for every service, application, or device, especially legacy devices and services. In addition, zero trust may not be appropriate given the risk mitigation costs associated with implementing this architecture.
Action items for principle 1:
- Complete an asset inventory of all users, devices, services, applications, and data.
- Conduct a risk assessment to better understand the degree of mitigation required for a given asset in comparison to its criticality in your environment.
2. Understand your user, service, and device identities
As the title indicates, with zero trust, we are doing away with trust being at the network perimeter and adopting identity as the new trust perimeter – if we can’t identify it, we don’t trust it.
Identifying users begins with implementing a single identity service to create accounts linked to individuals. When created, each of these identities should follow the concept of least privilege. With least privilege implemented, a user is only provided access to what they require to carry out the responsibilities of their role within your organization and nothing more.
Service accounts, keys, tokens, etc., should also be created under a single directory with least privilege enforced.
Every device in your organization should be cataloged and individually identified within an identity service directory or another device directory.
Action items for principle 2:
- Find a robust identity service that can do the following:
- Create roles and groups
- Support strong modern authentication methods including multi-factor
- Securely provision credentials to users
- Authenticate to services via common authentication methods such as SAML, OAuth, etc.
- Manage user identities in external services
- Support the full user lifecycle (provisioning, moving, disabling, terminating)
- Support third-party identity federation
- Services such as Azure Active Directory, Okta, IBM, etc., fit this bill.
- Plan the migration from traditional directory services to an identity service capable of all the above points. The migration will likely need to be carefully planned and phased to ensure that all entities are imported, synchronized, or federated correctly.
- Consider external users and how they will be handled within the identity service. Again, the services listed above have features for external users.
- Do not impersonate users.
- Let the user control if and when a service will be allowed to act on their behalf. Strong identification is undone when services are taking actions that users are unaware of. This will also provide non-repudiation because artifacts of the user authorizing actions should be created during the authorization process.
- Where possible, increase the authentication steps required of a service. An example would be requiring mutual authentication via TLS certificates of assets that make up a service so that client and server relationships are authenticated in both directions.
- Determine device identity through the implementation of cryptographic technologies.
- Tools such as a Trusted Platform Modules (hardware) or Duo Trusted Endpoints (software – certificates) can be used to authenticate device identity.
3. Continuously assess user behavior, and device and service health
Monitoring for the signs that trust has been or should be lost goes a long way to revoking authentication or authorization quickly.
For example, when a user attempts to access services from a different geographic location than they did five minutes ago, your architecture should require re-authentication of all connections or deny access altogether.
Action items for principle 3:
- Implement device health monitoring and enforcement through the use of a compliance tool or mobile device management solution. Granular rules for anti-virus requirements, up-to-date patches, geographic locations, etc., can be utilized to authorize or deny access.
- Microsoft Intune, Duo’s Device Trust and Adaptive Policies, and Okta Devices are examples of services that can be used to monitor and enforce device health checks.
- Service health can be monitored through various metrics specific to the given service. Unexpected changes in service metrics may indicate unauthorized change or malicious activity, which can be monitored via Security Information and Event Management (SIEM) tool. In addition, keeping the service up to date by patching at the earliest opportunity is extremely important to preventing service abuse.
- AlienVault SIEM, IBM SIEM, Splunk, etc., are great options for continuous monitoring of service health.
- Within the identity service chosen, define granular rules for user behavior based on what is expected of a typical user session. Examples of policies might include time of day restrictions, geolocation restrictions, device identification restrictions for specific services, etc. In addition to granular rules, implementation of multi-factor authentication can go a long way to ensuring user health is maintained.
- Duo Push, Okta Verify with Push, Azure MFA are great solutions for multi-factor authentication.
4. Make use of policies to authorize requests
If you haven’t caught it yet, the power of a zero trust architecture comes from the strength of your policies. Each request for data or service should be authorized against a well-defined policy. Always prefer products and protocols that support continuous authentication and authorization processes.
Action items for principle 4:
- Within authentication and authorization policies for a given device, service, application, etc., make use of granular policy options for expected behavior as mentioned above.
- Consider how your policies will handle the following two issues:
- Access denied – don’t provide overly verbose errors to the user. An attacker may use these errors to determine how the policies are configured and discover a way to bypass them.
- Break glass – When an emergency arises, there should be a process in place that allows users to establish connections even when the policy’s requirements can’t be satisfied.
5. Utilize Authentication and Authorization Everywhere
When we are assuming that all potential connections are hostile, we have to authenticate and authorize each and every connection as if it might be malicious. Striking the balance between utility and frustration is the paramount concern with this principle. No one wants to be asked for their username, password, and MFA code every five minutes nor should they have to.
Action items for principle 5:
- Determine the policy signals (e.g., geolocation, time of day, etc.) that are appropriate for the given asset to make authentication and authorization decisions.
- More critical = more signal input = more authentication steps. Less critical = less signal input = less authentication steps.
- Implementing a Single Sign-on (SSO) solution.
- SSO is the simplest method for mitigating the frustrations that can come along with continuous re-authentication and authorization. Provide the user the strongest authentication and authorization that would be required by your most critical service right from the get-go and let the other services benefit from that strength through SSO.
- Consider password-less authentication where supported.
- Password-less authentication via FIDO2 is an ideal solution that provides security and a wonderful user experience. With FIDO2, a user inserts a token such as a Yubikey into their device which handles authentication for them.
6. Focus your monitoring capabilities on users, devices, and services
With users, devices, and services outside of your traditional network perimeter, your organization should focus on the actions those users, devices, and services are performing. Through granular and adaptive policies and monitoring, a strong zero trust architecture should be able to adapt authentication and authorization dynamically based on the confidence level provided by the signals from the user, device, and/or service.
Action items for principle 6:
- Implement strong device security.
- Utilize strong configuration baselines such as those provided by the Centers for Internet Security (CIS). The CIS benchmarks for operating systems provide a great starting point to securing a device’s configuration.
- Utilize a strong endpoint protection tool. A device that can’t protect itself can’t provide you with the confidence to make decisions about its health.
- Endpoint Detection and Response or “Next-gen Anti-Virus” are great solutions for this problem. SentinelOne, Cylance, CarbonBlack, and CrowdStrike are all great options.
- Implement network monitoring.
- Even though we are assuming the network is compromised and hostile, that doesn’t mean we don’t want to know what is happening on the network. Implementing IDS/IPS, SIEM, a next-gen firewall, rogue device detection, network access control, etc., is important to understand your network’s health and potential threats to your assets.
7. Adopt services designed with zero-trust in mind
Many older technologies don’t support the concept of an untrusted or hostile network. While there are many workarounds for those older technologies, organizations should look for technologies that assume a zero trust architecture as their system lifecycle continues.
Action item for principle 7:
- Look for technologies that comply with popular standards. An example would be adopting a technology that can accept common authentication and authorization standards such as OpenID Connect, OAuth, or SAML to allow your organization to use a single identity service for authentication.
Summary
Zero trust is not a one size fits all solution and cannot be implemented by purchasing one product that does it all. Zero trust is a concept your organization must adopt as it continues to move into the modern age of the mobile workforce. Remember when considering how you will implement or migrate your next IT project to ask, “how will our organization, ‘never trust, always verify,’ the users, devices, services, and other applications that will be interacting with this project?” Let that question guide your efforts.
If you have any questions, comments, or would like to know more about zero trust concepts and how they apply to your organization, please let us know.