Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Security Breach Investigation

Scenario​

After a security breach, the organization needs to investigate how the incident occurred and confirm whether a Data Security Edition detection reflects a genuine, wider security incident — not just a storage-layer anomaly.

Implementation​

Enable an auditing database that logs all data operations and provides powerful search capabilities. Treat Data Security Edition as one detection domain within a broader incident response (IR) process: combine its storage-layer alerts with investigation from your endpoint protection and Identity and Access Governance (IAG) tools before deciding on lockout, recovery, or closure.

Incident response workflow​

Data Security Edition alerts include the context you need to start an end-to-end IR process: the username, client IP address, action taken (for example, user lockout enabled or disabled), the affected SMB/NFS share list, and a summary of affected files. Storage-layer detection is a symptom — the entry point of a breach is usually the endpoint, so treat this workflow as one part of a larger, multi-domain investigation rather than a standalone verdict.

Step 1 — Open an investigation​

Create an investigation or incident in your SOC tooling for the reported threat, using the event's username, client IP, and affected shares as the starting context.

Step 2 — Client IP investigation (endpoint)​

Look up the client IP in your endpoint management system and review any threat signals already logged for that host. If your endpoint software supports it, launch a deep scan and add any resulting artifacts to the SOC investigation.

Step 3 — Username investigation (IAG)​

Check the affected username in your Identity and Access Governance (IAG) platform for anomalous login behavior that could indicate account compromise. Add any findings to the SOC investigation.

Step 4 — Storage-layer decision​

Once you've gathered endpoint and IAG context, decide whether the storage-layer detection needs further action:

  • If enforcement mode is enabled and the user is already locked out, leave the lockout in place.
  • If enforcement mode is not enabled globally, open the event's Actions menu and select Lockout User to lock the user out of the file system.
  • Confirm the affected SMB shares in the event detail (already included automatically in SIEM/SOAR integrations) and add them to the SOC investigation's artifact list.
  • Verify that snapshots were taken for the active event.
  • Check whether other active events exist. Additional active events are a further indicator of possible compromise and should go through the same multi-domain review.
  • If your environment is facing a multi-host incident, consider enabling enforcement mode to limit the blast radius.

Use the combined endpoint, IAG, and storage-layer context to reach a final determination:

  • False positive — unlock the user and archive the event as resolved. See Triage workflow by severity for the closing steps.
  • Confirmed breach — continue to the forensics phase below.

Step 5 — Forensics phase (confirmed breach only)​

Only begin this phase after multi-domain context indicates a genuine breach. Validate the endpoint first — it's the entry point of the breach, and the storage-layer detection is a downstream symptom.

  • Open the event's Actions menu and review its detection history. If a suspicious file extension is listed, search for it online to identify the ransomware variant and understand its likely capabilities and mitigation options.
  • Run a 60-day user search for each affected username using Data Auditing → Queries & Reports. Review the user's file access patterns over that window for signs of bulk rename, bulk delete, or bulk read operations — indicators of data exfiltration rather than a single isolated event.

Storage-layer forensics is one component of a larger incident response process. Detection and response at the storage layer should not be the sole basis for concluding whether a breach or cyber incident occurred.

Quick assessment — Severity and Signal Strength​

Use the event's Severity and Signal Strength together to gauge how the detection should factor into your response, alongside the endpoint and IAG findings above:

  • Warning — low probability of infection.
  • Major — an increased probability of infection, or a medium-confidence user-behavior pattern.
  • Critical — a strong ransomware-consistent user-behavior pattern; a lockout decision should be made alongside a review of the affected files.
  • Signal Strength — at any severity, a higher Signal Strength indicates a continuous, repeating detection pattern, which is more consistent with active ransomware behavior than an isolated spike.

For the full terminology reference and the detailed triage workflow (opening events, reviewing the CSV export, and the Actions menu), see Threat Detections.

Outcome​

Security analysts combine storage-layer detection with endpoint and IAG context to reach a confident determination of false positive versus confirmed breach, efficiently sift through logs to pinpoint root cause, and enact preventive measures to avert similar incidents in the future. In the event of a confirmed incident, the 60-day user search and full audit trail support forensic investigation and recovery decisions.

See also​

  • Threat Detections — Full triage workflow by severity, the Actions menu, and Recovery Manager.
  • Data Auditing — Queries & Reports and WireTap, used to search and preview data operations, including the 60-day user search described above.
  • Integrations — Configure SIEM/SOAR webhook integration so your SecOps team receives event context automatically.