Trust is a vulnerability — The Zero Trust Security Model
Zero trust security is an improved security model that introduced a shift in how we traditionally thought of securing our data and resources.
The traditional approach to network security
The traditional approach to securing an infrastructure is to use network perimeter-based protection — otherwise known as the castle and moat approach. The corporate firewall becomes the moat that encircles and protects the network castle and anyone inside is trusted while the rest of the world is untrusted. These parties could get access to the inside either by being located inside, in a connected corporate office/ datacentre network, or connected via VPN. All devices and users behind the firewall perimeter are trusted while the rest of the world is considered untrusted. There could be different zones of trust within the trusted environment with more restrictions ( for example DMZ). Some of the tools employed to secure the trusted perimeters are firewalls, VPNs, ACLs, IDS, IPS, etc.
The inherent weakness in this approach is the de facto classification of inside devices and users as trusted. Devices and users can be compromised and once they are compromised can be used to launch attacks using the implicit trust conferred upon them. This problem is further aggravated by the growing adoption of SaaS/IaaS cloud services, more remote users, and bring-your-own-device (BYOD) policies. The perimeters of the trusted network get extended further in such a hybrid environment. It has become hard to bring all these elements under a few trusted perimeters and classify the traffic as trusted or untrusted.
Zero trust approach to network security
The cornerstone of zero-trust security is the elimination of the primary weakness in traditional security, ie implicit trust. Zero trust doesn’t use the network location — whether a user or device is inside the perimeter — to decide on authorization or access. It rather treats all requests as hostile and enforces security for every request made.
The approach follows three principles:
Verify explicitly: Authenticate and authorize devices and users based on multiple criteria set by the organization’s policy. This could include but is not limited to the health of the device, the identity of the user, the classification of target service or data to be accessed, suspicious activities originating from the device or by the user, etc.
Use least privilege access — Restricting a user or device to the minimum permission required to perform a certain action minimizes the attack surface. It prevents the chances for lateral movements ( getting access to one location and then moving on to adjacent services and systems ).
Assume Breach — Assume every access/operation is hostile and then implement processes to identify and approve legitimate access.
The zero trust model is not a single technology or software implementation. It is rather a framework that can be implemented by incorporating several security technologies that exist and being used already in silos or some combinations.
Fundamentally zero trust is the system that should allow access from a subject to a resource while ensuring authentication, authorization, and transport security for every request between them.
The subject could be
User/Identity
Device/Endpoints
Applications
Systems
The resource/object could be one or a combination of the following
Data
Applications/APIs
Infrastructure/Systems
The workhorse of zero-trust is the policy decision and enforcement infrastructure. This infrastructure is spread across the control and data planes of the zero-trust ecosystem.
The control plane hosts two components of the policy infrastructure:
Trust evaluation/policy engine — Responsible for granting access to a request from a subject to a resource. This component depends on input from multiple systems to make its decision. This includes enterprise access policy and input from various information and security systems like SIEM ( Security information and event management ), compliance services, threat intelligence services, etc.
Policy administrator/Access control engine — This component is responsible for authentication, authorization, and access control for every request. It is also responsible for the continued evaluation of trust while a trusted subject is accessing a resource ( and revoking the access if necessary ). This service will make use of identity management services, the policy engine, real-time threat analysis services, etc.
A data plane usually has only one component.
- (Trusted) Proxy — This proxy is also known as the policy enforcement point. It is responsible for enabling, monitoring, and terminating connections between subject and resource. It intercepts the traffic from the subject, executes the decision from the policy engine and administrator, and ensures the adaptive access control is enforced. It is responsible for encrypting all traffic.
The following diagram represents high-level elements of the zero-trust ecosystem.
Image adapted from NIST SP 800–207
Zero trust is a reference model that can be implemented in different ways as long as the underlying principles are maintained. Hence you would find different cloud and open-source products that fall under the zero-trust security model. Irrespective of the product or service you chose, zero-trust is an iterative process and requires a lot of work beyond using some services. Some of them include
Identifying the data stores
Classify the data according to sensitivity
Identify all the roles and the level of access to this data required for various use cases
Ensure all users are brought under one or more of these roles
Map out all transaction flows/communications to these systems and build policies that map those flows to the role and level of access required
Use the above information along with company policies, compliance requirements, and security practices to create enterprise access policies.
Once these are sorted out work out what solutions you want to adopt and redesign your security infrastructure accordingly.
