Detection Engineering and Threat Hunting

Detection engineering is software engineering. Treat it that way and the operations center scales; treat it as clicking rules into a console and it rots. The discipline has three moving parts: a detection lifecycle, a hunting loop that feeds it, and a coverage model that tells you where the holes are.

Begin with detection-as-code. Every detection is a versioned artifact in a repository -- a rule with a title, a hypothesis, a data source, a severity, a mapped adversary technique, and a test. It moves through a pipeline: propose, review, test against known-good and known-bad data, deploy, and monitor for false-positive rate. When a detection fires too often, you tune it in code and record why. When it never fires, you ask whether the threat disappeared or the logging did. This is the cure for alert fatigue. An ungoverned rule set is a landfill; a governed one is an instrument. The rule: no detection ships without a hypothesis it is testing and a test that proves it fires.

For AI infrastructure the detection catalog spans the converged surface. On the model-supply side, watch for tampering with the model registry, unsigned artifacts entering the serving path, and anomalous pulls of training data or weights -- weight exfiltration is the crown-jewel theft, and it looks like a large, patient, authorized-seeming transfer. On the compute side, watch for cryptomining on idle accelerators, container escapes in the orchestration plane, and credential abuse against the scheduler. On the operational-technology side, watch for out-of-band writes to controllers, firmware changes without a change ticket, and setpoint commands that arrive from the wrong network segment. On the identity side, watch for the vendor account that logs in from a new geography, then touches the power train. Each of these is a hypothesis you can encode.

Hunting is where you find what no rule anticipated. Detection is reactive by construction -- it encodes yesterday's knowledge. Hunting is hypothesis-driven and proactive. The loop is disciplined: form a hypothesis grounded in adversary behavior (an intruder who owns an engineering laptop would use it to bridge into the control network and enumerate the historian), decide what evidence would confirm or refute it, gather that evidence across your telemetry, and run it down. A hunt has three outcomes and all three are wins. You find an intrusion -- you respond. You find a visibility gap -- you file a new data source. You find nothing but you now have a repeatable query -- you promote it to a detection. Nothing-found is not failure; unrepeatable is failure.

Anchor both practices to shared frameworks so coverage is measurable, not felt. The enterprise attack matrix organizes IT techniques from initial access to exfiltration and impact; the industrial-control-systems matrix does the same for the process world, ending in techniques that damage equipment or endanger people. Overlay your detections and hunts on both. The resulting heat map is your honest coverage picture: solid where you can see, blank where you cannot. Prioritize the blanks by two factors -- how plausible the technique is against your architecture, and how catastrophic its impact. A technique that can trip your primary cooling loop outranks one that merely enumerates a share.

Feed the whole machine with current threat intelligence, but convert intelligence into detections, do not merely file it. When a report describes an intrusion set targeting data-center building-management systems, extract the observable behaviors -- the protocols abused, the persistence mechanism, the command pattern -- and write detections and hunts for each. Intelligence that does not change a query changed nothing.

Guard against two engineering failures. The first is the brittle detection: a rule keyed to a specific file hash or a single string, which the adversary defeats by changing one byte. Prefer behavioral detections keyed to what the attacker must do -- write to a controller, move weights, escalate a service account -- over what a particular tool happens to look like. The second is coverage theater: a long rule list that all watches the same three techniques while the operational-technology matrix sits untouched. The number of detections is vanity. The fraction of plausible, high-impact techniques you can see is the only score that counts. Engineer detections like code, hunt on a disciplined loop, and let the coverage map -- across both the IT and the industrial matrices -- drive where you invest next.