Changes in working patterns and the expansion of VDI, VPN and internet-based remote access has introduced new attack vectors. This has led to the explosion of vendor noise around zero trust, and typically we see every vendor has twisted aspects of what they do in a ‘Zero Trust Story’. Read on to explore what zero trust really is from both an analyst and common view, we’ll look at common approaches, including practical steps you can take now to start the journey, and share our views on the operational side of it all.
What is Zero Trust?
The analyst definition of zero trust is founded on the belief that trust itself is a vulnerability. We rely on it too heavily. Never trust, always verify. In other words, we’re saying that whoever you say you are, from whatever device you are on and wherever you are, you must prove it before we give you anything. What we choose to give you relies not only on how access has been managed in the organisation but how many of those verified, credible characteristics you can prove. Who you are, often backed with Multi Factor Authentication, that you are coming from a device that has active and up to date security software, from a sanctioned country, through an approved route or technology.
Organisations need a new security model that effectively adapts to the complexity of the modern environment, embraces the mobile workforce, and protects people, devices, applications and data wherever they’re located. This is the core of zero trust.
NCSCs Untrusting Eight
When deploying the zero trust model, it’s important not to look at the whole and deem it too big. If you consider it a journey of many steps, it’s thoroughly achievable, no matter what size enterprise you are. But understanding where you are with zero trust is essential when building a plan to deploy it. The NCSCs 8 Zero Trust principles help you focus your efforts when designing and deploying a zero trust architecture.
1. Know Your Architecture
To get the benefits, you need to know each component of your architecture, from users and their devices to the services and data they are accessing. This principle is fundamental if you’re transitioning to a zero trust architecture for an established system with many pre-existing services.
2. Know Your User, Service and Device Identities
In a zero trust architecture, identity becomes the new perimeter, making it one of the most important factors in deciding whether someone should be given access to data or services. It’s important to have a single source of identity for each of the following: user, service and device.
3. Assess Your User’s Behaviour, Devices and Services Health
You should monitor health signals from your users and devices to evaluate confidence in their trustworthiness.
4. Use Policies to Authorise Requests
Each request for data or service should be authorised against a policy. Use products and protocols that support a continuous authentication and authorisation process whilst protecting your data at rest and in transit with encryption.
5. Authenticate and Authorise Everywhere
Authentication and authorisation decisions should use multiple signals and evaluate risk associated with the access requests. Requests between services need to be authenticated, normally achieved using API tokens, frameworks such as OAuth or Public Key Infrastructure (PKI), and use mutual authentication wherever possible.
6. Focus Your Monitoring on Users, Devices and Services
Your monitoring should link back to the policies you set and verify they are being enforced. Additionally, monitoring should be carried out on your networks to measure performance, identifying all devices attached to your network, and detecting rogue devices and malicious activity, especially when hosting on-premise services.
7. Don’t Trust Any Network, Including Your Own
Don’t trust any network between the device and the service it’s accessing, including the local network. The device should be configured to prevent attacks present on a local network, including DNS spoofing and MITM.
8. Choose Services Designed for Zero Trust
Given that you can’t trust the network, services must be designed to protect themselves. Legacy services will need additional components; this may increase management overhead and cause usability issues, so ensure you have the resources to take this on. And whenever possible, use standards-based technologies; this allows interoperability between devices and services.
One Journey to Zero Trust
One possible journey to zero trust taken from Microsoft’s maturity model is that every connection is tied back to a primary authentication that’s recently been validated as genuine in a seamless single sign-on environment. This is important because by linking to one primary identity provider, you can attach the most important part of the human identity validation – Multi Factor Authentication (MFA). Using MFA improves the likelihood that the person who initiated the access request is the correct person.
The next step in your journey is to take a risk-based decision on when to use MFA and set a policy to match your risk appetite using technology you have access to. Once authentication has been improved, it can be added to Software-as-a-Service services very quickly if they support something like SAML (Security Assertion Markup Language) authentication. The Azure Active Directory will be the identity provider, and conditional access (a risk-based view of how much authentication is enough) will be automatically invoked by the identity provider when the conditions match the policy.
Traditional applications on-premise, need a way of brokering external access to applications so they can make use of the improved identity validation. This is possible with technology such as Google Identity Aware Proxy or Azure Application Proxy (if you have Azure AD Premium 1 or 2). By brokering the connection, you’re helping the Identity Aware Proxy make the call that the incoming requests have been appropriately authenticated and constrained to the access methods chosen.
Minimise access to applications using micro segmentation and focus available budget on high value applications first, then high-risk applications. The rationale for this is that in information security we want to separate high value from high risk.
If you have containerised applications, you should improve validation of the workloads which comprise the application. The process of making a workload live should be automated and include vulnerability assessment and remediation before signing them so that tampering can be prevented. If you’re using containers and container managers, you must set labelling policies that allow only signed binaries to run in production. You can augment this further just in time privileged access and just enough administration approaches so that privileges are not left lying around.]
In summary the practical steps to zero trust include:
- Making use of what you have – identity.
- Look at how access can be proxied in.
- Tighten up access in the meantime with micro segmentation.
- Tighten up privileged access with just in time provisioning.
- Move monitoring focus to the endpoint, identity and workloads.
But remember, zero trust is not a destination but a journey. Everyone can move towards it, and every step will count, using the goals to weigh against people, process and technology changes. Simplification is liberation.