A segment allow-list built from 30 days of observed flows permits an intruder's sessions too - why can the records not tell them apart?
answer
- descriptive, not normative
- five-tuple and counters only
- no payload, no user, no purpose
- present is not the same as normal
- intent is asserted by a human, never observed
basics
~20 sA flow record only says bytes moved between two endpoints on a port. It carries no payload, no user and no purpose, so a compiler turning records into permits cannot separate a designed dependency from an intruder who was present.
solid answer
~50 sA flow export is descriptive, not normative. Each record carries a five-tuple, byte and packet counters and start/end timestamps - and nothing about who asked for the traffic or why it exists. Compiling 30 days of records into permits therefore produces a list of what *happened*, and the only property every entry shares is that it occurred inside your window. An adversary resident before the capture began contributes flows that look exactly like a historian poll: modest volume, regular timing, a plausible port. The honest claim after enforcement is "this segment now denies anything that was not present during the window", not "this segment permits only authorised traffic". Turning the first sentence into the second costs human time: someone has to state, per flow, what it is for - and on a plant floor most flows have no such person.
code
text · 12 linesflowStartMilliseconds: 2026-03-04 02:11:07.412
flowEndMilliseconds: 2026-03-04 02:19:55.031
sourceIPv4Address: 10.42.8.19
sourceTransportPort: 51402
destinationIPv4Address: 10.42.3.7
destinationTransportPort: 502 # Modbus/TCP
protocolIdentifier: 6 # TCP
octetDeltaCount: 48219
packetDeltaCount: 611
ingressInterface: 7
...
# absent: payload, user, process, application name, and any reason this flow existsgo deeper
Be ready to state what a flow record does and does not contain, and to say out loud that a permit derived from one proves only that the traffic occurred.
Explain the compiling step - distinct five-tuples become permits - and why a resident adversary's sessions satisfy every criterion the compiler applies.
Show that you would fix the claim before you fix the list: state precisely what the enforced segment denies, and refuse the sentence that says permitted equals authorised.
Own the consequence for assurance and contracts: if intent cannot be observed, it must be procured, and that means specifying interface documentation as a deliverable rather than reconstructing it later.
## What a derived allow-list is A team inherits a flat plant network - controllers, a historian, an MES, engineering workstations, all reachable from each other - and is told to segment it. Nobody has a dependency diagram. The standard move is to observe first: put a passive vantage in the path (a mirror port, or flow export from the aggregation switches), collect for a few weeks, then compile the distinct source/destination/port/protocol combinations into permits. That compiled set becomes the first policy the segment has ever had. The technique is sound as a *starting point*. The mistake is what people believe the output is. ## What is actually in the record A NetFlow or IPFIX record is a summary of a conversation, keyed on the five-tuple. Typical fields: `sourceIPv4Address`, `destinationIPv4Address`, `sourceTransportPort`, `destinationTransportPort`, `protocolIdentifier`, `octetDeltaCount`, `packetDeltaCount`, `flowStartMilliseconds`, `flowEndMilliseconds`, an interface index, and on some templates the union of TCP flags seen. That is the entire input the compiler had. What is *not* in it: - **The payload.** Flow records prove bytes moved; they never show what the bytes were. A permit derived from one says nothing about the application riding the port. - **A user or process.** No account, no binary, no service identity. - **A purpose.** There is no field for "this exists because the MES polls tag values every 5 seconds". Intent is never observed; it is only ever asserted by a human. - **Authorisation.** No one consented to any of this. The traffic simply ran. ## The three things observation cannot establish **1. That a flow was intended.** A misconfiguration that has run for six years is indistinguishable from a designed dependency. Both are steady, both are old, both appear in every daily bucket. **2. That a flow is correct.** An engineering workstation reaching a controller directly instead of through the intended gateway looks like a first-class dependency to the compiler, because it is a real, repeated, high-count flow. **3. That the estate was clean when you looked.** This is the one that matters for security. The window is a *sample of what was present*, not a definition of what is normal. If an adversary held sessions during those 30 days - a jump host into the historian, the historian onward to controllers - those sessions are flows, they meet every criterion the compiler applies, and they become permits. Observation cannot distinguish "normal" from "present", because presence is the only evidence it has. ## Direction is an inference too People assume the record tells them who initiated. For TCP it often does - the flow start and the port pattern usually identify the client, and the flag union helps - but a long-lived session that was already open when export began, or a session that restarted mid-window, can be attributed backwards. UDP has no handshake at all, so initiator is inferred from timing and port role. Getting direction wrong in a derived rule means permitting the reverse of what actually happens, which is exactly the direction an intruder wants. ## What the technique does buy you It is not worthless - it is the difference between a flat network and a narrowed one. After enforcement, anything that did *not* appear in the window is denied. A new foothold reaching for a path nobody used is stopped. Flows are enumerated, which is more than the plant had yesterday. Those are real claims and you should make them. ## The price of upgrading the claim To move from "was observed" to "is authorised" you need an owner per flow who can state what it is for. That is a human campaign, not a tooling problem, and on an industrial estate most flows have no such owner: the integrator who commissioned the line left years ago, the contract never required an interface specification, and the people who remain will not sign a statement about traffic they did not design. That is why derived lists are so often adopted unread - not because engineers are lazy, but because nobody will accept the outage risk of deleting a line they cannot explain. ## How to answer in an interview Say plainly: a permit derived from a flow record proves the flow happened, nothing more. Then name the consequence - if an intruder was inside during the window, you have just written their access into policy - and then name the cost of doing better, which is per-flow intent attribution.
- So what claim can you honestly make to the plant owner the day the derived policy is enforced?That the segment now denies any traffic that did not occur during the observation window, which meaningfully narrows a previously flat network and stops a new foothold from reaching paths nobody used. You cannot claim that permitted traffic is authorised, that every conduit has a purpose, or that anyone already inside has been constrained. Say the first sentence and refuse the rest.
- Two flows look identical in the export - same ports, similar volume, both daily. What would actually separate them?Only something outside the record: a named owner who can state which application produces it and what breaks if it stops, a change or commissioning record that introduced it, or an asset register entry that makes one endpoint's role explicit. Volume, regularity and age are not evidence of legitimacy - an established intruder's traffic is steady, regular and old too.
Watching a building's doors for a month tells you which doors got used. It does not tell you which people were supposed to be inside, and it will happily issue a key to the burglar who came and went all month.
saying these in an interview costs you the question
- Treats thirty days of traffic as a definition of normal
- Says the flow export shows what the traffic contained
- Assumes long-running and high-volume implies legitimate
- Claims the derived list permits only authorised traffic
- Believes direction of a UDP flow is recorded rather than inferred