Cloud Security

1. Inventory providers, tenants/organizations, accounts/subscriptions/projects, regions, services, SaaS applications, marketplaces, support plans, domains, identity providers, and critical integrations. Assign a business and technical owner.
2. For each service, record service model, data handled, control plane, data plane, provider/customer/supplier responsibilities, configurable security features, defaults, required logs, backup, support escalation, and exit/deletion process.
3. Define cloud governance: approved services and regions, resource ownership, data classification/residency, cost/budget controls, exception process, tagging/labels, lifecycle, supplier review, incident authority, and evidence retention.
4. Establish a cloud center of enablement or equivalent collaboration among platform, security, identity, network, application, data, SRE, privacy, legal, procurement, and finance. Central guardrails must not make workload teams unaccountable.
5. Map organizational requirements to verifiable controls. Use the current CSA Cloud Controls Matrix 4.1 when a vendor-neutral cloud control catalogue is useful; tailor applicability and evidence rather than copying every control.
6. Define risk acceptance with owner, affected assets/data, evidence, compensating controls, expiry, review trigger, and remediation path. A provider compliance report does not accept customer workload risk.

Provider baselines: compare the AWS shared-responsibility model, Azure shared responsibility, and Google Cloud shared responsibility/shared fate. The division varies by service; none transfers responsibility for your identities and data.

Related Cyber Knowledge: Governance, Risk & Compliance (GRC) — Governance, organizational context, and accountable authority

1. Design organization/management hierarchy around security and operational boundaries—not the reporting chart alone. Separate production, non-production, security/log archive, shared services, identity, networking, sandbox, and suspended/quarantine areas.
2. Use distinct accounts/subscriptions/projects and provider-native policy inheritance to limit regions, public exposure, unsupported services, root/owner activity, weak authentication, unencrypted storage, external principals, unmanaged keys, and log deletion where supported.
3. Centralize organization-wide activity/audit, identity, configuration, security findings, DNS/flow, billing, and service logs into protected security/logging boundaries. Test new-region and newly enabled service coverage.
4. Establish asset inventory from provider APIs, configuration/change services, resource graph, DNS/certificates, deployment state, registries, repositories, CMDB, and external exposure. Preserve provider-native IDs and relationships; names/tags can collide or drift.
5. Require ownership, environment, application/service, data class, cost center, lifecycle, internet exposure, recovery tier, and repository/pipeline metadata through policy and automation. Define quarantine for unowned or policy-violating resources.
6. Use budgets, anomaly detection, quotas, and rate/service limits to detect abuse and prevent runaway automation. Cost controls are security controls for cryptomining, denial-of-wallet, compromised keys, and AI resource abuse.
7. Bootstrap the landing zone through reviewed, versioned infrastructure code with protected state, independent logging, break-glass recovery, and a tested update path. Avoid circular dependencies on the identity/network it must recover.

Related Cyber Knowledge: Governance, Risk & Compliance (GRC) — Cloud, DevSecOps, product, and control-as-code governance

1. Federate workforce identities from an authoritative identity provider; prohibit routine shared accounts and unmanaged local users. Enforce phishing-resistant MFA where possible, device/context conditions, session lifetime, and monitored recovery.
2. Separate everyday and privileged identities. Use just-in-time/time-bound elevation, approval for high-impact roles, privilege eligibility, session logging, and independent review. Inventory root/owner/global-admin access and eliminate routine use.
3. Model effective authorization across direct grants, groups, nested groups, resource policies, role trust, service control/organization policy, permissions boundaries, conditional policies, delegation, impersonation, and cross-account/tenant/project access.
4. Prefer provider-managed workload identity, federation, and short-lived tokens over static service-account keys or embedded secrets. Bind identity to the exact workload, environment, audience, repository/pipeline, and action required.
5. Control pipeline and automation identity: protected branches/environments, OIDC subject/audience conditions, minimal deployment roles, artifact identity, approval, concurrency, credential-free runners, and separation between build and production administration.
6. Govern secrets and keys by owner, consumer, purpose, environment, scope, creation, storage, access, rotation, revocation, recovery, audit, and destruction. Do not treat encryption as a substitute for authorization or secret lifecycle.
7. Maintain break-glass identities isolated from normal federation, strongly protected, monitored, tested, and used only under documented conditions. Ensure response does not depend on a compromised primary identity plane.
8. Review dormant, external, support, service, application, marketplace, workload, and machine identities. Revoke access automatically when owner, workload, contract, repository, or environment expires.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 9 — Identity defense and ITDR

1. Build a data-flow and trust-boundary model for users, administrators, workloads, APIs, control-plane endpoints, third parties, on-premises, internet, private service access, DNS, management, and egress.
2. Default-deny network paths where operationally feasible; explicitly authorize ingress, east-west, hybrid, management, and egress by source identity/context, destination resource/service, protocol, port, environment, and business purpose.
3. Protect internet edges with managed DDoS, CDN, WAF/API gateway, TLS/certificate automation, bot/abuse controls, origin restriction, rate/resource limits, secure headers, and validated client/source attribution. Edge controls do not fix application authorization.
4. Use private endpoints/service access deliberately. Review provider DNS zones, route tables, peering/transit, shared VPC/VNet, security groups/firewalls, load balancers, NAT, proxies, and service endpoints for transitive or unintended access.
5. Control egress using destinations, DNS, proxies, service perimeters, network policy, endpoint policy, and workload identity. Account for package repositories, telemetry, backups, provider APIs, webhooks, and incident tooling before enforcing.
6. Harden metadata/instance identity access, proxy headers, redirects, URL-fetching services, and server-side request functions against SSRF and credential theft. Require current provider protections and test application-layer bypasses.
7. For cloud-native zero trust, authenticate and authorize user, workload, service, and device context at each resource boundary; use short-lived service identity and policy. Network segmentation remains useful but does not grant trust by itself.
8. Log edge, DNS, flow, firewall, load balancer, API gateway, service mesh, and control-plane decisions with resource and identity context. Test what encryption, NAT, proxies, sampling, and managed-service abstraction hide.

Architecture baseline: NIST SP 800-207 removes implicit trust based on network location; SP 800-207A applies identity-tier and network-tier policy to multi-cloud cloud-native applications.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 8 — Network defense, protocol analysis, and NDR

1. Inventory data sets, owners, subjects, classification, purpose, legal/contractual basis, residency, tenants, systems of record, replicas, caches, logs, analytics, snapshots, exports, AI indexes, and deletion obligations.
2. Authorize data access at every layer: organization/resource policy, identity, object/table/row/column, service endpoint, application authorization, sharing link, backup, support, analytics, and administrative tooling. Test cross-tenant and cross-environment isolation.
3. Block unintended public or external sharing using organization policy, account-level controls, resource policy validation, automated exposure checks, and change alerts. “Public access blocked” must cover all relevant paths, not only one ACL.
4. Use encryption in transit and at rest with clear key ownership and threat model. Decide when provider-managed, customer-managed, external/HSM, or confidential-computing controls are justified; document availability, recovery, rotation, revocation, and cost tradeoffs.
5. Separate key administration, data access, and audit. Restrict decrypt/sign operations by workload, context, region, and purpose; log and alert on policy changes, unusual use, disabled/deleted keys, failed decrypts, and emergency access.
6. Design backups for ransomware and operator/provider failure: separate identity and account/project, immutability/object lock where supported, versioning, deletion protection, encryption/key survivability, offline/export needs, inventory, and tested restore.
7. Define retention and deletion across primary stores, replicas, snapshots, backups, logs, caches, search indexes, queues, exports, test data, support bundles, AI embeddings, and suppliers. Record provider limitations and verification evidence.
8. Prevent sensitive values in logs, tags, resource names, metadata, environment variables, tickets, prompts, CI output, container layers, or crash dumps. Discovery and DLP support review but do not replace data-flow design.

Related Cyber Knowledge: Secure Code & Application Security — Cryptography, secrets, and key lifecycle

1. For every workload component, document the service model, execution identity, code/artifact source, patch boundary, configuration, network path, data, storage, admin plane, logs, backup, quotas, tenancy, and provider/customer responsibilities.
2. For virtual machines, use hardened signed images, minimal packages/services, secure boot/attestation where required, encrypted disks, protected metadata, managed patching, EDR/runtime telemetry, no public administration, immutable replacement, and image retirement.
3. For managed databases, queues, object stores, analytics, integration, and PaaS, control public endpoints, authentication, authorization, tenant/database roles, encryption, backup/PITR, extensions, export/import, service identity, network policy, audit, and provider maintenance.
4. For serverless/functions, constrain triggers, invocation authorization, runtime/service identity, concurrency, duration, memory, temporary storage, environment/secrets, dependencies/layers, outbound destinations, dead-letter/retry behavior, and event replay/idempotency.
5. For SaaS, govern federation, MFA, administrators, application consent, API tokens, integrations, sharing, guest/external users, audit retention, data export, backup, eDiscovery, support access, lifecycle, and offboarding.
6. Harden application/API behavior—input, identity, authorization, secrets, SSRF, file/URL handling, rate/resource limits, session, error/logging, and tenant isolation. Managed hosting does not secure application logic.
7. Use availability zones/regions, deployment stamps/cells, circuit breakers, quotas, graceful degradation, and tested failover according to business requirements. Security controls must fail safely without making recovery impossible.

Application layer: the Secure Code & Application Security field guide covers application, API, parser, cryptography, supply-chain, and AI-system controls that remain customer responsibilities in managed cloud services.

Related Cyber Knowledge: Secure Code & Application Security — Requirements, ownership, inventory, and data flow

1. Declare infrastructure, organization policy, IAM, network, logging, data controls, clusters, applications, and detections as versioned code where practical. Define the exceptions that require imperative changes and how they are reconciled.
2. Protect source, branches, tags, environments, workflows/actions/plugins, runners, variables, artifacts, modules, package registries, state, plans, and deployment identities. Untrusted pull-request code must not receive privileged cloud credentials.
3. Use short-lived workload federation/OIDC from a tightly constrained repository, branch/tag/environment, workflow, audience, and subject. Separate build, test, release, production deploy, and cloud administration permissions.
4. Pin modules, actions, images, providers, and dependencies to reviewed immutable identities; verify provenance/signatures where supported; generate an SBOM from the built artifact; and retain exact inputs and resolved versions.
5. Review plan/change impact: new public paths, principals, trust, privileges, data stores, keys, regions, logs, deletion/replace actions, provider enablement, quotas, cost, drift, and rollback. Protect the plan from secrets and untrusted modification.
6. Apply policy as code at authoring, pull request, admission/deployment, and runtime/configuration layers. Policies need tests, versioning, owners, severity, exemptions with expiry, rollout mode, observability, and safe failure handling.
7. Secure remote state and locks with separate identity, encryption, versioning, audit, restricted access, backup, and break-glass recovery. State can contain resource identifiers and sensitive values even when marked “sensitive” in output.
8. Detect and reconcile drift; distinguish approved emergency changes, provider-managed mutation, dynamic data, and unauthorized configuration. Do not automatically overwrite an active incident or valid hotfix without review.

Hands-on: the Vulnerable Cloud Lab with Terraform demonstrates reproducible AWS/GCP lab deployment and destroy-when-done handling. It is intentionally insecure training infrastructure, not a production baseline.

Related Cyber Knowledge: Secure Code & Application Security — Dependencies, source control, builds, artifacts, and supply-chain assurance

1. Start with minimal maintained base images; pin by digest; remove package managers, build tools, caches, credentials, source, and unnecessary binaries from runtime stages; use a non-root user and read-only file system where possible.
2. Scan operating-system and application packages, secrets, malware, licenses, configuration, and provenance at build and registry time. Prioritize by deployed digest, reachability, exposure, privilege, exploit evidence, and business impact—not CVSS alone.
3. Generate and retain SBOM, provenance, signature/attestation, build identity, tests, scanner results, and policy decision for each immutable artifact. Rebuild rather than patching running containers manually.
4. Restrict registry push/pull/delete, cross-account sharing, replication, anonymous/public access, mutable tags, retention, signing keys, webhooks, and lifecycle rules. Monitor new repositories, policy changes, unusual pulls, and deletion.
5. At runtime drop capabilities, prevent privilege escalation, apply seccomp/AppArmor/SELinux where supported, limit devices, host namespaces, host paths, sockets, kernel interfaces, sysctls, and resource consumption. Avoid privileged containers.
6. Separate sensitive workloads on appropriately isolated nodes/runtimes. Keep host/container runtime/kernel patched, protect runtime sockets and metadata, monitor workload behavior, and design for immutable replacement.
7. Control secrets and workload identity without baking them into image layers or broad environment variables. Use short-lived identity and mounted files/provider integrations with tight permission and audit.
8. Preserve image digest, deployment manifest, runtime ID, node, identity, network, process/file events, and ephemeral storage during incidents. A tag name does not uniquely identify what ran.

Foundation: NIST SP 800-190 describes image, registry, orchestrator, container, and host risks. It was published in 2017, so combine its principles with current runtime, orchestrator, and provider documentation.

Related Cyber Knowledge: Secure Code & Application Security — Code review, SAST, SCA, secrets, IaC, and container analysis

1. Define provider/customer responsibility for managed or self-managed control plane, etcd, nodes, upgrades, certificates, audit, identity, networking, storage, admission, autoscaling, backup, and support. Record cluster version and lifecycle.
2. Restrict API-server reachability; federate human authentication; disable anonymous/legacy access where possible; use least-privilege RBAC; review cluster-admin, impersonate, bind, escalate, approve, token, secret, exec/attach, port-forward, node/proxy, CSR, and webhook powers.
3. Use dedicated service accounts, disable automatic token mounting when unnecessary, use bounded short-lived tokens/workload identity, restrict token audiences, and prevent workloads from reading unrelated namespace or cloud credentials.
4. Enforce Pod Security Standards—prefer Restricted for ordinary workloads—and add policy/admission controls for images/digests, signatures, registries, privilege, capabilities, root, host namespaces/paths/ports, seccomp, resources, probes, and approved exceptions.
5. Apply namespace/tenant boundaries, quotas, limit ranges, default-deny NetworkPolicy, controlled ingress/egress, DNS policy, service-mesh identity if used, sensitive-node isolation, and stronger sandbox/runtime classes where the threat model requires them.
6. Encrypt Secrets/appropriate API data at rest, restrict etcd and backup access, use external secret integrations when justified, avoid ConfigMaps/environment for confidential data, and monitor secret/token access.
7. Protect nodes and kubelets: minimal OS, patching, secure bootstrap, restricted metadata, no unnecessary SSH, runtime/socket protection, node authorization/restriction, workload isolation, image cleanup, EDR/runtime telemetry, and controlled debugging.
8. Enable and protect Kubernetes audit logs with a tested policy. Collect control plane, authentication, admission, scheduler, controller, kubelet, runtime, workload, network, DNS, registry, cloud identity, and deployment records into searchable storage.
9. Back up cluster state and application data; test rebuilding the cluster and restoring state under compromised-identity conditions. GitOps/IaC helps reconstruction but does not automatically back up persistent data or secrets.

Current project guidance: use the official Kubernetes Security Checklist and RBAC Good Practices. Then practice safely with the 1200km Kubernetes Security Lab.

Related Cyber Knowledge: Red Team & Offensive Security — Module 5 — Cloud, containers, and Kubernetes

1. Build a telemetry contract for organization, account/project/subscription, identity/federation, control plane, configuration, key/secret, storage/data access, network/DNS/edge, compute, database, SaaS, container/Kubernetes, application, CI/CD, security, and billing sources.
2. For each source record scope, enablement/defaults, regions, event categories, data-access events, exclusions, latency, sampling, schema/version, identity/resource IDs, clock, retention, integrity, cost, export, and outage behavior.
3. Centralize logs into a separately governed security boundary with least-privilege writers/readers, encryption, version/immutability where required, health monitoring, volume/budget controls, and independent alerting on disabled/deleted/changed logging.
4. Engineer detections for new privileged identity/trust, access-key/service-account key creation, MFA/conditional-access change, unusual federation/session, policy/RBAC escalation, public sharing/exposure, logging impairment, key/secret access, snapshot/export, security-control change, suspicious deployment/image, data staging/exfiltration, cryptomining, and destructive recovery actions.
5. Use MITRE ATT&CK’s cloud platforms to organize behavior and coverage. Map exact procedure, platform, data source, required fields, detection logic, assumptions, and test—not just a technique ID.
6. Build known-good and known-bad fixtures in a lab; execute authorized simulations; verify raw event generation, ingestion, normalization, query, alert, entity mapping, enrichment, case routing, and responder action.
7. Control automated response by scope, confidence, impact, prerequisites, approval, rate/concurrency, idempotency, timeout, rollback, audit, and safe failure. Start with enrichment/notification before destructive actions.
8. Measure source health, field completeness, rule execution, latency, alert quality, coverage gaps, stale identities/resources, failed automation, and untested changes. “Logging enabled” is not “detection works.”

First-party detection practice: read Kubernetes Logging and Monitoring. Use AdversaryGraph for reviewed ATT&CK, evidence, hunting, and validation workflows—not as proof that provider telemetry exists.

Related Cyber Knowledge: Blue Team & Defensive Security — Module 4 — Detection engineering and detection as code

1. Continuously inventory resources, identities, policies, network paths, data stores, images/packages, certificates/domains, public endpoints, vulnerabilities, sensitive data, logs, backups, and owners from authoritative provider APIs and deployment sources.
2. Normalize CSPM/CNAPP/CIEM/KSPM/vulnerability/exposure findings while preserving provider-native ID, source, rule/version, observation time, configuration evidence, scope, status, and remediation history. Deduplicate mirrors without losing independent corroboration.
3. Validate the exact resource and configuration. Account for provider defaults, inherited policy, effective authorization, route/load-balancer/DNS state, application controls, compensating protections, feature/region behavior, and scanner permission gaps.
4. Separate misconfiguration, vulnerability, public reachability, effective privilege, sensitive data, attack path, known exploitation, and observed malicious activity. Each supports a different conclusion and response.
5. Prioritize with business service, data class, internet/external exposure, exploitability, privilege, lateral reach, blast radius, deployed version, known exploitation, detection/recovery, owner, and age. Document uncertainty and rejected false positives.
6. Model attack paths as hypotheses across external access, workload identity, trust/impersonation, policies, secrets, metadata, pipelines, network, data, backups, and other clouds/SaaS. Validate safely before asserting the path is usable.
7. Remediate at the highest reusable layer: organization policy, identity pattern, landing-zone module, secure image, pipeline, admission rule, application control, or approved service template. Verify deployed state and monitor recurrence.
8. Use authorized attack simulation to validate prevention and detection, with dedicated lab accounts/projects, test identities/data, cost caps, cleanup, provider terms, and evidence. Never assume a tool’s “success” proves real data access or business impact.

Authorized assessment: StratusAI is a maintained AWS/GCP assessment and simulation project; read its project article. Findings require operator validation and explicit scope.

Related Cyber Knowledge: OSINT & Reconnaissance — Defensive external attack-surface discovery and continuous monitoring

1. Prepare a security/forensic account, cross-account roles, independent identity, immutable evidence storage, encryption, organization-wide log access, automation, regional coverage, quotas, snapshots, provider contacts, and clean communication.
2. Record case authority, tenant/account/project/subscription, resource and principal IDs, regions, session/token, API request IDs, source, user agent, raw and normalized timestamps, evidence export query, object version/hash, collector, and limitations.
3. Preserve identity/federation, control plane, configuration, data-access, key/secret, network/DNS, workload/application, container/Kubernetes, pipeline/repository, billing, support, security finding, snapshot, and backup evidence before retention expires.
4. Contain the full trust graph: sessions/tokens, human/workload/pipeline identities, keys/secrets, role trust, federation, application consent, policies, cross-account access, network/egress, exposed resources, and compromised delivery paths.
5. Snapshot or copy disks, objects, images, logs, serverless/package artifacts, manifests, persistent volumes, and relevant runtime state into the forensic boundary. Separate collection from analysis and avoid attaching affected storage to normal systems.
6. Scope organization-wide and cross-region activity, newly enabled services, replicated resources, related identities, marketplace/SaaS integrations, domains/certificates, and other clouds. Provider abstractions and short-lived resources demand API evidence.
7. Eradicate entry point, persistence, trust abuse, malicious resources, poisoned artifacts, vulnerable configuration, and exposed credentials. Rebuild from verified code/images and rotate secrets in dependency order.
8. Restore control plane, identity, logging, security services, network, workloads, data, and business flows through staged criteria. Validate backup/key availability, provenance, access, detection, monitoring, cost, and rollback.

Integrated practice: use the DFIR field guide and AdversaryGraph cloud-incident workflow to preserve the boundary between source evidence, enrichment, inference, and decision.

Related Cyber Knowledge: Digital Forensics & Incident Response (DFIR) — Cloud, SaaS, identity, container, and Kubernetes forensics

1. Define common control outcomes for ownership, identity, privileged access, workload identity, network, data, keys, logging, vulnerabilities, delivery, backup, incident response, deletion, and supplier access. Map provider-native implementations beneath them.
2. Preserve provider-native identifiers, APIs, policy semantics, regions, event schemas, defaults, and evidence. A normalized field improves correlation but can erase a critical distinction unless the original remains linked.
3. Govern cross-cloud connections and identity federation: trust anchors, issuers, audiences, subjects, certificates, DNS, network transit, egress, secrets, replication, data transfer, logging, and revocation. Avoid one broad identity spanning all providers.
4. Assess SaaS and suppliers for service/data flow, sub-processors, locations, shared responsibilities, identity, admin/support access, integrations/tokens, encryption/key options, logging/export/API, retention/deletion, backup/recovery, incident notification, assurance evidence, exit, and concentration risk.
5. Map controls to applicable obligations and contracts with owner, scope, implementation, inherited/shared/customer responsibility, evidence, collection cadence, exceptions, and test. Do not claim compliance from a tool score or provider certification alone.
6. Use provider attestations, CSA STAR/CAIQ where appropriate, penetration-test summaries, architecture, control evidence, incidents, service health, support history, and contract terms as different evidence types. Review applicability and period.
7. Continuously assure high-risk controls through API evidence and tests while protecting credentials, costs, rate limits, and sensitive results. Maintain human review for exceptions and business-context decisions.
8. Plan portability and exit: data and key export, identity removal, domain/certificate transfer, workload reconstruction, dependency replacement, evidence retention, deletion verification, cost, time, and business acceptance.

Related Cyber Knowledge: Governance, Risk & Compliance (GRC) — Third-party, service-provider, and software supply-chain risk

Pair the provider-specific controls below with the AI Security infrastructure and availability model so identity, egress, resource abuse, degradation, and recovery are tested as one system.

1. Inventory model providers/versions, endpoints, training/tuning/evaluation data, prompts/system instructions, retrieval sources, embeddings/vector stores, agents, plugins, MCP/A2A servers, tools, workload identities, secrets, outputs, logs, safety controls, and retained content.
2. Assign shared responsibility for base model, managed platform, customer data, application, retrieval, identity, tools, actions, moderation, monitoring, incident response, and deletion. Provider model safety does not secure your authorization or tool integrations.
3. Classify prompts, files, retrieved content, model outputs, feedback, traces, and training data. Apply region/residency, encryption, tenant isolation, access, retention, deletion, DLP, privacy, copyright, and provider training/use settings.
4. Use per-workload or propagated user identity and short-lived tokens. Avoid broad service accounts shared by every agent. Authorize retrieval and each tool/resource action independently from the model’s text.
5. For RAG, apply security trimming before retrieval and before response; preserve source identity/version/citation; isolate tenants and classifications; validate ingestion; detect poisoning; and reconcile additions, updates, deletions, and access changes.
6. For MCP/tools, allowlist server, tool, target, action, and data; validate strict input/output schemas; isolate execution; restrict network/file/cloud access; cap time/cost/concurrency; record calls; and require human approval for consequential changes.
7. Test prompt injection, indirect instruction in documents/web/logs, data leakage, cross-tenant retrieval, tool confusion, identity substitution, excessive agency, insecure generated code, resource exhaustion/denial of wallet, poisoned model/artifact, and unavailable provider.
8. Protect ML pipelines, feature stores, notebooks, registries, artifacts, deployment endpoints, evaluation sets, GPUs/accelerators, and supply chain like other privileged delivery systems. Pin and verify model/artifact identity where possible.
9. Log provider/model/version, prompt/template, data classification, source IDs, retrieval, tool calls, policy/authorization, approvals, output, cost/token/resource use, reviewer, and final disposition without leaking secrets or prohibited content.

Ecosystem: review the AdversaryGraph RAG/MCP guide, AI in Offensive Security, and HexStrike research. These are implementation and testing resources, not automatic assurance claims.

Related Cyber Knowledge: AI Security — Infrastructure, network, resource, and availability security