Skip to content

05 - Incident response

Section 5: Incident response (~18%) - tasks 5.1 to 5.3 of exam guide 2.0.

Detection ends where an alert becomes a case. This section covers containing and investigating, automating with playbooks, and managing the case life cycle so that nothing is dropped between people.

5.1 Containing and investigating security incidents

Collect evidence on scope. Start by preserving: forensic images and artefacts of affected systems (disk snapshots, memory where possible), the relevant logs and the alerts themselves. Use cloud-native capabilities, such as disk snapshots shared to an isolated project, and record who collected what and when. Do not modify the originals.

Observe and analyse alerts. In SCC and Google SecOps, review the alerts and findings related to the incident: related detections on the same entities, timing, severity and the entity context from notes 02. Group related alerts so the team sees one incident rather than many.

Analyse scope with tooling and context. Guide 2.0 names Cloud Logging, Google SecOps, Compliance Manager and Vulnerability Assessment for Google Cloud, so scope and severity are judged with posture and vulnerability context as well as logs: a compromised host with an unpatched, internet-facing flaw is worse than one without. Answer the scoping questions: which identities and credentials were used, which systems they touched, what data was accessed, how long it went on and whether other copies of the technique exist. Cloud Audit Logs are central here, which is why Data Access logs must have been enabled beforehand (notes 01).

Collaborate with engineering teams. Containment and remediation usually require the owners of the affected systems, who know the blast radius of a change, and long-term fixes (patches, redesign) belong to them. Agree on communication, decisions and who can approve disruptive actions.

Isolate affected services and processes. Contain to stop the spread while preserving evidence. Typical cloud actions: remove or restrict a compromised service account's roles or disable its keys, tighten firewall rules or network tags to quarantine a VM, stop or snapshot-and-stop an instance, revoke sessions, and block malicious indicators. Choose the least disruptive action that stops harm. Isolation should be reversible and logged.

Analyse identified artefacts. For hashes, IP addresses, URLs and binaries, use Google Threat Intelligence (the guide's example) to learn what the artefact is, who uses it and what else it connects to, and extract further IOCs for scoping.

Respond to GTI alerts. Guide 2.0 adds responding to alerts produced by GTI, such as Digital Threat Monitoring alerts about your organisation's exposure outside your perimeter (leaked credentials, mentions on criminal forums). Treat them as incidents: validate, scope what the exposure could reach, rotate or revoke, and feed what you learn back into detections.

Use AI for investigation. The guide names the Triage and Investigation Agent and the Gemini Summary widget in SecOps SOAR. The agent gives a disposition, confidence, timeline and suggested next steps for an alert (notes 03); the widget summarises a case for a reader who has just picked it up. They speed up reading, not judgment: confirm key facts in the underlying evidence before containing or closing.

Root cause analysis. Use SCC and the Google SecOps SIEM to establish the initial access point, the control that failed and the path the attacker took. The output is a fix, such as closing an exposure SCC flagged or tightening an over-permissioned account, not only a report.

5.2 Building, implementing and using response playbooks

What a playbook is. In Google SecOps SOAR, a playbook is built from a trigger, actions and flow logic: the flow commonly uses if-then-else branching so that later steps depend on earlier results. A case is the top-level container made of one or more alerts ingested from various sources, and an alert is a notification containing one or more security events. Case playbooks run at the case level, so one action can cover all alerts and entities, with reaction triggers such as a change of priority, assignee or stage, or the addition of a tag. A manual action pauses a playbook until an analyst completes or skips it, and appears in the Pending Actions widget (per the playbook actions documentation). These case-playbook features were marked pre-GA in the documentation I read, so confirm current behaviour.

Determine which steps to automate. Automate steps that are frequent, well understood and low risk: enrichment, reputation lookups, ticket creation, notifications, adding indicators to a watch list. Use a manual action or approval for disruptive steps such as disabling a production service account, since a wrong automated action can cause the outage the attacker wanted. Decide by asking how often the step is performed, how certain the trigger is, and the cost of getting it wrong.

Prioritise high-value enrichments. Choose enrichments by the threat profile of the alert: for a phishing alert, URL detonation and sender reputation; for a suspicious login, the user's role and recent travel; for malware, file reputation and other hosts with the same hash. Limit lookups to unique entities to save time and API quota (case playbooks can deduplicate entities across alerts).

Evaluate integrations. Playbooks reach other systems through integrations: threat intelligence, identity providers, endpoint tools, ticketing and messaging. Evaluate by the actions available, authentication method, rate limits and failure behaviour.

Improve from incidents. After incidents, design new processes for newly identified attack patterns and recommend new orchestrations where gaps show in the current implementation. If analysts do the same five manual steps for every alert of a type, that is the next playbook.

Update other systems. Guide 2.0 asks for playbook mechanisms that update relevant findings in other systems, for example marking an SCC finding after it is handled, so the source of the alert does not keep showing it as open.

Invoke the Triage and Investigation Agent. Guide 2.0 also asks for playbooks that invoke the agent. The documentation I read describes running it automatically on alerts or manually from the Alerts page or a case, and states that it works only on SecOps SIEM data, so I could not confirm the playbook mechanism from that page; check the current SOAR integrations before relying on a specific action.

Custom transformers and logical operators. Guide 2.0 lists creating custom transformers and logical operators. A transformer reshapes data between steps (for example extracting a domain from a URL or formatting a value for the next action), and a logical operator is a condition used in flow logic. Build custom ones when the built-ins cannot express your clean-up or branching, and keep them small and testable.

Notify analysts and stakeholders. Implement notifications to the right people with the right information: analysts for assignment, owners for containment approval, management for severity thresholds. Use channels that cannot be silently ignored for high severity.

5.3 Implementing the case management lifecycle

Cases need a defined path, or incidents stall. Guide 2.0 states two things to implement: capturing metrics throughout the case lifecycle (tagging, service level agreements, stages and closure reasons) and efficient escalation workflows.

  • Capture metrics through the lifecycle. Tags show what kind of case it is, SLAs set how long each step may take, stages show where it is, and closure reasons show why it ended (true positive, false positive, benign, duplicate). Closure reasons are the cheapest source of tuning data you have.

  • Assign cases into appropriate response stages. Stages such as triage, investigation, containment, remediation and closure show what is happening and where bottlenecks are. Each stage has entry and exit criteria, so cases do not jump or linger.

  • Implement efficient escalation workflows. Define what triggers escalation (severity, affected asset class, SLA breach, regulatory impact), who receives it and how fast. Escalation should be automatic where the trigger is clear.
  • Assess the effectiveness of handoffs. Many failures occur between shifts and teams. Review whether a receiving analyst can continue without asking questions: summary, evidence, actions taken, open tasks and next owner. Measure rework after handoffs and fix the template.

Close the loop with metrics (time to acknowledge, contain and resolve) and a review of each significant case, feeding detection gaps back to notes 04 and playbook gaps back to this section.

Key terms

  • Case - the top-level container in SecOps SOAR holding one or more alerts and the work done on them
  • Alert - a notification containing one or more security events
  • Playbook - an automated workflow made of a trigger, actions and flow logic that responds to alerts or cases
  • Case playbook - a playbook that runs at the case level and reacts to case events such as priority or stage changes
  • Manual action - a playbook step that pauses until an analyst completes or skips it
  • Enrichment - adding context, such as reputation or ownership, to an alert or entity
  • Containment - limiting the spread and impact of an incident while preserving evidence
  • Forensic image - a bit-for-bit copy of a disk or memory used for analysis without altering the original
  • Escalation - passing a case to a higher level of authority or skill under defined triggers
  • Handoff - the transfer of a case between analysts, shifts or teams
  • Root cause analysis - determining how an incident became possible and which change prevents recurrence
  • Gemini Summary widget - the SOAR widget that summarises a case
  • Custom transformer - a user-built step that reshapes data between playbook actions
  • Service level agreement (SLA) - the time target for a case or stage
  • Response stage - a defined step in the case life cycle, such as triage, investigation, containment or closure