PAN-OS: Components Configured in Panorama Device Groups

PCNSE Objective Focus (Domain 4 - 18%)

4.2 Configure device groups

• 4.2.1 Device group hierarchies

Device Group Purpose: Policies and Objects

In Panorama, Device Groups serve as the primary containers for managing configurations that define *what* traffic is allowed or denied and *how* it should be inspected. Unlike Templates (which handle Network/Device settings), Device Groups focus on:

• Policy Rulesets: Defining the criteria and actions for various policy types.
• Objects: Defining the reusable components (addresses, services, applications, profiles) referenced within those policy rulesets.

Device Groups enable administrators to apply consistent policies and related objects to logical groupings of firewalls (e.g., based on location, function, risk level) and leverage hierarchies for efficient policy inheritance.

When configuring a Device Group in Panorama (or the Shared scope), you primarily manage settings corresponding to the Policies and Objects tabs of a firewall's configuration.

Policies Tab Components:

This is where you define the rules governing traffic flow and security actions:

• Security Policies: (Pre-rules and Post-rules) The core rules defining allow/deny actions based on Zone, Address, User, Application, Service. Security Profiles are attached here.
• NAT Policies: (Pre-rules and Post-rules) Define Source NAT (SNAT) and Destination NAT (DNAT) rules.
• QoS Policies: Define Quality of Service rules to classify traffic (matching criteria like application, user, DSCP) and assign a QoS Profile (which maps to a QoS Class).
• Policy Based Forwarding (PBF): Define rules to override the standard routing table based on source/destination/application/service criteria, directing traffic to specific next hops or interfaces.
• Decryption Policies: (Pre-rules and Post-rules) Define rules for SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy, specifying traffic to decrypt or exclude.
• Authentication Policies: Define rules to trigger authentication methods (e.g., MFA, Captive Portal, Kerberos) based on traffic characteristics, often used with Explicit Proxy or for step-up authentication.
• Application Override Policies: Define rules to manually classify traffic based on port/protocol, bypassing App-ID (use with caution).
• Tunnel Inspection Policies: Define rules to inspect traffic within tunnels (e.g., Generic Route Encapsulation - GRE).
• DoS Protection Policies: Define rules to apply Denial-of-Service protection profiles based on zones and traffic criteria.

Remember the Pre/Post rule structure within each policy type allows for control over evaluation order relative to inherited rules and local firewall rules.

Objects Tab Components:

This is where you define the reusable building blocks referenced by your policy rules:

• Addresses: Define IP addresses (host, network, range) used in policy matching.
• Address Groups: Group multiple Address objects for easier policy management.
• Services: Define TCP/UDP ports or ICMP types used in policy matching.
• Service Groups: Group multiple Service objects.
• Applications: View standard App-IDs and create/manage Application Groups and Application Filters . (Custom Application *Signatures* are also defined here).
• External Dynamic Lists (EDLs): Define lists referencing external hosts for IPs, Domains, or URLs used in policies.
• Custom Objects:
  • Data Patterns
  • Spyware Signatures
  • Vulnerability Signatures
  • URL Categories
• Security Profiles: Define the inspection profiles applied by Security rules:
  • Antivirus
  • Anti-Spyware (including DNS Security settings if applicable)
  • Vulnerability Protection
  • URL Filtering
  • File Blocking
  • WildFire Analysis
  • Data Filtering
  • DoS Protection (Profiles)
  • SD-WAN (SaaS Quality, Error Correction - Profiles applied in SD-WAN Policy Rules, which are under Policies)
• Authentication Objects:
  • Authentication Profiles
  • Authentication Sequences
  • Authentication Portal Settings (though base enablement might be Device)
• Decryption Objects:
  • Decryption Profiles
  • (Certificates/Keys are managed under Device tab, but profiles referencing them are Objects)
• QoS Objects:
  • QoS Profile Objects (mapping traffic to Classes 1-8)
• Log Forwarding Profiles: Define profiles specifying where logs should be sent.
• Tags: Define Tags used for organizing objects and rules.
• GlobalProtect Objects (Some): While Portal/Gateway main config is in Templates, objects like HIP Objects/Profiles might be managed here or Shared.

What is NOT Configured in Device Groups

It's essential to remember the division of responsibilities:

• Network Settings: Interfaces, Zones, Virtual Routers, VLANs, IPSec Tunnels, GlobalProtect Portal/Gateway main setup, DHCP, DNS Proxy etc. -> Managed in Templates / Template Stacks .
• Device Settings: Management interface, Services (NTP/DNS/Syslog *servers*), HA, Logging settings, Content Update schedules, Server Profiles (Syslog, RADIUS, LDAP, etc.), Certificate Management -> Managed in Templates / Template Stacks .

Think of Device Groups for "what traffic to allow/inspect and how" (Policies & Objects) and Templates for "how the firewall connects to the network and operates" (Network & Device).

For the PCNSE exam, be able to identify:

• The primary purpose of Device Groups: Managing Policies and Objects .
• The main configuration tabs managed within Device Groups: Policies and Objects .
• Examples of specific Policy types found in Device Groups (Security, NAT, QoS, Decryption, PBF, Auth, App Override, DoS).
• Examples of specific Object types found in Device Groups (Addresses, Services, Applications/Groups/Filters, Security Profiles, Custom Objects, Log Forwarding Profiles).
• Crucially, differentiate components configured in Device Groups from those configured in Templates (Network & Device settings like interfaces, zones, virtual routers, server profiles, HA, GP Portal/Gateway setup).
• Understand that Device Groups utilize hierarchies and Pre/Post rules for policy inheritance and evaluation order.