An intrusion rule that has alerted on intruder traffic for months is set to drop - what changes about the cost of a wrong match?
answer
- same rule, different consequence
- accuracy unchanged, blast radius not
- who absorbs the mistake now
- an hour of triage becomes a severed session
- you stop seeing the next step
basics
~20 sIn alert mode a wrong match costs an analyst an hour. Inline, the identical match severs a live session. The rule's accuracy does not change - only who pays for its mistakes, which moves to whoever owns that traffic.
solid answer
~50 sFlipping the action does not make the rule more correct; it changes who absorbs its errors. In alert mode a false or benign match produces a record someone reads later, and the traffic still arrives. Inline, the same match discards packets, so the consequence lands on the business flow in real time - a transfer restarts, a session hangs, an operator sees a device stop responding with no error that names a firewall. Two things follow. First, the acceptable error rate is now set by whoever owns the traffic, not by the analyst queue. Second, you lose observation: an alerting rule lets you watch what the intruder does next, while a dropping rule truncates the sequence at the first match and tells the adversary which step is filtered. The gain is real - the drop lands before the payload does - but it is bought with someone else's uptime.
go deeper
Be ready to say plainly that the rule matches the same traffic either way, and that only the consequence of a match changes - from a record someone reads to a session that stops.
Explain the error-budget handover: who triages a wrong match in each mode, why a benign true positive cannot be tuned out, and why a dropped packet is harder to diagnose than a refused one.
Show that you weigh the visibility you lose and the feedback the adversary gains against the response time you buy, and that you know enforcement is argued in the traffic owner's units, not the security team's.
Own the framing that enforcement moves an error budget onto a business owner who can decline it, and be ready to say what the organisation accepts instead when they do decline.
## The one thing that changes, and the many that do not An intrusion rule has two independent properties: **what it matches**, and **what happens when it matches**. Promoting a rule from an alerting action to a dropping action changes only the second. The packets it selects are exactly the same packets the day before and the day after. This is why "we already had the detection, we just flipped the action" is such a seductive and such a weak justification - it is true about the matching and silent about the consequence, and the consequence is the entire subject. ## Who absorbs a mistake, before and after | | Rule alerts | Rule drops | |---|---|---| | A benign flow matches | a record in a queue, read later | the flow is severed now | | Who notices first | an analyst | the person using the application | | Cost of one error | ~an hour of triage | a failed transfer, a stalled procedure, a call-out | | Who signs for the error rate | the security team | the owner of the traffic | | Traffic still arrives? | yes | no | The row that matters in an interview is the last-but-one. In alert mode the security team owns its own false positives and can absorb them quietly. Inline, the errors are paid in someone else's currency - production units, a restarted study transfer, a clinician who cannot see a monitoring feed - and that person has both the right to refuse and, usually, the budget. ## The vocabulary an interviewer will hold you to A **false positive** is a match on traffic that is not what the rule claims. A **benign true positive** is a match on traffic that genuinely contains the pattern the rule looks for, but which is authorised - a vendor's diagnostic tool that legitimately exercises the same protocol call an exploit abuses. In alert mode the two are triaged identically and closed identically. Inline they are also blocked identically, and the benign true positive is the one that hurts, because no amount of tuning the rule's pattern will separate it from the attack. Only scope can: the segment it applies to, the direction, the source, the time. ## What you give up by preventing Prevention is not strictly safer than detection, and a candidate who says it is has missed the leaf. Three prices: 1. **Observation.** An alerting rule lets the intrusion continue and lets you watch the next stage - what they reach for after the first attempt fails, what else they can already talk to. A dropping rule cuts the sequence at the first match, and the record thins to "we blocked something, repeatedly". 2. **Feedback to the adversary.** A blocked step is information. Someone probing a boundary learns which of their techniques is filtered and adapts, and they learn it without ever talking to you. 3. **Diagnosis cost.** A dropped packet leaves no error on the wire that names the cause. A device that stops working because a rule matched looks, to the person operating it, exactly like a device that has failed. ## What you gain, stated honestly The gain is timing. Detection acts after a human reads a record; enforcement acts inside the flow. Where the population behind the control cannot be patched and cannot be rebuilt quickly - a production line's controllers, a ward full of equipment on a fixed vendor image - the interval between an alert and a response is exactly the interval in which the thing you cannot fix gets exploited. That is the argument for going inline, and it is an argument about response time, not about the rule being good. ## How this is probed Interviewers ask this early because it separates people who have operated an inline device from people who have only read about one. The strong answer names the shift of the error budget to a different owner, distinguishes a false positive from a benign true positive, and admits the visibility loss rather than presenting blocking as an unambiguous upgrade. The weak answer treats the change as a configuration detail and reasons only about whether the rule is accurate.
- Is a rule that has never produced a false alert therefore safe to run inline?No. A clean alert record says nothing benign matched during the traffic that actually crossed the sensor in that window. Flows that did not occur - a vendor's annual maintenance session, a rare failover procedure - were never offered to the rule. And a benign true positive, where authorised traffic genuinely contains the matched pattern, looks identical in an alert queue and is the case that cannot be tuned away.
- What do you lose in visibility once the same rule drops instead of alerts?The follow-on. In alert mode the session completes, so you observe what the intruder attempts next and what else they can reach. Dropping truncates at the first match, so the record collapses into repeated block events with no sequence behind them. You also hand the adversary a clean signal about which step is filtered, which they can use to pick another one without ever succeeding once.
- Why is 'the detection already exists, we are only changing the action' a weak justification?Because the two modes are judged against different budgets. Alerting is judged against analyst capacity, which the security team owns. Dropping is judged against interrupted business flows, which someone else owns and prices in their own units. Nothing about the existing detection evidence tells you what the second budget is, and it is the one that decides whether enforcement survives its first mistake.
A smoke detector that logs is a nuisance when it is wrong. The same detector wired to the sprinklers is wrong exactly as often and ruins the room.
saying these in an interview costs you the question
- Treats blocking as strictly safer than alerting
- Says a wrong drop is just another false positive
- Calls the change a configuration detail, not a decision
- Cannot distinguish a false positive from a benign true positive
- Assumes the affected device will retry and recover