The Zero Trust Model framework is the next evolution of our security model. Explore what exactly the Zero Trust model is and how companies have successfully implemented their own models.
The Zero Trust Model Explained
The original Zero Trust model of cybersecurity was developed by Forrester in 2010, but not fully embraced until Google successfully developed and implemented their version of Zero Trust, Beyond Corp, almost six years later. Let’s explore what exactly the Zero Trust model is and what it means to implement one.
In its simplest form, the Zero Trust model shifts focus from various types of authentication and access controls, including the fallacy of single security perimeters, to tailored controls around toxic or sensitive data stores, applications, systems and networks. They leverage identities (in the form of user, roles, and systems) and commission and decommission users and brokers their access based on role. This all sits on top of a network architecture that leverages micro-segmentation, security monitoring and response (analytics, behaviors, automation, orchestration, response, intelligence), and general protective/preventative controls (especially at the device).
This shifts away from the large, corporate perimeters, with layered-in or bolted-on compensating security controls and moves to a model that is made up of a large number of micro perimeters at each identity type. Instead of building many layers of security controls from the outside in, Zero Trust proposes the idea of protecting data from the inside out and building out security controls only where you need them.
Principles of the Zero Trust Security Model
Principles of Zero Trust are built on inherently not trusting users, devices, networks, and access to sensitive resources based on any single one of those identity types and their associated attributes. Geographic location (your offices, local coffee shop, other U.S. locations) is no longer a source of trust and is merely treated as an attribute to gauge trust across the various entities outlined above. You always assume the network is hostile at all times — your corporate network or any network.
Below you can see the sensitive data stores and identities that are at the core of the Zero Trust Model of Cybersecurity.
Figure 1: A model shows that Zero Trust is built on inherently not trusting users, devices, networks, and applications
What is the Ultimate Outcome of a Fully Deployed, Zero Trust Model for Cybersecurity?
The intended outcome of a Zero Trust model is that trusted identities get access to the applications, systems, networks, and data that they are entitled to, based on their role, to perform their jobs and that trust is verified at every step to ensure the employee is who they say they are.
Another intended outcome is breach prevention. I’m not saying that this is the silver bullet to stop all breaches, but it gives you a good chance at containing an incident before it ever becomes a breach. In other words, an incident involving a compromise of one identity type (users, devices, network traffic, applications, or data) doesn’t constitute a compromise of all identity types. If your user is compromised, an attacker would still need to compromise the system trust, network trust, and behavior trust separately before the attacker receives access to the data they’re interested in.
If a system is compromised, the attacker is still forced to break through the trust of the other types of identities. If any of the identity attributes are inconsistent or risky, you can intelligently respond with additional authentication methods or other compensating controls (isolate, contain, remove, etc.), creating a very quick way to contain a threat before you have a catastrophic breach. I’ve ironically called this the Titanic model, a breach of one identity (compartment of a ship) doesn’t compromise the other identity types (the rest of the ship).
How Do You Implement a Zero Trust Model?
Below are several requirements you need to meet before you can architect your Zero Trust solution. If you have a GDPR requirement, then you’ve probably already done some, if not the majority, of this work.
- Identify your toxic or sensitive data stores.
- Identify the roles at a granular level within your company and group employees based on those roles.
- Map the transaction flows of all roles to: toxic or sensitive data stores (including systems, applications, and their corresponding flows with the data) and to the necessary data stores, systems, and applications the role requires to do their job, day in and day out.
Once you have the requirements completed, the next steps will be to:
- Architect your Zero Trust network.
- Write your rules on your segmentation gateway based on expected behaviors of the data (users and applications).
- Monitor the network; inspect the log traffic; and update rules based on the intelligence you get from your security analytics systems.
The above steps are based on John Kindervag’s approach to Zero Trust. John was an early pioneer in the Zero Trust model and helped create it when he was at Forrester.
To help you get started, here is an example of the traditional Zero Trust architecture model that Google leveraged for their BeyondCorp initiative.
- User and certificate-based authentication for trusted systems and devices leveraging multifactor authentication and single sign on.
- An access proxy and access control engine to take the users and their roles, and proxy their access to specific applications, networks, and other resources; the policies that control the access are dynamically adjustable so business operations do not slow down while waiting on IT to adjust the access policies accordingly.
- A trust engine to infer trust and subsequently allow or deny access based on attributes at each identity type (user, systems, location, etc.).
- Monitoring, detection, and response across the entire architecture; to include behavior-based monitoring for users that can help verify the user is who they say they are based on their behaviors (another attribute).
- Security protection at the endpoint in addition to certificate-based authentication.
Here’s a diagram of their model to make it a bit easier to see:
Figure 2: Google’s BeyondCorp Zero Trust architecture model
The awesome thing is that with BeyondCorp you could, very easily, have a Zero Trust security model deployed in your environment tomorrow. The only catch is that you must use everything Google (G Suite, Chromebooks, their version of the Yubikey, etc.). As a business, you’ll be dependent on one vendor. That may not be something you’re interested in doing.
LogRhythm’s Approach to Zero Trust
We decided to not go down the path of Google or bust and instead, architected LogRhythm’s model based on the work Google had already done. When you break down the various capabilities from Google’s BeyondCorp, there are several off-the-shelf technology products that can be used to replicate that model:
- Identity and access management
- Privileged access management
- Cloud access security brokers
- Next Gen SIEM (to include SOAR) or UEBA for security monitoring and response
- Certificate authority
- Micro segmentation
In addition, we decided to leverage our HR systems as the sole source of truth for commissioning and decommissioning users, their roles, and their access and built an integration with that product. Our philosophy was that, if a person was collecting a paycheck from the company, there was a high likelihood that they would be a real employee. If they were receiving a paycheck and not a LogRhythm employee, that is a completely different problem that I must go solve.
Figure 3: LogRhythm’s approach to Zero Trust
Our Zero Trust architecture, as depicted in the models below, leverages:
- ADP as the HR system or sole source of truth
- Okta as the identity and access management (IAM) provider
- ScaleFT (by Okta) as the lightweight privileged access management solution
- Netskope (likely winner) or Skyhigh as the cloud access security broker
- LogRhythm as the NextGen SIEM (including SOAR) and UEBA solution
- Workspace One for trusted devices
- A micro segmentation solution that is still being evaluated
Figure 4: A visual of LogRhythm’s Zero Trust architecture model
Current State of LogRhythm’s Zero Trust Implementation
LogRhythm started its journey to Zero Trust at the very beginning of 2018. We expanded the scope of work associated with the (then upcoming) GDPR mandates to understand all the users, roles, toxic or sensitive data sources, and the flows between all the systems, applications, and users, not just personally identifiable information stores. We then implemented Okta IAM and MFA for all users and applications (SaaS and on premise). Then we integrated our LogRhythm NextGen SIEM and UEBA offering as a method or a collection of attributes to infer trust and create adaptive access. We also implemented our technology integration between Okta and ADP as the single source of truth.
In 2019, we’ll be implementing our micro segmentation solution, Netskope or Skyhigh cloud access security broker (CASB), lightweight privileged access management using Okta and their ScaleFT product, trusted device solution (MDM) through VMWare Workspace One, and finally, an expansion of our trust inference pipeline.
I should note that our implementation could have been accelerated with the proper resourcing (software and people) and that what we’ve outlined above was accomplished with a slow buildup of operating expense associated with software and a small group of people.
Any Pitfalls or Lessons Learned While Implementing a Zero Trust Model?
You’ll Need a Plan for Funding
You need to first get the initiative funded, and that starts with a strong business plan that shows new investments and cost, reduction of cost, people, and the return on investment with security and operational efficiency gains/costs. Although the Zero Trust model does not require a large number of people to operate, you still need to plan for the indirect and direct people costs.
You Need Team Buy-in
As technology practitioners, you must divert away from the old IT model. You and your IT organization must be open to changing the traditional, and still working, IT infrastructure model. Nothing will get an IT team more amped up than saying you’re going to get rid of firewalls, VPNs, and ultimately, active directory. You need to believe that bolt on, compensating controls are not sufficient in protecting an organization built on a legacy architecture which is the ultimate pitfall (why the breaches occur) and why Zero Trust is the only real way forward. It starts with winning over hearts and minds to see the vision of a secure company.
The Initial Requirements Matter
Don’t short change your efforts on the front end during requirements gathering, as you’ll pay the price later. It’s critically important to know your business, the employees, the roles, the types of access, and flows to sensitive data. Spend more time on these steps; validate and re-validate that you have everything needed to architect and implement the solution.
Organizational Culture is Key
I think organizational culture — its tolerance for change and friction — and the size and complexity of a business are some of the larger hurdles to overcome. If you have a legacy organization with a plethora of IT and data sprawl (shadow IT), homegrown code, and interconnected technology dependencies the business relies on, then implementing a Zero Trust model will require some significant time and patience. You’ll need to unwind and understand the tangled mess associated with a long established, legacy network and business before you can build a new model and you’ll likely break a few things along the way.
Your Vendors Might Change
Be prepared and don’t be afraid to tweak your architecture and the technology stack as you are building out the architecture. There are several technologies that can deliver on the capabilities required to build Zero Trust. Choose the ones that best fit your business model. The Identity Defined Security Alliance (IDSA) is a great starting point to search for vendors who also believe identity is at the center of security and may be a good fit for your model.
Building the integrations, automations, and workflow between the various off the shelf products will require a combination of vendor support and some engineering resources on your end. You’ll need to budget for that accordingly.
Don’t Fail at Execution
Finally, it’s all about the execution. Ultimately, I don’t think completely transforming your technology infrastructure happens overnight. It can be difficult and tiring work, especially for older, larger, and more complex businesses. You can have a sound architecture model, have the support from the business, but then you need to go execute. If you don’t execute accordingly, you’ll leave your company at risk and never meet the intentions of Zero Trust in the first place.
Don’t Forget the Inherent IT Benefits
We identified that 60 percent of our IT tickets were based on moves, adds, and changes related to employees’ users and their roles. Using ADP as the single source of truth and automating the provisioning, deprovisioning, and changing of users and roles, we’ve eliminated this workload from out IT department.
We were able to reduce our dependency and nearly eliminate our VPN software and are in the process of minimizing and eliminating our corporate (perimeter) firewalls. Reducing the maintenance costs from these two items helped subsidize the cost of additional technology to implement Zero Trust. Ultimately, we’re also looking to fully eliminate active directory by using our HR and IAM integration as the sole identity store for employees.
Another IT benefit is that the Zero Trust solution can be cloud only, cloud first, or a hybrid model. This is the direction that most CIOs are moving to, if not already there and this solution fits their model.
Common Questions and Concerns
Q: Didn’t Microsoft do something like this, even before Google?
A: Yes, they did. It was called “Red Forest,” and it focused on Active Directory as the toxic data source because leveraging account compromise was the source for many major breaches.
Q: In order to know what the toxic data is, don’t I need to discover and classify everything?
A: Not exactly. The focus of Zero Trust is identities and their access to toxic or sensitive data. You just need to know what and where your toxic and sensitive data is to classify it as such while everything else is considered non-toxic.
Q: This sounds a lot like things we’ve already done and know about.
A: That’s because it is. We’re just reducing the scope and subsequent level of effort down to something more “manageable” — the toxic and sensitive data vs. trying to do everything for everything.
Summary
In summary, the Zero Trust model is the next evolution of our security model. It’s built on an identity centric model for security that completely transforms the current and legacy IT models. Zero Trust is not easy to implement, but it’s achievable today. It’s no longer the pipe dream it was 10 years ago. The models I’ve referenced here have been used successfully at many organizations on the Zero Trust journey and by some that have completed their journey (e.g. Adobe). The model is the ultimate solution to building security from the inside out and not the outside in. While it may not be a complete silver bullet, it gives companies the best chance to contain security incidents before they become catastrophic breaches.
Visit the Identity Defined Security Alliance to find more information on LogRhythm’s journey to Zero Trust.