Zero Hype

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

 

At Ignite, I had the privilege of presenting “Zero Hype” with my colleagues Nupur Goyal (@nupur_11) who leads our Product Marketing, and Yinon Costica (@c0stica) who directs program management for Azure Security Center, Microsoft Cloud App Security, and Azure ATP for Users, among others. Concepts like Zero Trust are useful only if they are concrete. Despite years of the term being batted around, consistency and clarity on the term is still very poor among the folks I talk to. So, when Nupur asked me to do a talk on Zero Trust, I suggested we do everything we could to clear away the fog on the concept. I hope we achieved that. For those of you who weren’t able to see the session, I wanted to capture the essence here.

 

In a Nutshell

Zero Trust, conceptually, asserts that traditional security models based on “the walled garden” are outdated, and that security models should assume that all requests should be treated as though they originate from an uncontrolled (external or compromised) network. Whether you think of this as “assuming breach” and operating as though the enemy is inside your perimeter or you think of this as operating in a perimeter-less environment, it’s all about operating as though you are in a pervasive threat environment. This is a simple concept, we don’t need to complicate it or dress it up because it has powerful implications. Let’s dig in a bit.

 

Once Upon a Time

In 1990, I started a company that was (among other things) helping people build out networks for their offices. Fundamentally, there was very little in the way of connectivity between these networks. If you had two offices, you used a Wide Area Network – a leased line – to get between them. In this world, you could very safely assume that any access to any resource came from within a building you owned, from a machine you owned, by someone you employed. As a result of these assumptions, file shares were wide open, apps were accessible by anyone with a username/password combo, and almost all of the companies I worked with centered their strategy on “we trust our employees.” Yes, there were outliers, but even advanced security wasn’t very advanced then, and was centered more on building access than network access.

 

Over the next few years, with the advent of better modem speeds and cheaper PCs, telecommuting became more popular and VPNs (that you dialed in to, remember?) became a thing. By 1994, the Internet was gaining broad traction in academia and corporations were starting to forego leased lines in favor of public infrastructure. Suddenly, all those private networks were connected to the big world outside. Firewall companies took off, trying to keep all the unexpected or malicious traffic out. The walled garden – a network defended at the perimeter, but essentially open once inside – was born. I think of this as us “defending our assumptions.”

 

The years that followed brought dizzying changes – Netscape became big in 1995; Microsoft went “Internet first” in December of that year. Salesforce launched their SaaS offering in 2000. Starbucks put WiFi in all their stores in 2002. The iPhone Launched in 2007. Office 365 launched in 2011. With each of these changes, the assumptions we’d been making about access to resources – that they were from our network, on devices we owned, to apps we’d deployed, by people we worked with – became less and less valid. IT today looks nothing like the world the walled garden model was intended for. None of the assumptions are valid anymore – attackers have known this for years.

 

ZH1.PNG

Evolving Our Thinking

Fortunately, there were thought leaders who saw these changes happening and reacted. In 2003 the Jericho Foundation introduced the concept of de-perimiterization. In 2010 John Kindervag at Forrester wrote “Build Security Into Your Network’s DNA: The Zero Trust Network Architecture” and the term Zero-Trust was born. In 2013, Microsoft coined “Identity Driven Security” and introduced the Enterprise Mobility Suite (EMS) to address the core security and compliance needs of enterprises – Secure Access, Secure Devices, and Secure Data. That same year, Google implemented a no-network trust model in “BeyondCorp”, providing a “demonstrator” which inspired tremendous interest.

 

ZH2.PNG

 

This interest fueled a massive surge in hype. By this year’s RSA, virtually all booths were touting their Zero Trust-ness. One analyst told me “the age of Zero-Trust-washing has arrived.” Smart people simultaneously realized there was something there they should be paying attention to, and were completely unable to find a consistent, crisp definition. When I ask folks to raise their hands if they are confident in what Zero Trust means I’m lucky if 5% of folks are willing to venture a guess.

 

But the essence of Zero Trust remains simple – security models which assume safety based on network location are inadequate. Modern security models must assume all access requests come from uncontrolled networks.

 

De-FUD’ing Zero Trust

I sometimes use the slang term “FUD” – Fear, Uncertainty, and Doubt. I want to attempt to de-FUD Zero Trust by blowing away some of the fog surrounding the term. Here’s what Zero Trust isn’t:

  • Literal. Trusting absolutely nothing in your environment is neither pragmatic nor possible. While you want to approach security investments with the assumption that any component can fail, you have limits on your time and resources – absolutism isn’t going to help you make smart prioritization decisions.
  • An Adjective. You aren’t going to “be” Zero Trust. A product can’t “be” Zero Trust. Zero Trust is an approach to securing your assets – a mindset which will guide your strategy and investments.
  • For Sale. You can’t buy and install a product and “become” Zero Trust (not even ours!). In a world where we assume pervasive risk, trusting one angle, one approach, one product completely is counter intuitive.
  • Instant. Unwinding the assumptions in your environment will take time. Prioritize based on your biggest blind spots. Pick a corner to work out of – like cleaning a messy room, start with one surface, get it working well, and move on.
  • A Destination. This is a mindset you are adopting – a mindset of continuously questioning your assumptions, of looking for gaps in your telemetry, of fundamentally doubting your defenses. Once you adopt this mindset, you will spend your career applying it to prioritizing your investments.
  • One Size Fits All. The right investments for your organization are a function of where you are now, what you are defending, how your staff works, your strategy for infrastructure investments. Your approach to Zero Trust will be a function of your current reality and your wisdom.
  • A Revolution. As discussed in the history of changes leading to the Zero Trust concept, cyber security models (e.g. “defense in depth”) have been evolving for decades. Much of what you have adopted is necessary – but probably not sufficient. Use what you know and use what you’ve deployed. But don’t use it as an excuse to make assumptions about your environment.

 

The Zero Trust Mindset

I believe the most useful thing about Zero Trust is the mindset it creates. The mindset to adopt is that you are operating in a pervasive threat environment. An environment that demands that you continuously assess and re-assess the viability of your security strategy. Here are some key behaviors you might exhibit if you accept that you are operating in a pervasive threat environment:

  • Don’t accept complacency. This is the single biggest shift of Zero Trust. In the world of flat networks and VPN, we assume that if the request is originating from a known network, it must be safe. We assume the models that protected us yesterday will protect us tomorrow. Zero Trust demands we abandon those assumptions and instead validate and exercise controls over as many aspects of access as possible, explicitly validating what we can, and accepting that the things we don’t explicitly validate remain uncertain.
  • Assume all resources are on the open internet. One approach many customers have found valuable in countering their entrenched assumptions is to assume every user, device, and resource is on the public internet. Many of our most successful customers in this regard have simply moved as many resources as possible to the cloud, modernizing their security strategy as they go.
  • Trust no single source. In a pervasive threat environment, accurate insights are key. A CISO once shared that “Pops told me, honest people all tell the same story, but liars lie differently.” Security models which rely on multiple sources of validation are much stronger – triangulation provides a much more accurate fix than single source validation. Similarly, control which relies on multiple elements (using device trust, location, and strong auth, for example) is better than that which relies on only one aspect of access.
  • Breach containment. If we assume pervasive threats, we assume that some threats will break through our defenses. Containment strategies such as privileged identity management, role-based access, separation of duties and network segmentation can help contain adversaries who break through your first layers of defense.
  • Standards are security. While innovation is wonderful, a maxim of security (especially encryption) is that nothing is provably secure, but time without breach is a good indicator. Avoid security theater or security through obscurity – heavily inspected, heavily used, and yes - heavily attacked standards provide a great anchor for your security strategy. Leverage modern authentication standards like OAUTH2, provisioning standards like SCIM, and credential standards like FIDO2 wherever possible (or buy products that do).
  • There aren’t enough humans. You must automate everything you possibly can. There simply aren’t enough humans to handle the volume of telemetry and attacks you will be facing. Make use of cloud intelligence, machine learning, and most importantly automated response mechanisms like automatically locking at risk accounts or banning traffic from known bad IP addresses.

 

We can distill all this down to three key principles:

  • Move from assumption to explicit verification.
  • Adopt a policy-based, least privileged access model.
  • Design with the assumption that every element of your system can be breached.

ZH3.PNG

Conceptual Architecture

We have seen that successful adoption of a Zero Trust approach benefits from some critical elements. We pulled this together conceptually in a conceptual architecture, pictured below.

 

ZH4.PNG

 

The critical elements are as follows. First, the key resources:

  • Verify Identity. Knowing who is requesting access is essential, and that identity must be validated explicitly, not inferred from the environment. Ensure you are secure at the point of access by bringing users into a common identity system, using strong auth and threat intelligence to validate authentication.
  • Verify Devices. All data access requests result in the transfer of that data to a browser or app on a device. Knowing the state of that device is critical in a world where devices can be infected, lost, or stolen. Mobile Device Management (MDM) and Mobile Application Management are critical to protecting data once it is accessed.
  • Protect Data. Wherever possible, data should be protected from unauthorized transfer by auto-classification and encryption. This protects against intentional or accidental misrouting of downloaded data.
  • Harden Applications. Application access and configuration must be secure to mitigate intrinsic application risks, and to ensure access is governed by policy. Application behavior, including shadow IT, should be understood and monitored for and protecting from anomalies.
  • Protect Infrastructure. Where you are using cloud workloads (IaaS or PaaS), ensure you are utilizing your cloud fabric according to best security principles, utilizing the intelligence and protection provided.
  • Govern Networks. Mitigate lateral movement by using an intelligent, adaptive segmentation strategy for workloads, monitoring for and protecting from anomalous traffic patterns.

 

Then, the key tools to tie it together:

  • Policy driven access. Modern micro-segmentation means more than networks. It requires we also gate access based on their role, location, behavior patterns, data sensitivity, client application, and device security. Ensure all policy is automatically enforced at the time of access and continuously throughout the session where possible.
  • Automated threat detection and response. Telemetry from the systems above must be processed and acted on automatically. Attacks happen at cloud speed – your defense systems must act at cloud speed as well, and humans just can’t react quickly enough. Integrate intelligence with policy-based response for real-time protection.

 

Next Steps

Here are some next steps and related on demand sessions to help you go deeper on how to get started today:

Identity Teams:

  1. Connect all your apps for single sign-on – Identity is your control plane, but only for apps and users that are visible to it!
  2. Ensure strong identity with multi-factor authentication and risk detection.
  3. Enforce policy-based access and least privileged access for breach containment.
  4. Check out these sessions:
    • BRK2132: How Microsoft uses Azure Active Directory Identity Protection and Conditional Access to protect its assets
    • BRK4017: The science behind Azure Active Directory Identity Protection

 

Device Management Teams:

  1. Register your devices with your Identity provider so you can consider device context in your policies.
  2. Implement MDM security baselines with compliance reporting.
  3. Implement role-based access control that allows view access for impact assessment.
  4. Check out this session:
    • DEP50: Why Microsoft 365 device management is essential to your Zero Trust strategy

 

Network and Infrastructure Teams:

  1. Enable a cloud workload protection solution across your hybrid and multi-cloud estate.
  2. Use cloud-native controls to create micro perimeters.
  3. Reduce attack surface by implementing just-in-time application and network segmentation.
  4. Check out these sessions:
    • BRK3188: Protect your cloud workload from threats using Azure Security Center
    • BRK3185: Securing your cloud perimeter with Azure Network Security

 

Application and Data Teams:

  1. Perform shadow IT discovery and implement a cloud control program – you can’t manage what you can’t see.
  2. Agree on a label taxonomy and classify documents and emails – use default taxonomy for initial classifications.
  3. Apply protections to high risk scenarios such as sensitive data and unmanaged access in apps.
  4. Check out these sessions:
    • BRK2108: Top CASB use cases to boost your cloud security strategy
    • BRK2119: Secure your sensitive data! Understanding the latest Microsoft Information Protection capabilities

 

Finally, check out our Zero-Trust center and especially the maturity model which we hope will help you think about next steps on your journey.

I really hope this blog has helped make Zero Trust clear and actionable for you – but if you have questions or feedback, please reach out to me on Twitter at @alex_t_weinert

Stay safe out there!

-Alex

 

 

 

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.