Incident Response
Real Breach Investigation & Containment

Background

The Problem: No Incident Response Capability

When I joined the organization, there was no formal incident response process. Security events were discovered by end users reporting performance issues or strange behavior — not by any detection tooling. The previous AV (legacy signature-based) generated no meaningful alerts and had no centralized dashboard. When something happened, the response was ad hoc: an IT ticket was opened, someone looked at the machine, and decisions were made without a structured process or documentation.

Five security events had occurred in the 12 months prior to my joining. None had a formal post-mortem. Two involved compromised credentials; one involved malware on a production-floor machine that wasn't identified for several days after the initial infection. The absence of detection tooling, centralized logging, and any IR playbook meant the organization was operationally blind to its own threat landscape.

Building the IR Foundation

Detection: SentinelOne Deployment

The first step was eliminating the detection gap. Legacy AV was replaced with SentinelOne Singularity across all 100+ endpoints — providing behavioral AI detection, centralized telemetry, and the ability to isolate endpoints remotely. (Full deployment write-up: SentinelOne EDR Deployment.) With SentinelOne active, previously-invisible threats became immediately visible and actionable.

Playbook Development

I documented a tiered IR playbook based on the NIST SP 800-61 framework, adapted for a small IT team operating without a dedicated security team:

Incident Summaries (Anonymized)

Incident 1 — Credential Phishing / Business Email Compromise Attempt

Incident 2 — Malware on Production-Floor Workstation

Incident 3 — Unauthorized Remote Access (Shared Credentials)

Incidents 4 & 5 — Summary

Two additional incidents — one involving a ransomware pre-cursor (Cobalt Strike beacon activity detected and contained before stage 2) and one involving a compromised vendor account used to send internal phishing emails — were both contained within the 6-hour MTTR target. Both were detected proactively by SentinelOne and FortiAnalyzer rather than by user reports, demonstrating the direct impact of the detection tooling deployment.

MTTR Improvement

What I Learned from Real Incidents

• Detection is the force multiplier: Every hour from infection to detection is an hour the attacker has to establish persistence. Getting detection time from days to minutes changed everything downstream.
• Playbooks must be pre-written: During an active incident is not the time to decide what to do. The playbook forces you to make those decisions in advance, with a clear head, and then just execute under pressure.
• Shared credentials are a control gap, not a convenience: Incident 3 would have been caught at offboarding if individual accounts had been enforced. Shared credentials create invisible attack surface.
• Every incident is a free penetration test: Each event revealed a gap that became a hardening project. Legacy auth blocking, macro GPO restriction, VPN MFA enforcement — all came out of incident findings.
• Executive communication is part of IR: I reported every incident to management with a plain-language summary: what happened, what we did, and what we're doing to prevent it. Building that trust early meant no pushback on security investments later.

Tools Used