Security is more important than ever, with cyber attacks hitting the news with what seems like clockwork. Organizations are getting more and more concerned that they will be next in the spotlight, so how can you help protect your organization?
One concept that has been picking up steam in the security community is zero trust. zero trust is a network architecture design based on the premise of assuming breach and never providing inherent trust.
Zero trust rethinks how we design networks. Traditional networks usually trust users and devices inside the network boundary. zero trust, on the other hand, always assumes breach so devices, communications and users aren’t inherently trusted just because they are in the network.
While implementing zero trust can be a costly and time-consuming endeavor for organizations with large and established networks, startups building their architecture from scratch, known as a greenfield approach, are prime candidates. This is because the network can be designed from the ground up to support zero trust principals. Established networks take more time and resources to migrate to a zero trust architecture due to the need to retire and migrate existing workloads and systems, while maintaining minimal impact to business operations.
Implementing zero trust involves multiple pieces working in tandem. The National Institute of Standards and Technology (NIST) outline the following tenets of Zero Trust Architecture in SP 800-207:
7 Tenants of Zero Trust Cybersecurity Architecture
- All data and computing services are considered resources.
- All connection is secured regardless of network location.
- Access to individual enterprise resources is on a per-session basis.
- Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset - and may include other behavioral and environmental attributes.
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
- The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.
While implementing any number of these seven tenets will increase your organization’s security posture, you’ll only realize the benefits of a zero trust architecture when you implement all seven effectively—in other words, zero trust is all or nothing.
1. All Data and Computing Services Are Considered Resources
Accurately classifying data, services and devices is key to the zero trust approach. Networks consist of many different types of devices, services and communications. It’s paramount to properly evaluate your resources as it’s easy to accidentally ignore some if you don’t complete a thorough scoping exercise.
Some examples of devices to identify include endpoints, servers, Internet of Things (IoT), Operational Technology (OT), network appliances (such as firewalls, intrusion detection and prevention systems, and email filters), file shares, Software as a Service (SaaS), cloud infrastructure, and even personally owned devices.
2. All Connection Is Secured Regardless of Network Location
Oftentimes, networks treat connection originating from within the corporate network differently from connection originating from outside the corporate network. However, a zero trust approach applies the same security controls independent of network location.
Even if the asset making the connection is within the network perimeter, the connection must use the most secure methods available and provide proper authentication, just as a connection from outside the perimeter would.
3. Access to Individual Enterprise Resources Is on a Per-Session Basis
Access requests must be granted trust on a per-session basis, especially when accessing different assets. Just because access to one asset was authenticated and authorized, does not imply authentication and authorization for another asset, or even the same asset but a different session.
We must evaluate requester trust before granting access to a resource, not after. In addition, access should be granted following the principle of least privileges, which limits the access to only the privileges needed to complete the required business task.
4. Access to Resources Is Determined by Dynamic Policy
Dynamic policy can be extremely powerful in controlling authentication and authorization. Using dynamic policy, access can be granted only after trust is gained from the requester and requesting resource. Some examples of criteria to use in dynamic policy includes location (IP or GPS based), device compliance (such as installed software, managed vs unmanaged, patches and updates, operating system, and device manufacturer), the type of user, the resource being requested, and user behavior.
5. The Enterprise Monitors and Measures the Integrity and Security Posture of All Owned and Associated Assets
While establishing trust before allowing access to resources is a step in the right direction, all assets should have their security posture actively monitored and improved. Apply patches to all owned assets in a timely manner and consider treating systems with known vulnerabilities differently from other resources.
6. All Resource Authentication and Authorization Are Dynamic and Strictly Enforced Before Access Is Allowed
Continuous monitoring, assessment and trust validation is key to making zero trust work. Define policies that determine the criteria for authentication and authorization of access requests. Implementing policies that require occasional re-authentication and re-authorization will help ensure these access attempts are legitimate. You should also be using multi-factor authentication for most, if not all, enterprise resources.
7. The Enterprise Collects Information to Improve Its Security Posture
Zero trust only works if organizations understand what’s in their network, where their sensitive data is, what communications are happening, etc. The security architecture uses this information to inform access requests and create a baseline to identify anomalous and potentially malicious access requests including authentication and authorization.
What Zero Trust Architecture Looks Like
Ask 100 people how to architect a zero trust network and you’ll get 100 different answers. Zero trust can look very different from organization to organization but it generally contains three components, that can be architected in different ways:
Components of Zero Trust
- Policy Engine
- Policy Administrator
- Policy Enforcement Point
The policy engine determines if access requests are granted or not. It does this by following defined organizational policy, as well as dynamic content such as the resource being requested, the requesting user, the requesting device’s compliance, user behavior analytics, and more. While the policy engine determines whether access is approved, denied, or revoked, it does not grant, deny, or revoke access. That function is passed to the policy administrator component.
The policy administrator starts or stops connections between the requester and the requested resource based on the decision passed to it by the policy engine. The policy administrator communicates with all policy enforcement points (more on that to come) and sends commands to them in order to control the connections made. It’s important to note that while a policy administrator is different from a policy engine, some architectures group these into a single component.
Zero trust is all or nothing.
Policy Enforcement Point
A policy enforcement point makes connections between requesters and resources, monitors the connection and shuts down the connection depending on the commands it receives from the policy administrator. A policy enforcement point acts like a gateway to the enterprise resources held behind it, referred to as the trust zone.
The architecture has additional systems factored into it to provide information that informs the dynamic policy systems outlined above. These can include continuous diagnostic and mitigation systems, industry compliance systems, threat intelligence feeds, network and system activity logs, data access policies, and security information and event management systems, among others.
Continuous Diagnostics and Mitigation Systems (CDM)
CDMs collect data on enterprise resources and update their configuration and software. A CDMs policy engine allows you to apply device state such as operating system, current version numbers, device make, installed software, and more to the Policy Engine’s decisions.
Industry Compliance Systems
Industry compliance systems help keep organizations aligned with their regulatory standards. Policies derived from this engine can help ensure that the Policy Engine’s decisions remain compliant.
Threat Intelligence Feeds
Threat intelligence feeds provide information on emerging threats in a variety of formats. Feeding this information to the Policy Engine can help it make access request decisions using data such as malicious IPs, malicious domains and software vulnerabilities. This can be even more useful when combined with the data from a CDM to determine which resources have new and emerging vulnerabilities.
Network and System Activity Logs
Activity logs from both the systems and network should be incorporated into the Policy Engine to understand the current security posture in real time. This allows the Policy Engine to make instantaneous decisions based on what’s happening in the network.
Data Access Policies
Data access policies are the foundation of determining what access is allowed, and what access is denied or requires additional trust to be provided. We define data access policies statically or dynamically, but ultimately the Policy Engine will make dynamic decisions on when to permit access.
Security Information and Event Management Systems (SIEM)
SIEM solutions allow for the centralization of log sources and support anomaly detection of those logs. Usually, an SIEM solution will provide alerts when it identifies certain events such as “impossible travel” when a user logs in from two different countries within a short time period. Implementing an SIEM solution into your dynamic access systems allows the Policy Engine to change its decisions based on security events occurring in the network. For example, if the SIEM solution detects multiple failed login attempts for a user, the Policy Engine may decide to require the requester to provide additional trust such as multi-factor authentication or a password reset, before allowing the user to access the resource.
Implementing zero trust in your network is not a light endeavor, and will require significant resources to design, implement and monitor. However, zero trust can greatly improve your security posture by reducing the impact of breached credentials and increasing the cost for attackers to target your network.
While implementing zero trust is a great goal, organizations should ensure they have built a solid security program first. Practicing basic cyber hygiene should be the first step towards securing your organization. Not sure where to start in this crazy world of security? I recommend taking a look at the Center for Internet Security (CIS) Controls framework, which is a great place to start.
* * *
Opinions expressed are solely my own and do not express the views or opinions of my employer.