156-315.81.20 Advanced Policy Configuration

Advanced Policy Configuration Detailed Explanation

This breakdown will focus on the essential components of Advanced Policy Configuration in Check Point environments.

Key Objective 1: Dynamic Objects and Updatable Objects

What are Dynamic Objects?

Dynamic Objects are placeholders used in security policies when the actual IP address of a resource is unknown or subject to change. They are particularly useful in environments with dynamic IPs or during migrations.

How Dynamic Objects Work:

1. A Dynamic Object is defined in SmartConsole without specifying a static IP address.
2. When a connection is initiated, the gateway dynamically resolves the object’s IP using configured rules or an external script.
3. Example Use Case:
   • A mobile workforce uses dynamic IPs. Policies based on Dynamic Objects allow seamless access without manually updating IP addresses.

Steps to Configure Dynamic Objects:

1. Define the Object:
   • In SmartConsole, create a new object of type Dynamic Object.
   • Assign a placeholder name (e.g., “MobileUsers”).
2. Map IPs Dynamically:
   • Use the CLI or an API to update the object’s IP mapping as needed.
   • Command: dynamic_objects -o MobileUsers -r <IP>
3. Apply to Policies:
   • Use the Dynamic Object in access control or NAT policies.

What are Updatable Objects?

Updatable Objects represent cloud-based or external resources, such as AWS services or known malicious IPs. These objects automatically update based on feeds from Check Point ThreatCloud or other external data sources.

Benefits of Updatable Objects:

1. Automatically reflect changes in cloud resources or threat intelligence.
2. Simplify policy management for hybrid or multi-cloud environments.
3. Reduce administrative overhead for frequently changing external entities.

Steps to Use Updatable Objects:

1. In SmartConsole, navigate to Updatable Objects under the objects section.
2. Select the required service, such as "AWS Regions" or "Microsoft Office365."
3. Add the object to the appropriate access control policy or rule.
4. Ensure the gateway has internet access to sync updates.

Key Objective 2: Layered Policy Management

What is Layered Policy Management?

Layered Policy Management divides a security policy into multiple layers, each focusing on specific aspects of access control. This approach improves clarity and enables modular management of complex environments.

Components of Layered Policies:

1. Global Layer:
   • Applies universally across all gateways managed by the server.
2. Sub-Policies:
   • Nested policies focusing on granular access control for specific zones or user groups.
3. Local Layers:
   • Defined per gateway for unique access requirements.

Steps to Configure Shared Policies Across Multiple Gateways:

1. In SmartConsole, create a Shared Layer under the policy section.
2. Define rules that apply universally to all gateways (e.g., block certain ports or malicious IPs).
3. Attach the shared layer to the policies of individual gateways.

What are Sub-Policies?

Sub-Policies are embedded within the main policy and act as "rules within rules." They are often used for:

1. Delegating control to specific administrators.
2. Applying granular controls to specific traffic flows (e.g., departmental access policies).

How to Implement Sub-Policies:

1. In SmartConsole, create a new sub-policy under the desired rule.
2. Define specific rules within the sub-policy, such as allowing or denying access based on source, destination, or services.
3. Test the policy to ensure the rules function as intended.

Key Objective 3: Global Policy Management

What is a Global Domain?

A Global Domain in Check Point is used to create a unified policy applicable across multiple domains in a Multi-Domain Management (MDM) environment. It ensures consistency in security practices across geographically dispersed or organizationally distinct environments.

Benefits of Global Policy Management:

1. Centralized management for multinational organizations.
2. Reduces redundancy by reusing shared rules and objects.
3. Allows specific domain-level customization while maintaining global oversight.

Steps to Create a Global Policy:

1. In the Multi-Domain Security Management Console, define a new Global Domain.
2. Create a global policy, specifying rules and objects that apply universally.
3. Distribute the global policy to individual domains.

Delegating Domain-Level Controls:

1. Assign domain administrators with limited rights to modify local rules within the global framework.
2. Configure audit logs to track changes made by domain-level administrators.

Key Objective 4: NAT (Network Address Translation)

What is NAT?

Network Address Translation (NAT) modifies the source or destination IP address of traffic as it passes through the gateway. It is used for purposes such as:

1. Hiding internal IP addresses from external networks.
2. Enabling communication between overlapping IP ranges.
3. Forwarding traffic to specific internal resources.

Types of NAT in Check Point:

1. Hide NAT:

   • Multiple internal IPs share a single external IP.
   • Used for outbound traffic to the internet.
   • Example:
     • Internal Range: 192.168.1.0/24
     • External NAT IP: 203.0.113.1

2. Static NAT:

   • One-to-one mapping between internal and external IPs.
   • Example:
     • Internal Server: 192.168.1.10
     • External NAT IP: 203.0.113.10

3. Bi-Directional NAT:

   • Combines static NAT with reverse NAT for traffic initiated from either direction.
   • Example:
     • External access to an internal server via a public IP.

Steps to Configure NAT Rules:

1. Open the NAT Policy section in SmartConsole.
2. Add a new rule and specify:
   • Original Source/Destination.
   • Translated Source/Destination.
3. Test the rule by sending traffic to verify the translation.

Advanced Use Cases

Scenario 1: Designing Policies for Dynamic Endpoints

• Problem: A company employs remote workers whose IPs change frequently.
• Solution:
  • Use Dynamic Objects to represent remote workers.
  • Define a policy allowing access to internal systems based on these objects.

Scenario 2: Implementing Global Policies for Multinational Organizations

• Problem: A multinational company needs uniform security policies while allowing local flexibility.
• Solution:
  • Use a Global Domain to create consistent rules for all locations.
  • Delegate domain-level control for local administrators to customize policies.

Advanced Policy Configuration (Additional Content)

Key Objective 1: Dynamic & Updatable Objects

Limitations of Dynamic Objects Across Blades

Dynamic Objects are powerful for policy flexibility, especially in dynamic environments (e.g., VPNs, roaming users). However, their applicability is limited to specific Blades:

Blade	Supports Dynamic Objects?
Access Control	Yes
IPS	Yes
VPN	Yes
Threat Prevention (Anti-Bot, Anti-Virus, etc.)	Not supported

Implication: You cannot use Dynamic Objects in Threat Prevention profiles or rules.

Useful CLI Parameters for Managing Dynamic Objects

In addition to the commonly used -r (register/update) option, the dynamic_objects command supports other useful parameters:

dynamic_objects -o <object_name> -r <IP>      # Register/update
dynamic_objects -o <object_name> -d <IP>      # Delete IP
dynamic_objects -l                            # List all registered dynamic objects

These are essential for troubleshooting or scripting dynamic object changes in real time.

Updatable Objects – Cloud Access Requirement

Updatable Objects automatically retrieve threat intelligence or cloud service IPs from Check Point’s online repositories.

• Gateway Connectivity Requirement:
  The gateway must have outbound access to updates.checkpoint.com (and associated services) to receive updates.

• Typical Uses:

  • Microsoft Office365
  • AWS Regions / Services
  • Known Botnet Command & Control IPs

Tip: Ensure DNS resolution and HTTPS access are functioning from the gateway to avoid stale objects.

Key Objective 2: Layered Policies

Inline Layer vs. Ordered Layer – Core Distinction

This is a frequent exam topic in CCSE and should be clearly understood:

Aspect	Inline Layer	Ordered Layer
Placement	Nested inside a rule in the main Access Policy	Stacked sequentially above or below others
Evaluation Order	Processed only if parent rule matches	Processed in top-down order
Use Case	Granular access control per department/role	Multi-policy logic across domains/sites
Visual Marker	Represented by a nested rule (>) icon	Separate tabbed policy layers

Administrator Access Control per Layer

Check Point supports Role-Based Access Control (RBAC), allowing you to restrict administrators to specific policy layers:

• In SmartConsole > Manage & Settings > Permissions Profiles:
  • Define what layers each admin can view/edit.
  • Prevent unauthorized changes to global or sensitive layers.

This is especially useful in large environments with multiple security admins (e.g., per department or region).

Key Objective 3: Global Domain (in MDM Environments)

Global Policy Overlap Handling

When Global and Local policies include overlapping rules or objects, precedence and conflict resolution follow this logic:

1. Global Policy is evaluated first.
2. If a Global rule matches, local rules are bypassed for that traffic.
3. This means the Global Policy has enforcement priority, which may override site-specific intentions.

Best Practice: Minimize conflicts by using explicit exclusion rules in Global Policy or coordinating object naming across domains.

Global Publish and Install Requirements

Global Domain policies require a two-stage process:

1. Global Publish:

• Commits changes within the Global Domain.

2. Global Install:

• Pushes the Global Policy to all linked domains.

Important Exam Note: Global policy changes do not take effect unless both steps are completed. This is a common source of operational errors.

Key Objective 4: NAT (Network Address Translation)

NAT Rule Matching Order – Manual vs. Automatic

Check Point NAT logic uses the following evaluation order:

1. Manual NAT rules (explicit) – Located in the NAT Rule Base.
2. Automatic NAT rules – Defined within object properties.

Implication:
If both manual and automatic NAT rules exist for the same traffic, manual NAT will take precedence.

Tip for exam questions: Always check if manual NAT exists before assuming automatic NAT will apply.

Special Scenario – NAT for Internal Communication

In complex environments, hosts may need to communicate using their NATed (translated) IPs even when located in the same network. This requires "Hide Behind Internal IP" or "Translate Internal Communication" configuration.

Key Concepts:

• Bidirectional NAT:
  • Enables translation for both directions of communication (initiator and responder).
• NAT Loopback:
  • Internal users accessing an internal server using its public IP.

Troubleshooting Tip: Use fw monitor to verify actual source/destination after NAT processing.

Summary Table of Key Additions

Category	Supplementary Insight
Dynamic Objects	Blade limitations, CLI options -d, -l
Updatable Objects	Requires internet access to updates.checkpoint.com
Inline vs Ordered Layers	Evaluation logic and visual differences
Layer Permissions	Per-layer admin access control via RBAC
Global Policy in MDM	Overlap behavior, Global Publish + Install requirements
NAT Evaluation Order	Manual over automatic; bidirectional NAT use case