A municipal water plant must add IDS coverage to its control network before an upcoming audit. Plant rules forbid any appliance from sitting in the path of control traffic, and they ban new cabling or taps beyond a mirror session the core switch already supports. Engineers need signature-based alerts on exploit attempts this quarter, with blocking deferred to phase two. Which deployment mode meets those constraints?
Select an answer to reveal the explanation.
Short Explanation
Run the FTD in passive mode on the existing SPAN session, so you can inspect mirrored traffic without putting an appliance in the control network’s path. It’s like checking a photocopy of the mail instead of interrupting delivery; your intrusion policy still raises signature alerts now, while blocking can wait until phase two.
Full Explanation
In passive mode the FTD receives a copy of traffic from a switch SPAN session and runs the intrusion policy against it, producing signature alerts while leaving the original flow completely alone. That satisfies both constraints at once: the appliance stays out of the control path, no new cabling or taps are introduced, and analysts still get detection this quarter. Putting the FTD inline as an inline set gives real enforcement, but it places hardware in the path of control traffic, so it violates the plant rule about appliances on the path even with fail-open handling. Deploying passive monitoring on new optical taps is conceptually the right mode, yet it requires new hardware and cable runs, which the site rules rule out, missing the infrastructure constraint. Exporting NetFlow from the core switch keeps everything off-path and needs no new gear, but flow records carry no payloads, so signatures cannot match exploits and the detection requirement fails. Exam caveat: remember passive mode can alert and log but never drop, which is why blocking belongs in phase two. Practical check: confirm the SPAN session delivers traffic and watch for signature alerts on a test exploit.