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.

CODEBLOCK0

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:

CODEBLOCK1

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:

CODEBLOCK2

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:

CODEBLOCK3

Step 2: Rulebase Layer Analysis

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

CODEBLOCK4

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.

CODEBLOCK5

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.

CODEBLOCK6

Verify activation status for each blade on every gateway:

Blade	Function	Expected On
Firewall	Stateful packet inspection	All gateways
IPS

Intrusion prevention signatures | Internet-facing gateways |
| Application Control | Application identification and enforcement | Internet-facing gateways |
| URL Filtering | URL categorization and blocking | Gateways with user web traffic |
| Anti-Bot | Bot C2 communication detection | All gateways |
| Anti-Virus | File-based malware scanning | All gateways |
| Threat Emulation | Sandbox analysis for unknown files | Internet-facing gateways |
| Threat Extraction | Content disarm and reconstruction | Email/download gateways |
| Content Awareness | Data visibility and DLP | Gateways handling sensitive data |
| HTTPS Inspection | TLS decryption for content inspection | Internet-facing gateways |

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.

CODEBLOCK7

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).

CODEBLOCK8

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.

CODEBLOCK9

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.

Step 6: Log and Compliance Verification

Verify log infrastructure and compliance monitoring.

CODEBLOCK10

Check:

• - Log Server connectivity: Verify each gateway can forward logs to the

Log Server. Check for log gaps that indicate connectivity interruptions.

• - Log completeness: Rules with Track=None produce no log entries.

Identify security-relevant rules without logging — at minimum, all Drop and Reject rules should log.

• - SmartEvent correlation: If SmartEvent is deployed, verify correlation

policy is active and generating events from security logs.

• - Compliance blade: If enabled, verify compliance checks are running

and review the latest compliance report for failed checks.

CODEBLOCK11

Verify Threat Prevention signature databases are current:

Database	Maximum Age	Check
IPS signatures	7 days	INLINECODE8
Application Control DB

7 days | cpstat appi |
| Anti-Bot signatures | 24 hours | cpstat antimalware |
| Anti-Virus signatures | 24 hours | cpstat antimalware |
| URL Filtering DB | 7 days | cpstat urlf |

Threshold Tables

Policy Rule Severity Classification

Finding	Severity	Rationale
Source=Any, Destination=Any, Service=Any, Action=Accept	Critical	Fully open rule — permits all traffic within the layer
Gateway SIC trust not established

Critical | Gateway cannot receive policy updates; running stale policy | | Licensed blades not enabled on internet-facing gateway | High | Purchased security capability not deployed | | Rule with Action=Accept and no Threat Prevention profile | High | Traffic passes without IPS, Anti-Bot, or AV inspection | | HTTPS Inspection not enabled on internet-bound traffic | High | Encrypted traffic bypasses content inspection blades | | Threat Prevention signatures >7 days old | High | Detection gap for recently discovered threats | | Missing Stealth rule (no rule protecting gateway itself) | High | Gateway management plane exposed to data-plane traffic | | Manual NAT rule conflicts with Automatic NAT | Medium | Unexpected NAT behavior; traffic may not translate as intended | | Rules with zero hit count >90 days | Medium | Unused rules — cleanup candidates | | Disabled rules in production layer | Medium | Audit confusion; stale configuration | | Track=None on Drop/Reject rule | Medium | Security-relevant denied traffic not logged | | Identity Awareness source connectivity failure | Medium | Identity-based rules unable to match users; fallback behavior | | Log Server connectivity intermittent | Medium | Log gaps reduce incident investigation capability | | Implicit cleanup rule handling all denied traffic | Low | Expected behavior, but verify logging is enabled |

Blade Activation Maturity

Coverage	Maturity	Guidance
All licensed blades enabled + profiles in policy	Mature	Maintain; review profile settings quarterly
Blades enabled but profiles not referenced in rules

Developing | Bind Threat Prevention profiles to all Accept rules | | Licensed blades not enabled | Immature | Enable blades and create Threat Prevention profiles |

Decision Trees

Overly Permissive Rule Remediation

CODEBLOCK12

Blade Gap Remediation

CODEBLOCK13

Report Template

CODEBLOCK14

Troubleshooting

Large Rulebases Spanning Multiple Layers

Auditing rulebases with hundreds of rules across multiple ordered layers
is impractical via SmartConsole alone. Use the Management API to export
all layers programmatically:
mgmt_cli show access-rulebase name "<layer>" details-level full --format json -r true
Iterate over all layers and merge into a single dataset for automated
shadow detection, profile gap analysis, and hit count review.

Multi-Domain Server (MDS) Audits

In MDS deployments, each domain is an isolated management container. The
auditor must connect to each domain separately (or use the MDS-level API
with domain context). Policy in one domain does not affect another — but
verify that cross-domain traffic paths have consistent policies on both
domain gateways.

Policy Installation Failures

If a gateway shows "Policy out of date" in SmartConsole, the running policy
may not match the current rulebase. Use fw stat on the gateway to see
the installed policy name and timestamp. Compare with SmartConsole to
identify the delta. Audit findings should be based on the installed policy,
not the pending session.

SecureXL and CoreXL Impact on Inspection

SecureXL accelerates traffic by bypassing full inspection for established
sessions. Some blades (especially IPS and Threat Emulation) require traffic
to pass through the Firewall kernel (Medium Path or Firewall Path), not
the accelerated path. Verify SecureXL template status:
fwaccel stat and fwaccel templates -S
Templates that match security-sensitive traffic and bypass blade inspection
are a finding.

ClusterXL and VSX Considerations

In ClusterXL (HA) deployments, verify both members run the same policy
version and software release. In VSX (Virtual System Extension) deployments,
each virtual system has independent policy — audit each VS separately.
Use vsx stat -v to list virtual systems.