Stackvora.tech

Zero-trust: 5 controls to start with

Implementing a zero-trust security model represents a fundamental shift from perimeter-centric defense to an "assume breach" mindset, where no user,…

Implementing a zero-trust security model represents a fundamental shift from perimeter-centric defense to an "assume breach" mindset, where no user, device, or application is implicitly trusted, regardless of its location. This article outlines five foundational controls essential for initiating a robust zero-trust architecture, focusing on practical implementation details relevant to network engineers, sysadmins, cloud consultants, and developers.

1. Multi-Factor Authentication (MFA) Everywhere

MFA is the bedrock of identity-centric zero-trust. It moves beyond single-factor password reliance, significantly reducing the risk of credential theft and reuse. Implementing MFA should be comprehensive, covering all user types and access points.

MFA Implementation Strategies

  • Phased Rollout: Start with privileged users (admins, developers) and critical systems, then extend to all corporate users, and finally to external partners or customers.
  • Adaptive MFA: Incorporate contextual factors like location (geo-fencing), device type, time of day, and risk scores to prompt for MFA only when necessary or to step up authentication strength.
  • FIDO2/WebAuthn: For highest assurance, deploy passwordless authentication using FIDO2-compliant security keys (e.g., YubiKey, Titan Security Key). These offer phishing-resistant MFA, directly addressing a common weakness of OTPs.
  • Conditional Access Policies: Leverage Identity Provider (IdP) capabilities (e.g., Azure AD Conditional Access, Okta Adaptive MFA) to define rules for MFA enforcement based on user, device, application, and location.

Example: Azure AD Conditional Access Policy for MFA

This policy requires MFA for all users accessing cloud apps from untrusted locations.


# Azure CLI Example to create a Conditional Access policy
# This is a conceptual example; actual implementation involves JSON policy definition

az ad conditional-access policy create \
  --display-name "Require MFA for untrusted locations" \
  --state "enabled" \
  --conditions '{
    "users": {"includeUsers": ["All"]},
    "applications": {"includeApplications": ["All"]},
    "locations": {"includeLocations": ["Any location"], "excludeLocations": ["All trusted locations"]},
    "clientAppTypes": ["all"]
  }' \
  --grant-controls '{
    "operator": "AND",
    "builtInControls": ["mfa"]
  }'

Note: "Trusted locations" are IP ranges defined within Azure AD. Ensure these are accurately configured to avoid locking out users.

2. Enhanced Device Posture Assessment

Trusting a user implicitly is insufficient; the device they are using must also meet security standards. Device posture assessment verifies the health and compliance of endpoints before granting access.

Key Device Posture Metrics

  • OS Version and Patch Level: Ensure devices are running supported operating systems with the latest security updates.
  • Endpoint Protection Status: Verify that antivirus/EDR software is installed, running, and up-to-date.
  • Disk Encryption: Confirm full disk encryption (e.g., BitLocker, FileVault) is enabled.
  • Firewall Status: Check if the local firewall is active.
  • Compliance with Configuration Baselines: Assess against security baselines (e.g., CIS benchmarks, corporate GPOs).

Integration with Access Control

Modern IdPs and ZTNA solutions integrate with endpoint management tools (e.g., Intune, SCCM, Jamf, CrowdStrike, SentinelOne) to collect device posture data. This data then informs conditional access decisions.

For instance, an access policy might dictate: "Allow access to Salesforce only if the user is MFA'd AND the device is corporate-managed, compliant, and running an approved EDR agent." Devices failing posture checks can be quarantined, redirected to remediation steps, or blocked entirely.

3. Micro-segmentation

Micro-segmentation involves dividing data center and cloud networks into small, isolated segments down to the workload level. This limits lateral movement by attackers, even if they breach one segment.

Implementation Approaches

  • Network-Based (VLANs/ACLs): Traditional method using firewalls, VLANs, and Access Control Lists (ACLs) to define boundaries. Can be complex to manage at scale.
  • Host-Based (Software-Defined): Utilizes host-based firewalls (e.g., iptables, Windows Defender Firewall) or agents from vendors like Illumio or VMware NSX. This approach applies policies directly to workloads, independent of network topology.
  • Cloud-Native: Leverages cloud provider constructs like Security Groups (AWS), Network Security Groups (Azure), and Google Cloud Firewall Rules to define granular ingress/egress policies for VMs and containers.

Example: Cloud-Native Micro-segmentation (AWS Security Groups)

Restrict an application server (app-sg) to only accept traffic on port 8080 from a load balancer (lb-sg) and port 22 from specific management hosts (mgmt-sg).


# AWS CLI Example: Ingress rules for an application server Security Group

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 8080 \
  --source-group sg-abcdef01234567890 \
  --description "Allow traffic from Load Balancer"

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 192.168.1.0/24 \
  --description "Allow SSH from Management Subnet"

Trade-offs: Network-based solutions require careful IP address management and can lead to rule sprawl. Host-based solutions offer greater flexibility but require agent deployment and management. Cloud-native options are integrated but specific to the cloud provider.

4. Identity-Aware Proxies (IAP) / Zero Trust Network Access (ZTNA)

IAPs and ZTNA solutions replace traditional VPNs by providing secure, granular access to internal applications based on user identity, device posture, and context, without placing users directly on the corporate network.

How IAP/ZTNA Works

  1. Authentication and Authorization: User authenticates against an IdP (e.g., Okta, Azure AD).
  2. Device Posture Check: The ZTNA client or IAP verifies the device's security posture.
  3. Contextual Policy Evaluation: Policies are evaluated based on user, device, location, and application.
  4. Secure, Least-Privilege Access: If all checks pass, a secure, encrypted tunnel is established directly to the requested application, not the entire network. This is often referred to as a "micro-VPN" or "per-application VPN."

Benefits over Traditional VPNs

  • Reduced Attack Surface: Applications are not exposed to the public internet; they are accessed only via the ZTNA gateway.
  • Granular Access: Policies can be defined per application, not just per network segment.
  • Improved User Experience: Often provides seamless, clientless or lightweight client access.
  • Scalability: Designed for cloud and hybrid environments, easier to scale than traditional VPN concentrators.

Key ZTNA Vendor Solutions

  • Google Cloud IAP: Integrates with Google Cloud services to protect web applications.
  • Cloudflare Zero Trust (Teams): Provides secure access to internal applications and filters internet traffic.
  • Zscaler Private Access (ZPA): Connects users directly to applications without exposing them to the network.
  • Palo Alto Networks Prisma Access: Comprehensive SASE platform with ZTNA capabilities.
  • Microsoft Azure AD Application Proxy: Publishes on-premises web applications for secure remote access.

Migrating from VPN to ZTNA significantly enhances security by enforcing a "never trust, always verify" approach for every access request.

5. Continuous Data Classification and Protection

Understanding what data you have, where it resides, and its sensitivity level is crucial for applying appropriate security controls. Zero-trust principles extend to data itself, ensuring only authorized entities can access it.

Steps for Data Classification

  1. Identify Data: Locate all data across endpoints, cloud storage, databases, and applications.
  2. Classify Sensitivity: Assign classification labels (e.g., Public, Internal, Confidential, Highly Confidential, PII, PCI) based on business impact and regulatory requirements. This can be manual, automated with DLP tools, or a hybrid approach.
  3. Apply Protection Policies: Based on classification, implement encryption, access controls (ACLs, RBAC), data loss prevention (DLP), and retention policies.
  4. Monitor and Audit: Continuously monitor access patterns to sensitive data and audit compliance with policies.

DLP and Encryption

  • Data Loss Prevention (DLP): Tools that identify, monitor, and protect sensitive data in use, in motion, and at rest. DLP can prevent data exfiltration by blocking emails with sensitive content or preventing uploads to unauthorized cloud storage.
  • Encryption at Rest: Ensure all sensitive data stored on disk (databases, file shares, cloud storage buckets) is encrypted using strong algorithms (e.g., AES-256).
  • Encryption in Transit: Mandate HTTPS/TLS 1.2+ for all data in transit between clients, applications, and databases.
  • IRM/DRM (Information/Digital Rights Management): Apply persistent protection to documents (e.g., PDFs, Office files) that travels with the file, controlling who can open, edit, print, or forward it.

Example: Azure Information Protection (AIP) for Data Labeling

AIP allows administrators to define sensitivity labels that users can apply to documents and emails, or that can be applied automatically based on content inspection. These labels then enforce protection policies like encryption and access restrictions.


# PowerShell Example: Define a sensitivity label in Azure Information Protection
# This is a high-level conceptual example for AIP configuration.
# Actual deployment involves complex policy definitions.

New-Label -Name "Confidential - Finance" `
  -DisplayName "Confidential - Finance" `
  -Tooltip "This content contains sensitive financial data and is restricted to Finance department." `
  -Color "#CC3300" `
  -ProtectionEnabled $true `
  -EncryptionKeyType "ADRMS" `
  -EncryptionRights "VIEW,EDIT" `
  -AssignedToGroups "Finance_Dept_Group" `
  -SetAsDefault $false `
  -MinimumPermission "VIEW" `
  -ParentLabelId  # If it's a sub-label

Continuous classification ensures that data protection policies remain dynamic and adapt to changes in data location and sensitivity.

Common Pitfalls

  • "Big Bang" Implementation: Attempting to deploy all zero-trust controls at once often leads to project failure and user resistance. Adopt a phased approach, starting with high-impact, low-friction controls.
  • Neglecting User Experience: Overly restrictive policies or cumbersome authentication methods can lead to shadow IT or workarounds that undermine security. Balance security with usability.
  • Incomplete Asset Inventory: You can't protect what you don't know you have. A thorough inventory of users, devices, applications, and data is a prerequisite.
  • Lack of Executive Buy-in: Zero-trust is an organizational transformation, not just a technical project. Strong executive support is vital for resource allocation and cultural shift.
  • Ignoring Legacy Systems: Many existing applications and infrastructure components may not natively support modern zero-trust controls. Plan for adaptation, proxies, or phased replacement.
  • Insufficient Monitoring and Auditing: Without continuous monitoring of access logs, policy violations, and security events, zero-trust controls can become "set and forget," losing their effectiveness over time.

Back to the knowledge base · Ask the AI assistant