An IPS rule matched only intruder traffic for 90 days - what does that license, and what does it not, before it may drop on a ward network?
answer
- evidence about observed traffic only
- which flows never happened in the window
- counted alerts are not reviewed alerts
- a class is not a rule
- rule updates and firmware move the target
basics
~20 sIt licenses one claim: on traffic that actually crossed that sensor in that window, nothing benign matched. It says nothing about flows the window never contained - twice-yearly vendor maintenance, a rare failover - nor about firmware that changes next month.
solid answer
~50 sRead the record for what it is: evidence about matches over observed traffic at one sensor position, over one window. That licenses promoting the specific rules whose matches you reviewed, on that segment, in that direction. It does not license the rule class those rules sit in, another segment, or the reverse direction, because none of that traffic was ever offered to the rule. The gaps that bite on a clinical or plant network are seasonal: a vendor's remote maintenance session that happens twice a year, an annual validation run, a failover procedure exercised only during an outage. A 90-day window that missed all three has not tested them. So the licence is conditional - enumerate the exact rules, name the segment and direction, name the legitimate flows you know could match and why they did not appear, set a review date tied to rule and firmware updates, and confirm someone actually inspected the matches rather than counting them.
go deeper
Know that alert history is evidence only about traffic that actually passed the sensor during that period, and that traffic which never occurred cannot have produced a false match.
Explain the difference between no observed benign matches and no benign traffic that would match, and name the categories a short window is likely to miss: vendor maintenance, annual validation, failover paths.
Turn the record into a scoped licence - named rules, segment, direction, reviewed matches, named candidate flows checked with their owners, a window justified by the operating cycle, and a trigger that reopens the decision.
Own the standard of evidence the organisation accepts before any control is allowed to break traffic, and make it consistent enough that a promotion decision does not depend on which engineer happened to prepare it.
## What the record actually says A rule in alerting mode produces one kind of evidence: for each packet that crossed this sensor, in this position, during this window, here is whether the pattern matched and here is what it matched on. Everything you are entitled to conclude has to be derivable from that sentence. Derivable: over the traffic observed, the matches were adversary traffic and only adversary traffic - **if a human looked at them**. Counting alerts is not reviewing them. A rule that fired four thousand times and was never opened is not evidence; it is a number. Not derivable, and this is the whole question: ### 1. Coverage - the flows the window never contained A rule cannot false-positive on traffic that did not occur. On a ward or a plant floor the dangerous legitimate flows are precisely the rare ones: - a vendor's remote maintenance session, contracted twice a year, which uses tooling that looks like exploitation because functionally it is the same protocol call; - an annual or post-change validation run that exercises paths nothing else touches; - a failover or emergency procedure that only runs during an incident - so its first appearance under enforcement will coincide with the worst possible moment; - a seasonal production mode, a different recipe, a device type that arrives with the next capital purchase. A 90-day window is a sample, and the interviewer wants to hear you say which parts of the year it did not sample. ### 2. Stationarity - the rule and the estate both move Rule content updates change what the rule matches without changing its identifier. A firmware update changes what the equipment emits. A new vendor tool arrives. Any of these can turn a clean rule into one that matches authorised traffic, and none of them are visible in the historical record. This is why the licence carries a review date and is re-examined on rule-set updates rather than being granted once. ### 3. Position - the sensor sees a path, not a network Evidence is tied to where the sensor stands. Traffic that took another path, or a return direction that routes differently, was never offered to the rule. Promoting the same rule at another boundary reuses a conclusion drawn from different traffic. ### 4. Scope - a class is not a rule The request usually arrives as "promote this category". A category contains rules nobody reviewed, on traffic nobody sampled. Evidence is per rule. If the intent is to promote a class, then the class is what must be enumerated and reviewed, and in practice that collapses to promoting a much smaller set than was asked for. ## The distinction that carries the answer A clean record demonstrates the absence of *observed* benign matches. It cannot demonstrate the absence of benign traffic that *would* match. Those are different claims, and the second is the one enforcement depends on. You close the gap not by extending the window forever but by naming the candidates: sit with the people who run the ward or the line, list the legitimate flows that plausibly resemble what the rule looks for, and check each one deliberately - was it present in the window, and if not, when does it next run? ## What a defensible licence looks like - the **exact rules**, by identifier, not a category name; - the **segment and direction** - inbound to the clinical zone is a different decision from outbound; - the **traffic actually observed**, and the confirmation that matches were inspected, not counted; - the **named legitimate flows** that could match, each marked present-and-clean or absent-from-window; - the **window length justified against the operating cycle**, not against a round number; - a **review trigger**: rule-set update, firmware campaign, new device class, new vendor; - an **owner** who can revoke it. ## The wrong answer to aim at The answer a strong engineer still gives is "it has been clean for a quarter, that is enough". It treats a sample as a proof and a class as a rule. The correcting fact is that the observation window is a statement about traffic that happened, that the rarest legitimate flows are exactly the ones a quarter is least likely to contain, and that on a clinical or industrial estate the rarest flow is often the one running when something has already gone wrong.
- How do you decide the observation window rather than defaulting to 90 days?Anchor it to the operating cycle of the estate behind the control, not to a round number. Ask what the longest-period legitimate activity is - a contracted vendor maintenance visit, an annual validation, a seasonal production mode - and note which of those the window can and cannot contain. Where it cannot, the flow is checked deliberately with its owner instead of waited for.
- Someone asks you to promote the whole rule category rather than four rules. What is your answer?That the evidence does not extend to it. The category contains rules that never matched anything here, so there is no record for them either way, and rules whose matches nobody reviewed. Promote the enumerated set you have evidence for, and treat any addition as a new decision with its own review. A category promoted wholesale is how an unreviewed rule ends up severing a flow nobody predicted.
- What makes reviewing the matches different from counting them?A match proves the pattern was present, not that the traffic was hostile. Authorised tooling can contain the same protocol call an exploit uses, and in an alert queue that is indistinguishable from an attack unless someone opens it. Counting turns a benign true positive into supporting evidence for blocking it, which is precisely the mistake enforcement then makes at full cost.
saying these in an interview costs you the question
- Treats a clean quarter as proof the rule is safe
- Promotes a rule category on evidence for a few rules
- Counts alerts instead of inspecting them
- Reuses one sensor's evidence at another boundary
- Ignores rare seasonal and vendor maintenance flows