Summary Section Redesign & API Changes

We are revamping the Summary section to provide a more structured, narrative-driven experience for analysts, alongside a richer, categorized payload for developers. This update bridges the gap between high-level incident summaries and raw data, allowing for faster verdicts and more flexible integrations.

What’s Changed?

The Overview 

The incident story has been redesigned into three distinct phases for clearer consumption:

• Context: Identifies the origin. Highlights specific assets, users, and initial triggers that started the investigation.

• Analysis: Understands the behavior. Details analysis that have been made, technical actions, software involved, and the scope of the activity.

• Conclusion: Describe the verdict and provides final classification (e.g., Malicious, Inconclusive, Not Harmful).

Findings

The right-hand panel now provides a standardized health check of the incident across critical categories:

• Threat: Determines if the alert's threat is inherently malicious or benign.

• Assets: Confirms the status of involved entities: are they compromised?

• Spread: Analyzes if the threat attempted lateral movement or remained contained.

• Historical Context: Displays insights from previous similar alerts to inform the current verdict (visible when applicable) - Link to more information here

How to Update?

Platform

No action is required; these changes are already live and automatically applied.

HTML Report

The update is in progress and will be available before April 1st on your environment.

API Integrations

If you consume our API, please review the following technical changes and update your logic accordingly.

1. overview[*].question Value Updates

The string values within the investigation.report.overview[*].question field have been renamed.

• Schema Impact: None. The overview field remains Array<Map<string, string>>.

• Legacy Values: "What happened?", "Was there user engagement?", "What is the impact?"

• New Values: "Context", "Analysis", "Conclusion"

Technical Requirement: Update any conditional logic or hardcoded checks in your integration to evaluate against the new string values.

2. Deprecation of indicators Field

The investigation.report.indicators field is officially deprecated.

• Legacy Schema: Array<string>

• Status: Available until April 1st, after which it will be removed entirely from the API output.

3. Introduction of findings Object Array

A new investigation.report.findings field replaces the flat indicators array with a nested, categorized structure.

New Schema Definition:

findings:
  type: array
  items:
    $ref: '#/components/schemas/FindingSection'

FindingSection:
  type: object
  properties:
    section:
      type: string
    findings:
      type: array
      items:
        type: string

JSON Payload Example:

"findings": [
  {
    "section": "Threat",
    "findings": [
      "mskssrv.sys matches benign Microsoft component (0/72 VT)."
    ]
  },
  {
    "section": "Assets",
    "findings": [
      "FR-CHA-LPT15263: mskssrv.sys quarantined pre-execution.",
      "LP15242-BES: mskssrv.sys present, not executed."
    ]
  },
  {
    "section": "Spread",
    "findings": [
      "Contained locally; no lateral movement observed."
    ]
  },
  {
    "section": "Historic Context",
    "findings": [
      "mskssrv.sys previously identified as routine benign OS component."
    ]
  }
]

4. Handling findings[*].section Strings

The section key returns categorized labels (initially "Threat", "Assets", "Spread", "Historic Context").

Technical Constraints & Implementation Logic:

• No Strict Enum: The section field is intentionally typed as a plain string. Future API updates will add, rename, or reorganize these sections without prior schema versioning.

• Mapping Requirement: Integrations must not use section values as stable enums or direct database keys. You must implement a mapping layer with a fallback for unknown strings.

Implementation Example (Python):

# Required: Map dynamic API section labels to stable internal identifiers
SECTION_MAP = {
    "Threat": "threat",
    "Assets": "assets",
    "Spread": "spread",
}

for section_block in report["findings"]:
    section_label = section_block["section"]
    # Fallback applied for any newly introduced API section labels
    internal_key = SECTION_MAP.get(section_label, "other") 
    
    for finding in section_block["findings"]:
        store_finding(internal_key, finding)