The original Zero Trust model 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.
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 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.
Why Zero Trust?
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).
Implementing 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
We took inspiration from both John Kindervag’s approach to Zero Trust and Google’s BeyondCorp initiative. Forrester provided a high level approach and BeyondCorp provided a much more detailed approach, but the 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 not go down the path of Google or bust and instead, architected LogRhythm’s model based on the work Google had already done. There are several off-the-shelf technology products that can be used to replicate the more detailed BeyondCorp 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.
Our Zero Trust architecture 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
- 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
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, 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.
Lessons Learned
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. The IDSA also provides a good source of practical guidance for combining capabilities and technologies that can inform your architecture and roadmap.
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.
Other 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 our 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.
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 (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.
About the Author: James Carder, LogRhythm CISO and VP Of LogRhythm Labs and IDSA Customer Advisory Board Member. He has more than 22 years of experience working in corporate security and consulting for the Fortune 500 and U.S. Government. At LogRhythm, he oversees the company’s governance, risk, and compliance program, security architecture, awareness, product security, physical security, and security operations. He also directs the LogRhythm Labs strategic integrations, threat and compliance research teams. He holds an MBA from the University of Minnesota, is an Advisory Board member for Colorado University and New Cloud Networks, in addition to the IDSA, and a member of the Forbes Technology Council.
