CS0-003 Incident Response and Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Conduct a tabletop exercise for the incident response team.

  Why it's wrong here

  Tabletop exercises are an evaluation or training mechanism for incident response processes, roles, and communication flows, not a method for modifying detection content. Running a dry-run with the team may surface procedural gaps, such as unclear escalation paths, but it does not add or tune any signature, YARA rule, or SIEM correlation logic. Because the goal is to improve human readiness rather than defensive sensors, it would not have directly detected the actual ransomware on the network.

• ✗

  Increase the frequency of vulnerability scans.

  Why it's wrong here

  Vulnerability scanning is a proactive posture activity that identifies missing patches, weak configurations, or known CVEs, but it is not a detection-rule update. Even if the ransomware exploited a known vulnerability, the scanner does not write indicators or behavioral patterns into the SIEM, EDR, or endpoint protection. Increasing scan frequency might reveal the attack surface before exploitation, but it provides no mechanism to detect the specific ransomware's files, hashes, or attacker TTPs during an active intrusion.

• ✓

  Create YARA rules to identify the ransomware file hashes and patterns.

  Why this is correct

  YARA rules are highly effective for endpoint detection of a known ransomware strain because they can match on multiple characteristics beyond simple hashes—such as unique strings, mutex names, byte patterns, PE section anomalies, and file metadata. By creating a rule that evaluates file content and structure, the team can identify the malicious payload regardless of filename or hash mutation (e.g., hash-busting variants), enabling rapid triage on forensic images and live systems. This directly addresses the immediate need to recognize the specific ransomware artifacts that were observed during the incident.

• ✗

  Share IOCs with external threat intelligence platforms.

  Why it's wrong here

  Sharing IOCs with external threat intelligence platforms (e.g., MISP, ITX) is a community-based defense action that benefits other organizations by publishing indicators like IPs, domains, and hashes, but it does not alter the incident team's own detection infrastructure. The action is outward-bound; until an external feed is imported back into the SIEM or EDR and configured as a detection source, it has no effect on internal monitoring. Moreover, relying solely on blocklists after an incident is often insufficient because the same TTPs may be reused with new IOCs, so this step alone is not a direct detection-rule update.

• ✓

  Update the SIEM correlation rules to detect the TTPs observed.

  Why this is correct

  Updating SIEM correlation rules to encode the observed TTPs—such as suspicious PowerShell invocation, process injection into LSASS, abnormal SMB activity, or C2 beaconing patterns—enables the SOC to detect future instances of similar behavior without depending on static hashes or filenames. This is a detection-rule update because it modifies the analytical logic used to surface alerts from raw log and event streams. By aligning correlation rules with the MITRE ATT&CK techniques used by the ransomware, the team shifts from reactive IOC matching to proactive behavioral detection, which is more resilient to minor variations in the malware.

Go deeper

Related to this question