Understanding Properties of Zero Trust Networks

Zero Trust is a well-known but 'hard-to-implement' paradigm in computer network security. As the name suggests, Zero Trust is a set of core system design principles and concepts that seek to eliminate the practice of implicit trust-based security. The core idea of Zero Trust is very simple, Trust Nothing and Verify Continuously, period! In my view, the two defining principles of Zero Trust are the following. 

At any given point in time, any request, transaction, or operation (and of course the subject behind them, whether human or programmatic), 

1. Can never be inherently or implicitly trusted even when they have passed perimeter-level security checks, whether external or internal (originating within the same network as the resource being accessed).
2. Can never be provided more privilege than is needed to accomplish the task being performed.

These are simple principles but they have quite complex implications when it comes to implementing them consistently across an Enterprise computer network.

In the discussion that follows, we will try to break down and examine some practical properties of any Zero Trust implementation and how they can be implemented with examples of possible technology stacks.

Must-Have Properties of Any Zero Trust System

Based on the above principles and all the possible ways of their implementation in real-world computer networks, it turns out that such a system is possible only if it possesses the following properties. 

1. Full-featured security automation
2. Network traffic monitoring capability, both internal and external
3. Risk-based dynamic access control
4. Continuous analysis and feedback of every network component
5. Complete 360-degree visibility of the underlying infrastructure

Each of the items in this list is quite abstract. To understand them we will need to explore each one separately one-by-one, listing down exactly what activities constitute them and what possible technology stack could be used to implement them. This article will focus on the first property "Full-featured security automation."

Implementing Zero Trust Properties

Full-Featured Security Automation

What is meant by this umbrella term "Full Featured Security Automation"? Here is the breakdown of what specific automation should be part of a Zero Trust network. 

Automation of IAM (Identity and Access Management)

• Just-In-Time (JIT) or Temporary Security Credentials: Automated provisioning of security credentials specific to a particular task only when needed and automatically invalidating them when the task is completed. Example: The AWS IAM role is a great example of the use of temporary security credentials that are issued to a user (human or system) that has permission to assume the role on a given AWS IAM Role (see AWS IAM Assume Role).
• Dynamic Role-Based Access Control (RBAC): Automatic assignment of roles to groups or users (humans or service accounts) and automatic assignment of access permissions to roles. Automatically adjusting roles and permissions based on real-time context such as location and current risk profile. Example: You can use Terraform to define RBAC at the infrastructure level for instance while setting up the infrastructure for a Confluent Kafka Cluster, you can define the various service accounts, their RBAC allocations, and associated permissions.

Endpoint Security Automation

• Automated Patch Management: Automatic detection and application of necessary security patches to ensure that all endpoints are consistently updated. Example: Microsoft Intune can be used for Endpoint Management on a network that allows security monitoring, compliance, and patch updates for network endpoints.
• Self-Healing Systems: Automatic repair and resolution of standard vulnerabilities as they get exposed and published. This can be achieved by automated threat detection software. Example: SentinelOne offers endpoint threat detection and vulnerability management capability that can be used to automate standard endpoint vulnerability detection and repair. (see SentinelOne). 

Network Security Automation

• Micro-Segmentation: Automatic segmentation of network traffic to minimize attach surface and contain breaches. This automation helps achieve a very important guideline of "Zero Trust," namely the idea of reducing the "Implicit Trust Zone." Implicit Trust Zone is the set of secured resources that a subject/principal can access without further authentication once it has been authenticated and authorized. Ideally, this Implicit Trust Zone should be as small as possible and as close to the target resource as possible. Micro-segmentation helps in achieving this. Example: VMWare NSX enables Micro-Segmentation by automatically creating virtualized, logical network segments isolated from each other and independently secured. NSX automates the creation and management of these micro-networks. One instance of such a system could be Java-based Microservice applications running on Spring boot deployed on VMWare virtualized private networks on Cloud. There are other technologies like Cisco ACI that provide equivalent Micro-Segmentation automation.
• Dynamic Policy Enforcement: Provide automation of potential breach detection and notification by implementing Dynamic Security Policies based on real-time contexts, such as user behavior device compliance, and network activity. Example: Palo Alto Prisma Access is a cloud-based security platform that enforces security policies dynamically based on real-time data. It integrates with various network components to collect telemetry data and adjust policies to accordingly. Let us look at some hypothetical example scenarios to better understand the problem that Dynamic Policy automation attempts to solve. 
  • Insider Threats: Suppose an employee with legitimate authorization to access financial data attempts to exfiltrate this information. Without dynamic policies, the static policies will not be able to detect any unusual behavior like large data being transferred to a server outside the network, too frequent access outside working hours, or accessing the enterprise network via VPN from an unusual, potentially foreign location. However Dynamic Policies are designed to monitor unusual activity like large data access, access from new locations, etc., and would typically generate alerts or enforce further authentication processes.
  • Device Non-Compliance: Suppose an employee connects an unpatched and vulnerable device to a corporate network. Static policies would not be able to detect this as there is no automation of monitoring authentication or compliance status of the device. However, dynamic policies automate the process of compliance detection and easily detect non-compliant devices, either blocking access or raising alerts.

Automation of Continuous Authentication

• Contextual Continuous Authentication: Automate the evaluation of contextual factors such as location, device, and network activity to increase the level of authentication required for continuing a user's or device's session. Example: Google Cloud Identity provides the ability to automate the monitoring of contextual factors such as device type, IP address, etc., and adjust the authentication requirements. Consider the scenario that there is a sudden surge in network traffic from a specific IP address, which could be an indication of a potential DDoS attack. Without the automation of continuous authentication, this effect may go unnoticed if the initial authentication is successful. However, with this automation in place, the system continuously monitors network activity and detects unusual network traffic. It may automatically take corrective actions by blocking incoming traffic from that IP address or raising alerts so that the security team can take appropriate action.
• Risk-Based Authentication: Automate the dynamic adjustments of authentication requirements based on risk factors such as user behavior, and device compliance. For example, if an employee suddenly accesses data outside working hours and in large volumes that user behavior change should trigger the process of requiring a second-level or third-level authentication.

Conclusion

For Zero Trust to be implemented correctly your network or system must possess certain properties. One of those properties is "Full featured Security Automation" which we explored in detail above by examining what problems it solves, how it can be implemented, what relevant examples or scenarios can be used to better understand it, and what possible technology stacks can be used to implement it. 

In the future continuation of this article, we will explore the rest of the properties of a Zero Trust system with a similar set of details.