How long does a routine malware alert investigation take?

A routine malware alert — a textbook endpoint detection event paired with a policy bypass — took a skilled analyst ninety minutes to close. Most of that time was not spent analyzing the threat. It was spent pivoting between consoles, copying data into a case template by hand, writing custom queries because fields weren't indexed as needed, and correlating network telemetry across parallel tabs. The investigation itself was straightforward. Building a readable record of how she reached her conclusion was not.

What is evidence-building in security operations?

Evidence-building is the process of documenting how an analyst reached a conclusion during a security investigation — not just what the verdict was, but the full record of data gathered, pivots made, and reasoning applied. The case file needs to be readable by the next analyst, an auditor, or an incident responder who was not present. SOC automation that produces only a label without a readable evidence trail fails this requirement: the analyst doesn't trust it, the auditor can't verify it, 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: pulling asset context from the EDR, populating case templates, running follow-on queries across data sources, and correlating telemetry across consoles. The same applies to redundant queries that analysts run only because fields aren't indexed the way they need. What should not be automated is the evidence-building itself — the reasoning, documentation, and chain of analysis that makes the case readable to the next person. Automating the former without replacing the latter is the right dividing line.

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. Incident responders inheriting the case can't follow the work. The result is that analysts still do the investigation themselves to produce a record they can stand behind, even when automation has nominally closed the alert. 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. Tracing lineage one relationship at a time to identify the originating process is one of the most time-consuming steps in a routine malware alert investigation, and one of the clearest candidates for automation.

← Resources

BlogJune 16, 2026

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.

See it in your environment.

The Ninety-Minute Routine Alert

Outcome-Driven Security Operations Require Multi-Model Support

Neurosymbolic Systems for SOC Operations

Download Crogl free.