Zero Trust Security: Why Perimeter-Based Security is Dead

The traditional castle-and-moat security model — trust everything inside the network perimeter — was already weakening before the pandemic. Remote work, SaaS sprawl, and cloud adoption destroyed the concept of a perimeter entirely. Zero Trust is not a product you buy; it is an architectural philosophy built on one principle: never trust, always verify.

WARNING

The average cost of a data breach in India in 2024 was ₹19.5 Crore (IBM Cost of a Data Breach Report). Lateral movement after initial compromise — enabled by implicit internal trust — is the primary reason breaches become catastrophic.

The Five Pillars of Zero Trust

Identity: every user, device, and service must authenticate and be authorised explicitly
Devices: device health (patch level, EDR status, compliance) must be verified before access
Networks: micro-segment the network; no implicit east-west trust between services
Applications: least-privilege access per application, not per network zone
Data: classify data and enforce access policies at the data level, not just the network level

Step 1: Identity Is the New Perimeter

Start with identity. Every access request must be verified against a strong identity provider. If you are running Microsoft 365, Azure Active Directory (now Microsoft Entra ID) gives you Conditional Access policies out of the box. For hybrid or multi-cloud environments, Okta or JumpCloud provide vendor-neutral alternatives.

Minimum viable identity controls for Zero Trust:

MFA enforced for all users — no exceptions, including executives and service accounts
Passwordless authentication where possible (FIDO2 / Windows Hello / Passkeys)
Conditional Access: block sign-ins from untrusted devices or anomalous locations
Just-in-time (JIT) privileged access: no standing admin accounts — elevate on demand
Regular access reviews: automated quarterly review of who has what permissions

Step 2: Device Compliance Verification

A legitimate user logging in from a compromised device is still a breach. Device compliance checks — enforced at the identity provider level before granting access — close this gap.

Enrol all corporate devices in MDM (Microsoft Intune, Jamf, or Google Endpoint Management)
Define compliance policies: OS patch level, disk encryption enabled, EDR agent installed
Block access from non-compliant or unmanaged devices to sensitive applications
For BYOD scenarios: use app-level containerisation (Intune MAM) to avoid blocking personal devices

Step 3: Network Micro-Segmentation

Flat networks are the attacker's best friend. Once inside, they can move laterally to every system. Micro-segmentation divides the network into small, isolated segments — each with its own access controls.

hcl

# Terraform: AWS Security Group for micro-segmented application tier
resource "aws_security_group" "app_tier" {
  name        = "app-tier-sg"
  description = "Application tier — only accepts traffic from load balancer SG"
  vpc_id      = var.vpc_id

  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]  # Only from ALB
  }

  egress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.db_tier.id]  # Only to DB
  }

  # No direct internet egress — all outbound via NAT Gateway
}

For Kubernetes environments, use Network Policies to enforce pod-to-pod communication rules. By default, Kubernetes allows all pods to communicate — enable a default-deny policy and explicitly allow only required traffic.

yaml

# Default deny-all network policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Allow frontend to talk only to backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 3000

Step 4: Least Privilege Access

Every user, service account, and application should have the minimum permissions required to do its job — nothing more. This is harder to implement than it sounds because organisations accumulate permission debt over years.

Audit all IAM roles and remove permissions unused in the last 90 days (AWS IAM Access Analyzer helps)
Replace broad policies (AdministratorAccess, FullAccess) with scoped, resource-specific policies
Use IAM Roles for service accounts in Kubernetes (IRSA on EKS) — never embed AWS credentials in pods
Implement role-based access control (RBAC) at the application layer, not just infrastructure
Rotate all service account credentials quarterly; use secrets managers (AWS Secrets Manager, Vault)

Step 5: Continuous Monitoring and Verification

Zero Trust is not a state you achieve — it is a continuous process. Verification must happen on every request, not just at login time.

Deploy a SIEM (Azure Sentinel, Splunk, or the open-source stack: OpenSearch + Fluent Bit)
Enable CloudTrail / Azure Activity Log / GCP Audit Logs and centralise them
Set up anomaly detection alerts: impossible travel, after-hours access, bulk downloads
Run penetration tests annually and after major infrastructure changes
Red team exercises quarterly for organisations with sensitive data

TIP

Start with identity and MFA before anything else. A team that implements MFA with Conditional Access and blocks legacy authentication protocols will eliminate over 99% of credential-based attacks immediately — before touching network segmentation or SIEM.

Zero Trust Maturity Model

Level	Identity	Devices	Networks	Data
Traditional	Username + password	No checks	Flat network	No classification
Initial (Level 1)	MFA enforced	MDM enrolled	Basic segmentation	Data identified
Advanced (Level 2)	Conditional Access	Compliance checks	Micro-segmentation	DLP policies
Optimal (Level 3)	Passwordless + JIT	Continuous health check	All traffic verified	Automated enforcement

Most Indian organisations are between Traditional and Level 1. Getting to Level 2 is achievable in 6–12 months with the right tooling and executive buy-in. Reaching Level 3 is a multi-year journey — and often not necessary for companies that are not high-value attack targets.

Category:Cybersecurity