As more companies migrate to the cloud, the way that companies protect data changes as well. In a traditional on-premises network architecture, companies were able to follow the “trust but verify” philosophy. However, protecting cloud data needs to take the “never trust always verify” approach. Understanding what a Zero Trust Architecture is and how to implement one can help enhance security.
What is Zero Trust?
The zero trust cybersecurity model requires that all users, devices, and applications connected to the organization’s network are continuously authenticated, authorized, and monitored to ensure appropriate configurations and posture before granting them access to networks and data, regardless of whether they are on-site or remote.
In traditional on-premises network architectures, users and devices connecting to networks were considered “trusted” because you could limit their activity using hardwired connections and firewalls. However, with the rise of wireless networks, the concept of trust eroded. Zero trust is a way that companies can reduce risk by continuously requiring authentication and authorization.
What are the basic principles of Zero Trust?
Zero Trust means what it says and says what it means. Trust no one. According to the National Institute of Standards and Technology Special Publication (NIST SP) 800-207, the basic principles of a Zero Trust enterprise cybersecurity architecture include:
- Assuming breach
- Assuming enterprise-owned environment is no different or more trustworthy than non-enterprise-owned environment
- Continuously analyzing and evaluating risk
- Continuously enacting risk mitigation protections
- Minimizing user and asset access to resources
- Continually authenticating and authorizing identity and security for each access request
What are the different approaches to Zero Trust Architecture?
As with everything in cybersecurity, no “one size fits all” approach to zero trust exists. Although three different variations on the zero trust theme exist, many companies choose to take a “mix and match” approach across all three.
Enhanced identity governance
Identity governance is the process of managing the identity lifecycle from the time you first grant a user or entity access to systems, networks, and software until you terminate that access.
As a best practice, you should limit access according to the principle of least privilege, providing the least amount of access necessary for a person, device, or software to complete its job function. Additionally, you should consider incorporating the following as additional attributes when considering permissions:
- Network location
- Device used
- Resource risk
Enhanced identity governance includes restricting network access according to the principle of least privilege and requiring multi-factor authentication (MFA).
Micro-segmentation is the process of protecting resources, either in groups or individually, by placing them on a unique network segment using a switch, firewall, or another gateway device.
Although this approach incorporates identity governance, it also relies on network devices to prevent unauthorized access. When using micro-segmentation to protect data, organizations need to ensure that the devices can respond to threats or changes in workflow.
Network infrastructure and software-defined perimeters
Often referred to as a software-defined perimeter, this approach often uses technologies like Software-Defined Networks (SDN) and intent-based networking (IBN). Under this approach, the organization deploys a gateway at the application layer that establishes a secure channel between the user and resource.
What is the difference between Zero Trust Access (ZTA) and Zero Trust Network Architecture (ZTNA)?
When discussing zero trust, people often toss around the terms ZTA and ZTNA. The two both enable zero trust but do it differently.
Zero trust access (ZTA)
ZTA relies on the organization’s Identity and Access Management (IAM) policies, often requiring MFA as a way to verify that they are who they say they are. Additionally, ZTA usually includes maintaining a continuous inventory of devices and users connecting to the network while continuously scanning for new access.
Zero trust network architecture (ZTNA)
While ZTA focuses on who and what connects to a network, ZTNA focuses on who and what can connect to applications located on the network. ZTNA places the applications behind a gate called a “proxy point,” creating a secure, encrypted tunnel that data travels across. This makes it easier to secure remote users and entities without having to use a VPN.
Five use cases for zero trust
If you’re considering whether zero trust is appropriate for your organization, the following use cases might make it easier for you to understand how it would fit into your current IT landscape.
1. Enterprise satellites
Often, organizations have a headquarters with remote offices or employees. Since the remote locations, home or building, don’t connect to the enterprise local network, a company might decide to create a portal for users who need access to resources.
2. Multi-cloud architecture
Increasingly, organizations use more than one cloud services provider, hosting multiple applications across the different clouds. A zero trust approach enables better security for both Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) by requiring users and entities to access the resources through a portal or installed agency. This gives the company more control over how users gain access to the cloud resource and ensures better visibility into cloud security.
3. Managing third-party, non-employee access
To mitigate the risks associated with outsiders accessing enterprise resources, zero trust can be used to create a portal for those who need network connectivity to perform their tasks. Using zero trust enables you to offer access while obscuring enterprise resources.
4. Across enterprise boundaries
Many enterprise organizations have different databases used by various subsidiaries. Creating multiple accounts for users who need access to more than one database across the subsidiary lines becomes overwhelming.
For example, an enterprise might have Sub 1 and Sub 2 with Database A and Database B. Both Sub 1 and Sub 2 use Database A, but only Sub 2 needs access to Database B. Creating unique logins for each database increases credential theft risk. In this case, zero trust provides the same benefit as remote employees and offices.
5. Customer-facing services
In some cases, companies offer customer services that require user registration. In this case, the organization needs to protect both internal assets and customer information. Zero trust enables enhanced security when organizations can segregate these customer services from enterprise services and use portals that drive customers to the resources they need.
Understanding the risk considerations for Zero Trust
While zero trust enables organizations to better secure data, it also comes with its own set of risks.
Any software or hardware component used must be securely configured and maintained. This can include monitoring for new risks arising from:
- Hardware vulnerabilities
- Software vulnerabilities
- Credential theft
Denial-of-Service (DoS) attack or network outage
All of the technologies that enable a Zero Trust Architecture rely on network connectivity. A network outage, either as part of a DoS attack or cloud service provider downtime, can undermine the core technologies protecting the digital assets. Additionally, unexpected heavy usage can lead to slower service that leads to business disruption. Any of these scenarios can lead to users being unable to access resources. This means that employees or customers may not be able to connect to resources, decreasing productivity or interrupting customer services.
Stolen credentials/insider threat
No matter what deployment method you choose, zero trust relies entirely on authenticating users and entities to networks or applications. Stolen credentials or a malicious insider can undermine your zero trust goals.
To mitigate this risk, you should consider:
- Assigning additional attributes to access controls, including geolocation and IP address
- MFA to mitigate the use of stolen credentials
- User and entity behavior analytics (UEBA) to determine abnormal behaviors indicating malicious resource use
- Network segmentation to prevent lateral movement
9 Steps to a Zero Trust Architecture
While establishing a Zero Trust Architecture can enhance security, many organizations find the implementation challenging. Understanding the steps involved can help move toward a zero trust security approach.
Taking a rip-and-replace approach is not the most likely path, but some organizations can do it. This approach requires:
- Knowing all applications/services
- Understanding all workflows
- Deciding on the technologies to use
- Mapping how the technologies interact
- Building the infrastructure
- Configuring all technologies
It’s more likely that you already have a network infrastructure in place. Ultimately, this means taking a perimeter-based approach which requires engaging in the following 8 steps.
1. Identify users who need network access
The first step is understanding who needs access to your digital resources. However, you also need to do more than just get a list of employees. When identifying users, you need to consider:
- Third-party contractors
- Service accounts
- Robotic process automations (RPAs/bots)
- Serverless functions
Additionally, you need to consider users with privileged access, including:
- System administrators
2. Identify the devices that need network access
Zero trust also tracks all devices that connect to your network. The increased use of Internet of Things (IoT) devices has made identifying and cataloging devices more challenging.
When creating the asset catalog, you should include:
- Workstations (laptops/desktops)
- IoT devices (printers, smart security cameras)
As part of a zero trust architecture, you need to maintain secure configurations for all of these devices.
3. Identify the digital artifacts that need network access
Increasingly, applications and other non-tangible, digital artifacts require network access. As you build out your list, you should consider:
- User accounts
- Digital certificates
Another challenge here is shadow IT, technologies connecting to the network that your IT team may not know about. As part of your zero trust migration, you want to engage in a network scan to ensure you know all access points.
4. Identify key processes
Once you know all the applications your company uses, you need to define the ones most critical to your operations. These key business processes help you set resource access policies.
Low-risk processes are often good candidates for the first round of migration because moving them won’t cause critical business downtime.
Meanwhile, cloud-based critical resources are good candidates overall because placing controls around them protect sensitive data and services. When putting the controls around these processes, however, you should engage in a cost-benefit analysis that includes:
- User experience
- Impact to workflows
5. Establish policies
With all users, technologies, and key business processes identified, you now start establishing policies.
For each asset or workflow, you need to identify:
- Upstream resources (things that flow into the current asset, like ID management, systems, databases)
- Downstream resources (things that flow out of the current asset, like event logs)
- Entities (connections to the asset, like users and services accounts)
6. Identify solutions
The solution you choose should be based on the previous steps because different tools enable different business goals. According to NIST, the primary questions you should ask yourself when making the decision are:
- Does the solution require that components be installed on the client asset?
- Does the solution work where the business process resources exist entirely on enterprise premises?
- Does the solution provide a means to log interactions for analysis?
- Does the solution provide broad support for different applications, services, and protocols?
- Does the solution require changes to subject behavior?
7. Deploy solution
Deploying your solution should be done in stages to mitigate business interruption risk. This first stage should consider:
- Initially operating in observation and monitoring mode
- Ensuring that all privileged user accounts have access
- Ensuring that all privileged user account access is appropriately limited
- Reviewing access to make sure no one has more access than they need
8. Monitor controls
Once you know that everything works as intended for the first round of migrated processes, you should engage in a period of monitoring. During this time, you want to make sure you set baselines for activities like:
- Asset and resource access requests
- Communication patterns
Moreover, you want to monitor basic policy functionality lik:
- Denying requests that fail MFA
- Denying requests from known attacker controlled or subverted IP addresses
- Granting access for most other requests
- Ensuring that all necessary logs are generated
9. Expand Zero Trust Architecture
With the first phase of migration complete, you now have baselines and logging that should give you confidence over workflows and monitoring. However, each phase of the rollout should follow a similar process where you implement, review, monitor, set baselines, and ensure documentation.
SecurityScorecard: Continuous environment scanning and monitoring
SecurityScorecard’s security ratings platform enables organizations to continuously scan their environment for new risks. Our platform scans all IP addresses, giving you visibility into all access points, including IoT devices. Our security ratings use an A-F system that gives you at-a-glance visibility into risk, and our prioritized alerts incorporate remediation steps you can take to enhance your security posture.