Michael Krawczyk | Information Security Engineer · 18+ YRS · MCP
Return
Incident Response · How I Investigate
This Is My Forensic Mindset
Three parallel tracks. Six standards. The investigation framework I run on every high-impact case.
🛡️
Track 1
Recovery
🔬
Track 2
Attribution
📋
Track 3
Documentation
The six standards I hold myself to
01 define
Define the Claim Precisely
I don't accept "AV is breaking backups" as a conclusion — that's a hypothesis. I translate it into testable statements: did AV quarantine a file? Did it cause I/O contention? Did it block a process? I only close the claim when I can show the exact mechanism and a timeline that actually fits.
Hypothesis First
02 anchor
Build the Timeline Before You Test Anything
The timeline is the spine of every investigation. I anchor on first known good, first known bad, policy change times, automation execution windows, and system event timestamps. Then I look for cause-worthy adjacency — a symptom that begins inside the plausible window of a high-privilege action. If the timing doesn't fit, the theory doesn't hold.
Timeline First
03 capture
Treat Evidence Collection Like a Controlled Capture
Even when I'm not doing a legal forensic acquisition, I behave like I might need to defend my findings later. Raw log excerpts with timestamps and source context. Screenshots when GUI evidence matters. Hostnames, versions, policy IDs, agent versions — all noted. I also separate what I observed directly from what was reported to me. The goal isn't lots of notes. It's high-signal notes that stand on their own.
Evidence Integrity
04 prove
Separate Correlation from Causation — Require a Mechanism
This is where most troubleshooting writeups fail. Correlation is easy. Mechanism is harder. If AV is suspected I look for quarantine logs, remediation events, detection names, file paths, and process lineage. If automation is suspected I identify the exact job, the specific actions it performed, and whether I can map each one to a symptom. I don't call something "interference" unless I can show the full chain from action to impact.
Prove The Chain
05 fix
Keep Remediation Production-Safe by Default
Every fix I make is controlled, reversible, and verified. Pre-checks confirm the condition exists and capture a before state. The remediation is the smallest viable change. Post-checks confirm it's resolved and record the after state. Rollback steps exist before I touch anything. I'm not going to close one outage and open a different one because I moved too fast.
Smallest Viable Fix
06 write
Write Documentation for Review — Not Just Closure
My ticket notes are structured so a peer can pick up the case without any tribal knowledge. Facts observed. Evidence and where it came from. Hypotheses considered and why they were accepted or rejected. Tests and results. Root cause with a mechanism. Remediation, verification, rollback plan, and residual risk. Closing the ticket is not the finish line. Closing it in a way that survives audit is.
Built For Audit
3.5
/ 5.0
Where I Sit on the Forensic Reviewer Scale
I operate with forensic discipline in both mindset and method. The gap between 3.5 and 4.5 isn't about skill — it's about formalizing the things I already do: evidence capture headers, integrity hashing on key artifacts, explicit limitations blocks, and consistent conclusion confidence ratings. That's the next level.
Timeline Rigor
Mechanism Proof
Documentation
Formal Evidence
Chain of Custody