NGFW Engineer: App-Based Block With Zero Hits on a 3,800-Rule Base

App-Based Block With Zero Hits on a 3,800-Rule Base

A rule base migrated from a legacy firewall has 3,800 top-down first-match rules. Finance (10.30.0.0/16, 120 users) must be blocked from consumer file-sharing SaaS; engineering may use it. Decryption is not applied to finance traffic because two internal applications broke with certificate-pinned clients, so the whole finance subnet sits on the decryption exclusion list. Analysts report finance users uploading to the SaaS app from a browser, and the application-based block rule - logged, positioned at 2,140 - shows zero hits. A broad 'allow finance to internet' rule sits at 2,980. Client-side traffic is TLS 1.3 to TCP 443 only. The security team's position is that 'the rule is there, so the policy is correct.'

1. Why does the application-based block rule never match, and how do you prove where the traffic actually goes?

Read the worked answer

The rule is not being shadowed - it is being made unmatchable. Two different failures look the same in a hit-count report.

The match problem Application identification needs to read the TLS handshake. With finance excluded from decryption, the firewall sees TLS 1.3 to port 443 and nothing else: no server certificate, and where Encrypted Client Hello is offered, not even the server name. The session is classified as ssl or unknown-tcp, so a rule whose condition is application = <SaaS app> can never fire. The traffic falls through to the broad allow at 2,980, which matches on address alone.

Proving it

Filter the traffic log on source 10.30.0.0/16, destination port 443 and read the application column. You will see ssl, not the app name.
Take a packet capture at the ingress interface and confirm the ClientHello is opaque.
Check hit counts on rules 1 through 2,140 for the finance subnet to rule out genuine shadowing as a second, separate defect.
Confirm the zero-hit rule is actually committed on the running config and not just in the candidate.

State the conclusion plainly: ordering is fine, identification is blind. Rewriting the rule order will not fix this.

2. You are told decryption of 10.30.0.0/16 is not negotiable. What controls do you actually deploy?

Read the worked answer

Accept the constraint and design around it, in this order of preference:

1. Shrink the exclusion, don't accept it wholesale. The breakage is two pinned applications, not 120 users' entire browsing. Replace the /16 exclusion with destination-based exceptions for those two server FQDNs, keep decryption on for everything else, and attach a decryption profile that fails closed on unsupported versions and untrusted issuers. This is usually achievable and it restores full App-ID for finance.

2. If the /16 truly cannot be decrypted:

Build deny rules on the fields you can still see - SNI / URL category and FQDN-based destination matching - and explicitly log them.
Add DNS-layer blocking so resolution of the consumer service fails before a connection is attempted; this catches users who would otherwise fall through.
Keep a log-only shadow rule at the top for finance, matching application = ssl with byte thresholds, so you can measure uploads you are not blocking.
Document the residual gap: TLS 1.3 with ECH defeats SNI matching entirely, and a user who reaches the service by IP bypasses DNS control.

3. Compensating control - API-based CASB integration or an endpoint agent gives visibility the firewall cannot.

Do not leave the dead app-based rule in place as evidence of coverage. Convert it to the SNI/URL form and note the blind spot in the rule comment.

3. How do you roll this out without breaking engineering and without a flood of false positives?

Read the worked answer

Treat enforcement as a measurement exercise with a defined end date.

Stage 1 - observe (3-5 business days)

Insert the new finance rules as log-only, placed above the broad allow, scoped by source user group rather than the whole subnet.
For engineering, add a scoped allow above with an explicit user group so the two populations cannot overlap by accident.
Review daily: what matched, what business categories appeared, which users generated the most traffic.

Stage 2 - tighten

Convert to deny for the specific SaaS categories only, keeping everything else log-only. Allow-list any legitimate business service the logs surfaced, with a comment and an owner.

Stage 3 - verify

Confirm hit counts moved: the deny rule counts up, the broad allow at 2,980 stops matching finance 443 traffic.
Spot-check with a finance test account and with an engineering account, using the traffic log as the source of truth rather than the user's description.
Set a review date for the two pinned applications; when they are replaced, remove the exclusion and return to full inspection.