PAN-OS: GlobalProtect Host Information Profile (HIP) & Zero Trust Access

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 .

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`.

3. Enabling HIP Collection & Usage:

   • Portal/Gateway Agent Config: HIP data collection must be explicitly enabled.
     • Go to Network > GlobalProtect > Portals > [Portal Name] > Agent > [Agent Config] > Data Collection Tab -> Check 'Enable'.
     • Go to Network > GlobalProtect > Gateways > [Gateway Name] > Agent > Data Collection Tab -> Check 'Enable'.
   • HIP Notification Messages (Optional): ( Device > Response Pages > GlobalProtect Clientless VPN or similar based on version/context) Customize messages shown to users whose devices fail HIP checks.
   • Policy Enforcement: Use the created HIP Profiles as matching criteria in:
     • Security Policy Rules: ( Policies > Security ) Add a HIP Profile in the 'User' tab.
     • Authentication Policy Rules: ( Device > Authentication Policy ) Add a HIP Profile as Match Criteria.

sequenceDiagram
    participant Client as GP Agent
    participant Portal as GP Portal
    participant Gateway as GP Gateway
    participant PolicyEngine as Firewall Policy Engine

    Client->>+Portal: 1. Connect & Authenticate
    Portal-->>Client: 2. Request HIP Report (if enabled)
    Client->>Client: 3. Collect Host Information (based on config)
    Client->>+Portal: 4. Submit HIP Report
    Portal->>Portal: 5. Evaluate Report vs HIP Profiles
    Note over Portal: HIP Profile Match/Mismatch Determined
    alt Portal Enforces HIP Check
        Portal-->>Client: 6a. Grant/Deny Config based on HIP Match
    else Portal Collects Only
         Portal-->>Client: 6b. Provide Config (incl. Gateway List)
    end
    deactivate Portal

    Client->>+Gateway: 7. Connect & Authenticate
    Gateway-->>Client: 8. Request HIP Report (if enabled)
    Client->>+Gateway: 9. Submit HIP Report
    Gateway->>+PolicyEngine: 10. Evaluate Report vs HIP Profiles
    PolicyEngine-->>Gateway: 11. HIP Profile Match/Mismatch Result
    Gateway->>+PolicyEngine: 12. Use HIP Match in Policy Evaluation
    alt Security/Auth Policy Requires HIP Match
        PolicyEngine-->>Gateway: 13a. Policy Match Success/Failure
        Gateway-->>Client: 14a. Grant/Deny Access based on Policy
    else Policy Doesn't Require HIP
        PolicyEngine-->>Gateway: 13b. Policy Match based on other criteria
        Gateway-->>Client: 14b. Grant/Deny Access based on Policy
    end
    deactivate PolicyEngine
    deactivate Gateway

    Note over Client, Gateway: Periodic HIP Re-submissions occur

    

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.
11. When user traffic arrives through the tunnel, 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, allowing for continuous posture assessment.

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:

• 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.

Caveats, Gotchas, and Considerations

• Start Simple, Iterate: Begin with basic checks (OS version, AV enabled) and gradually add more criteria as needed and validated.
• Audit First: Initially, create HIP Profiles that match desired states but use them in Security/Authentication rules set to 'Allow' or 'Alert' with logging enabled. Monitor the logs to understand the compliance landscape before enforcing blocking actions.
• Clear Naming Conventions: Use descriptive names for HIP Objects and HIP Profiles (e.g., `HIP-Object-Win10-Patched`, `HIP-Profile-Compliant-Corp`).
• Logical Grouping: Use AND/OR logic within Profiles effectively to define meaningful compliance states.
• Provide Remediation Guidance: Use HIP Notification messages to inform users *why* they failed a check and *how* to remediate (e.g., "Antivirus is disabled. Please enable it.", "OS Patch level is too low. Please run Windows Update.").
• Align with Security Policy: Ensure HIP Profiles directly support and enforce the organization's endpoint security policies.
• Regular Updates: Keep firewall content versions (AV, App-ID, etc.) up-to-date for accurate HIP checks.
• Test Thoroughly: Test HIP profiles against various compliant and non-compliant scenarios before broad deployment.
• Integrate with MFA: Use HIP in Authentication Policy to potentially trigger MFA challenges based on device posture (e.g., require MFA if device is only partially compliant).

For the PCNSE exam, related to HIP:

• Understand the purpose of HIP: Assessing endpoint security posture.
• Know the difference between HIP Objects (what to check) and HIP Profiles (the required state).
• Know where HIP Objects and Profiles are configured ( Objects > GlobalProtect ).
• Understand that HIP collection must be enabled in the Portal/Gateway agent configurations.
• Know how HIP Profiles are used as matching criteria in Security Policy and Authentication Policy rules.
• Understand the basic HIP report submission workflow (Agent -> Portal/Gateway -> Policy Engine).
• Recognize HIP as a key component for achieving Zero Trust by verifying device health alongside user identity.
• Be aware of the reliance on the GP agent and potential OS differences.
• Know the importance of content updates for accurate checks.

References

• GlobalProtect Admin Guide: About Host Information
• GlobalProtect Admin Guide: Configure Host Information
• GlobalProtect Admin Guide: Configure HIP-Based Policy Enforcement
• Palo Alto Networks: What is Zero Trust?
• Palo Alto Networks Certified Network Security Engineer (PCNSE) Exam Blueprint