DETECTION ENGINEERING
The master bladesmith does not begin at the forge. They begin with the commission — the specific purpose the blade must serve, the specific adversary it must penetrate, the specific conditions it will face in use. A blade forged without that knowledge is a blade forged for nothing in particular — capable of cutting something, but not engineered for the specific thing it needs to cut.
Most detection programs work the same way. Rules written from general best practice rather than specific adversary intelligence. Coverage that looks comprehensive on a checklist and reveals its gaps the moment a technique that was always in use goes undetected. BLADE was built to change that standard — replacing the generic rule with the precision detection, the undirected rule writing with the structured engineering lifecycle, and the assumption of coverage with the verified confirmation that the rule performs as designed.
Every Detection Gap Arrives as a Commission — Not a Wish List Item
The Detection Rule That Was Validated Before It Was Trusted
Every Technique Covered. Every Gap Visible. Every Priority Clear.
THE FORGE IS OPEN.
The Edge That Never Goes Dull
EXCLUSIVE
The Problem BLADE Was Built to Solve
There is a meaningful distinction between a detection program that has rules and a detection program that has coverage — and most security organizations have never formally made the measurement that tells them which one they have.
A detection program with rules has analysts who have written logic into a SIEM, endpoint platform, or network monitoring tool for the techniques they believe are most important to catch. The rules exist. They appear on a checklist. They contribute to a coverage count that gets reported to leadership as evidence of detection maturity. And in most organizations, that is where the assurance ends — because nobody has confirmed that the rules are currently producing alerts against current telemetry in the current environment, and nobody has a structured mechanism to do so.
A detection program with coverage has confirmed that every rule it counts as coverage is actually detecting the technique it was designed to detect — against the specific telemetry it is monitoring, in the specific environment it is protecting, right now. The distinction sounds subtle. The operational difference is the gap between a rule that exists and a rule that works — and that gap is exactly where the adversary who has studied your detection program operates.
BLADE was built to close that gap at every stage of the detection engineering lifecycle.
A CLOSER LOOK
Every Rule Your Program Needs — Grounded, Built, Tested, and Deployed. See How.
The difference between a detection program that counts rules and one that confirms coverage is the difference between a forge that has started commissions and one that has tested and deployed the blades. A free BLADE consultation shows you exactly what that difference looks like in your environment — which techniques in your detection program have validated active coverage, which have rules that have never been confirmed to work, and what the gap register looks like when every undetected technique is grounded in the CIPHER actor intelligence that makes the priority explicit. Thirty minutes. The complete picture of what your detection program can actually catch right now.
BLADE - BEHAVIORAL LOGIC AND ADVERSARY DETECTION ENGINEERING
Intelligence-grounded detection requests. A mandatory six-stage rule lifecycle. Validated coverage that updates the ATT&CK map the moment a rule goes active — and degrades the moment it fails revalidation.
Intelligence-Driven Request Queue
TIME gap entries, PROWL True Positive findings, SHIELD post-incident gaps, and CIPHER coverage alerts all route to BLADE automatically — each carrying the ATT&CK technique, actor attribution, and behavioral indicators the engineer needs to build the rule correctly. The queue is never a backlog. It is an intelligence-grounded work list.
Mandatory Rule Lifecycle
Every rule passes six mandatory stages — research, build, test, review, deploy, validate — before it updates the ATT&CK coverage map. The test stage confirms the alert fires when the technique is present. The validate stage confirms it performs as designed in the live environment. Coverage in BLADE means confirmed. Not assumed.
ATT&CK Coverage Map
The BLADE coverage map tracks every ATT&CK technique against the detection program's validated rule inventory. The map updates the moment a rule goes active and degrades the moment a rule fails revalidation. The coverage picture is always current — not a snapshot from the last assessment but the real-time state of what the program can actually detect.
Revalidation and False Positive Management
Every active rule is assigned a revalidation cadence — monthly for high-priority rules, quarterly for medium, semi-annually for lower priority. Rules that fail immediately degrade to Gap on the coverage map. False positive dispositions from FLARE route back to BLADE as tuning intelligence — refining the edge so the rule catches more signal and generates less noise..
PILLAR FEATURES - PROBLEMS BLADE SOLVES
The detection program that fails during an incident almost never lacks rules. It lacks confirmed rules — rules that have been tested, validated, and revalidated against the current environment. Every problem below has a structural cause. BLADE addresses the structure.
The detection backlog nobody owns
The rule that was never confirmed to work
The coverage map nobody believes
VERIFIED REVIEWS
The difference between a detection program that counts rules and one that confirms coverage is the difference between a forge that has started commissions and one that has tested and deployed the blades. A free BLADE consultation shows you exactly what that difference looks like in your environment — which techniques in your detection program have validated active coverage, which have rules that have never been confirmed to work, and what the gap register looks like when every undetected technique is grounded in the CIPHER actor intelligence that makes the priority explicit. Thirty minutes. The complete picture of what your detection program can actually catch right now.
K.C. Yerrid
“I built BLADE for a specific moment that every detection engineer has experienced — the moment during a post-incident review when someone asks why the detection rule for the technique the adversary used did not fire, and the answer is that nobody had confirmed the rule was working.
That moment has a structural cause. Most detection engineering programs have a build stage and a deploy stage. They do not have a mandatory test stage between them. They do not have a revalidation cycle after deployment. They do not have a coverage map that degrades when a rule fails — because nobody is checking whether rules are still working after they go active.
Every design decision in BLADE was built around eliminating that moment. The mandatory test stage that a rule cannot bypass on the way to deployment. The revalidation cadence that confirms the rule is still performing as designed in the live environment. The false positive pipeline that routes tuning intelligence back to the engineer who built the rule. And the ATT&CK coverage map that makes the state of every rule visible — so the rule that is silently failing is never the one the program is counting as coverage when the adversary is already through the gap.”
