A utility operator runs an FTD sensor in passive mode on a switch SPAN port. The sensor raises alerts for known-bad traffic, including a test download that it flagged correctly, yet the sessions still complete and the file is delivered. Which factor most directly explains why the flagged traffic continued to flow?
Select an answer to reveal the explanation.
Short Explanation
You get the trade-off of an out-of-band sensor: it reads traffic instead of steering it. It’s like a guard watching camera footage of a door they can’t physically lock. A passive deployment puts the appliance beside the wire, so alerts fire while the session runs untouched.
Full Explanation
In passive mode, the appliance receives a copy of traffic from the SPAN port and does not forward the live traffic, so it cannot block or shape that traffic. Nothing it detects can change packets already on the wire, which is why the flagged transfer can finish while the alert is recorded. An access control rule that allows the connection is beside the point: the appliance is not forwarding the flow or applying a drop action. SPAN oversubscription is a real concern because a switch can discard mirrored frames under load, but that does not explain why a session the sensor detected was not blocked. Missing decryption can prevent inspection of encrypted payloads, though alerts may still be based on visible metadata; in any case, passive mode cannot stop the session. Exam caveat: in an inline deployment, blocking depends on the applicable policy and action, while inline tap mode remains nonblocking. Practical check: confirm the device mode on its interfaces, then rerun the download and watch whether the transfer completes.