Including Zero Trust in your Cybersecurity Strategy
By David Roggen and Matt Warner
As the world begins to move into a post-Corona phase, despite the recent Omicron wave, the business environment of the future is starting to emerge. We see increased cloud adoption, remote work, gig economy, etc., all of which mean cybersecurity best practices must evolve to address new vulnerabilities that will arise. There will be a variety of new and hybrid data-sharing models in the emerging environment. For example, micro-segmentation allows various people from various settings to access data that will be “sealed off” from the rest of the world
As business models continue to evolve, it is critical to develop an approach to security that goes beyond protecting the traditional network perimeter. Zero Trust Architecture (ZTA) is an approach to security that focuses on the resource/assets rather than the perimeter of the enterprise. ZTA is defined by NIST (National Institute of Standards and Technology) as
“the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
Zero Trust seeks to secure data at the most granular level possible, at the site where the resource is consumed.
Zero Trust is still evolving, with many organizations, including NSA, NIST, ACT-IAC, Google, Microsoft, Amazon Web Services (AWS), and others, contributing to the literature and understanding of this critical cybersecurity concept. Zero Trust contributes to the elimination of common attacks such as malware. Today, if malware breaches a perimeter, it has the potential to move relatively easily throughout the environment. Zero Trust requires every interaction with internal resources that the malware attempts to be separately authenticated. Breaching the perimeter does not grant freedom of movement.
Zero Trust advocates mutual, multi-attribute authentication, including validating the identity and integrity of subjects (e.g. requestors such as people and systems) irrespective of location and providing access to objects (e.g., assets, services, workflows, network accounts, etc.) based on the total trust level of the requestor. In a Zero Trust environment, no request should be trusted by default, even if the requestor is connected to a managed network such as the corporate LAN, and even if they were previously verified by some other service. Zero Trust works on the principle that subjects are provided with only sufficient permission to perform the required action (Just Enough Access), only at the point-in-time it is needed (Just-In-Time), and only for a limited period of time (ephemeral credentials).
Tenets of Zero Trust
It is essential to understand that Zero Trust is not a prescriptive technology or strategy but rather an approach that provides additional tools and methods to enhance overall cybersecurity. Zero Trust should be additive and advocates a comprehensive approach. All data sources and computing resources are classified as resources. NIST provides seven high-level tenets as guidance to a Zero Trust approach:
NIST-Zero Trust Tenets
1. “All data sources and computing services are considered resources.” This includes all classes of devices, including such things as BYOD.
2. “All communication is secured regardless of network location” There is no implied authorization to an object based solely on the location within the network. There is no automatic access based on location. All communications are encrypted.
3. “Access to individual enterprise resources is granted on a per-session basis” Access is provided in alignment with the principles of least privilege access, including “Just Enough” and “Just-In-Time” access.
4. “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” Access is not dependent solely on username and password but is also dependent on the attributes associated with the request. These behavioral and environmental attributes can include software versions installed, network location, time/date of request, differences from previously observed activity, etc.
5. “The enterprise monitors and measures the integrity and security posture of all owned and associated assets” Unlike traditional perimeter security, there is no inherent trust of any asset. All resources should continuously be monitored and managed, including providing patches/fixes as needed.
6. “All resource authentication and authorization are dynamic and strictly enforced before access is allowed. “ Continuously monitor and reevaluation of trust, including reauthentication and reauthorization as needed.
7. “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.” The more information collected, the more context a system has when deciding to authorize a request.
Traditional vs. Zero Trust
Once access is provided in a traditional Internet-Facing Environment, it enables lateral movement across. In the example below the User is able to escalate privileges and move from resource A to resource B because resource B is configured to simply respond to HTTP requests.
Traditional internet-facing environment
· The User (aka the bad actor) accesses Resource A (normal and allowed) but escalates their privileges.They then opens an unexpected HTTP session to Resource B
· Resource A has no public IP and is not expected to take Internet traffic directly. It responds to all HTTP requests because it implicitly trusts everything on the internal network and assumes all traffic it sees originates internally
· B uses the same access policies for all requests. It does not assume a restricted role based on the type of requestor but uses the same privileges for all request types.
· B has no idea A has been compromised
· Resource C makes HTTP requests to Resource B as expected
A Zero Trust environment does not allow for lateral movement. Resource A is not allowed to connect to resource B by security groups, but even Resource C must supply authentication for each request.’
Zero Trust Environment
· The User (aka the bad actor) accesses Resource A (normal and allowed) but escalates his privileges. He then attempts to open an unexpected HTTP session to Resource B
· Resource B requires time-limited, signed access tokens for all HTTP requests, regardless of source
· Resource C’s Token’s signature is validated
· Token’s payload contains access policy references
· Resource B uses a corresponding scoped-down policy to perform an action for validated requests from Resource C
· B also refuses connections from any location/host not explicitly listed (e.g., not in the security group)
· Resource C makes HTTP requests to Resource B only after obtaining an access token
By requiring reauthorization every time the user attempts to access a resource, the ability for insiders or malware to move throughout an environment is limited. Best practices demand that enterprises no longer put faith in only their security perimeter but rather focus on the authorization of any interaction between the subject/user and the resources/object.
Getting Started with Zero Trust
Zero Trust is a model to approach cybersecurity. Since it is not a method or technology, it is often difficult to find a way to begin. Below are a few ways to start your Zero Trust Journey:
· Read the NIST Special Publication 800–207 Zero Trust Architecture. It provides an excellent primer for understanding Zero Trust. This publication is general and can be understood by technologists and non-technologists alike.
· Explore the Zero Trust capabilities of your cloud provider (e.g. Azure, Google Cloud, and AWS. As an example, AWS Zero Trust-related capabilities include:
AWS SigV4 request signing process
AWS Identity and Access Management (IAM)
Amazon API Gateway | API Management | Amazon Web Services
· Assess your environment against the goal of Just in Time and Just Enough.
Do team members have access to data they don’t need to access (minimum required)?
Are team members given blanket access to data sources?
Are short-lived, temporary access credentials used?
· Perform data prioritization exercises to identify initial candidates for Zero Trust strategies
To which regulations are you subject (e.g. GDPR, HIPAA, CCPA)?
What industry standards are you responsible to maintain (PCI_DSS)?
Though Zero Trust has received a great deal of attention lately as a strategic approach to security, the technical capabilities for Zero Trust exist today and are part of best practices for Identity and Access Management, Network Access Control, and Privileged Access Management. Zero Trust brings these concepts together. Zero Trust is an additional lense to security that drives stakeholders to focus on securing their most critical resources rather than securing the perimeter. As business models, and their associated data, become more decentralized, the need for Zero Trust will grow. You can never start too soon to plan out your Zero Trust strategy and how it fits into your overall cybersecurity strategy.
David Roggen builds operations and processes for emerging technologies. David has worked with private enterprises, government agencies, and non-profits to facilitate their development and adoption of cutting-edge capabilities.
Matt Warner figures out how to make Cloud technologies do what the business needs. He’s done work for Fortune 50 companies as well as small startups and is especially passionate about challenging business-as-usual thinking.
