Zero Trust has managed to both inspire and confuse the cybersecurity industry at the same time. A significant reason for the confusion is that Zero Trust isn’t a specific technology, but a security strategy (and arguably the first formal strategy, as I recently heard Dr. Chase Cunningham, Principal Analyst at Forrester, aptly point out).
Microsoft believes that the Zero Trust strategy should be woven throughout your organization’s architectures, technology selections, operational processes, as well as the throughout the culture of your organization and mindset of your people.
Zero Trust will build on many of your existing security investments, so you may already have made progress on this journey. Microsoft is publishing learnings and guidance from many perspectives to help organizations understand, anticipate, and manage the implications of this new strategy. This guidance will continue to grow as we learn more. A few highlights include:
In previous posts of this series, we described Microsoft’s vision for an optimal Zero Trust model and the journey of our own IT organization from a classic enterprise security to Zero Trust. Today, we focus on what a good strategy looks like and recommended prioritization (with a bit of history for context).
Zero Trust security continuously validates trustworthiness of each entity in your enterprise (identities, applications and services, devices) starting each with a trust level of zero.
Evolution of security strategy
The central challenge of cybersecurity is that the IT environment we defend is highly complex, leading security departments (often with limited budgets/resources) to find efficient ways to mitigate risk of advanced, intelligent, and continuously evolving attackers.
Most enterprises started with the use of a “trusted enterprise network,” but have since found fundamental limitations of that broad trust approach. This creates a natural pressure to remove the “shortcut” of a trusted enterprise network and do the hard work of measuring and acting on the trustworthiness of each entity.
Network or identity? Both (and more)!
The earliest coherent descriptions of the Zero Trust idea can be traced to proposals in the wake of the major wave of cybersecurity attacks. Beginning in the early 2000s, businesses and IT organizations were rocked by worms like ILOVEYOU, Nimda, and SQL Slammer. While painful, these experiences were a catalyst for positive security initiatives like Microsoft’s Security Development Lifecycle (SDL) and began serious discussions on improving computer security. The strategy discussions during this timeframe formed into two main schools of thought—network and identity:
- Network—This school of thought doubled down on using network controls for security by creating smaller network segments and measuring trust of devices before network controls allow access to resources. While promising, this approach was highly complex and saw limited uptake outside a few bright spots like Google’s BeyondCorp.
- Identity—Another approach, advocated by the Jericho Forum, pushed to move away from network security controls entirely with a “de-perimeterisation” approach. This approach was largely beyond the reach of technology available at the time but planted important seeds for the Zero Trust of today.
Microsoft ultimately recommends an approach that includes both schools of thought that leverage the transformation of the cloud to mitigate risk spanning the modern assets and (multiple generations of) legacy technology in most enterprises.
Prioritizing and planning Zero Trust
Microsoft recommends rigorous prioritization of Zero Trust efforts to maximize security return on investment (ROI). This default prioritization is based on learnings from our experience, our customers, and others in the industry.
- Align strategies and teams—Your first priority should be to get all the technical teams on the same page and establish a single enterprise segmentation strategy aligned to business needs. We often find that network, identity, and application teams each have different approaches of logically dividing up the enterprise that are incompatible with each other, creating confusion and conflict. See the CISO workshop video, Module 3 Part 3: Strategy and Priorities, for more discussion of this topic.
- Build identity-based perimeter—Starting immediately (in parallel to priority #1), your organization should adopt identity controls like Multi-Factor Authentication (MFA) and passwordless to better protect your identities. You should quickly grow this into a phased plan that measures (and enforces) trustworthiness of users and devices accessing resources, and eventually validating trust of each resource being accessed. See the CISO workshop video, Module 3 Part 6: Build an Identity Perimeter, for more information on identity perimeters.
- Refine network perimeter—The next priority is to refine your network security strategy. Depending on your current segmentation and security posture, this could include:
- Basic segmentation/alignment—Adopt a clear enterprise segmentation model (built in #1) from a “flat network” or fragmented/non-aligned segmentation strategy. Implementing this is often a significant undertaking that requires extensive discovery of assets and communication patterns to limit operational downtime. It’s often easier to do this as you migrate to the cloud (which naturally includes this discovery) than it is to retrofit to an existing on-premises environment.
- Micro-segmenting datacenter—Implement increasingly granular controls on your datacenter network to increase attacker cost. This requires detailed knowledge of applications in the datacenter to avoid operational downtime. Like basic segmentation, this can be added during a cloud migration or a net new cloud deployment easier than retrofitting to an on-premises datacenter.
- Internet first clients—A simple but significant shift is when you move client endpoints from being on the internet part-time to full-time (versus sometimes on corporate network and sometimes remote). This is a straightforward concept, but it requires having already established a strong identity perimeter, strong endpoint security and management over the internet, publishing legacy applications to your internet clients, dedicated administrative workstations, and potentially other initiatives before “rolling back” the firewalls from clients.
What good looks like
Zero Trust is a model that will ultimately be infused throughout your enterprise and should inform virtually all access decisions and interactions between systems.
Expanding on the three principles of Zero Trust from the Zero Trust vision paper—Verify Explicitly, Least Privilege Access, and Assume Breach—the hallmarks of a good enterprise Zero Trust strategy include:
- Continuously measure trust and risk—Ensure all users and devices attempting to access resources are validated as trustworthy enough to access the target resource (based on sensitivity of target resource). As technology becomes available to do it, you should also validate the trustworthiness of the target resources.
- Enterprise-wide consistency—Ensure that you have a single Zero Trust policy engine to consistently apply your organizations policy to all of your resources (versus multiple engines whose configuration could diverge). Most organizations shouldn’t expect to cover all resources immediately but should invest in technology that can apply policy to all modern and legacy assets.
- Enable productivity—For successful adoption and usage, ensure that the both security and business productivity goals are appropriately represented in the policy. Make sure to include all relevant business, IT, and security stakeholders in policy design and refine the policy as the needs of the organization and threat landscape evolve. For more information, see Meet Productivity and Security Goals.
- Maximize signal to increase cost of attack—The more measurements you include in a trust decision—which reflect good/normal behavior—the more difficult/expensive it is for attackers to mimic legitimate sign-ins and activities, deterring or degrading an attacker’s ability to damage your organization.
- Fail safe—The system operation should always stay in a safe state, even after a failed/incorrect decision (for example, preserve life/safety and business value via confidentiality, integrity, and availability assurances). Consider the possible and likely failures (for example, mobile device unavailable or biometrics unsuccessful) and design fallbacks to safely handle failures for both:
- Security (for example, detection and response processes).
- Productivity (remediation mechanisms via helpdesk/support systems).
- Contain risk of attacker movement into smaller zones—This is particularly important when you’re reliant on legacy/static controls that cannot dynamically measure and enforce trustworthiness of inbound access attempts (for example, static network controls for legacy applications/servers/devices).
Into the future
Over time, we expect Zero Trust will become accepted and commonplace where people simply learn it in “Security 101” (much like the least privilege principle today). Zero Trust is expected to evolve as we all become more comfortable with what this new normal entails and have ideas on how to optimize efficiency and address the attackers’ ongoing attempts to find a chink in the new armor.
Our next blog will discuss how to make Zero Trust real in your enterprise starting with technology available today, which you may already have deployed or have access to! In the meantime, bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.