Every SOC analyst knows the feeling. You have a hunch about an attack pattern, so you start building it out in the SIEM search bar. One query, then a filter, then a subquery, then a wall of syntax you will not remember in an hour. You find something interesting, but there is no clean way to save the reasoning, share it, or run it again next week. The work lives and dies in a browser tab.
The SIEM is a great place to store logs and fire alerts. It is a bad place to think.
Where Clicking Through a SIEM Breaks Down
SIEM query languages are built for retrieval, not analysis. That shows up in a few predictable ways.
- Iteration is slow. Each change means re-running a search against the full backend and waiting. You cannot hold intermediate results and poke at them.
- The logic is not portable. A detection expressed as a nest of clicks and menu selections is hard to review, hard to diff, and hard to hand to a teammate.
- Statistics are limited. Once you want a rolling z-score, a clustering pass, or a distribution comparison, most SIEM query languages run out of room fast.
- There is no history. The thinking behind a detection lives in your head or a screenshot, not in anything you can version.
None of this means the SIEM is wrong. It means the SIEM is doing a job it was not designed for.
Move the Analysis into Python and Jupyter
The change is straightforward: pull a slice of data out of the SIEM, do the actual analysis in a notebook, and push validated logic back. Concretely, the workflow looks like this.
Pull data via API. Every serious SIEM and EDR exposes a query API. Use it to pull a representative window (say, a week of authentication events or process starts) into a DataFrame. Now the data sits in front of you and every operation is instant.
Analyze in Pandas. Grouping, joins, rolling windows, value counts, and distribution checks are one line each. You can inspect intermediate results at every step instead of guessing what a monolithic query returned. This is the same tabular toolkit we use in data science for incident responders, and it transfers directly to detection work.
Prototype the detection. Express the detection as code. Compute the feature, set the threshold, and immediately measure how many events it fires on and what they look like. If you are reaching for clustering or an anomaly score, scikit-learn is right there. You see the false positive rate before the rule ever touches production.
Version the result. This is the part the SIEM cannot give you. Commit the notebook and, more importantly, extract the validated logic into a plain module or the SIEM’s rule format. Store it in git with the metadata that matters: data source, time window tested, observed false positive rate, and the ATT&CK technique it covers. A detection becomes a reviewable artifact instead of tribal knowledge.
Why This Changes the Work
Once detections are code, they inherit everything good about code. They get code review, so a second analyst catches the edge case before it pages someone at 3 a.m. They get a history, so you can see why a threshold was set and when it changed. They get reuse, so the beaconing detection you built for one dataset runs against another with a parameter change.
It also raises the ceiling on what you can detect. Approaches that are awkward or impossible in a query language, such as building an anomaly model or an AI agent for threat hunting, become normal work once your data is in a DataFrame and your logic is in Python.
This is a skills shift, not a tooling purchase. You do not throw out the SIEM; you stop asking it to be your analysis environment. The SIEM collects and alerts at scale. Jupyter is where you figure out what to alert on.
If you want to build this workflow with real security data, we teach it in Applied Data Science and AI for Cybersecurity, including the live session at Applied Data Science at Black Hat USA 2026.
Trade the query bar for a notebook and see the difference: join us at Black Hat USA 2026.