Zero-trust is something I’ve talked about and heard many vendors talk about for many years already. These days vendors are using this as leverage to sell their products to “Implement Zero-Trust based networks” therefore I wanted to use this blog post as a way for myself to dig deeper into Zero-Trust and its core design principles, what it is and what it isn’t and also some ways to get started.
So where are we coming from?
The best example that I could think of when it comes to the traditional perimeter based defence is going back to the trojan war, where the trojans had the GREAT WALL. Where the trojans tok in the “gift” from the greeks to the inside of their perimeter which turned out to be their downfall. Since once they got on the inside they managed to bring down their defences and let the greek army in trough the gate from the inside, basically taking down the perimeter.
Perimeter based defences
This is a typical design where you have edge perimeter security, such as firewalls, proxies and such and once a user is on the inside and have gone trough any type of MFA or perimeter defence they are “Trusted”. So if someone managed to get to the inside they could wreak havok since they are then essentially trusted. So if you have a NGFW that didn’t detect any attacks or abnormal behaviour then they wouldn’t be able to detect anything abnormal once the attackers are on the inside. The Australian National University just recently published a incident breach report on what happened to their perimeter based infrastructure –> https://imagedepot.anu.edu.au/scapa/Website/SCAPA190209_Public_report_web_2.pdf where the attackers exploited their network and lack of security mechanisms to get access to information.
So where are with headed with Zero-Trust?
Zero-Trust is a set of design principles and not a solution on how to should design on how your users, devices and application get access. As you should not define access to services or applications based upon “trusted or non trusted networks” you should defining access based upon the user and context. Who is the user? Where is the user coming from? Which device is the user on? Essentially that you should not trust anyone, always verify access and context.
Trust no-one!
Microsoft has a good model on how Zero-Trust architectures should be built where we have device and user trust claims to gate access to data and resources.
- Identity provider to keep track of users and user-related information
- Device directory to maintain a list of devices that have access to corporate resources, along with their corresponding device information (e.g., type of device, integrity etc.)
- Policy evaluation service to determine if a user or device conforms to the policy set forth by security admins
- Access proxy that utilizes the above signals to grant or deny access to an organizational resource
As such this is something that Microsoft can provide as part of their ecosystem where user and device context and risk is being evaluated before an user is allowed access to applications, and where this risk evaluation is constantly evaluated before an user is allowed access to a particular application or a set of data
Source: https://www.microsoft.com/security/blog/2018/06/14/building-zero-trust-networks-with-microsoft-365/
If we compare a perimeter based architecture between a zero-trust based configuration.
Perimeter based configuration: An attacker tries to access Office365 using a set of credentials on a compromised device. The attacker manages also to MiTM MFA codes and therefore now has access to Office 365 on the compromised device, and all data and other applications which the user uses.
Zero-Trust based configuration: An attacker tries to access Office365 using a set of credentials on a compromised device. Security mechanisms evaluate risk on the user and device, and detects abnormal behaviour on the device and raises the risk score. The user tries to login from a unknown location which also raises the risk. This triggers an set of protection mechanisms such as PIM to reset the user password and isolate the compromised machine before they are allowed access. In this scenario we also use Conditional Access to do this context aware based evaluation.
Then we have Google’s approach which they have documented in a case study they call BeyondCorp, (which you can read more about here –> https://www.beyondcorp.com/ ) where they have adopted a zero-trust based architecture. One thing that Google also focused on is that Zero Trust is not dependent on a location. Users, devices and application workloads are now everywhere, so we cannot enforce Zero Trust in one location – it must be proliferated across your entire environment. Google used the following design-principles.
Perimeterless design – That you should be able to access services regardless of where you are.
Context Aware – That access to services is granted based upon what they know about the user and the device they are coming from
Dynamic Access Controls – All access to services are authenticated, authorized and encrypted
And with it they also have different security mechanisms in place which they use to verify if they come from a trusted device and verify who the user actually is. They also implemented central access control engine to handle user authentication and authorization to different services, as a type of enforcement point. So this is essentially a simliar setup to what Microsoft has in terms of context aware access.
Zero Trust and Microservices?
Now another interesting thing is that much of the context around Zero Trust is based upon Users and Devices that require access to services. What about service to service access? much of it today is also based upon perimeter based access where we have different VLAN’s and have ACL’s in place to lock down the service-to-service communication. The interesting thing now, with the rise of Service Mesh capabilities is that we can also now extend zero-trust architecture to Microservices.
Such as with Istio which provides a mutual TLS for service-to-service and end-user communications. You can even upgrade unencrypted traffic transparently in the service mesh. Istio can handle end-user authentication using the originating end-user JWT (JSON Web Token) credential in the original request.
Should be noted that this model does not look at risk evaluation to establish service to service communication but uses certificate based authentication.
Recently also NIST published their draft of their Zero Trust architecture which you can read here as well –> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft.pdf
Now many of the main properties of a Zero-Trust architecture is going from Perimeter based access where the firewall is the main point of access to now where the identity is now the new firewall in combination of device health which now decided more on if a user should get access based upon risk or not.
So how can I get started with Zero-Trust?
There is already a great deal of good material on Zero-Trust, this list from Cisco is a good starting point. The specific use cases that must be addressed will often be different by organization. Before moving to the more complex use cases, consider these capabilities:
- Inventory of your hardware, software, patches, and network flows
- Identify and catalog your sensitive data and map how it flows between assets
- Rank your top 50 pieces of sensitive data and understand where it resides
- Knowing your top risks (e.g. threats, brand image, fines, compliance)
- Who is after your data and how capable they are
- Authentication of your users, devices, and workloads
- Enterprise-wide policy with an automated rule base—as much as possible
- Segmentation
- Privilege escalation monitoring
- Continuously monitor and mitigate your trusted ecosystem
This is also covered as part of the NIST framework. Be sure to review the Google BeyondCorp implementation of Zero Trust, which Duo Security productized (read their ebook). Most of the security vendors as well are now evolving their products to be more adjusted to the zero-trust reference architecture.