A team moving its FTD 7.x sensors from Snort 2 to Snort 3 has tuning guides written around preprocessors in a network analysis policy, and the leads want to know how inspection work is organized in the new engine. Which statement about Snort 3 architecture on Threat Defense is accurate?
Select an answer to reveal the explanation.
Short Explanation
Snort 3 organizes inspection around network flows, with modular inspectors replacing Snort 2 preprocessors and feeding traffic to a shared rule engine. You can think of inspectors as specialized stations that prepare traffic for the same central rule check, so preprocessor-focused guides describe the older engine.
Full Explanation
The accurate description is that Snort 3 on Threat Defense uses a flow-based, modular architecture: inspectors perform traffic-processing functions that were handled by preprocessors in Snort 2, and their processed traffic is evaluated by a shared rule engine. This organization supports inspection across flows rather than treating each packet as an isolated detection event, so Snort 2 preprocessor-centric tuning guides do not directly describe Snort 3. The packet-by-packet, fixed-order model is the traditional packet-based approach; it fails because it misstates Snort 3’s flow-oriented processing and inspector architecture. The “repackaged Snort 2 core” approach also fails: Snort 3 is not simply the old detection core under a new name, and preprocessor tuning assumptions require review rather than automatic carryover. The centralized-management detection approach is incorrect because detection runs on the sensor; the Management Center manages the deployment and receives and displays events. Exam caveat: distinguish the sensor’s inspection role from the Management Center’s management and event-display role. Practical check: confirm the sensor is running Snort 3, then review the deployed policy for inspector configuration instead of relying on Snort 2 preprocessor names or tuning guidance.