Detection engineering

The finished Ironwood design has one open path: the support agent's own legitimate session reading customer records. No control removes it without stopping the work. The bench accepts that path as the honest remainder for one reason only: it crosses a logged edge, and somebody reads the log. Turn detection off and keep every prevention control on, and the bench reads one path and one undetected. Same door, same room, and now it is dark.

So the queries written tonight are not a monitoring nicety layered on top of a secure estate. They are the thing that makes it acceptable to leave the last door open. A leader who signs off the design is signing off the assumption that these detections run, that their thresholds are sane, and that a named human reads the table every day. The engineering that follows is about making that assumption true.

• Tactic - ATT&CK's word for the attacker's goal at one stage. Version 19.2 lists fifteen for the enterprise matrix; tonight uses five of them: Credential Access, Privilege Escalation, Collection, Exfiltration and Impact.
• Hypothesis - a sentence of the form "if an attacker were doing this tactic here, the log would show that". Every detection starts as one, and a detection that cannot be stated as one is a query looking for a purpose.
• Login history - the warehouse's record of every authentication: who, when, from which address and client, whether it succeeded. Distinct from query history, which starts after the login.
• Grant history - the record of every role granted or revoked, to whom, by whom, when. Most platforms expose it as a system view or an account-usage table; some only as an audit log export.
• Change window - the agreed hours in which privilege changes are expected, with a ticket. A grant outside one is not wrong; it is a row.
• Precision - of the rows a detection writes, the share that had a real cause. The discipline is to raise it by tuning against the detection's own history, never by making the query blind.
• Review table - the one table all detections write to. Its reviewer and outcome columns are the control; everything upstream is plumbing.

• Pick a tactic. Use the ATT&CK v19.2 names, because they are the vocabulary the rest of the industry uses when it describes an incident, and because the list is finite. Fifteen tactics; a warehouse estate needs detections against roughly a third of them.
• State the hypothesis in your own logs' terms. "If someone were doing Credential Access with Ironwood's ETL key, login history would show that service account authenticating from a client or address it has never used." If you cannot finish that sentence for a tactic, you either lack the log or the tactic does not apply, and both are findings worth writing down.
• Write the query. The hypothesis becomes a WHERE clause and usually a join to a baseline or an allowlist. Keep it read-only over the log until the final step.
• Decide the threshold, then tune it against history. Run the query over the last 90 days before scheduling it. Count the rows. Each one either had a real cause or is a reason to sharpen the query.
• Name the reviewer. A person, not a channel. A detection with no named reader is a detection that will be read by the incident responder, afterwards.

Two of the five already exist from session 5. The point of writing the table anyway is the first column: each detection now says which tactic it is a hypothesis about, which is the sentence an incident report needs and the sentence a new engineer needs to know whether the set is complete.

ATT&CK v19.2 lists fifteen enterprise tactics. Five have detections tonight because five correspond to edges on Ironwood's graph that lead to or through the crown jewels. The rest are not ignored; they are either closed by prevention, outside the warehouse, or someone else's log.

• Initial Access at Ironwood is phishing and a public repo. MFA and key rotation closed those edges in session 2; the residual signal is the new-client login, which is why Credential Access is watched rather than Initial Access.
• Execution and Persistence live on the CI runner and the laptops, whose logs belong to the platform and endpoint teams. The warehouse sees their consequence, which is a login or a query, and that is where tonight's detections sit.
• Stealth and Defense Impairment, the two tactics v19 split out of the old Defense Evasion, would appear in a warehouse as somebody disabling the logging or the scheduled job itself. The right control is that the review table notices when it stops receiving rows; the homework asks for that check.
• Discovery and Lateral Movement show up in query history as SHOW and DESCRIBE statements from a role that never issues them, and as a login hopping between roles. Both are reasonable sixth and seventh detections once the first five are quiet.
• Reconnaissance, Resource Development and Command and Control happen outside anything the warehouse records. Naming them here is what stops a future engineer from believing the five are the whole picture.

Data observability learned the false-page rule the expensive way: a monitor that pages on every late load is muted within a month, and it is muted the month it matters. Security detection inherits the rule with a sharper edge, because the person who stops opening the review table is the person the whole design assumes is there.

• Tune against the detection's own history before it goes live. Run each query over 90 days. Every row it returns is either a real cause you can name or a defect in the query. Fix the defects: a service account whose "new client" is the runner's second address, a change window nobody wrote down, a backup schema whose nightly rotation issues a legitimate DROP.
• The target is less than one row a week without a real cause. Not zero. A detection that never fires is either perfect or blind, and the tuning history is how you tell them apart.
• Tune the join, never the eyes. Add the runner's second address to the service account's expected clients. Add the rotation job's role to an exception list with an owner and a review date. Do not raise a threshold globally to silence one role; that blinds the detection for every other role.
• Record every tuning decision with a reason and an owner. An exception list without owners is the next public bucket.

Session 5's table took two detections. Tonight's takes five, and the reason for keeping one table rather than five is the reader. One table, one morning read, one place where "reviewed by" and "outcome" get filled in. Five tables become five habits, and habits are what a detection programme actually runs on.

Each row carries the tactic it is evidence for, the object it concerns, the actor as the log recorded them, the evidence itself, and the name of the person who owns the answer. The reviewer is chosen per detection, not per row: the platform lead owns new-client logins and drops, the access owner owns out-of-window grants, the data owner of customers owns unusual reads and unlisted copies. Their names are in the job, so a row is born with a reader.

Two limits are worth writing next to the detections, because the review table will otherwise be read as saying more than it can.

• Query history attributes a read to a user and the roles active in the session, not to the grant that permitted it. When the analyst read customers with the admin role active, the row says user and role. It does not say whether the read was permitted by the Friday grant, by an older grant to a role the admin role inherits from, or by a direct grant on the table. Answering that needs a join to grant history as of the query's timestamp, and on many platforms the reconstruction is approximate. The review table records what the log recorded; the reviewer's question is what recovers the grant.
• The export bucket path is outside all five. A read of the nightly extract is a request to the object store. It is not a login to the warehouse, not a grant, not a SELECT, not a COPY, not a DROP. Session 3 closed that door with a private bucket; the only log that would ever see it being opened again is the object store's own access log, and it needs its own detection with its own reviewer, or an honest blank in the inventory's "seen by" column.

Write both limits into the runbook next to the table. The incident that tests them will not be the moment to discover them.

When an incident is confirmed, the first document anyone asks for is the timeline: when did the credential first authenticate from the new address, when was the role granted, when was the first unusual read, when did the copy leave, when was the backup schema touched. Every one of those timestamps lives in a row one of tonight's detections wrote, or in the underlying history the detection reads.

• Retain the review table for longer than the log. Platform query history is often retained for weeks or a year; the review table is yours and can be kept for as long as the postmortem process needs it.
• Keep the query text and query identifier on the row. The evidence column that says "above 10x typical" is a summary; the identifier is what lets the responder pull the exact statement later.
• The outcome column is part of the record. "Expected, confirmed by owner on the day" is what turns a row from noise into a documented decision, and a stack of those is what lets a postmortem say the detections were working before the incident, not just after.

What a confirmed exfiltration obliges the company to tell regulators and customers is the governance course; what the first hour looks like and what the report funds is leader session 6. Tonight's contribution to both is that the timeline exists.