GlobalProtect Host Information Profile (HIP)

What is a Host Information Profile (HIP)?

A Host Information Profile (HIP), often referred to simply as "HIP Check", is a dynamic security posture assessment feature within Palo Alto Networks GlobalProtect. The GlobalProtect agent running on an endpoint (laptop, mobile device) collects information about the host's state – such as operating system version, patch level, antivirus status, disk encryption, running processes, registry keys, etc.

This collected information forms a HIP report, which is sent to the GlobalProtect Portal and/or Gateway. The firewall then compares this report against predefined HIP Profiles to determine if the endpoint meets the organization's security requirements.

The result of this comparison (HIP match or HIP mismatch) can then be used as a matching criterion in Security and Authentication policies to enforce granular access control based not just on user identity, but also on the security posture and compliance of the connecting device.

Basic concept of HIP: From collection to enforcement.

Core Components of HIP Configuration

Several key components work together to enable HIP functionality:

1. HIP Objects: Defining What to Collect

Purpose: Define the specific attributes or conditions the GlobalProtect agent should check for on the endpoint.

Location: Objects > GlobalProtect > HIP Objects

Examples of Attributes:

• General: Operating System (e.g., Windows 10 build 22H2, macOS Ventura), Hostname, Domain.
• Anti-Malware: Specific vendor (e.g., CrowdStrike, Defender), Real-time protection enabled, Signature version within X days.
• Disk Encryption: Specific vendor (e.g., BitLocker, FileVault), Encryption state (Full Volume Encrypted).
• Patch Management: Specific vendor (e.g., Microsoft SCCM, JAMF), Agent installed, Last check-in time.
• Firewall: Specific vendor (e.g., Windows Firewall, macOS Firewall), Enabled state.
• Data Loss Prevention (DLP): Agent installed/running.
• Disk Backup: Agent installed/running, Last backup status.
• Custom Checks: Check for specific files, registry keys (Windows), Plist files (macOS), running processes. Use with caution due to potential performance/privacy implications.

Multiple conditions can be combined within a single HIP Object using AND/OR logic.

2. HIP Profiles: Defining the Required State

Purpose: Define the required security posture by referencing one or more HIP Objects. It determines if a device is considered "compliant", "non-compliant", or matches some other defined state.

Location: Objects > GlobalProtect > HIP Profiles

Configuration:

• Select HIP Objects created in the previous step.
• Use Match/Exclude logic (e.g., "Match if OS is Windows 10 AND Anti-Malware state is Enabled", "Exclude if Disk Encryption state is Not Encrypted").
• Combine multiple criteria using AND/OR logic.
• Common Profiles: Compliant-Device , Non-Compliant-Device , Corporate-Managed , BYOD-Basic-Checks .

Example of HIP Objects combined in a HIP Profile.

Enabling HIP Collection & Usage

For HIP to function, data collection must be explicitly enabled on the GlobalProtect Portal and/or Gateways.

Portal/Gateway Agent Configuration:

HIP data collection is specified in the agent configuration associated with the Portal and Gateways.

1. For Portal:
   • Navigate to Network > GlobalProtect > Portals > [Your Portal Name] > Agent > [Your Agent Config] > Data Collection Tab .
   • Check the box for 'Enable' under Host Information Profile (HIP) Data Collection.
   • Optionally, configure HIP report submission intervals.
2. For Gateway(s):
   • Navigate to Network > GlobalProtect > Gateways > [Your Gateway Name] > Agent > Data Collection Tab .
   • Check the box for 'Enable' under Host Information Profile (HIP) Data Collection.
   • The Gateway typically uses the HIP data for continuous monitoring and policy enforcement.

HIP Notification Messages & Policy Enforcement

HIP Notification Messages (Optional but Recommended)

Purpose: To inform users why their access might be restricted due to a failed HIP check and guide them towards remediation.

Location: Device > Response Pages (The exact path might vary slightly based on PAN-OS version, look for GlobalProtect related response pages or HIP notifications).

• You can create custom messages for different HIP Profiles (e.g., a message for "Antivirus Outdated" and another for "OS Not Patched").
• These messages are displayed to the user via the GlobalProtect agent or a captive portal page, depending on the configuration.

Policy Enforcement: Using HIP Profiles

Once HIP Objects and Profiles are defined, and HIP collection is enabled, you use the HIP Profiles as matching criteria in:

1. Security Policy Rules:
   • Navigate to Policies > Security .
   • When creating or editing a rule, go to the 'User' tab.
   • In the 'HIP Profiles' section, add the desired HIP Profile(s).
   • Traffic will only match this rule if, in addition to other criteria (User-ID, Zone, App-ID etc.), the connecting device's HIP report matches the specified HIP Profile.
2. Authentication Policy Rules:
   • Navigate to Device > Authentication Policy .
   • When creating or editing a rule, add HIP Profile(s) as Match Criteria.
   • This allows you to enforce different authentication requirements (e.g., require MFA only for devices that are partially compliant or not company-managed) based on device posture.

How HIP Works: The Workflow

The HIP process involves several steps, from agent connection to policy enforcement:

GlobalProtect HIP Workflow from Agent to Policy Enforcement.

1. The GlobalProtect agent connects to the Portal and authenticates the user.
2. If HIP data collection is enabled in the Portal's agent configuration, the Portal requests a HIP report.
3. The agent scans the endpoint based on the HIP Objects defined in the configuration received from the Portal.
4. The agent sends the HIP report (a summary of its findings) back to the Portal.
5. The Portal evaluates the report against its configured HIP Profiles. (Optional) The Portal can be configured to deny configuration delivery if the device doesn't meet certain HIP criteria at this stage.
6. The agent receives its configuration, including the list of Gateways.
7. The agent connects to the selected Gateway and authenticates (potentially using cookies or re-authenticating).
8. If HIP data collection is enabled on the Gateway, it requests a HIP report from the agent.
9. The agent sends the current HIP report to the Gateway.
10. The Gateway evaluates the report against its configured HIP Profiles. The result (match/mismatch for various profiles) is associated with the user/device session.
11. When user traffic arrives through the tunnel (or from an internal user whose HIP info is known), the firewall's Policy Engine uses the HIP Profile match status (along with User-ID, App-ID, Zones, Addresses, etc.) as criteria in Security and Authentication Policy rules.
12. Access is granted or denied based on the policy match, which now includes the device's security posture via the HIP Profile.
13. The agent periodically re-submits HIP reports to the Gateway (and sometimes Portal), allowing for continuous posture assessment and dynamic policy adjustments if the device's compliance state changes.

How HIP Enables Zero Trust Access (ZTA)

Zero Trust is a security model based on the principle of "never trust, always verify." It assumes that threats can exist both outside and inside the traditional network perimeter. Access decisions should be granular and enforced based on verified identity and context, not just network location. GlobalProtect HIP is a cornerstone technology for implementing ZTA for remote and internal access:

HIP's role in contributing to Zero Trust principles.

1. Verifying Device Trust ("Always Verify"):
   • ZTA requires verifying not just the user but also the device attempting access.
   • HIP provides the mechanism to continuously assess the security posture and health of the endpoint.
   • Access is granted only if both the user authenticates successfully AND the device meets the minimum security requirements defined in the HIP Profile.
2. Enforcing Least Privilege Access:
   • Different HIP Profiles can represent varying levels of device compliance (e.g., Fully-Compliant, Partially-Compliant-Needs-Patching, Non-Compliant).
   • Security Policies can use these HIP Profiles to grant granular access:
     • Fully compliant devices get access to sensitive applications.
     • Partially compliant devices might get access only to less sensitive resources or a remediation portal.
     • Non-compliant devices might be denied access entirely or only allowed to access helpdesk resources.
   • This ensures users only get the access appropriate for their current device posture, minimizing the potential impact of a compromised or vulnerable endpoint.
3. Dynamic and Context-Aware Access Control:
   • HIP reports are submitted periodically (configurable).
   • If a device's posture changes (e.g., antivirus becomes disabled, a critical patch is missed), the next HIP report will reflect this.
   • The firewall re-evaluates the HIP profile match, and Security Policies can dynamically adjust or revoke access in near real-time based on the updated posture.
   • This moves away from static, location-based trust towards continuous, context-aware verification.
4. Reducing the Attack Surface:
   • By preventing non-compliant or potentially compromised devices from accessing sensitive resources, HIP significantly reduces the pathways available for malware propagation or data breaches originating from unhealthy endpoints.

In a Zero Trust architecture, HIP complements strong user authentication (like MFA via SAML integration) and granular App-ID based policies to create a robust access control model based on verified user identity, verified device health, and allowed application usage.

HIP with External Gateways

External Gateways are the typical deployment model for providing secure remote access to users outside the corporate network (e.g., home users, traveling users).

Role in Enforcing Restrictions:

• Full Posture Check: When a user connects to an External Gateway, the GlobalProtect agent submits a HIP report. The gateway evaluates this report against configured HIP Profiles.
• Conditional Access: Based on the HIP match/mismatch:
  • Compliant Devices: Can be granted full access to internal resources and/or the internet as defined by security policies.
  • Non-Compliant Devices:
    • Can be denied access completely.
    • Can be granted limited access (e.g., only to a remediation portal or helpdesk resources).
    • Can be placed in a "quarantine" group with highly restricted access.
• Traffic Tunneling: Typically, External Gateways are configured for full tunnel (all traffic from the endpoint goes through the gateway) or split tunnel (only specific traffic goes through the gateway).
  • In a full tunnel scenario, all user traffic is inspected by the firewall, and HIP-based policies can be applied comprehensively.
  • In a split tunnel scenario, HIP-based policies are applied to the traffic that *is* tunneled through the gateway. Traffic that bypasses the tunnel is not subject to the gateway's HIP enforcement.
• Continuous Monitoring: HIP reports are re-submitted periodically. If a device's posture changes (e.g., AV disabled mid-session), the gateway can dynamically update access based on the new HIP status and matching security policies.

HIP with Internal Gateways

Internal Gateways are used to provide secure access and posture validation for users within the corporate network. Their role and how HIP is leveraged can be more nuanced compared to External Gateways.

Purpose of Internal Gateways:

• User Authentication & Identification: Authenticate users on the internal network and provide User-ID information to the firewall.
• HIP Collection for On-Premise Users: Collect HIP reports from internal endpoints to assess their compliance.
• Secure Access to Specific Internal Resources: Can be used to create secure tunnels to sensitive internal applications, even for users already on the network, applying HIP checks for that specific access.
• Enforce "Internal Segmentation Zero Trust": Ensure that even internal users accessing internal resources meet device compliance standards.

How Internal Gateways Use HIP:

An Internal Gateway's primary function related to HIP is to collect the HIP report and associate it with the User-ID information for users on the internal network. This information is then used by the firewall's policy engine when that user's traffic traverses the firewall to access other network segments.

Does Internal Gateway get used to extract HIP which in turn would allow the firewall to enforce access even if the user is not in a full tunnel?

Yes, absolutely. This is a primary use case for Internal Gateways.

• When a GlobalProtect agent on an internal endpoint connects to an Internal Gateway (even without establishing a full tunnel, e.g., in "User-ID agent mode" or for "internal host detection"), it submits a HIP report.
• The Internal Gateway (or the Portal, if configured for internal connections) processes this report.
• The resulting HIP match/mismatch information is associated with the user's IP address and User-ID on the firewall.
• Subsequently, when this user attempts to access resources in different internal zones (e.g., from the user VLAN to a server VLAN), and that traffic passes through the Palo Alto Networks firewall, the security policies governing that traffic can use the cached/associated HIP profile match status as a criterion.

Internal Gateway HIP collection for non-tunneled traffic enforcement.

Enforcing Restrictions on Internal Resources via Internal Gateways

While an External Gateway typically creates a tunnel through which all (or selected) remote user traffic flows, an Internal Gateway's role in "forcing" traffic for inspection is different.

Can an Internal Gateway be used to force traffic through the firewall like an External Gateway, to enforce restrictions on non-compliant devices accessing resources on the internal network?

Not directly in the same way. An Internal Gateway itself doesn't typically act as a transparent inline device that all internal user traffic must pass through by default. Instead, enforcement on internal resources relies on a combination of factors:

1. HIP Collection: The user's endpoint (with GlobalProtect agent) connects to the Internal Gateway (or Portal configured for internal use) and submits a HIP report. This establishes the device's compliance status associated with the User-ID.
2. Network Segmentation & Firewall Policy:
   • The internal network must be segmented into different zones (e.g., User Zone, Server Zone, DMZ).
   • The Palo Alto Networks firewall must be positioned to inspect traffic flowing *between* these internal zones.
   • Security policies are configured on the firewall to control this inter-zone traffic. These policies will use:
     • Source/Destination Zones
     • Source User (via User-ID, which the Internal Gateway helps populate)
     • HIP Profile Match (obtained via the Internal Gateway connection)
     • Application (App-ID)
     • Services, etc.
3. Traffic Path: For restrictions to be enforced on a non-compliant device accessing an internal resource, the traffic from that device to the resource must traverse the firewall where the HIP-aware security policy is applied.

Advanced Use Cases for GlobalProtect HIP

Beyond basic compliant/non-compliant access, HIP can be leveraged for more sophisticated security controls:

• Dynamic User-to-Group Mapping:

  While not directly mapping users to groups via HIP in User-ID, HIP results can be used in policies that effectively segment users. More advanced integrations or scripting might use HIP data to influence group memberships in external systems (e.g., Active Directory), which User-ID then consumes. However, the primary PAN-OS method is using HIP Profiles directly in policies.

• Integration with MDM/UEM Solutions (Indirectly):

  While GlobalProtect HIP itself checks attributes, MDM/UEM solutions manage device compliance. You can configure HIP to check for the presence and status of an MDM agent or specific compliance markers set by the MDM (e.g., a registry key or file indicating MDM compliance). This allows HIP to leverage the detailed compliance state determined by the MDM.

  Look for: HIP checks for MDM agent process, specific files/registry keys written by MDM upon compliance.

• Automated Remediation Workflows:

  When a device is non-compliant, HIP can be used in policies to redirect the user to a remediation portal. This portal can provide self-service tools, links to download patches, or instructions to fix the compliance issue. More advanced setups might use API integration (e.g., via Cortex XSOAR) to trigger automated actions like notifying IT, creating a helpdesk ticket, or even initiating a scan by an EDR tool.

• Granular Access Based on Multiple Compliance Tiers:

  Create several HIP Profiles representing different levels of trust or compliance (e.g., "Fully Compliant Corporate", "Partially Compliant BYOD", "Guest-Level Checks", "High-Risk Device"). Then, assign varying access privileges in security policies based on these tiers. For example, a "High-Risk Device" might only get internet access through a very restrictive profile with extensive threat prevention.

• HIP for Server Posture (Limited):

  If servers have the GlobalProtect agent installed (less common but possible for specific use cases), HIP can be used to check their posture before allowing them to communicate with certain network segments or other servers. This is more niche, as server security is often managed by other tools.

• Conditional MFA Prompts:

  Use HIP Profiles in Authentication Policies. For example, a device that is "Compliant-Corporate" might bypass MFA for certain apps, while a "BYOD-Compliant" device is always prompted for MFA, and a "Non-Compliant" device is denied access outright or forced into MFA for even basic access.

  Authentication Policy integration with HIP is a common advanced use case and exam topic.
• Using Custom Attributes for Very Specific Checks:

  Leverage custom checks (registry, file, plist, process) to verify the presence of very specific corporate software, configurations, or even indicators of compromise (though dedicated EDR is better for IoCs). This requires careful planning due to performance and maintenance overhead.

• Geo-Location Based HIP (Indirect):

  While HIP itself doesn't directly check physical location, you can combine region-based User-ID information or source IP geo-location in security policies along with HIP profiles to create location-aware posture-based access rules. For example, a device connecting from an unexpected country might need to meet stricter HIP criteria.

Caveats, Gotchas, and Considerations

Implementing GlobalProtect HIP effectively requires awareness of its limitations and potential pitfalls:

• Agent Requirement: HIP relies entirely on the GlobalProtect agent being installed, running correctly, and not tampered with. It cannot assess devices without the agent.
• OS Support & Feature Parity: The specific attributes that can be checked, and the depth of these checks, may vary between operating systems (Windows, macOS, Linux, iOS, Android). Always check the PAN-OS documentation for the latest supported features per OS.
• Definition Updates & Content Versions:
  • The firewall needs up-to-date definition files (content updates from Palo Alto Networks) for antivirus, anti-spyware, disk encryption products, patch management systems, etc., to accurately match the data reported by the agent.
  • If the firewall's list of known AV products/versions is outdated, it might incorrectly flag a compliant AV as unknown or non-compliant. Ensure regular content updates are scheduled and successful.
• Custom Checks Complexity & Performance:
  • Custom checks (registry, file, process, plist) are powerful but can be complex to define and maintain.
  • Poorly configured custom checks can cause significant performance overhead on the client endpoint during HIP scans or lead to false positives/negatives. Test thoroughly.
  • They might also raise privacy concerns depending on what is being checked.
• User Experience & Remediation:
  • Abruptly blocking users due to failed HIP checks without clear notification or straightforward remediation steps can lead to user frustration and a surge in helpdesk calls.
  • Implement comprehensive HIP Notification messages and consider a phased rollout.
• Initial Rollout & Baseline:
  • Implementing strict HIP policies from day one can be disruptive. Start with "audit mode" profiles (allow and log) to understand the current compliance landscape of your endpoints.
  • Gradually introduce enforcement policies after addressing common non-compliance issues.
• Time Lags & Reporting Intervals:
  • There's an inherent delay between when a state changes on an endpoint (e.g., AV disabled) and when the next HIP report is submitted, processed by the gateway, and policies are re-evaluated. While near real-time, it's not instantaneous.
  • Configuring very frequent HIP report submissions can increase load on endpoints and the firewall. Balance currency of data with performance.
• BYOD Challenges:
  • Enforcing strict HIP checks on personally owned devices (BYOD) can be difficult due to privacy concerns, lack of administrative control over the device, and user resistance.
  • HIP policies for BYOD often need to be less stringent or focus on different attributes (e.g., presence of basic AV, OS version) compared to corporate-managed devices.
• Agent Health & Tampering: If the GlobalProtect agent itself is compromised or disabled by a malicious actor or even a savvy user, HIP collection will fail or report inaccurate data. Endpoint security hardening is complementary.
• Matching Logic Precision: Be precise with HIP object matching logic (e.g., "is," "is not," "contains," "greater than"). A vague "contains" for a process name might match legitimate and unwanted processes.
• Vendor Name Consistency: For checks like Anti-Malware or Patch Management, ensure the vendor names configured in HIP Objects exactly match what the agent reports. Discrepancies (e.g., "Microsoft Defender" vs. "Windows Defender") can lead to mismatches. Check HIP logs on the firewall for reported values.
• PAN-OS and Agent Version Compatibility: New HIP features or attribute checks might require specific PAN-OS versions and GlobalProtect agent versions. Ensure compatibility across your deployment.
• Split Tunneling and HIP: If split tunneling is used on an External Gateway, remember that HIP enforcement only applies to traffic directed through the GlobalProtect tunnel. Traffic bypassing the tunnel is not subject to HIP checks by that gateway.

Best Practices for HIP Implementation

Following best practices can help ensure a smooth and effective HIP deployment:

• Start Simple, Iterate: Begin with basic, broadly applicable checks (e.g., OS version, AV enabled and up-to-date). Gradually add more granular criteria as your understanding of your environment's compliance posture grows and as you validate the checks.
• Audit First, Enforce Later:
  • Initially, create HIP Profiles that match your desired compliant states.
  • Use these profiles in Security/Authentication rules set to 'Allow' and enable logging (especially HIP match logging).
  • Monitor the logs (System logs for HIP, Traffic logs for policy hits) to understand the current compliance landscape, identify common issues, and see what data the agent is actually reporting. This helps fine-tune HIP Objects before enforcing blocking actions.
• Clear Naming Conventions: Use descriptive and consistent names for HIP Objects and HIP Profiles (e.g., HIP-Obj-Win-AV-Defender-Enabled , HIP-Prof-Corporate-Compliant-Win ). This greatly helps in troubleshooting and policy management.
• Logical Grouping & Boolean Logic: Use AND/OR logic within HIP Objects and HIP Profiles effectively to define meaningful and accurate compliance states. Avoid overly complex logic that becomes hard to manage or debug.
• Provide Actionable Remediation Guidance:
  • Utilize HIP Notification messages to clearly inform users why they failed a check and provide specific, easy-to-follow instructions on how to remediate the issue (e.g., "Your Antivirus is disabled. Please open [AV Program Name] and enable Real-Time Protection.", "Your Windows OS is missing critical patches. Please run Windows Update and reboot if necessary.").
  • Consider linking to internal knowledge base articles or helpdesk resources.
• Align with Security Policy: Ensure HIP Profiles directly support and enforce your organization's documented endpoint security policies. HIP is a tool to enforce policy, not define it in isolation.
• Regular Content Updates: Keep firewall content versions (Antivirus, Applications and Threats, GlobalProtect Data Files) up-to-date. This is crucial for accurate matching of AV products, patch management systems, etc.
• Test Thoroughly in a Pilot Group: Before broad deployment, test HIP profiles and associated policies against a pilot group of users with various device types and compliance states. Test both compliant and non-compliant scenarios.
• Integrate with MFA Strategically: Use HIP in Authentication Policy to intelligently trigger MFA. For example, compliant corporate devices might have a smoother login, while less trusted or BYOD devices always get MFA.
• Phased Rollout: Roll out HIP enforcement gradually, perhaps department by department, or starting with less critical applications, to manage user impact and helpdesk workload.
• Document Your HIP Configuration: Keep documentation on your HIP Objects, Profiles, the logic they implement, and the policies that use them.
• Monitor HIP Match Logs: Regularly review HIP match logs ( Monitor > Logs > HIP Match ) to identify trends, problematic checks, or widespread non-compliance issues. This helps in proactive management.
• User Communication & Training: Communicate upcoming HIP policy changes to users, explain the rationale (security), and provide training on how to check their device compliance and remediate common issues.

PCNSE Exam Focus for GlobalProtect HIP

Based on general PCNSE exam objectives and community feedback, here are areas related to GlobalProtect HIP that are commonly emphasized:

• Core Concepts:
  • Understanding what HIP is, its purpose (device posture assessment), and how it contributes to security.
  • The difference between HIP Objects and HIP Profiles and their roles.
• Configuration Steps:
  • Where to configure HIP Objects and HIP Profiles in PAN-OS ( Objects > GlobalProtect ).
  • How to enable HIP data collection in the Agent Configuration for Portals and Gateways ( Network > GlobalProtect > Portals/Gateways > Agent > Data Collection ).
  • Knowing what attributes can be checked (OS, AV, Patch Management, Disk Encryption, Custom Checks, etc.).
  • Understanding the AND/OR logic and Match/Exclude options within HIP Objects/Profiles.
• Workflow and Process:
  • The sequence of events: Agent connection, HIP report submission, Portal/Gateway evaluation.
  • The role of the Portal vs. the Gateway in HIP processing (Portal often for initial check/config, Gateway for ongoing enforcement).
  • Periodic HIP re-submission and its importance for dynamic policy.
• Policy Enforcement:
  • How HIP Profiles are used as matching criteria in Security Policies (User tab).
  • How HIP Profiles are used as matching criteria in Authentication Policies (for conditional MFA, etc.).
• Zero Trust Context:
  • How HIP aligns with Zero Trust principles (verifying device, least privilege, dynamic access).
• Troubleshooting:
  • Knowing where to look for HIP-related logs ( Monitor > Logs > HIP Match , System logs for GP agent connections).
  • Common reasons for HIP mismatches (e.g., outdated content definitions on the firewall, incorrect vendor names in HIP Objects, agent issues).
  • Understanding the impact of missing content updates for AV/patch management definitions.
• Internal vs. External Gateway Usage:
  • How HIP is applied for remote users (External Gateway).
  • How HIP information is collected and used for internal users (Internal Gateway associating HIP with User-ID for inter-zone policy enforcement).
• Notifications:
  • The purpose and configuration of HIP notification messages.
• Caveats:
  • Dependency on the GlobalProtect agent.
  • Potential performance impact of custom checks.
  • Challenges with BYOD.

Questions might present a scenario and ask you to identify the correct HIP configuration, troubleshooting step, or policy application to achieve a desired security outcome.

GlobalProtect HIP - Interactive Quiz

Test your knowledge on GlobalProtect Host Information Profile (HIP).