At an MSSP, a customer ticket includes a SOAR log saying a host was isolated, yet that host still answers ping. What should the analyst do next?
Select an answer to reveal the explanation.
Short Explanation
The log says the latch closed, but you can still push the door open. You treat the isolation as failed and check the control that was supposed to quarantine the host. The trap is reading the ping as success, as proof the host is harmless, or as a reason to wipe it blind.
Full Explanation
A SOAR log records that an isolation action was requested or reported. The host still answering ping shows that the quarantine did not take effect on the network path being tested, so the analyst cannot treat the ticket attachment as proof of containment. The next move is "Treat the isolation as failed and check the control that was supposed to quarantine the host". "Treat the ping replies as proof the isolation playbook finished and the host is now contained" reads the playbook line as enforcement, and a host that still answers is not contained. "Treat the ping replies as proof the host is benign and close the customer ticket as a false alarm" confuses reachability with innocence; a compromised host can still reply to ping. "Wipe the host immediately, without first checking how wide the customer incident still is" destroys evidence and skips scope, and the immediate gap is the failed isolation rather than a wipe. Exam caveat: the SOAR entry is evidence of what the playbook attempted, and it is not a packet capture proving the host is cut off. Operational check: open the live isolation status on the control that owns the host, compare it with the SOAR line, and retest from a segment the quarantine is supposed to block.