Skip to content
6 min read·Lesson 6 of 8

Data and Workload Protection

The fourth and fifth pillars — protecting applications, workloads, and the data they hold, the ultimate target of every attack.

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:

ClassExamplesControls
PublicMarketing, docs siteNo restriction
InternalWiki, internal emailAuthenticated access; encrypted in transit
ConfidentialCustomer data, source code, financials+ Compliant device, MFA, DLP, audit log
Restricted / RegulatedPII, 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:

  1. Provider-managed keys — easy, fine for most data
  2. Customer-managed keys (CMK / KMS) — your KMS, your rotation policy, your audit trail. Required for many compliance regimes.
  3. 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:

  1. Identity — verified user with phishing-resistant MFA
  2. Device — compliant laptop, EDR healthy
  3. Network — accessed via ZTNA broker, mTLS to the CRM
  4. Application / workload — the CRM is hosted in a workload running a signed image, scanned for vulnerabilities, with admission control
  5. 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.

Key Takeaways

  • Data is the prize — identity, device, and network defences exist to protect it.
  • Classify data first: you cannot apply differential controls without a label.
  • Encrypt by default in transit and at rest; manage keys in an HSM-backed KMS.
  • DLP and CASB enforce data movement policies across SaaS, email, endpoints.
  • Workload protection = supply chain (signed images, SBOM), admission (policy as code), runtime (EDR for cloud).

Test your knowledge

Try exam-style practice questions to reinforce what you've learned.

Practice Questions →