Program overview
This program trains the people who build and defend cloud environments to recognize attacks on them and respond. Participants investigate simulated attacks using cloud audit logs, configuration state, and the alerts your tools raise, then take containment steps in an isolated training account.
It suits cloud and platform engineers, SOC analysts who handle cloud alerts, and incident responders. Scenarios are built for the providers and services you use, such as AWS, Azure, Google Cloud, or Kubernetes. DeployOpen engineers facilitate each session.
Skills covered
Identity and access attacks
Investigating stolen access keys, abused roles, risky application consent, and new identities created for persistence.
Misconfiguration abuse
Spotting public storage, overly broad permissions, and exposed services, and tracing how an attacker used them.
Cloud log investigation
Querying control plane audit logs, flow logs, and storage access logs to rebuild a sequence of events.
Workload and container attacks
Responding to compromised virtual machines, containers, and Kubernetes clusters, including secrets read from workloads.
Containment in the cloud
Revoking credentials, isolating resources, and preserving evidence such as snapshots without breaking dependent services.
Secrets and CI/CD pipelines
Tracing leaked secrets in repositories and misuse of build pipelines that deploy to cloud accounts.
How the program runs
We review your cloud architecture, account structure, identity model, and logging setup with your cloud and security leads. We agree which providers, services, and teams the training covers and set learning objectives.
We build scenarios in a dedicated, isolated training account with synthetic resources and data. Logging and alerting follow your team's setup where possible. You approve the scenarios and the account boundaries before the exercise.
Participants investigate and respond as the scenario develops, working from logs, configuration, and alerts. A DeployOpen engineer facilitates, releases new events, and records each decision.
We walk through the attack path, compare it with what participants found, and list gaps in logging, alerting, permissions, and response steps. The training account is then torn down or kept for reruns, as agreed.
Formats
| Format | Who it suits | What it covers |
|---|---|---|
| Hands-on lab exercise | Cloud engineers and SOC analysts | Investigation and containment in an isolated training account |
| Multi-day program | Teams new to cloud security or moving to a new provider | Modules on identity, configuration, workloads, and pipelines, each with an exercise and debrief |
| Cloud incident tabletop | Cloud, security, and engineering leads | Ownership, escalation, and containment decisions for a cloud incident, discussed without hands-on systems |
| Recurring drills | Teams whose cloud environment changes often | New scenarios that follow changes to services, accounts, or tooling, run at an agreed interval |
Sample scenarios
Leaked access key
A key committed to a repository is used to list storage, copy data, and create a new user. Participants find the source, scope the access, and rotate credentials.
Role chaining and privilege escalation
An attacker moves from a low-privilege role to an administrative one through trust policies. Participants trace each role assumption in audit logs.
Public storage exposure
A storage bucket is made public and accessed from unknown addresses. Participants determine what was exposed and for how long.
Compromised Kubernetes workload
A vulnerable container is used to read service account tokens and reach the cluster API. Participants contain the workload and review cluster permissions.
Pipeline compromise
A modified build step deploys a backdoored image. Participants trace the change, remove the image, and restore the pipeline.
Cryptomining on stolen credentials
Compute instances appear in unused regions. Participants identify the credentials used, stop the activity, and check for other persistence.
What you receive
After each exercise your team receives the debrief outputs and the material needed to repeat the training.
Debrief notes
- Attack path and participant decisions
- Evidence found and evidence missed
- Ownership questions between cloud and security teams
Logging and detection findings
- Audit and data access logs that were disabled or not collected
- Alerts that did not fire or lacked context
- Suggested detection rules for the techniques used
Recommended improvements
- Permission and configuration changes to consider
- Updates to cloud incident runbooks
- Access responders need during a cloud incident
Materials to rerun
- Scenario briefs and facilitator notes
- Templates to rebuild the training account
- Expected findings for each scenario
Common questions
Who should attend?
Cloud and platform engineers, DevOps staff, SOC analysts who handle cloud alerts, and incident responders. Cloud security leads can join the debrief.
Does the training run in our production accounts?
No. Hands-on work runs in a dedicated, isolated training account with synthetic data.
Do the exercises use our tools?
Scenarios are tailored to the providers, services, and security tools you use, so participants work with the logs and consoles they already know.
Is it remote or on-site?
Remote or on-site delivery can be agreed.
How do you measure progress?
Each scenario has objectives and expected findings, and the debrief records which were met. Rerunning a scenario after changes shows whether logging, alerting, and response have improved.
Can it be repeated?
Yes. Scenario materials and account templates are handed over, and new scenarios can be added as your cloud environment changes.
How to prepare
Share an outline of your cloud setup: providers, account or subscription structure, identity provider, main services, and where logs are sent. Note any past cloud incidents or audit findings you want the training to address.
Name a cloud owner who can approve the training account and the scenario scope. Confirm which participants need console or query access during the exercise.
Frameworks used
Scenario techniques are mapped to the MITRE ATT&CK Cloud Matrix, so findings can be compared with your detection coverage.
Control recommendations can reference the CSA Cloud Controls Matrix, and skills can be mapped to NICE Framework work roles for training plans.
