The Feed That Blocked the Partner Before the Rule Could Allow It
Contoso's data center FTD pair sits inline between the partner VPN and a file-transfer server at 10.50.7.20. The access control policy begins with a prefilter policy containing a fastpath rule for backup traffic, then the Prod-ACP rules: rule 1 allows TCP/22 from the partner range 203.0.113.0/24 to 10.50.7.20 with an intrusion policy attached, and the default action blocks everything else. The Security Intelligence policy uses the Talos intelligence feed for source and destination blocking plus a custom feed the SOC updates from its threat-intel platform. At 14:05 partner SFTP uploads began failing. Connection events show the flows as blocked, and the event reason field names Security Intelligence rather than any rule. At 13:58 the SOC pushed a custom feed update that added 203.0.113.0/24; the range belongs to a hosting provider that also serves legitimate customers. Rule 1 itself was not modified, and its hit counters stopped incrementing at 14:05.
1. Explain why rule 1 does not rescue this traffic, and give the two legitimate remediation options with their trade-offs.
Read the worked answer
Inside the access control policy, Security Intelligence is evaluated before the access control rules are consulted. A source or destination that matches a block-list entry is dropped at that stage; the rules below are never reached, so an Allow rule cannot 'outvote' an SI block. That is exactly what the hit counters show: rule 1 stopped matching because the traffic never got that far. The prefilter policy is evaluated even earlier, but its fastpath rule targets backup traffic, not SFTP, so it is not involved.
The two legitimate fixes:
- Correct the intelligence. If 203.0.113.0/24 was added by mistake, or if a hosting-provider range is too coarse to be actionable, fix the custom feed. This restores the original behaviour and leaves SI effective for the rest of that range. Preferred when the feed entry is simply wrong.
- Create a Do Not Block exception in the Security Intelligence policy. Appropriate when the intel is generally valid but this specific partner path is an approved business exception. The exception is evaluated with SI, so it applies immediately once deployed and will keep applying through future feed updates.
Do not add a second higher-priority Allow rule or move rule 1 upward; neither changes the evaluation order and the traffic stays blocked.
2. The SOC proposes adding the entire 203.0.113.0/24 range to the Do Not Block list. How do you scope this and why?
Read the worked answer
Scope the exception to the business relationship, not to the feed entry's convenience.
- A do-not-block for the whole /24 at both source and destination removes SI protection for every tenant of that hosting provider, including hosts that later appear on real threat intel. You would be trading one partner path for blind spots across an entire provider range.
- Narrow it to what you actually know: the partner's specific source addresses talking to 10.50.7.20 on TCP/22. Where the SI policy allows per-list scoping, attach the exception to the source list matching the partner hosts, and confirm the destination side is separately handled if the flow is also evaluated as inbound to the server.
- Record an owner and an expiry date. Exceptions without an owner become permanent, and nobody remembers why the range is trusted two years later.
- If the partner cannot supply stable source addresses and the whole /24 is genuinely required, raise it as a formal risk acceptance with the SOC and the business owner rather than approving it inside the firewall team.
After deploying, verify the exception appear in the SI policy on the device and that the connection events for the partner flow now show the rule 1 match instead of an SI block.
3. How do you verify the fix and detect a recurrence without waiting for the partner to complain again?
Read the worked answer
Verification and monitoring in order:
- Deploy the SI policy change and confirm the deployment task succeeds on both units of the pair.
- Reproduce with a controlled SFTP session from an approved partner host, then inspect the connection event. It should now show rule 1 as the matching rule, the action Allow, and no Security Intelligence block reason. The rule 1 hit counter should increment.
- For a documented flow, use the FMC packet tracer against the partner source, 10.50.7.20 and TCP/22 to confirm the expected path (prefilter, SI, then rule 1). Treat packet tracer as a simulation and still confirm with real traffic.
- Set up a saved search or correlation view for connection events where the reason is Security Intelligence and the destination is 10.50.7.20, and alert on it. That catches both a re-added feed entry and a partner address change.
- Subscribe the firewall team to the SOC's feed-change notifications so an update touching a business-critical range triggers a review before it hits production.
The lesson to document: intel changes are policy changes and need the same change control as rule edits.