Secops Cases

3. Case Inspection and Alert Linking

Cases group one or more related security alerts that represent a single attack chain or incident scope. Alert linking connects new detections to existing cases.

• Step 1: Retrieve Case Context
  • Remote: Call get_case(case_id=..., expand="tasks,tags,products").
  • Local: Call get_case_full_details(case_id=...).
• Step 2: Inspect Associated Alerts
  • Remote: Call list_case_alerts(case_id=...).
  • Local: Call list_alerts_by_case(case_id=...).
• Step 3: Analyze Alert Grouping & Evidence
  • Identify alert group identifiers using list_alert_group_identifiers_by_case.
  • Retrieve underlying raw connector events using list_connector_events (Remote) or list_events_by_alert (Local).
  • Retrieve involved entities using list_involved_entities (Remote) or get_entities_by_alert_group_identifiers (Local).
• Step 4: Correlate and Link Alerts
  • When investigating incoming alerts that share indicators (same target host, compromised user credentials, or command-and-control IP) with an open case, group or associate the alert with the existing case_id rather than generating redundant cases.
  • Document the alert correlation rationale in a case comment.

4. Updating Case Priority and Status

As evidence emerges during an investigation, adjust the case severity and operational stage to reflect current risk.

• Priority Levels:
  • PriorityInfo: Informational events with no immediate operational impact.
  • PriorityLow: Low severity, standard tracking, no business disruption.
  • PriorityMedium: Anomalous behavior requiring validation within standard SLA.
  • PriorityHigh: Active exploit attempts or confirmed credential misuse.
  • PriorityCritical: Confirmed breach, active ransomware, or sensitive data exfiltration.
• Updating Priority:
  • Remote: Call update_case(case_id=..., priority="PriorityHigh").
  • Local: Call change_case_priority(case_id=..., case_priority="PriorityHigh").
• Updating Description & Scope:
  • When the attack vector or blast radius is confirmed, update the case summary.
  • Remote: Call update_case(case_id=..., description="...").
  • Local: Call update_case_description(case_id=..., description="...").
• Updating Lifecycle Stage & Assignment:
  • Remote: Call update_case(case_id=..., status=..., assignee=...).
  • Local: Call change_case_stage(case_id=..., stage=...) and assign_case(case_id=..., user=...).

5. Adding Case Comments and Investigation Notes

Document every investigative step, enrichment finding, and remediation action to maintain an auditable chain of custody.

• When to Comment:
  • Documenting SIEM UDM search results or IOC matches.
  • Recording host isolation, password reset, or IP blocking actions.
  • Summarizing communications with asset owners or incident commanders.
• Tool Invocations:
  • Remote: Call create_case_comment(case_id=..., comment=...).
  • Local: Call post_case_comment(case_id=..., comment=...).
• Comment Format Standard:

  ### Investigation Note: [Topic]
  - **Timestamp / Phase**: Triage / Containment / Remediation
  - **Findings**: Summary of extracted artifacts and validated activity.
  - **Entities Involved**: Host: `hr-ws-04`, User: `jdoe`, IP: `198.51.100.22`
  - **Actions Taken**: Blocked external IP on firewall; forced credential rotation.
  - **Next Steps**: Monitor authentication logs for recurring anomalies.

6. Case Closure and Final Determination

When containment and verification are complete, close the case with full attribution and categorical categorization.

• Closure Criteria:
  • All linked alerts have been investigated.
  • Containment and remediation actions are validated.
  • Final executive summary is recorded in comments.
• Closure Categorization Enums:
  • Malicious: Confirmed security threat or unauthorized activity.
  • NotMalicious: Benign true positive or authorized administrative activity.
  • Maintenance: Expected alert triggered by scheduled testing or system maintenance.
  • Inconclusive: Insufficient telemetry to confirm or refute malicious intent.
• Tool Invocations:
  • Remote: Call execute_bulk_close_case(case_ids=[...], root_cause="...", reason="NotMalicious", comment="...").
  • Local: Call close_case(case_id=..., root_cause="...", reason="NotMalicious", comment="...", tags="...").
• Verification:
  • Call list_cases or get_case to confirm status reflects closed state.

Best Practices & Safety Guardrails

1. Verify Case Existence Before Updates: Fetch case details with get_case or get_case_full_details before modifying priority, comments, or status, because updating a nonexistent or closed case causes RPC failures and risks modifying stale incident state.
2. Document Root Cause Before Case Closure: Every case closure must include a specific root cause and explanatory comment, because missing root-cause metadata prevents SOC metrics tracking, breaks compliance audit trails, and stops detection engineers from tuning noisy rules.
3. Preserve Case History: Append notes via comments rather than overwriting descriptions unless correcting factual inaccuracies, ensuring an immutable chronological audit trail for incident response handovers.
4. Correlate Before Creating: Search existing open cases (list_cases) before creating a new case to prevent ticket fragmentation and avoid split investigations for the same alert cluster.