Historically, enterprise businesses have relied upon a traditional “Moat/Castle” strategy for IT Security, which aims to protect critical business assets through perimeter security controls (e.g. Firewalls, etc.) This strategy was established during a time when the majority of IT services existed within private data centres, where the end-to-end technology stack was fully managed.
Users would be “verified” at the perimeter before being granted access to business assets, usually via the Local Area Network (LAN) or remotely via a Virtual Private Network (VPN). Once inside the permitter, the business would assume a level of trust.
Unfortunately, modern working has exposed the Most/Castle strategy as inadequate, highlighted by three realities:
The majority of users (employees/contractors) no longer operate from controlled locations (e.g. Offices), especially post-COVID, where remote working has become a necessity.
IT Services are increasingly distributed (e.g. SaaS, Cloud Hosting) and rented vs. owned (e.g. Public Cloud, Colocation Data Centres), meaning business-critical assets could be hosted and/or processed at multiple unmanaged locations, making the concept of a permitter very difficult to define and maintain.
It is no longer safe to assume that verified users (internal or external) are “friendly”, recognising the growth in outsourcing, partnerships and social engineering.
Many enterprise businesses (and security vendors) continue to perpetuate the inadequate Moat/Castle strategy, often positioning additional security layers that deliver the illusion of increased control. Unfortunately, in the context of security, investment against the wrong strategy can be counterintuitive, adding complexity and technical debt, which contributes to additional risk.
With this in mind, a fundamentally different strategy is required, one that accepts and embraces the realities of modern working.
Zero Trust is an emerging strategy for IT security, which assumes that internal and external threats exist at all times and that all networks are inherently hostile.
The traditional concept of a perimeter is disregarded, shifting the emphasis to Identity Access Management (IAM). It could be argued that identity becomes the new perimeter, stipulating that all connections (users, services, machines or devices) accessing business assets must first be authenticated and authorised.
In this scenario, IT services (applications and data) are individually secured and monitored at source via a central control pane, following the Principle of Least Privilege (PoLP). Therefore, a holistic security posture can be maintained regardless of the user or IT service location, with appropriate threat identification and controls that inherently limit the impact of a breach.
It should be noted, that although not depicted in the diagram, the firewall still plays an important role, shifting from Layer 3 (Network) to Layer 7 (Application), creating a Software-Defined Perimeter that can be managed from a central control pane.
The philosophy of Zero Trust is reasonably easy to understand (everything is hostile), but the practical implementation of a Zero Trust architecture can be challenging.
The following eight principles highlight the foundational technologies and techniques that enable a Zero Trust architecture:
Architecture and Asset Transparency: Situational Awareness is an important part of any strategy, therefore it is critical to understand the end-to-end architecture and assets across the business, covering the users and their devices, through to the services and data they are accessing. Without this basic insight, it becomes very difficult to identify the risks and dependencies that allow for data-driven decisions. In the context of Zero Trust, focus on assets that interact with a network (specifically important within a microservice architecture), leveraging automated discovery tools to reduce the burden of ongoing maintenance.
Prioritise Identity Access Management: In a Zero Trust architecture, identity becomes the new perimeter, it is important to have a single source of identity for all users, services, machines and devices, ideally managed via a central control pane and complimented by Privileged Access Management (PAM). These identities must be continuously maintained, modified and monitored throughout their access lifecycle, requiring a robust governance model, mature processes and discipline (e.g. Joiners-Movers-Leavers, etc.)
Authenticate Everything: Every network flow from a user, service, machine or device must be authenticated, preferably leveraging a modern authentication protocol (e.g. SAML, Oauth2, OpenID Connect, etc.) User authentication must include Multi-Factor Authentication (MFA), alongside the use of Secure Cryptoprocessor technologies (e.g. HSM, TPM, etc.)
Authorise Everything: The Principle of Least Privilege (PoLP) must be established, where all service and data access requests are only granted if required (need-to-know basis). Ideally, every request to access a service or data must be checked by a central policy engine, which should be dynamic and calculated from as many sources of data as possible, enabling conditional access.
Log Everything: Given that users, services, machines and devices are increasingly network connected, it is important that comprehensive logging and monitoring is maintained to provide visibility. The output can be used to help identify gaps and opportunities, as well as verify that all policies are being enforced appropriately. Any identified issue can be automatically flagged and remediated following an event-driven architecture.
Hostile Network: Recognising that all networks are considered hostile, all users, services, machines and devices must be secured at source and in transit. Network locality is not sufficient for defining trust, however, network segmentation concepts to create secure enclaves which limit network and application flows between workloads can form effective mitigation when looking to reduce the “blast radius” of a breach.
Health Confidence: The health of services, machines and devices are important signals that should be used as part of the conditional access policies. Health should be established based on standard control policies, which stipulate the minimum required criteria for access (e.g. hardening controls, patching levels, etc.) NCSC or CIS standards/benchmarks can be utilised to provide a robust foundation.
Automation: IT Security is a dynamically evolving and often volatile space, with new exploits and threat actors being identified regularly. With this in mind, it is unrealistic to rely upon reactive, manual interventions to protect an enterprise ecosystem. Investment in automation across the ecosystem can mitigate this challenge, promoting agility, whilst ensuring the consistent adoption of security controls that can be proactively and immediately applied based on specific criteria or events.
The diagram below helps to highlight the key components of Zero Trust:
Alongside these principles, a robust education curriculum must be established to help embed the concepts of Zero Trust. This is especially important for any team designing/delivering digital solutions (e.g. Product Teams), as well as architects and engineers working on the core infrastructure, DevOps or DataOps.
Zero Trust Anti-Patterns
Another perspective that can help position Zero Trust is to review anti-patterns, which include common designs that reduce the effectiveness of Zero Trust, resulting in technical debt. Zero Trust can only be effective if the entire business is aligned, although as with any transformation, the transition will take time.
Virtual Private Network (VPN): Client VPN and Business-to-Business VPN (B2B VPN) technologies used to establish connectivity between two parties (user or business). These technologies commonly operate at the Network Layer (Layer 3), maintained by brittle access control lists. VPN technologies often assume IT services are static and therefore are not well suited for highly ephemeral, dynamic services. As a result, without application layer controls, achieving the Principle of Least Privilege (PoLP) across multiple IT services via a single VPN tunnel can become very complex. Zero Trust alternatives would include targeting API-Centric connectivity (e.g. REST) and/or a service such as Boundary from HashiCorp.
Application Architecture: Traditional three-tier applications running within a private data centre are often tightly-coupled, leveraging proprietary technologies and custom integrations. This “monolithic” approach to application architecture commonly relies upon network locality to define trust, instead of targeting modern authentication protocols (e.g. OAuth2), open APIs (e.g. REST) and secure transit (e.g. TLS). To achieve Zero Trust, a modern “cloud-native” application methodology should be followed, such as The Twelve-Factor App.
IP Whitelists: Legacy services and data stores can rely upon an IPv4 address to define trust. Static IP addresses are increasingly rare, due to address translation technologies, proxies and dynamic services. They can also be subject to “man-in-the-middle” attacks and address spoofing. A Zero Trust alternative would be to implement a modern authentication protocol, such as OAuth2, OpenID Connect, etc.
Finally, like all trending “buzzwords”, vendors will look to “rebrand” their existing products and services to promote Zero Trust concepts (the same can be said for Artificial intelligence). Therefore, be careful to ensure that any investment is verified as “Zero Trust” compliant, by benchmarking it against the previously highlighted principles.
In conclusion, I am a strong believer that enterprise businesses need to stop perpetuating inadequate security strategies, recognising the hard reality that modern working requires a different approach.
Zero Trust is a good example of a modern security model, but the transition can seem insurmountable for an enterprise business with a large legacy ecosystem. Even in this scenario, it is critical to “stop the bleed” and look for pragmatic opportunities to invest in technologies and techniques that support the principles of Zero Trust, for example, I would recommend protecting (growing) investments related to Identity Access Management (IAM).