Skill: vahagn-madatyan/checkpoint-firewall-audit (version 1.0.0)

--- name: checkpoint-firewall-audit description: >- Check Point R80+/R81.x rulebase layer analysis with blade activation audit, SmartConsole management plane validation, NAT policy review, identity awareness assessment, and compliance verification. Systematic layer-by-layer evaluation for Check Point Security Gateways managed via Management Server or Multi-Domain Server (MDS). license: Apache-2.0 metadata: safety: read-only author: network-security-skills-suite version: "1.0.0" openclaw: '{"emoji":"🛡️","safetyTier":"read-only","requires":{"bins":["ssh"],"env":[]},"tags":["checkpoint","firewall","audit"],"mcpDependencies":[],"egressEndpoints":[]}' --- # 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: | 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. ``` 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. ### Step 6: Log and Compliance Verification Verify log infrastructure and compliance monitoring. ``` cpstat logging fw log -t ``` 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. ``` cpstat antimalware cpstat appi ``` Verify Threat Prevention signature databases are current: | Database | Maximum Age | Check | |----------|-------------|-------| | IPS signatures | 7 days | `cpstat ips` | | 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 ``` Rule has Source=Any, Destination=Any, Service=Any ├── Action = Accept? │ ├── Yes → CRITICAL: Fully open rule │ │ ├── Is this a temporary migration rule? │ │ │ ├── Yes → Set expiration, add to migration tracker │ │ │ └── No → Immediate remediation required │ │ └── Identify actual traffic via SmartLog: │ │ Filter by rule number → analyze source/dest/service │ │ → Replace with specific objects and services │ └── No (Drop/Reject) → This is the cleanup rule; verify Track=Log │ ├── Threat Prevention profile bound? │ ├── No → Bind profile BEFORE narrowing rule scope │ │ └── Ensures threat visibility during migration │ └── Yes → Proceed with scope reduction │ └── Rule in ordered layer or inline layer? ├── Ordered layer → Affects all traffic in that layer └── Inline layer → Scoped to parent rule match └── Check parent rule scope to assess true exposure ``` ### Blade Gap Remediation ``` Gateway missing expected blades ├── Blade licensed? │ ├── No → Procurement required; document risk until enabled │ └── Yes → Enable blade in SmartConsole gateway object │ ├── IPS → Assign IPS profile; set to Prevent mode │ ├── Application Control → Create/assign App Control policy │ ├── Anti-Bot → Assign profile; enable in Threat Prevention │ ├── Anti-Virus → Assign profile; enable in Threat Prevention │ ├── Threat Emulation → Assign profile; select emulation env │ ├── HTTPS Inspection → Configure CA cert + inspection policy │ └── URL Filtering → Assign categorization profile │ ├── Performance concern? │ ├── SecureXL acceleration enabled? → Verify blade compatibility │ └── CoreXL CPU allocation → Check SNDs and FW workers balance │ cpstat os -f multi_cpu │ └── After enabling → Install policy and verify blade active: cpstat blades -f blade_name ``` ## Report Template ``` CHECK POINT SECURITY POLICY AUDIT REPORT ========================================== Management Server: [hostname] [version] Gateway(s): [hostname(s)] [version(s)] Domain: [domain name (MDS) / N/A (SMS)] Policy Name: [installed policy name] Audit Date: [timestamp] Performed By: [operator/agent] MANAGEMENT ARCHITECTURE: - Management Server: [hostname] R[version] - Log Server: [hostname(s)] - Gateways: [count] ([list with SIC status]) - MDS domains: [count or N/A] RULEBASE LAYER SUMMARY: - Ordered layers: [count] ([layer names]) - Total rules across layers: [count] - Accept rules: [n] | Drop rules: [n] | Inline layers: [n] - Rules with Threat Prevention profiles: [n] / [accept count] - Rules with zero hits (>90d): [count] - Disabled rules: [count] BLADE ACTIVATION: Per Gateway: [gateway name] - Licensed blades: [list] - Enabled blades: [list] - Gap: [licensed but not enabled] NAT SUMMARY: - Manual NAT rules: [count] - Automatic NAT objects: [count] - Static NAT entries: [count] - Conflicting rules identified: [count or none] IDENTITY AWARENESS: - Identity sources: [list with status] - Access roles in policy: [count] - Coverage gaps: [segments without identity] FINDINGS: 1. [Severity] [Category] — [Description] Layer: [layer name] Rule Number: [n] Issue: [specific problem] Current Config: [what the rule does now] Recommendation: [specific remediation] SIGNATURE CURRENCY: - IPS: [version] ([age]) - App Control: [version] ([age]) - Anti-Bot: [version] ([age]) - Anti-Virus: [version] ([age]) RECOMMENDATIONS: - [Prioritized action list by severity] NEXT AUDIT: [CRITICAL: 30d, HIGH: 90d, clean: 180d] ``` ## 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.

path: references/cli-reference.md
content: # Check Point CLI and API Reference — Audit Commands

Read-only commands organized by audit category for Check Point Security
Gateway and Management Server assessment. All commands are non-modifying
(`show`, `stat`, diagnostic queries). Validated against R80.40 and R81.x.

Four access methods are available:
- **Clish:** Check Point CLI shell on the gateway (restricted command set)
- **Expert mode:** Full Linux shell on the gateway (fw, cpstat, cpview)
- **mgmt_cli:** Management API CLI on the Management Server (policy/object queries)
- **Web API:** HTTPS REST API on Management Server (same as mgmt_cli, JSON)

## System and SIC Status

| Function | Command | Context |
|----------|---------|---------|
| System version and build | `clish -c "show version all"` | Gateway/SMS |
| Hostname and platform | `clish -c "show hostname"` | Gateway/SMS |
| Uptime | `clish -c "show uptime"` | Gateway/SMS |
| CPU and memory summary | `cpview` (interactive) | Gateway |
| CPU utilization | `cpstat os -f cpu` | Gateway |
| Memory utilization | `cpstat os -f memory` | Gateway |
| Disk space | `cpstat os -f disk` | Gateway/SMS |
| SIC status | `cpstat sic` | Gateway |
| SIC certificate details | `cpconfig` → option 7 (view) | Gateway |
| Firewall status (policy name, install time) | `fw stat` | Gateway |
| All CP processes status | `cpwd_admin list` | Gateway/SMS |
| Management Server status | `cpstat mg` | SMS |
| MDS domain status | `mdsstat` | MDS |

### System Notes

- `fw stat` is the quickest way to verify the installed policy name and installation timestamp. Compare with SmartConsole to detect policy drift.
- `cpview` provides a real-time dashboard of CPU, memory, network, and blade status. Use it for quick health assessment.
- `cpwd_admin list` shows all Check Point watchdog-managed processes and their PID/status. Crashed processes appear as "down."

## Policy and Rulebase

| Function | Command | Context |
|----------|---------|---------|
| List access layers | `mgmt_cli show access-layers --format json -r true` | SMS |
| Show rulebase (layer) | `mgmt_cli show access-rulebase name "<layer>" --format json -r true` | SMS |
| Show rulebase (full detail) | `mgmt_cli show access-rulebase name "<layer>" details-level full --format json -r true` | SMS |
| Show NAT rulebase | `mgmt_cli show nat-rulebase --format json -r true` | SMS |
| Show HTTPS inspection rulebase | `mgmt_cli show https-rulebase --format json -r true` | SMS |
| List threat prevention profiles | `mgmt_cli show threat-profiles --format json -r true` | SMS |
| Show threat prevention rulebase | `mgmt_cli show threat-rulebase --format json -r true` | SMS |
| Show gateways and servers | `mgmt_cli show gateways-and-servers --format json -r true` | SMS |
| Show access roles | `mgmt_cli show access-roles --format json -r true` | SMS |
| Installed policy on gateway | `fw stat` | Gateway |
| Connection table summary | `fw tab -t connections -s` | Gateway |
| Active connections count | `cpstat fw -f policy` | Gateway |

### Policy Notes

- `mgmt_cli` commands with `-r true` use the last published session (read-only mode). Without `-r true`, a new session is created (unnecessary for audit).
- `details-level full` returns complete object data (IP addresses, names) inline rather than just UIDs. Required for meaningful audit analysis.
- `fw tab -t connections -s` shows connection table utilization. Near-capacity tables cause new connection drops.

## Blade Status

| Function | Command | Context |
|----------|---------|---------|
| All blade status summary | `cpstat blades` | Gateway |
| Firewall blade statistics | `cpstat fw` | Gateway |
| IPS blade status | `cpstat ips` | Gateway |
| Application Control status | `cpstat appi` | Gateway |
| URL Filtering status | `cpstat urlf` | Gateway |
| Anti-Bot status | `cpstat antimalware -f ab` | Gateway |
| Anti-Virus status | `cpstat antimalware -f av` | Gateway |
| Threat Emulation status | `cpstat threat_emulation` | Gateway |
| Content Awareness status | `cpstat content_awareness` | Gateway |
| HTTPS Inspection statistics | `cpstat https_inspection` | Gateway |
| Identity Awareness status | `pdp status stat` | Gateway |
| VPN tunnel status | `cpstat vpn` | Gateway |

### Blade Notes

- `cpstat blades` provides a single-command overview of all enabled blades and their status. Use this for initial blade inventory.
- Each blade-specific `cpstat` command provides counters (inspected, detected, prevented). Zero counters on an enabled blade may indicate misconfiguration or no matching traffic.
- Anti-Bot and Anti-Virus share the `antimalware` category; use the `-f ab` or `-f av` flag to query each independently.

## NAT and Connections

| Function | Command | Context |
|----------|---------|---------|
| NAT rulebase (API) | `mgmt_cli show nat-rulebase --format json -r true` | SMS |
| NAT translation table | `fw tab -t fwx_alloc -s` | Gateway |
| Connection table (summary) | `fw tab -t connections -s` | Gateway |
| Connection table (detail) | `fw tab -t connections -u` | Gateway |
| Active connections count | `cpstat fw -f policy` | Gateway |
| Session rate | `cpstat fw -f policy` (inspected/sec field) | Gateway |
| ARP table | `clish -c "show arp dynamic all"` | Gateway |

### NAT Notes

- `fw tab -t fwx_alloc -s` shows the NAT allocation table size and usage. High utilization may indicate NAT pool exhaustion for hide NAT.
- Cross-reference NAT table entries with security policy findings to identify static NAT objects that may need tighter access control.

## Sessions and Logging

| Function | Command | Context |
|----------|---------|---------|
| Log file list | `ls -la $FWDIR/log/` | Gateway/SMS |
| Recent log entries | `fw log -t` | Gateway |
| Log status (forwarding) | `cpstat logging` | Gateway |
| SmartLog query (API) | `mgmt_cli show logs filter "<query>" --format json -r true` | SMS |
| Audit log (admin actions) | `mgmt_cli show sessions --format json -r true` | SMS |
| Published sessions | `mgmt_cli show sessions --format json -r true` | SMS |

### Logging Notes

- `cpstat logging` shows log forwarding status and queue size. A growing queue indicates the gateway cannot forward logs fast enough — logs may be dropped.
- `fw log -t` tails the local log file. Useful for real-time verification that specific rules are generating log entries.
- SmartLog queries via API support the same filter syntax as the SmartConsole SmartLog view.

## Cluster and High Availability

| Function | Command | Context |
|----------|---------|---------|
| Cluster status | `cphaprob stat` | Gateway |
| Cluster members and state | `cphaprob -a if` | Gateway |
| Cluster sync status | `cphaprob syncstat` | Gateway |
| Interface status per member | `cphaprob -ia list` | Gateway |
| Failover history | `cphaprob -f list` | Gateway |
| VSX virtual systems | `vsx stat -v` | VSX Gateway |

### Cluster Notes

- `cphaprob stat` shows the HA state (Active/Standby/Down) and cluster member health. Both members should be visible.
- `cphaprob syncstat` reveals whether state synchronization (session table, policy) is functioning between members. Sync failures mean failover may drop sessions.

## Performance and Acceleration

| Function | Command | Context |
|----------|---------|---------|
| SecureXL status | `fwaccel stat` | Gateway |
| SecureXL template count | `fwaccel templates -S` | Gateway |
| CoreXL CPU allocation | `cpstat os -f multi_cpu` | Gateway |
| CoreXL SND/FW worker split | `fw ctl multik stat` | Gateway |
| Connection table capacity | `fw tab -t connections -s` | Gateway |
| Packet buffer utilization | `cpstat os -f memory` | Gateway |

### Performance Notes

- `fwaccel stat` shows SecureXL acceleration status and counters. "Accept templates" accelerate established sessions past the firewall kernel — verify that security-sensitive traffic is not being over-accelerated (bypassing blade inspection).
- `fw ctl multik stat` shows the CoreXL worker distribution. Uneven distribution can cause CPU bottlenecks on specific workers.

## Management API (Web API) Examples

For programmatic audit, the Management API is preferred over CLI scraping.
All `mgmt_cli` commands have equivalent HTTPS API calls.

| Function | API Call |
|----------|---------|
| Login (get session token) | `POST /web_api/login {"user":"<user>","password":"<pass>"}` |
| Show access layers | `POST /web_api/show-access-layers {}` |
| Show rulebase | `POST /web_api/show-access-rulebase {"name":"<layer>","details-level":"full"}` |
| Show NAT rulebase | `POST /web_api/show-nat-rulebase {}` |
| Show gateways | `POST /web_api/show-gateways-and-servers {}` |
| Show threat profiles | `POST /web_api/show-threat-profiles {}` |
| Show logs | `POST /web_api/show-logs {"filter":"<query>"}` |
| Logout | `POST /web_api/logout {}` |

### API Notes

- All API calls require a session token from `/web_api/login`. The token is passed in the `X-chkp-sid` header.
- For audit, use read-only credentials. The API enforces the same RBAC as SmartConsole.
- API calls use POST with JSON body, even for read operations. The base URL is `https://<sms-ip>/web_api/`.
- Use `"details-level": "full"` to get resolved object details instead of UIDs.


path: references/policy-model.md
content: # Check Point R80+ Policy Architecture

Reference for Check Point R80+ management architecture, Unified Policy model,
Software Blade framework, and policy installation process. This documents
how Check Point evaluates traffic from gateway ingress through rulebase
layers — the foundation for understanding policy audit findings.

## Management Architecture

```
SmartConsole (GUI Client)
       │
       ▼ (TCP 19009 / HTTPS 443)
┌─────────────────────────────┐
│  Security Management Server │  Central policy repository
│  (SMS)                      │  Stores rulebase, objects, logs
│                             │  Runs management API (mgmt_cli)
└────────┬────────────────────┘
         │  SIC (Secure Internal Communication)
         │  Certificate-based mutual authentication
         ▼
┌─────────────────────────────┐
│  Security Gateway           │  Enforces installed policy
│  (SGW)                      │  Runs fw, fwd, cpd daemons
│                             │  Reports logs back to SMS
└─────────────────────────────┘

Multi-Domain Server (MDS) variant:
┌─────────────────────────────┐
│  Multi-Domain Server        │
│  ├── Domain 1 (SMS instance)│  Independent object/policy DB
│  │   └── Gateway A, B       │
│  ├── Domain 2 (SMS instance)│  Isolated from Domain 1
│  │   └── Gateway C          │
│  └── Global Domain          │  Global policies/objects shared
│      └── Global assignments │  across domains
└─────────────────────────────┘
```

### Key Components

| Component | Role | Port |
|-----------|------|------|
| **SmartConsole** | GUI for policy management, object definition, log review | TCP 19009 (legacy), HTTPS 443 (R81+) |
| **Security Management Server (SMS)** | Central repository for policy, objects, and certificates | TCP 18190 (SIC), 18210, 18264 |
| **Log Server** | Receives and stores logs from gateways; may be co-located with SMS | TCP 18210 |
| **Security Gateway (SGW)** | Enforces policy on traffic; inspects packets per installed rulebase | SIC to SMS |
| **SmartEvent** | Correlation engine for log-based event detection | Co-located with Log Server or separate |
| **MDS** | Multi-tenant management; each domain is an isolated SMS instance | Same as SMS per domain |

### SIC (Secure Internal Communication)

SIC provides certificate-based authentication and encrypted communication
between all Check Point components. Each component has an SIC certificate
issued by the Management Server's Internal Certificate Authority (ICA).

SIC states:

| State | Meaning | Audit Implication |
|-------|---------|-------------------|
| **Trust established** | Mutual certificate authentication succeeded | Normal — policy installation works |
| **Uninitialized** | SIC not yet initialized on the component | Component cannot communicate with SMS |
| **Trust in progress** | SIC initialization underway | Transient — wait or reinitialize |
| **Trust broken** | Certificate mismatch or revocation | CRITICAL — gateway cannot receive policy updates |

## Unified Policy Model (R80+)

R80+ replaced the legacy single-rulebase model with a Unified Policy
composed of ordered layers.

### Access Control Policy

```
Access Control Policy
├── Ordered Layer 1: "Corporate Network"
│   ├── Rule 1: Block known-bad IPs → Drop
│   ├── Rule 2: Allow DNS to DNS servers → Accept (inline layer)
│   │   └── Inline Layer: "DNS Inspection"
│   │       ├── Sub-rule 1: Allow UDP/53 → Accept
│   │       └── Sub-rule 2: Allow TCP/53 → Accept
│   ├── Rule 3: Allow web browsing → Accept
│   ├── ...
│   └── Implicit Cleanup Rule → Drop
│
├── Ordered Layer 2: "Application Control"
│   ├── Rule 1: Block risky apps → Drop
│   ├── Rule 2: Allow business apps → Accept
│   └── Implicit Cleanup Rule → Drop
│
└── Policy evaluation: ALL layers must accept.
    If any layer drops, traffic is dropped.
```

### Layer Types

| Type | Behavior | Use Case |
|------|----------|----------|
| **Ordered Layer** | Independent rulebase evaluated top-down; first match wins within layer | Primary policy enforcement — network, application, content layers |
| **Inline Layer** | Embedded within a rule in a parent layer; evaluates only when parent rule matches | Sub-dividing a broad rule into granular sub-decisions |

### Policy Evaluation Logic

Traffic must be accepted by **every ordered layer** in the policy. If any
layer drops the traffic, the overall decision is Drop — even if other layers
accept it.

Within each layer:
1. Rules evaluate top-down (first match wins)
2. If a rule's action is an inline layer, the inline layer's rules evaluate
3. If no rule matches in a layer, the implicit cleanup rule applies (Drop)

### Implicit Rules

Implicit rules are controlled by Global Properties in SmartConsole, not by
explicit rules in the rulebase. Key implicit rules:

| Implicit Rule | Default State | Function |
|--------------|---------------|----------|
| Accept Control Connections | Before Last | Allows management traffic (SIC, logging, policy install) |
| Accept Remote Access VPN | Before Last | Allows VPN connections to the gateway |
| Accept Outgoing from Gateway | Before Last | Allows gateway-initiated traffic (DNS, NTP, updates) |
| Accept ICMP | Before Last | Allows ICMP packets |
| Stealth Rule | Not automatic | Must be manually created to protect gateway from data-plane access |

The "Accept Control Connections" implicit rule is particularly important —
it ensures management connectivity even if no explicit rule permits it.
However, relying on implicit rules reduces visibility since they are not
visible in the standard rulebase view.

## Software Blade Architecture

Check Point uses a modular blade architecture. Each blade provides a
specific security function and requires both licensing and activation.

### Blade Categories

| Category | Blades |
|----------|--------|
| **Network Security** | Firewall, IPS, VPN (IPSec/SSL) |
| **Threat Prevention** | Anti-Bot, Anti-Virus, Threat Emulation, Threat Extraction |
| **Access Control** | Application Control, URL Filtering, Content Awareness, Identity Awareness |
| **Inspection** | HTTPS Inspection |
| **Compliance** | Compliance Blade (policy verification against best practices) |

### Blade Activation Model

```
License (Contract/SKU)
       │
       ▼
Blade Enabled (Gateway Object in SmartConsole)
       │
       ▼
Threat Prevention Profile (references blade in policy rule)
       │
       ▼
Policy Installed on Gateway
       │
       ▼
Blade Active (inspecting traffic)
```

A blade that is licensed and enabled but not referenced in any policy rule's
Threat Prevention profile does not inspect traffic. All four levels must be
satisfied for effective protection.

### Threat Prevention Profiles

Threat Prevention profiles bundle blade settings and are assigned to rules:

| Profile Type | Controls |
|-------------|----------|
| **Threat Prevention** | IPS, Anti-Bot, Anti-Virus protections and actions |
| **Threat Emulation** | Sandbox environments, file types, emulation scope |
| **Threat Extraction** | File reconstruction settings, extracted content types |

## NAT Policy

### NAT Types

| Type | Definition | Evaluation Order |
|------|-----------|-----------------|
| **Manual NAT** | Explicit rules in the NAT rulebase, defined by the administrator | Evaluated first (top-down) |
| **Automatic NAT** | Generated from NAT settings on network objects (hosts, networks, ranges) | Evaluated after manual rules |

### Automatic NAT Sub-types

| Sub-type | Method | Use |
|----------|--------|-----|
| **Hide NAT** | Many-to-one PAT behind a single IP or gateway interface | Outbound internet access for internal networks |
| **Static NAT** | One-to-one bidirectional address translation | Server publishing, bi-directional access |

### NAT Evaluation Order

```
1. Manual NAT rules (top-down within manual section)
2. Automatic Static NAT rules (system-generated from objects)
3. Automatic Hide NAT rules (system-generated from objects)
```

Manual rules always take precedence over automatic rules. Within the
automatic section, static NAT evaluates before hide NAT.

## Policy Installation Process

```
SmartConsole → Publish session → Install Policy
       │
       ▼
Management Server compiles policy
       │
       ▼
Compiled policy pushed to gateway(s) via SIC
       │
       ▼
Gateway loads new policy
       │
       ▼
Verification: fw stat → shows policy name + install time
```

### Installation Implications for Audit

- **Policy installation is atomic** — the gateway switches from old to new
  policy in a single operation. No partial-install state.
- **"Policy out of date"** — indicates the rulebase has been modified in
  SmartConsole but not yet installed on the gateway. The gateway runs the
  last installed policy.
- **Install policy failure** — gateway continues running the previous policy.
  A failed install does not leave the gateway unprotected, but it means
  recent rule changes are not enforced.
- **Session publishing** — R80+ uses a session model. Changes are made in
  private sessions and must be published before installation. Unpublished
  changes exist only in the session owner's view.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)