2.2 Access Control Policy Overview

The Access Control Policy in R82

The Access Control policy is the primary firewall rulebase on a Check Point Security Gateway. In R82, Access Control is unified with Threat Prevention under a single policy model: an Access Control policy contains one or more ordered layers (each a top-down rulebase), and within those ordered layers you can nest inline layers for modular, reusable rule groups. The gateway evaluates the Access Control policy for every connection that passes through it, deciding whether to allow, drop, reject, or hand off the connection to a deeper inspection layer.

This unified model replaced the older split between Firewall and Threat Prevention rulebases. In R82, Application Control, URL Filtering, IPS, Anti-Bot, Anti-Virus, and Threat Emulation/Extraction are still configured on their own tabs, but they are installed as part of the same policy package and chained into the Access Control evaluation flow.

Ordered vs Inline Layers

The two structural building blocks of an Access Control policy are ordered layers and inline layers.

• Ordered layers are independent top-down rulebases. Each ordered layer is evaluated in sequence — first the top ordered layer, then the next, and so on. Within each ordered layer, rules are evaluated top-down and the first match wins.
• Inline layers are nested inside a single rule of an ordered layer. When a rule with an inline layer matches, evaluation drops into the inline layer's rules, evaluates them top-down (first match wins), and the inline layer's result becomes part of the parent rule's action.

The distinction matters because it controls how rules are grouped, shared, and ordered. Ordered layers are the structural backbone; inline layers are the reuse mechanism for grouping related rules under a single parent match.

Layer Types in R82

Check Point R82 supports several Access Control layer types:

A new Access Control policy starts with one Network ordered layer named Network. Administrators typically add an Application ordered layer for App Control/URL Filtering and rely on Threat Prevention layers for IPS, Anti-Bot, Anti-Virus, and SandBlast.

The Layer Evaluation Flow

When a packet arrives at the gateway, the Access Control policy is evaluated as follows:

1. The gateway identifies the connection and looks up the active Access Control policy.
2. The first ordered layer is evaluated top-down. If a rule matches, the rule's action is applied.
3. If the matching rule contains an inline layer, the inline layer is evaluated top-down, and the inline rule's action overrides the parent rule's action for matching traffic.
4. If no rule in the ordered layer matches, the layer's default action is applied (typically Drop or Accept depending on the layer's design).
5. If the layer's action is Accept (or a continue-style action), evaluation proceeds to the next ordered layer, and so on.
6. Once all ordered layers have been evaluated, Threat Prevention layers (IPS, App Control, URL Filtering, Anti-Bot, AV, Threat Emulation) run their own inspection on traffic that Access Control has accepted.

This ordered-chain model lets you separate broad network access decisions from granular application-level decisions without putting every check into one giant rulebase.

Default Actions and Layer Settings

Each ordered layer has a default action — what happens when no rule in the layer matches. For the Network layer this is usually Drop (deny-by-default), aligning with firewall best practice. For Application layers it is typically Allow or Drop depending on whether the layer is enforcing an allow-list or a deny-list posture. The default action is visible at the bottom of the layer in SmartConsole and is editable in the layer's properties.

Layer properties also control:

• Installation targets — which gateways receive this specific layer.
• Sharing — whether the layer is shared across policy packages.
• Inline layer invocation — how inline layers attached to this layer's rules behave.
• Policy — the parent policy package the layer belongs to.

Access Control vs Threat Prevention

Although the policy is unified, Access Control and Threat Prevention perform different jobs. Access Control decides which traffic is allowed to pass the gateway. Threat Prevention inspects the traffic that Access Control allowed to detect and block malicious content. A connection that Access Control drops never reaches Threat Prevention. This ordering is why Access Control rules are typically permissive on broad IP ranges and granular on application/URL rules, while Threat Prevention layers focus on signatures, profiles, and protections.

Why This Matters for the Exam

CCSA R82 questions frequently test the distinction between ordered and inline layers, the order of evaluation (Access Control first, then Threat Prevention), the role of the default action, and the names of the layer types. Remember: ordered layers are sequential rulebases, inline layers are nested rule groups inside a parent rule, and the Access Control policy as a whole is evaluated before Threat Prevention on accepted traffic.