Hardware reference guide

132 GlobalProtect Administrator’s Guide
About Host Information Use Host Information in Policy Enforcement
How Does the Gateway Use the Host Information to Enforce Policy?
While the agent gets the information about what information to collect from the client configuration
downloaded from the portal, you define which host attributes you are interested in monitoring and/or using for
policy enforcement by creating HIP objects and HIP profiles on the gateway(s):
 HIP Objects—Provide the matching criteria to filter out the host information you are interested in using
to enforce policy from the raw data reported by the agent. For example, while the raw host data may include
information about several antivirus packages that are installed on the client you may only be interested in
one particular application that you require within your organization. In this case, you would create a HIP
object to match the specific application you are interested in enforcing.
The best way to determine what HIP objects you need is to determine how you will use the host information
you collect to enforce policy. Keep in mind that the HIP objects themselves are merely building blocks that
allow you to create the HIP profiles that are used in your security policies. Therefore, you may want to keep
your objects simple, matching on one thing, such as the presence of a particular type of required software,
membership in a specific domain, or the presence of a specific client OS. By doing this, you will have the
flexibility to create a very granular (and very powerful) HIP-augmented policy.
 HIP Profiles—A collection of HIP objects that are to be evaluated together, either for monitoring or for
security policy enforcement. When you create your HIP profiles, you can combine the HIP objects you
previously created (as well as other HIP profiles) using Boolean logic such that when a traffic flow is
evaluated against the resulting HIP profile it will either match or not match. If there is a match, the
corresponding policy rule will be enforced; if there is not a match, the flow will be evaluated against the next
rule, as with any other policy matching criteria.
Unlike a traffic log—which only creates a log entry if there is a policy match—the HIP Match log generates an
entry whenever the raw data submitted by an agent matches a HIP object and/or a HIP profile you have defined.
This makes the HIP Match log a good resource for monitoring the state of the hosts on your network over
time—before attaching your HIP profiles to security policies—in order to help you determine exactly what
policies you believe need enforcement. See Configure HIP-Based Policy Enforcement for details on how to
create HIP objects and HIP profiles and use them as policy match criteria.
How Do Users Know if Their Systems are Compliant?
By default, end users are not given any information about policy decisions that were made as a result of
enforcement of a HIP-enabled security rule. However, you can enable this functionality by defining HIP
notification messages to display when a particular HIP profile is matched and/or not matched.
The decision as to when to display a message (that is, whether to display it when the user’s configuration matches
a HIP profile in the policy or when it doesn’t match it), depends largely on your policy and what a HIP match
(or non-match) means for the user. That is, does a match mean they are granted full access to your network
resources? Or does it mean they have limited access due to a non-compliance issue?
For example, consider the following scenarios: