Identity, device, and network pillars all exist to protect what attackers actually want: applications, workloads, and especially data. This lesson covers the remaining two pillars in CISA's model.
Data Classification First
You cannot apply different controls to "sensitive" vs "public" data without a label. The very first data project is classification — usually a small, opinionated scheme:
| Class | Examples | Controls |
|---|---|---|
| Public | Marketing, docs site | No restriction |
| Internal | Wiki, internal email | Authenticated access; encrypted in transit |
| Confidential | Customer data, source code, financials | + Compliant device, MFA, DLP, audit log |
| Restricted / Regulated | PII, PHI, payment, secrets | + Phishing-resistant MFA, no download, encryption with managed keys, retention policy |
Four classes is enough. More than that and users guess.
Implementation tooling:
- Microsoft Purview / Information Protection — apply sensitivity labels to Office docs, emails, SharePoint sites; persist labels across exports.
- Google Workspace Data Classification — labels and DLP rules across Drive, Gmail.
- AWS Macie / Azure Purview / GCP DLP — auto-discovery of sensitive data in cloud storage.
- Snowflake Object Tagging, BigQuery policy tags — column-level labels for analytical data.
Encryption
In transit
TLS 1.2+ everywhere. mTLS between services (service mesh handles this). Modern recommendations:
- TLS 1.3 preferred, 1.2 minimum; 1.0/1.1 disabled
- HSTS on every web property; preload list for high-value domains
- Cipher suites with forward secrecy only (ECDHE)
- Internal service-to-service: mTLS or service mesh equivalent — never plaintext, even inside a "trusted" VPC
At rest
Cloud providers encrypt-at-rest by default — but the keys matter. Three tiers:
- Provider-managed keys — easy, fine for most data
- Customer-managed keys (CMK / KMS) — your KMS, your rotation policy, your audit trail. Required for many compliance regimes.
- Customer-supplied / HYOK — your HSM, your hardware. Rare; very high-assurance scenarios.
Practical advice: CMK in your cloud KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) for sensitive and restricted data; envelope encryption with per-tenant DEKs for multi-tenant SaaS.
In use
Confidential computing — encrypted data processed inside a hardware enclave (Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves). Still niche but rising fast in regulated industries.
Data Loss Prevention (DLP)
DLP scans content as it moves and enforces policy:
- Endpoint DLP — block USB copy, screenshot, print, or upload of labelled content from a managed device
- Network / web DLP — inspect traffic at the secure web gateway; block uploading source code to consumer file-sharing
- Email DLP — block outbound email containing 16-digit numbers (credit cards) unless encrypted; replace customer PII with token
- Cloud / CASB DLP — apply policies inside SaaS (e.g., prevent sharing a Drive file containing PII externally)
The honest reality: DLP has high noise. Tune slowly with audit-mode → warn-mode → block-mode over months. Without tuning, users will route around it.
Cloud Access Security Broker (CASB)
CASB sits between users and SaaS, providing visibility, DLP, threat protection, and identity enforcement across applications. Microsoft Defender for Cloud Apps, Netskope, Zscaler, Cisco Umbrella all play here. Common use cases:
- Shadow IT discovery — which SaaS apps are employees using without IT approval?
- Sanction / unsanction apps and proxy access
- Enforce session controls (no download on personal device) for sanctioned apps
- Detect anomalous activity in SaaS — mass downloads, impossible travel, OAuth grant abuse
Secrets Management
Static secrets in environment variables, config files, and (worst) git repositories are a Zero Trust violation. The pattern:
- Centralised secrets store: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.
- Workload identity (covered earlier) fetches secrets at runtime.
- Short-lived dynamic secrets for databases — Vault can mint a 1-hour Postgres user per session.
- Secret scanning in CI to catch leaks. trufflehog, GitHub secret scanning, GitGuardian.
- Rotate secrets automatically; alert on age-of-secret thresholds.
Application and Workload Protection
The application/workload pillar covers the SDLC and runtime:
Supply chain
- SBOM generation at build time (Syft, anchore, Trivy)
- Vulnerability scanning of containers (Trivy, Grype, Snyk, Aqua)
- Image signing with Sigstore / Cosign
- SLSA attestations for build provenance
- Dependency scanning (Dependabot, Renovate, Snyk) with auto-PR for patches
Admission control
Kubernetes admission controllers enforce policy at the cluster boundary:
- Only signed images may run (Sigstore Policy Controller, Connaisseur)
- No privileged or hostPath pods (Pod Security Admission, Kyverno, OPA Gatekeeper)
- Required labels and resources on every workload
- Vulnerability gating — block images with critical CVEs
Runtime workload protection (CWPP)
EDR equivalents for cloud workloads — Falco, Tetragon (eBPF-based runtime security), Aqua, Sysdig Secure, Prisma Cloud:
- Detect unusual syscalls, file changes, network connections inside containers
- Block known attack patterns (cryptominers, container escape attempts)
- Feed events to SIEM and policy engine
Cloud Security Posture Management (CSPM)
Continuous evaluation of the cloud control plane itself: misconfigured S3 buckets, over-permissive IAM, public databases, missing logging. Wiz, Lacework, Prisma Cloud Defender, Microsoft Defender for Cloud, Orca. Findings feed into a backlog the platform team prioritises.
The Composite Picture
For a typical request — a user opening a customer record in a SaaS CRM — Zero Trust pulls signals from every pillar:
- Identity — verified user with phishing-resistant MFA
- Device — compliant laptop, EDR healthy
- Network — accessed via ZTNA broker, mTLS to the CRM
- Application / workload — the CRM is hosted in a workload running a signed image, scanned for vulnerabilities, with admission control
- Data — the record is labelled "Confidential — Customer PII"; DLP prevents copy-paste to personal cloud; access is audit-logged; the database column is encrypted with a CMK rotated quarterly
Every pillar contributes; none alone is sufficient. That layered, identity-centric, context-aware decision is what Zero Trust actually looks like in practice.
Two lessons remain: how the policy decision actually gets made (the engine), and how to phase the journey from where you are today to mature Zero Trust.