Policy Configuration and Management
Rule evaluation and structure
Security policy is evaluated top-down, first match wins, with an implicit deny at the bottom. Understand zones (intra-zone versus inter-zone defaults), source/destination/user/application/service fields, and the difference between port-based service and application identification. Modern NGFWs resolve application dependencies; a rule allowing generic web-browsing may not permit an app that uses non-standard ports unless the app is explicitly allowed.
Profiles, NAT, and decryption
Security profiles (antivirus, anti-spyware, vulnerability, URL filtering, file blocking) attach to allow rules and inspect only permitted sessions. Decryption policy is separate and typically evaluated before security policy; an exception for financial or health sites is a classic trap. NAT rules have their own order: source NAT is commonly applied after policy lookup, destination NAT before-know your platform.
Traps
Shadowed rules, redundant rules, any-any permits, and overly broad applications. A rule with zero hits for 90 days is a retirement candidate, but check dependents first. Also watch shadowing caused by a broader rule above, and user-ID mapping failures that make user-based rules miss.
Rule of thumb
Place specific denies (known malicious geographies, risky apps) above broad allows, and keep a documented emergency-deny block at the top.
Worked example
If HTTPS to a SaaS app fails while ping works, check whether the app is identified as SSL and whether decryption is bypassing the certificate; add the app explicitly and verify in the session browser.