Ron Shenkar
MenuClose

CASE STUDY

AI Incident Investigation

Designing an AI-assisted investigation experience that helps security analysts move from incident understanding to evidence validation and response.

AI Incident Investigation product screen: incident overview with an AI incident brief, alert summary and an attack-stage storyline showing attack progression and defense response
ROLE
Senior Product Designer
DOMAIN
Automotive Cybersecurity
FOCUS
AI-Assisted Investigation
SCOPE
Product Strategy · UX · UI · Interactive Prototype
COLLABORATION
Product · Engineering · Cybersecurity Experts

01

CONTEXT

A complex security incident only makes sense when you can see the full story.

Automotive cybersecurity incidents are rarely represented by a single alert. An investigation can involve multiple signals, affected assets, entities, evidence, timeline events, and response actions.

These elements are often distributed across different views and levels of detail, making the incident itself difficult to understand as one coherent sequence of events.

02

THE CHALLENGE

Analysts had the evidence. What they lacked was a clear, trustworthy picture of the incident.

Investigations can span dozens of alerts, multiple entities, affected assets, and response actions. Each piece may be valid on its own, but when it is distributed across separate views, analysts have to spend valuable time reconstructing the sequence and relationships before they can investigate with confidence.

At the same time, an AI-generated summary can speed up orientation only if analysts can understand where it came from, verify the underlying evidence, and remain in control of any response action. Speed without traceability would simply introduce a different kind of risk.

The challenge was therefore not to show more information, but to reduce the cognitive effort required to understand the incident while preserving evidence, context, and analyst control.

03

RESEARCH

Understanding how analysts turn fragmented signals into a trusted incident story.

What I needed to understand

I wanted to understand how VSOC analysts investigate incidents, where the process becomes slow or confusing, which information they need first, and what would help them move more efficiently from detection to understanding and action.

I also wanted to examine how leading cybersecurity platforms structure incident investigation and how they balance summaries, timelines, evidence, entities, and response actions.

How I learned

  1. 01

    VSOC analyst interviews

    I interviewed four analysts from the VSOC department to understand their investigation workflows, daily challenges, and what could help them analyze incidents more effectively.

  2. 02

    Comparative product research

    I reviewed incident investigation experiences from:

    Microsoft Defender XDR
    Google Security Operations
    Palo Alto Networks Cortex XDR / XSIAM
    CrowdStrike Falcon / Incident Workbench

    The review focused on how each platform presents incident summaries, attack progression, entities, evidence, timelines, automated conclusions, and response actions.

  3. 03

    AI-assisted comparative analysis

    I used ChatGPT, Claude, and Gemini as research tools to compare the different platforms, identify recurring patterns, and examine the strengths and limitations of each approach.

    AI accelerated the comparative analysis. The conclusions were based on the reviewed workflows and the interviews with the VSOC analysts.

Comparative research: incident investigation screens from Palo Alto Networks Cortex XDR / Cortex XSIAM, Google Security Operations, CrowdStrike Falcon — Incident Workbench, and Microsoft Defender XDR
Microsoft Defender XDR incident investigation screen

Microsoft Defender XDR

Google Security Operations incident investigation screen

Google Security Operations

Palo Alto Networks Cortex XDR / Cortex XSIAM incident investigation screen

Palo Alto Networks Cortex XDR / Cortex XSIAM

CrowdStrike Falcon Incident Workbench investigation screen

CrowdStrike Falcon — Incident Workbench

What I learned

The research revealed that the primary challenge was not access to data, but the effort required to connect it.

Analysts may need to move between alerts, entities, timelines, logs, and security tools before they can reconstruct the incident as a coherent story. This increases investigation time and makes it more difficult to identify the most important information.

  1. 01

    A clear first layer before more data

    Analysts need an initial view that explains the incident, its severity, likely cause, scope, and current status.

  2. 02

    Turn alerts into a narrative

    Individual signals are easier to understand when they are connected into meaningful attack stages rather than presented only as a chronological event list.

  3. 03

    Show the defense as well as the attack

    Understanding the attack is only half of the investigation. Analysts also need to see how the defensive system responded at each stage and where prevention, detection, or containment failed.

  4. 04

    Make AI conclusions transparent

    Analysts need to distinguish between confirmed evidence and inferred relationships, understand confidence levels, and trace conclusions back to their sources.

  5. 05

    Preserve context during deep investigation

    Analysts should be able to inspect evidence, entities, and raw activity while remaining connected to the incident stage they are investigating.

  6. 06

    Keep significant response actions under human control

    Recommendations should explain their reason, scope, and expected impact before an analyst approves or dismisses them.

04

KEY PRODUCT DECISIONS

The research led to five product decisions that shaped the investigation model, from the first moment of orientation to deeper validation and response.

DECISION 01

Design for the first minute

PROBLEM

The interviews and competitive research showed that incident pages often expose a large amount of information before establishing a clear hierarchy.

DECISION

Create an incident overview that immediately presents an AI-generated summary, the likely root cause, key evidence, severity, affected assets, compromised identities, data sources, and pending actions.

RATIONALE

The analyst should not need to reconstruct the basic incident story manually before beginning the investigation.

DESIGN NOTE

The top section provides a concise AI incident brief supported by confidence levels and key evidence. Summary cards communicate the incident scale and operational status at a glance.

DECISION 02

Pair attack progression with defense response

PROBLEM

Most investigation experiences focus primarily on attacker behavior. This makes it harder to understand where the defensive system succeeded, responded late, or failed to contain the threat.

DECISION

Present every attack stage together with the corresponding defensive response.

RATIONALE

The experience should not only explain what the attacker did, but also reveal how the defensive system responded and where that response could be improved.

The model treats attack progression and defense response as two connected parts of the same incident story.

S05 — Focused Stage Comparison: the five attack stages, from initial access to the OTA deployment attempt, each paired with its defense response
Timeline → Stage Comparison

DECISION 03

Make AI conclusions explainable

PROBLEM

AI can accelerate analysis, but analysts cannot rely on conclusions that appear without supporting evidence.

DECISION

Clearly label AI-generated insights and connect them to confidence levels, evidence, and relevant stages in the storyline.

RATIONALE

AI should reduce investigation time without asking the analyst to accept a conclusion that cannot be explained or verified.

Crop of the incident overview: AI incident brief at 92% confidence, likely root cause marked as AI inference at 88% confidence with a View in Storyline link, and key evidence

DESIGN NOTE

The interface distinguishes AI inference from confirmed facts, displays confidence levels, highlights the likely root cause, and provides direct access to the supporting storyline and evidence.

DECISION 04

Preserve context while going deeper

Incident storyline with the Execution attack stage selected and its Overview drawer open on the right, showing why it matters, affected entities and the defensive outcome while the storyline stays visible

PROBLEM

Moving between separate pages can make analysts lose their position in the investigation and repeatedly reconstruct context.

DECISION

Provide several levels of investigation within the same incident experience.

RATIONALE

The analyst should be able to move from a broad understanding to detailed evidence without losing sight of the overall story.

DESIGN NOTE

Selecting a stage opens a contextual side drawer with its evidence, entities, MITRE ATT&CK mapping, and defensive outcome, while the surrounding storyline stays in view.

DECISION 05

Keep consequential actions under human control

PROBLEM

Some response actions, such as isolating an endpoint or suspending an account, may affect business-critical systems.

DECISION

Allow automation to recommend actions while requiring analyst approval for responses with significant operational impact.

RATIONALE

Automation should support decision-making without removing accountability or operational judgment.

Pending response actions modal over the incident storyline: two automation-recommended actions, each with reason, expected impact, scope and source, awaiting analyst approval; one is being dismissed with a required reason recorded in the audit trail

DESIGN NOTE

Automation can identify what should be done, but the analyst retains responsibility for judging whether an action’s operational impact is acceptable at that moment.

Each recommendation therefore shows its reason, scope, and expected impact, so approval is an informed decision with a clear owner, not a default the analyst has to catch.

05

THE EXPERIENCE

From first orientation to accountable action, without breaking the investigation context.

  1. 01Orient
  2. 02Investigate
  3. 03Validate
  4. 04Act

01ORIENT

The analyst begins with a concise overview of the incident.

The AI incident brief explains what happened, identifies the likely root cause, presents the key evidence, and summarizes the incident severity and scope. Supporting cards show the number of alerts, affected hosts, compromised identities, data sources, and pending response actions.

This first layer was designed around a one-minute orientation target, used as a guiding design principle rather than a measured usability outcome.

Incident Overview, focused state: incident title, severity and risk score, the AI incident brief with 92% confidence, summary, likely root cause at 88% confidence, key evidence, and the alerts, affected hosts, compromised identity, sources and actions pending cards

02INVESTIGATE

The Storyline transforms fragmented alerts into five meaningful attack stages:

  1. 1Initial access
  2. 2Execution
  3. 3Credential access
  4. 4Lateral movement
  5. 5OTA deployment attempt

Each stage is paired with the corresponding defensive response, allowing the analyst to understand both the attacker’s progression and the effectiveness of the security controls.

A proportional time axis communicates when events occurred and highlights delays between the attack and the defensive response.

Timeline
when events happened
Stage Comparison
how the defense responded to each attack stage

03VALIDATE

The analyst validates the incident by tracing the evidence and relationships behind the story.

The Investigation Map connects the affected files, processes, identities, endpoints, infrastructure, and defensive controls involved in the incident.

Confirmed and inferred relationships are visually differentiated, helping the analyst evaluate how strongly the available evidence supports the incident narrative.

Investigation Map: entity graph linking the Q3_Bonus_Plan.xlsm file, endpoint FIN-LT-042, powershell.exe, lsass.exe, identity Alex Morgan, external IP 203.0.113.42, server FIN-SRV-02 and the egress gateway, with confirmed and inferred relationships

04ACT

Once the incident is understood and validated, the analyst can review the recommended response actions.

Each action includes its reason, scope, expected impact, and the automation or response plan that recommended it. Actions with significant operational impact remain pending until the analyst approves them.

If the analyst decides not to proceed, the action can be dismissed with a documented reason that is preserved in the incident audit trail.

Dismissal requires a documented reason

Fast orientation for immediate understanding.

Evidence-based investigation for deeper validation.

Human-controlled response for accountable action.

Instead of forcing analysts to choose between a simplified summary and a complex investigation environment, the experience connects both. It provides a clear picture of the incident first, then allows the analyst to investigate as deeply as the situation requires.