Zero Trust as a concept has but one fundamental assumption. Nothing should be implicitly trusted – not your identities, not your devices, not your network components. “Trust, but Verify”, gives way to “Do not trust. Verify every time.” The draft NIST 800-207 explains the basics of Zero Trust (ZT) and Zero Trust Architecture (ZTA). This article summarizes and simplifies the core concepts of NIST 800-207.
The concept is deceptively simple.
By Chaitanya Kunthe, Co-founder and Chief Operating Officer at Risk Quotient
The challenge, for CISOs, lies not in understanding the concept, but in finding the right path to implement it within their environments.
What is Zero Trust?
Zero Trust is different from the traditional ‘castle and moat’ architecture where you protect your perimeter and stop the bad guys from entering your sacred space. If you can control who comes in, you can trust everyone within your network. Bad guys out there. Good guys in here. You see the problem already?
The modern network does not have clear boundaries. You might have autoscaling container clusters that are hosted by cloud service providers and accessed by your DevOps team from their homes. Your HR team might be running their HRMS as a SaaS. Your security operations centre might be outsourced to a third party. The castle and moat approach fails when what-you-need-to-protect is outside your castle.
Zero Trust Architecture does not care where your assets are or where your users are. That is the beauty of it.
In the NIST 800-207, there are 2 goals of ZT and ZTA:
- Prevent unauthorised access to data and services
- Make access control and decisions of access control as granular as possible
The first goal is plain common sense. It is the second one that makes ZTA interesting.
To achieve it, you have to devise an architecture that shrinks ‘implicit trust zones.’ For example, if you have a server zone containing 100 servers, and an admin who has access to the entire server zone then the ‘implicit trust zone’ for the admin is 100 servers wide. Not very Zero Trust.
The trick lies in reducing this 100 servers’ zone to say 5 servers, for admin A, without increasing authorization delays.
Core Areas of Zero Trust
ZTA focuses on three core areas:
- Enterprise identities and devices
- Enterprise Resources
- Trust Verification Systems (Policy Decision Points (PDP) & Policy Enforcement Points (PEP) and policy engine)
Enterprise identity and devices: This has two parts. First, the device authenticates the identity (user) and checks if the request is valid. This is already implemented in organizations today. Think of your average run-of-the-mill VPN connection – the user logs in to the device (authenticate the identity) and then the VPN application checks for a proper VPN certificate (valid request).
Trust Verification Systems: Here is where ZT really comes into its own. Your verification system should judge the level of confidence on the identity as well as the request and not just provide access when the base criteria are met.
The level of confidence is the trust that the verification system (Policy Engine /PDP / PEP) has in the system + identity making the request based on certain criteria. Some points that can be considered:
- Does the device + identity normally connect at these times?
- Does the identity connect from various devices? Which ones are trusted?
- Is there anything out of pattern in the request?
Think of your VPN server that is accepting connections. Does it analyze the level of confidence in the request? If it were, it could provide different levels of access based on the level of confidence it has on the request. These are what Zero Trust calls ‘dynamic risk-based policies’ to access resources.
This ‘Trust Algorithm’ or ‘Policy Engine’ is the brain behind Zero Trust.
Resource: No surprises here. They can be any system, applications, devices, data, information etc. that have some value for the organization.
Tenets of Zero Trust Architecture
There are 7 basic tenets that every zero trust architecture must try to achieve:
Consider these as the ‘goals’ of zero trust’:
- All data sources and computing services are considered as ‘resources’
- All communication is secured (internal or external)
- All access is provided ‘per-session’
- Access is provided based on a dynamic risk-based policy
- All devices should be in the most secure state possible. They should be monitored for this
- Dynamic authentication and authorization is strictly enforced before granting access
- Collect as much information about the network and infrastructure as possible
Getting Started with Implementing Zero Trust Architecture
Here we move a little away from the basics and talk more from the implementation perspective.
CISOs should start thinking of their enterprise in terms of these tenets and create a plan that will take them from where they are to a zero trust architecture. There are many paths to zero trust. As long as you comply with these tenets, you can say that you are a zero trust company.
You need not comply to all of these tenets. Pick and choose what makes your network more secure.
Here are a few logical steps to get you started:
- Identify all the resources in your organization – data sources as well as computing resources used. Check if they have basic authentication and request validity checks. You can use your existing asset databases, configuration databases etc. for this.
- List all the ‘identities’ in your organization. How many and what type of identities do you manage? This might not be easily available as most organizations do not track identities as effectively as they track assets. However, you are in luck if you have an IDAM solution implemented across the organization.
- Now, the tricky part – identify the places where the identities need to interact with the resources. It is almost like creating a data flow diagram. At each interaction point, identify levels of confidence. For example, a known user and device connecting from an unknown IP would have a lesser level of confidence as compared to a known user and device connecting from a known IP. This can get very daunting. A piecemeal approach is best suited here.
- Identify the level of access to provide at various levels of trust.
- Identify if your current access control tools can deliver what you expect. If not, calculate the risk associated with not being able to identify the level of confidence. If the risk is unacceptable, look for a solution that meets your requirement
Implementing zero trust is a very strategic exercise. You cannot have a tool that you can plug, and it magically implements zero trust in your organization. If you want to implement zero trust, prepare to roll up your sleeves and painstakingly proceed step by step.
You might now have more questions, like:
- What are the risks of implementing Zero Trust?
- What inputs should the trust algorithm consider?
- What are the different deployment scenarios in which Zero Trust can be implemented?
The NIST 800-207 draft is a detailed document that answers these questions. It contains many sections that a would-be practitioner of Zero Trust would be interested in. If this has piqued your interest, download the standard from the NIST website and go through it.
About the author:
Chaitanya Kunthe is a seasoned cybersecurity mentor who believes in simplifying things. He is the Co-founder and Chief Operating Officer at Risk Quotient, where he mentors the team to provide innovative and practical cybersecurity advice.
Disclaimer
CISO MAG did not evaluate/test the products mentioned in this article, nor does it endorse any of the claims made by the writer. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same. CISO MAG does not guarantee the satisfactory performance of the products mentioned in this article.
 and Zero Trust Architecture (ZTA).){kind=link}