Advanced Security: Zero Trust

The End of the Castle

Traditional network security follows the castle-and-moat model. There is a perimeter. Everything inside the perimeter is trusted. Everything outside is not. Firewalls guard the gates. VPNs extend the walls. Once you are inside, you move freely.

This model worked when the perimeter was clear: a corporate office, a data center, a known set of machines. It fails in a world of cloud services, remote workers, mobile devices, third-party APIs, and microservices that communicate across networks you do not control. The perimeter dissolved. The moat dried up. But many organizations kept behaving as though the castle still stood.

Zero trust is the security model built for a world without perimeters.

Three Core Principles

NIST Special Publication 800-207, published in August 2020, defines zero trust architecture around three principles.

1. Verify explicitly. Every access request must be authenticated and authorized based on all available data: identity, location, device health, service or workload, data classification, and anomalies. There is no "already inside, so probably fine."

2. Use least privilege access. Grant the minimum permissions needed for the task at hand. Use just-in-time and just-enough-access policies. If a service needs to read from a database, it should not have write permissions. If it needs write permissions for five minutes during a migration, revoke them after six.

3. Assume breach. Design as though an attacker is already inside your network. Minimize blast radius. Segment access. Encrypt all traffic, including internal traffic. Verify end-to-end. This assumption changes how you build everything.

Perimeter Security vs. Zero Trust

Service Mesh and mTLS

In a microservices architecture, services call other services constantly. In a perimeter model, these calls happen over plain HTTP inside the "trusted" network. In zero trust, every service-to-service call must be authenticated and encrypted.

A service mesh handles this transparently. Tools like Istio, Linkerd, and Consul Connect deploy a sidecar proxy alongside each service. The proxy handles mutual TLS (mTLS), meaning both sides of every connection present certificates and verify each other. The application code does not change. The mesh handles identity, encryption, and policy enforcement at the infrastructure layer.

mTLS differs from standard TLS. In standard TLS, only the server presents a certificate. The client verifies the server but the server does not verify the client. In mTLS, both sides authenticate. This prevents a compromised service from impersonating another.

Secrets Management

Zero trust requires that secrets (API keys, database passwords, TLS certificates) are never hardcoded, never stored in environment variables long-term, and never shared between services. Secrets management tools like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault provide centralized, audited, and rotatable secret storage.

Vault, for example, can issue short-lived database credentials on demand. A service requests credentials, receives a username and password valid for one hour, and the credentials are automatically revoked when they expire. If the service is compromised, the attacker gets credentials that expire shortly. Compare this with a shared database password that has not been rotated in two years.

Dynamic secrets, automatic rotation, and lease-based access are the mechanisms that make least privilege practical instead of theoretical.

SIEM for Threat Detection

If you assume breach, you need the ability to detect anomalies in real time. Security Information and Event Management (SIEM) systems aggregate logs from every component, correlate events, and detect patterns that indicate compromise.

A SIEM might detect that Service A, which normally makes 100 requests per minute to Service B, suddenly made 10,000 requests. Or that a service account authenticated from an IP address it has never used before. Or that a database query returned 50 million rows when the typical result set is 50.

Tools like Splunk, Elastic Security, Microsoft Sentinel, and AWS Security Hub serve this role. The zero trust principle of "assume breach" only works if you have the observability to detect when a breach actually happens.

Implementing Zero Trust Layer by Layer

Zero trust is not a product you buy. It is a design approach applied at multiple layers.

Network layer: Microsegmentation. Services can only reach the specific services they need. Default deny for all traffic. Network policies in Kubernetes. Security groups in AWS. No flat networks.

Service layer: mTLS between all services. Service identity via certificates (SPIFFE/SPIRE). Authorization policies enforced by the mesh. No service trusts another service just because it is on the same network.

Data layer: Encryption at rest and in transit. Field-level encryption for sensitive data. Access logging on every data store. Row-level security where supported. Data classification and handling policies enforced programmatically.

Further Reading

• NIST SP 800-207: Zero Trust Architecture (NIST)
• NIST SP 800-207A: Zero Trust Architecture Model for Access Control in Cloud-Native Applications (NIST)
• What Is NIST SP 800-207? (Palo Alto Networks)
• HashiCorp Vault (HashiCorp)