Two workflows, one evidence record.
New detections go through the detection pipeline. Live rules that get noisy go through the tuning loop. Each flow stops twice for an engineer, and every stage leaves an artifact your team can review. Start with the flow that hurts most.
New detection pipeline
From an ATT&CK technique or a threat report to a validated, packaged detection.
- Research
- Coverage
- Simulate & investigate
- Design
- Gate 1
- Build
- Policy
- Gate 2
- Validate
- Package
- Monitor
A brief you can check
Turns a technique or threat report into a structured threat brief, with cited procedures and atomic test variants.
Is the data there?
Checks each procedure against your SIEM: available normalized, available raw, or missing. An empty search is not evidence; the agent re-checks with smaller windows before it marks a source missing.
Run the attack, read the logs
Runs Atomic Red Team variants in your lab. Each run carries a signed marker, so only genuine test events count. Then it investigates the logs per variant.
Primitives before SPL
Breaks the technique into 3 to 7 capability primitives and picks the layer: atomic, behavioral, UEBA or hybrid. Proposes risk-based alerting correlation across the TTP chain.
G1 Engineer gate. Approve the design, or send it back.
Your repository format
Detection YAML, filter macro and test samples that must pass your repository validator. Base searches go through macros or datamodels, never hardcoded indexes.
Exceptions with a reason
Applies your allowlist file. Every exception has a justification and is written to a tamper-evident, hash-chained audit log.
G2 Engineer gate. Approve the merge request.
Proof both ways
Needs true-positive evidence from the simulation and false positives per day under your team's target over a 7 to 30 day baseline. A failure carries a typed reason that sends the work back to the right stage.
- syntax errorback to Build
- logic errortelemetry gapback to Design
- too many false positivesback to Design, with samples
- missing infrastructurestop and ask the team
Ready to hand over
A runbook per detection, a design record, the ATT&CK mapping and a checksummed manifest. Refuses to package if any detection is blocked.
Catch drift early
Coverage matrix and ATT&CK heatmap, with a drift alert when a rule's true-positive rate drops.
Tuning loop
For a live detection that has become noisy. Eight steps, two engineer gates.
- Intake
- Sample & measure
- Profile
- Diagnose
- Gate 1
- Design & measure
- Gate 2 & deploy
- Post-check
One rule, one owner
Confirms the rule exists, is enabled and has been stable for two weeks. Snapshots its configuration and claims it, so two people never tune it at once.
Look before touching
Exports alerts from a 7-day window (up to 30), masking usernames and secrets. Measures volume by day and hour, analyst dispositions, top values per field, and required versus actual log sources.
What the rule is for
Writes what the rule is meant to catch and the assumption behind each condition. An automated checker rejects any claim that cites SPL or fields that do not exist.
Causal clusters
Groups alerts by cause, each cluster with the field that separates it and a label such as logic false positive, benign true positive or telemetry gap. Self-checks first: nearly all alerts clustered, none in two clusters, no confirmed true positive in a cluster proposed for removal.
G1 Engineer gate. Pick one outcome, the clusters to drop and the values that must keep firing.
Measure exactly what disappears
Drafts the smallest exception, with must-keep and must-drop test cases and an anti-evasion rationale when it keys on attacker-controlled fields. Measures the exact set of alerts that would disappear, not just before and after totals; every one must map to a cluster the reviewer chose to drop. An independent reviewer sees only the change and the numbers.
G2 Engineer gate and deploy. The live rule is re-read first, and the run stops if it changed since the snapshot. An engineer approves the exact change and its rollback; a guarded deploy script makes the only write, with a backup and a hash-chained audit entry.
Confirm it held
After enough scheduled runs, confirms the reduction matches the measurement and must-keep values still fire. Rollback is verified by re-reading the SIEM.
Stop before it is silent. The loop aims at most of the diagnosed noise, not all of it. A drop to zero alerts is treated as a red flag, not a win.
Guardrails
The rules every agent runs under, whichever flow it is in.
Agents never deploy
Every production change is a human-approved step.
Read-only production access
Agents search your SIEM; they cannot change it.
Capped runs
Each run has a spawn and budget cap, and returns partial results instead of running away.
Secrets scan before every write
Nothing with a credential in it leaves the agent.
Destructive SPL is blocked
Commands that write, delete or alter data are rejected.
Exceptions are owned
Every exception has a justification, an owner and an expiry.
Every write is audited
Each write lands in an append-only, hash-chained log.
How Kyrolan fits your Splunk
Kyrolan does not replace Splunk and does not ingest your logs. Splunk stays your SIEM, your repository stays the source of your rules, and your CI/CD stays the only path to production. The agents work on top of that detection engineering workflow.
- 1Read-only searches. Kyrolan agents run read-only searches in your Splunk and get the query results back.
- 2Merge requests. Agents propose changes as merge requests in your detection repository (Git).
- 3Engineer review & approval. Your engineer approves the merge request, or sends it back.
- 4Your CI/CD deploys. Your pipeline ships the approved change into Splunk. Agents never deploy.
Splunk stays your SIEM
Your logs stay in Splunk. Agents run read-only searches and get back only the query results a task needs.
Changes arrive as merge requests
Agents push to their own branches in your detection repository and open merge requests in your format.
An engineer approves
Each merge request waits for review by your engineers. They approve it or send it back.
Your CI/CD deploys
Approved changes reach Splunk through your existing pipeline. Agents never deploy. What leaves your environment
What you need
- Splunk (Enterprise Security or Core).
- A detection repository on GitLab or GitHub.
- Read-only search credentials for the indexes in scope.
- A lab for attack simulations (not needed for Research and Coverage).
- Analyst verdicts exported from your case tool (for the tuning loop).