Checkpoint Firewall Audit

Check Point Firewall Security Policy Audit

Policy-audit-driven analysis of Check Point Security Gateway policies. Unlike generic firewall checklists that check for open ports and default-deny, this skill evaluates the Check Point-specific security architecture: rulebase ordered and inline layers, Software Blade activation coverage, management plane trust (SIC), and the Unified Policy model introduced in R80+.

Covers R80.x and R81.x gateways managed via SmartConsole connected to a Security Management Server or Multi-Domain Server (MDS). Reference references/policy-model.md for the R80+ architecture and layer model, and references/cli-reference.md for read-only CLI and API commands.

When to Use

• Rulebase layer review after rule additions or layer restructuring
• Blade activation audit verifying that licensed blades are enabled on all gateways
• Annual or quarterly compliance audit requiring per-rule justification
• Post-incident rulebase assessment to identify how traffic was permitted
• SmartConsole management plane validation — SIC trust, log server connectivity
• Multi-Domain (MDS) domain isolation audit for MSSP or multi-tenant environments
• NAT policy review after network re-addressing or migration
• Pre-upgrade rulebase baseline before R80.x → R81.x migration
• Identity awareness assessment — verifying AD integration and access role coverage

Prerequisites

• Read-only administrator access to SmartConsole or Management Server API (mgmt_cli / Web API)
• SSH access to the Security Gateway for fw, cpstat, and cpview commands (Expert mode)
• Understanding of the management architecture — Management Server, Log Server, and Security Gateway relationships
• Knowledge of expected blade activation per gateway — which blades should be enabled where
• For MDS environments: domain-level access with visibility into each managed domain
• Policy installed — audit evaluates the installed policy, not the SmartConsole staging session

Procedure

Follow this audit flow sequentially. Each step builds on prior findings. The procedure moves from management architecture through rulebase layer analysis to blade activation, NAT, identity, and compliance verification.

Step 1: Management Architecture Inventory

Map the management plane topology.

cpstat mg
mgmt_cli show gateways-and-servers --format json -r true

Record: Management Server hostname and version, Log Server(s), Security Gateway(s) with version and SIC status. In MDS environments, list all domains and their assigned gateways.

Verify SIC trust between Management Server and each gateway:

cpstat sic
fw stat

SIC (Secure Internal Communication) trust must be established for policy installation and log forwarding. A gateway with SIC status other than "Trust established" cannot receive policy updates — stale policy is a Critical finding.

For Multi-Domain deployments, verify domain isolation:

mdsstat

Each domain should be an independent management container. Cross-domain policy leakage indicates architecture misconfiguration.

Check Management Server disk space and health — a full log partition prevents logging:

cpstat os -f disk
cpview

Step 2: Rulebase Layer Analysis

R80+ uses a Unified Policy model with ordered layers. Each layer is an independent rulebase evaluated sequentially.

mgmt_cli show access-rulebase name "Network" --format json -r true

Retrieve each access layer and evaluate:

• Layer structure: Ordered layers evaluate top-to-bottom. Each layer must independently reach a decision (Accept/Drop/Reject) for the traffic, or the traffic is implicitly dropped. An inline layer is embedded within a rule in a parent layer — it sub-divides that rule's match.
• Rule ordering within layers: First-match evaluation. Rules within a layer are evaluated top-down; the first matching rule is applied.
• Implicit rules: Check Point inserts implicit rules controlled by Global Properties. Key implicit rules include:
  • Accept control connections (Management, logging)
  • Accept outgoing from gateway
  • Cleanup rule (default drop at bottom)
  • Stealth rule (protect the gateway itself — must be explicitly added)
• Disabled rules: Rules with enabled: false consume rulebase space but do not evaluate. Flag for cleanup.
• Rule hit counts: Identify rules with zero hits over 90+ days as cleanup candidates. Hit counts are available via SmartConsole or API.
• Overly permissive rules: Rules with Source=Any, Destination=Any, Service=Any, Action=Accept are Critical — they permit all traffic within the layer.

mgmt_cli show access-rulebase name "Network" details-level full --format json -r true

Use details-level full to retrieve source, destination, service, action, track, and profile bindings for each rule.

Step 3: Blade Activation Audit

Check Point Software Blades provide security functions. Each blade must be licensed and enabled per gateway.

cpstat blades
cpstat fw

Verify activation status for each blade on every gateway:

Compare licensed blades (contract entitlement) against enabled blades. Licensed but disabled blades represent undeployed security capability. Enabled but unlicensed blades will stop functioning on license expiry.

cpstat licenseStat
cplic print

Check Threat Prevention profiles assigned to rules — blades are only effective when both enabled on the gateway AND referenced in policy rules via a Threat Prevention profile.

Step 4: NAT Policy Review

Check Point supports two NAT methods: Automatic NAT (per-object) and Manual NAT (explicit rulebase).

mgmt_cli show nat-rulebase --format json -r true

Evaluate NAT policy:

• Automatic NAT rules: Defined on network objects (host, network, address range). Check Point generates NAT rules automatically based on object NAT settings. Review each object's NAT configuration.
• Manual NAT rules: Explicit rules in the NAT rulebase, evaluated top-down before automatic rules. Review rule ordering for conflicts.
• NAT method: Hide NAT (many-to-one PAT) vs Static NAT (one-to-one). Static NAT on internal servers should have corresponding security rules restricting access to required services only.
• NAT rule ordering: Manual rules evaluate before Automatic rules. Within each section, rules evaluate top-down. Conflicting rules in manual section override automatic NAT.

Verify that NAT does not expose internal addressing or create unintended access paths. Cross-reference static NAT entries with security policy rules.

Step 5: Identity Awareness and Access Role Assessment

If Identity Awareness blade is enabled, evaluate the identity integration.

pdp status stat
mgmt_cli show access-roles --format json -r true

Check:

• Identity sources: Active Directory integration (AD Query or Identity Collector), RADIUS accounting, Terminal Servers agent, captive portal, Remote Access VPN identity. Verify connectivity to each source.
• Access roles in security rules: Access roles combine user/group identity with machine identity. Rules referencing access roles require functioning identity sources — if AD connectivity fails, identity-based rules cannot match, and traffic falls to non-identity rules.
• Identity agent deployment: Check whether Identity Agent or Captive Portal covers all user segments. Gaps in identity collection mean those users match rules as "unknown user."
• Identity sharing: In MDS or distributed environments, verify identity information is shared between gateways that need it.