A Suricata content rule matches one encoding of an attacker technique and the coverage matrix says 'detected'. What do you publish with the rule, and what do you refuse to claim?
answer
- the claim travels further than the rule
- someone defunds a fix on the strength of it
- state the variants not matched
- a rule is only true inside its header
- widening is a funded choice with an owner
basics
~20 sPublish the evasion margin: the variants tested and matched, the variants known not to match, and the conditions - buffer, direction, ports - under which the rule holds. Refuse the binary 'detected', because someone will stop funding the gap on the strength of it.
solid answer
~50 sA content rule is a narrow instrument and a coverage matrix is a binary. The gap between them is where the harm happens, because a risk owner reads 'detected' and declines to fund the fix, a questionnaire answer goes out on it, and nobody re-derives what was actually tested. So the artefact that ships with the rule is a margin statement: which variants were tested and matched, which are known not to match and why, which buffer and direction the rule is bound to, and when it should be re-tested. What you refuse to sign is the unqualified claim. Then make the trade explicit rather than absorbing it quietly: widening the rule to cover the remaining variants costs CPU per packet on the sensor and false positives that, inline, drop real sessions. That is a funded choice - more capacity, a narrower deployment, or accepted residual risk - and it belongs to whoever owns the budget and the outage, not to the rule author alone.
go deeper
Know that a signature matches specific bytes in a specific place, so 'the technique is detected' is a bigger statement than any single rule supports.
Be able to write the margin: the variants you tested, the ones you know slip past, and the buffer, direction and ports the rule is bound to.
Show that you cost the widening - CPU per packet and false positives against a named business flow - rather than arguing coverage on principle.
Own the claim as an organisational artefact: name who consumes it, what decision it funds or cancels, who accepts the residual, and what you do when the tooling offers only a checkbox.
## Why this is a judgment call, not a technical one The technical facts are settled by the time this question is asked. The rule matches a pattern in a buffer within a window. Padding, case and encoding variants slip past it. Widening it costs cycles and false positives. None of that is in dispute. What is in dispute is what gets written down, because the written claim travels further than the rule does. A coverage matrix is read by people who will never open the signature: a risk owner deciding whether to fund an application fix, someone answering a customer security questionnaire, an auditor sampling controls, an engineering manager deciding whether a mitigation can be deprioritised. Each of them will convert 'detected' into a decision. That conversion is the reason a rule author cannot treat the claim as somebody else's paperwork. ## What the margin statement contains Five things, and none of them takes long to write if the rule was authored deliberately: 1. **What was tested and matched.** The specific variants exercised, not "the technique". 2. **What is known not to match.** Padded, re-cased, differently-encoded, delivered on another port, or arriving in the opposite direction. This is the part everyone omits and the part with all the value. 3. **The binding conditions.** Which buffer the content is written against, which direction and flow state the rule requires, which address sets and ports the header asserts. A rule is only true inside its header. 4. **What was deliberately not covered, and why.** Usually cost: the variant-proof version was rejected on CPU or false-positive grounds. Say so. 5. **A re-test trigger.** A parser or buffer-handling change, or a new variant seen in the wild, invalidates the statement without touching the rule text. The cost of this is real and it is review burden: someone writes it, someone reads it in the change, and it is maintained. That is the price this leaf is about, and the argument for paying it is that the alternative is an unverifiable claim that other people spend money against. ## What to refuse Refuse the unqualified binary. Not by blocking the matrix - a matrix with a blank cell helps nobody - but by insisting the cell carries a qualifier and a link: partial, with the margin attached. If the tooling only accepts a checkbox, that is a finding about the tooling, and it is worth raising once, in writing, rather than quietly ticking the box every quarter. Also refuse to let the rule's existence close the underlying issue. A content signature that pattern-matches one encoding is not a substitute for the fix; it is a narrow, cheap, temporary observation that the fix has not shipped. The most damaging outcome of an over-claimed rule is not a missed alert - it is a remediation that got cancelled. ## Making the trade a funded decision When someone pushes back and asks you to just cover all the variants, put numbers on it: - Cost of widening: measured CPU per packet before and after, and the resulting headroom on the sensor at peak. - Cost of the false positives: on a passive sensor, analyst time; on an inline sensor, dropped sessions in a named business flow, with an estimate of how often. - Cost of not widening: the residual variants, and who accepts them. Presented that way it stops being a security argument and becomes a normal resourcing choice with three legitimate answers: buy the capacity, deploy the wide rule only where a drop is survivable, or accept and record the residual. All three are defensible. What is not defensible is a wide rule shipped inline without the capacity to run it, or a narrow rule recorded as full coverage. ## The signal an interviewer wants Seniority here shows as unwillingness to overstate, paired with the ability to keep the work moving. Someone who says "I can't claim coverage" and stops is not useful; someone who ticks the box is worse. The answer that lands describes the artefact they publish, names who consumes it and what decision it feeds, and turns the widening question into a costed choice with a named owner.
- Who should own the residual risk when the rule stays narrow?The person who owns the system the technique targets, or the risk owner who declined to fund widening or the underlying fix - named, in the record, with a date. Leaving it with the detection engineer is how a known-narrow rule becomes an organisational surprise later, because the only person who understood the margin was not the person making the funding decision.
- Is a partial rule worth shipping at all, given it can be evaded?Usually yes, if it is cheap and specific. It costs little, catches the unmodified and opportunistic use of the technique, and gives you a dated marker for when activity started. The danger was never the narrow rule; it was the unqualified claim attached to it. Ship it, and ship the margin with it.
- What changes if the sensor is inline rather than passive?The false-positive currency changes from attention to availability. A widened rule that drops a legitimate session is an outage in a business flow, so the decision to widen needs an owner who can accept that outcome and a deployment where it is survivable. Many teams run the wide variant in alert mode and keep only the narrow, well-anchored version on the dropping path.
saying these in an interview costs you the question
- Ticks the coverage box because a rule exists
- Says a signature makes the underlying fix unnecessary
- Refuses to claim anything and offers no alternative record
- Widens the rule inline without a capacity measurement
- Leaves the residual risk unowned and undated