A SOC analyst has written a custom Snort rule that flags an internal host beaconing to a known command-and-control domain. Three requirements apply: the custom rule must raise alerts, every other rule in the current intrusion policy must keep its base-policy state, and the change must reach the FTD device today. Which intrusion policy change meets all three requirements?

An intrusion policy is a set of rules with individual states layered over a base policy, and that policy only inspects traffic when an access control rule selects it. Adding your custom rule to the existing policy keeps it in the same inspection path, changing only its state to Generate Events leaves every other rule at the base-policy default, and deployment is the step that writes the staged policy to the device, since saving in the Management Center alone does not apply the change to the appliance. Building a second policy on a lower access control rule fails on first-match semantics, because the flow is already matched by the rule above it, so the new policy and its custom detection are never evaluated. Switching every other rule to Generate Events violates the requirement that the remaining states stay as the base policy defines them, and it can produce unrelated events. Waiting for an automatic push fails because the Management Center holds policy edits as pending until you deploy them. State labels and the way overrides are displayed vary between Snort 2 and Snort 3 policies. After deploying, search intrusion events for your custom rule signature ID and confirm the event appears while other rules keep their previous action.