Cynet Incident Response Plan Template

Standard Operating Procedure: Cybereason (Cynet) Incident Response & Triage Execution

Document ID: SOP-SEC-CYN-042
Effective Date: October 24, 2023
Version: 3.1.0
Review Cadence: Semi-Annual
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational lifecycle for detecting, containing, eradicating, and recovering from security incidents utilizing the Cybereason (Cynet 360 / Cybereason Defense Platform) Extended Detection and Response (XDR) ecosystem. The purpose of this document is to establish a deterministic, institutional-grade protocol for Security Operations Center (SOC) analysts and Incident Response (IR) engineers to minimize Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR), preserve evidentiary integrity, and ensure zero-downtime execution of containment plays.

---

2. Scope & Prerequisites

2.1 Scope

This procedure applies to all endpoints, servers, cloud workloads, and network segments monitored by the Cynet agent or integrated via Cynet Network Analytics and Deception modules across all corporate and production environments managed by Template Registry.

2.2 Prerequisites & Required Access

• Platform Access: Cynet Master Console Administrator or Tier-3 IR Analyst RBAC role.
• Auxiliary Tools:
  • SIEM / Log Aggregation platform (Splunk / Elastic) for cross-correlation.
  • Out-of-band communication channel (Signal / PagerDuty) for incident command.
  • Forensic workstation equipped with KAPE (Kroll Artifact Parser and Extractor) and Wireshark.
• Physical/Environmental: Dual-factor authentication (2FA) enforced on all administrative access sessions.

---

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Procedure

Phase 1: Triage & Validation (0 - 15 Minutes)

• Log in to the Cynet 360 console via verified SSO and navigate to the Alerts dashboard.
• Filter alerts by Severity (Critical / High) and review incoming Cynet Guardian automated correlation vectors (e.g., suspicious process injection, lateral movement, credential dumping).
• Inspect the associated Suspect or Malicious file hashes against internal threat intelligence feeds and VirusTotal via the Cynet automated file-lookup API.
• Determine if the alert represents a True Positive (TP) or False Positive (FP).
  • If FP: Document rationale, adjust Cynet behavioral suppression rules, and close ticket.
  • If TP: Escalate incident status to Active Containment and open the Incident Bridge.

Phase 2: Containment & Isolation (15 - 45 Minutes)

• Navigate to the Endpoints view within the Cynet console and locate the compromised asset(s).
• Execute immediate network isolation to sever command-and-control (C2) channels while preserving memory state:
  • Select target endpoint $\rightarrow$ Click Isolate.
  • Note: Ensure critical business continuity servers (e.g., primary domain controllers) are placed in custom containment policies restricting inbound/outbound traffic exclusively to the SOC jumpbox.
• Terminate active malicious processes identified in the process tree:
  • Click Kill Process on the root cause execution path.
• Quarantine suspected binaries across all endpoints:
  • Highlight malicious hash $\rightarrow$ Select Quarantine File to automatically purge the payload from disk storage.

Phase 3: Eradication & Forensic Acquisition (45 - 120 Minutes)

• Extract full process execution telemetry, network connection logs, and file modification history from the Cynet Forensic Investigation module.
• Trigger remote memory acquisition via the Cynet remediation interface or deploy secondary tooling (DumpIt/WinPmem) if deep-dive kernel analysis is required.
• Identify persistence mechanisms (Registry Run keys, Scheduled Tasks, WMI event subscriptions, or Cron jobs) created by the threat actor.
• Remove identified persistence mechanisms manually or via Cynet remediation scripts.
• Patch or remediate the root-cause vulnerability (e.g., zero-day exploit, exposed RDP, compromised credentials) that permitted initial access.

Phase 4: Recovery & Validation (120+ Minutes)

• Run a targeted full-system antivirus/behavioral scan across remediated endpoints using the updated Cynet signature database.
• Validate system integrity, service availability, and application health with the respective IT Infrastructure System Owner.
• Lift endpoint isolation via the Cynet console once stability and sanitization are confirmed:
  • Select isolated endpoint $\rightarrow$ Click Remove Isolation.
• Verify telemetry resumption: Ensure heartbeat signals and log forwarding from the restored asset return to normal operational thresholds within the Cynet console.

Phase 5: Post-Incident Review

• Compile all Cynet-generated incident reports, indicators of compromise (IoCs), and timelines into the master incident ticket.
• Conduct a post-mortem review with the IR team within 72 hours to update Cynet detection policies, Yara rules, and prevention profiles.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Never delete immediately: Always quarantine files rather than execute destructive local deletions immediately, ensuring recovery options exist if a critical OS binary is misidentified.
• Preserve Context: Prioritize isolating the host over killing processes if dealing with advanced adversaries who employ process-hollowed monitoring watchdogs.

Common Pitfalls

• Premature De-isolation: Releasing an endpoint from isolation before verifying root-cause elimination invariably leads to reinfection via secondary persistence artifacts.
• Ignoring Lateral Movement Indicators: Treating an isolated alert as an isolated event without checking adjacent endpoints linked via SMB/RDP telemetry.

Metric Thresholds

• Mean Time to Detect (MTTD): $\le 5\text{ minutes}$ from initial payload execution.
• Mean Time to Respond (MTTR): $\le 15\text{ minutes}$ for critical endpoint isolation.

---

6. Frequently Asked Questions (FAQ)

Q: What should I do if the Cynet agent fails to isolate a compromised host due to a severed network interface?
A: If network isolation commands fail due to severed connectivity or agent unresponsiveness, immediately coordinate with the network engineering team to implement Access Control Lists (ACLs) or VLAN shifts at the switch/firewall layer to quarantine the hardware physically.

Q: How do I handle a critical business asset where immediate isolation will cause catastrophic operational downtime?
A: Escalate immediately to the Incident Commander. Execute a "surgical containment" approach: use Cynet to block outbound external communication and terminate the specific malicious process tree, while keeping internal service ports open under strict SOC observation until a maintenance window permits full isolation.