The Ninety-Minute Routine Alert
Jeff Blake
Director, Field Engineering, Crogl
Ninety minutes. That's what a routine malware alert cost an analyst I sat with last week. The signature was textbook: an endpoint detection alert paired with a policy bypass event, close in time and proximity. I've seen the same pair at almost every customer I work with.
The threat wasn't the hard part. Proving it wasn't a threat was.
She started in the SOAR queue, then pivoted to the EDR for asset context. The case template lives as a Word doc on her desktop. She opened it and began the copy. Hostname into one field. Process names into another. Execution paths, timestamps, and parent IDs lifted from the EDR console and dropped into the template by hand.
The process lineage took twenty minutes by itself. She walked it up one relationship at a time, looking for the parent that explained the child. The EDR shows you the tree. It doesn't tell you what to make of it. That part is the analyst's job.
Back to the SOAR. Was the pattern showing up anywhere else in the environment? Three queries to find out, because the field she needed wasn't indexed the way she wanted. The answer was no. She wrote it down anyway.
Custom KQL came next, for process telemetry the original alert hadn't surfaced. Write the query, run it, read the result, refine, document. Then again for the next data source.
Network telemetry was the next pivot. She pulled up proxy logs, firewall events, and connection history in parallel tabs, then worked across them by hand to build a picture of what the host had talked to and when.
Ninety minutes in, she still didn't have a verdict.
She pulled the quarantined files back through the EDR's remote response shell. The scripts opened. She decoded the embedded images, read what each one did, and wrote it into the case. Then she formatted the case for the next team and sent it on.
After enough of these, the shape of the work changes on you. The analyst is producing evidence. The ninety minutes built a record of how she reached her conclusion, lined up so the next person could read it and follow the work. The conclusion itself was almost a footnote.
Most of what gets sold as SOC automation in this market skips that part. The system produces a label and asks you to trust it. The analyst doesn't, the auditor can't read the work, and the case file is empty when someone later asks how you knew.
The pivoting between consoles and the copy-paste from EDR to template, those are the parts worth automating. The third query because the first two didn't index right, that too. The evidence-building stays with the analyst. The evidence has to be readable tomorrow when someone asks how we knew.
Most of the market does it backwards. Crogl doesn't.
Frequently asked questions
How long does a routine malware alert investigation take?
A routine malware alert cost one analyst ninety minutes in the investigation this Crogl post describes: an endpoint detection alert paired with a policy bypass event. Most of that time went to pivoting between the SOAR, the EDR, and network logs, copying data into a case template by hand, and rerunning queries because a field wasn't indexed the way she needed.
What is evidence-building in security operations?
Evidence-building is documenting how an analyst reached a conclusion, lined up so the next person can read it and follow the work. This Crogl post argues that SOC automation producing only a label fails that test. The analyst doesn't trust it, the auditor can't read the work, and the case file is empty when someone later asks how you knew.
What parts of a SOC investigation should be automated?
The pivot-and-copy work should be automated: pivoting between consoles, copying from the EDR into the case template, and rerunning queries because fields weren't indexed right. The evidence-building stays with the analyst, because the record has to be readable tomorrow when someone asks how the team knew. This Crogl post argues most of the market does it backwards, and Crogl doesn't.
Why does most SOC automation fail analysts?
Most SOC automation produces a label and asks the analyst to trust it. It skips the evidence-building step: the readable record of how the system reached its conclusion. Analysts don't trust black-box verdicts. Auditors can't verify them. And the case file is empty when someone later asks how you knew. Automation that replaces pivoting and copy-paste while preserving analyst-authored evidence is the part the market consistently gets backwards.
What is process lineage analysis in EDR investigations?
Process lineage analysis is the practice of walking up the process tree during an endpoint investigation to find the parent process that explains a child process's behavior. The EDR shows the relationship tree, but it does not interpret what the relationships mean; that is the analyst's job. In the routine malware alert described here, tracing lineage one relationship at a time took twenty minutes by itself.