Containing a Compromised Production Server in Google SecOps

PSOE By islever Editorial Last updated

Containing and investigating security incidents. Building, implementing, and using response playbooks.

Short answer

C Use the Google SecOps EDR integration to quarantine the compromised production server, halting the attack while preserving forensic evidence for the investigation.

Question

You are an incident responder at your organization using Google Security Operations (SecOps) for monitonng and investigation. You discover that a critical production server, which handles financial transactions, shows signs of unauthorized file changes and network scanning from a suspicious IP address. You suspect that persistence mechanisms may have been installed. You need to use Google SecOps to immediately contain the threat while ensuring that forensic data remains available for investigation. What should you do first?
  1. Use the firewall integration to submit the IP address to a network block list to inhibit internet access from that machine.
  2. Deploy emergency patches, and reboot the server to remove malicious persistence.
  3. Use the EDR integration to quarantine the compromised asset. Correct Answer
  4. Use VirusTotal to enrich the IP address and retrieve the domain. Add the domain to the proxy block list.

Key Takeaways

The question tests incident-response containment sequencing: isolate the host via EDR while keeping evidence intact, and the trap is choosing an action that destroys volatile data or only partially blocks traffic.

When a production server shows unauthorized file changes and scanning from a suspicious IP, the immediate priority is containment that preserves volatile forensic evidence. In Google SecOps, the correct first move is to use the EDR integration to quarantine the compromised asset, isolating it without destroying memory, logs, or disk artifacts needed for investigation.

Common mistake: Option B (patch and reboot) is the most tempting wrong answer because it appears remediation-focused, but rebooting destroys volatile memory and running persistence artifacts that the investigation requires; option A only blocks internet egress and does not stop lateral movement.

Expert Analysis

Why the Answer Is Correct

Option C is correct because quarantining the asset through the EDR integration is the standard containment action that immediately halts unauthorized file changes, outbound scanning, and potential lateral movement while leaving disk contents, memory snapshots, logs, and the chronology of events available for forensic analysis. Google SecOps EDR integrations expose host isolation/quarantine as a response action, which fits the requirement to "immediately contain the threat while ensuring that forensic data remains available." Containment precedes eradication and recovery in the incident-response lifecycle, so this is properly the FIRST action.

Why the Other Options Are Wrong

Option A only inhibits internet access from the machine via a network block list; it does not stop internal lateral movement, ongoing file tampering, or local persistence, so containment is incomplete. Option B destroys the evidence: patching and rebooting removes volatile memory, running processes, and active persistence artifacts, and it constitutes eradication before the investigation has captured what was installed. Option D is an enrichment and blocking task that addresses only the indicator at the proxy layer; it neither contains the compromised host nor stops the on-server activity already underway.

Community Comment Notes

Commenter sunil299 stated simply that "EDR integration is correct for isolation," matching this verdict. Dhirajdj2804 added that "the primary objective upon discovering an active server compromise is containment" and that the asset must be isolated "while preserving volatile system memory and forensic data for investigation." Both comments align with option C, and no comment offered a defensible case for the firewall block list, reboot, or VirusTotal enrichment as the first step.

Official Reference

https://cloud.google.com/security-operations/docs

This link opens the official vendor documentation in a new tab.

Exam Strategy

Read for the phrase 'immediately contain' versus 'remove' or 'block': containment questions want host isolation through EDR, not eradication or indicator blocking. Eliminate any option that reboots, patches, or wipes the host, since it destroys forensic evidence the investigation still needs.

Frequently Asked Questions

Why is firewall block-listing the suspicious IP not sufficient containment here?

A network block list on egress only stops internet traffic; it does not prevent the host from scanning or moving laterally inside the network, nor does it stop malicious local file changes.

Why can't I patch and reboot the server to remove the persistence mechanism first?

Rebooting erases volatile memory and running persistence artifacts before evidence is captured, so it is eradication performed before containment and forensics are complete.

What does EDR quarantine preserve for the investigation?

Isolating the asset keeps disk contents, memory, process state, and logs intact and on-network-readable by SecOps, allowing the responder to determine scope and root cause.

More PSOE FAQ →

Discussion 2 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 2

  1. sunil299 👍 2 Answered C
    EDR integration is correct for isolation
  2. Dhirajdj2804 👍 1 Answered C
    In incident response, the primary objective upon discovering an active server compromise is containment. You must isolate the asset immediately to stop lateral movement and network scanning while preserving volatile system memory and forensic data for investigation.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Ingesting On-Prem NAS Logs into Google SecOps Without IP Aliasing

S-grade

Which Log Source Completes principal.user.userid Matching?

S-grade

Reducing Secops Alert Noise with High-Value Asset Context

S-grade

Handling Vendor Parser Field Changes in Google SecOps

S-grade

← Back to PSOE Study Guide