Control Access to Network Resources
Anatomy of a security rule
Each rule matches source zone, source address, destination zone, destination address, application, service/port, user, and optionally HIP and URL category, then applies an action (allow, deny, drop, reset) plus logging and a security profile group. Rules are evaluated top-down, first match wins; ordering is the biggest single source of errors.
Default rules and implicit deny
Two read-only rules sit at the bottom: intrazone-default (allow, so traffic between interfaces in the same zone passes) and interzone-default (deny, so traffic between different zones is blocked). Anything unmatched is dropped. Best practice is explicit deny rules with logging above the defaults, plus periodic use of the policy optimiser to find unused, duplicate or shadowed rules.
NAT interactions
Source NAT happens after policy lookup, so policy sees the pre-NAT source zone and address. Destination NAT happens before policy lookup, so the rule must reference the post-NAT destination zone and translated address. This is the classic trap: a DNAT rule translating a public address to an internal web server requires a security rule whose destination zone is the internal server's zone, with the server's private IP.
Service and application
Selecting an application normally sets service to application-default. Overriding service is legitimate for custom ports, but pairing application 'any' with a specific service defeats App-ID. Application filters and groups reduce rule sprawl.
Worked example: internet users in zone untrust reach 203.0.113.10:443, DNAT'd to 10.1.1.20 in zone trust. The security rule is source zone untrust, destination zone trust, destination 10.1.1.20, application ssl, service application-default.