Introduction to Compliance White Lists
A compliance white list, sometimes abbreviated as a white list, is a set of criteria that specifies which operating systems, applications (web and client), and protocols are allowed on hosts on your network. The system generates an event (violation) if a host is not on this list.
A compliance white list has two main components:
-
Targets are the hosts you select for compliance evaluation. You can evaluate all or some monitored hosts, constraining by subnet, VLAN, and host attribute. In a multidomain deployment, you can target domains and subnets within or across domains.
-
Host profiles specify the compliance criteria for the targets. The global host profile is operating system agnostic. You can also configure operating-system specific host profiles, either unique to one white list or shared across multiple white lists.
The Cisco Talos Intelligence Group (Talos) provides a default white list with recommended settings. You can also create custom white lists. A simple custom list might allow only hosts running a certain operating system. A more complex list might allow all operating systems, but specify which operating system a host must use to run a certain application protocol on a specific port.
Note |
The system can add hosts to the network map from exported NetFlow records, but the available information for these hosts is limited; see Differences between NetFlow and Managed Device Data. This limitation may affect the way you build compliance white lists. |
Implementing Compliance White Lists
To implement white lists, add the list to an active correlation policy. The system evaluates the targets and assigns every host a corresponding attribute:
-
Compliant — The host does not violate the list.
-
Non-Compliant — The host violates the list.
-
Not Evaluated — The host is not a target of the list, the host is currently being evaluated, or the system has insufficient information to determine whether the host is in compliance.
Note |
To delete the host attribute, delete its corresponding white list. Deactivating, deleting, or removing a white list from a correlation policy does not delete the host attribute, nor does it change the attribute’s value for each host. |
After its initial evaluation, the system generates a white list event whenever a monitored host goes out of compliance with an active white list; it also records a white list violation.
You can use workflows, dashboards, and network maps to monitor system-wide compliance activity and determine when and how an individual host violates your white lists. You can also automatically respond to such violations with remediations and alerts.
Example: Restricting HTTP to Web Servers
Your security policy states that only web servers may run HTTP. You create a white list that evaluates your entire network, excluding your web farm, to determine which hosts are running HTTP.
Using the network map and the dashboard, you can obtain an at-a-glance summary of the compliance of your network. In just a few seconds, you can determine exactly which hosts in your organization are running HTTP in violation of your policy, and take appropriate action.
Then, using the correlation feature, you can configure the system to alert you whenever a host that is not in your web farm starts running HTTP.
Compliance White List Target Networks
A target network specifies the hosts you want to evaluate for compliance. A white list can have more than one target network, and it evaluates hosts that meet the criteria of any of its targets.
Initially, you constrain a target network by IP address or range. In multidomain deployments, the initial constraints also include a domain.
The system-provided default white list targets all monitored hosts: 0.0.0.0/0 and ::/0. In a multidomain deployment, the default white list is constrained to (and only available in) the Global domain.
If you modify a target network or a host so that the host is no longer a valid target for the white list, the host is no longer evaluated by the list and is considered neither compliant nor non-compliant.
Surveying and Refining Target Networks
When you add a target network to a white list, the system prompts you to survey the network map to help you characterize compliant hosts. The survey adds a target to the white list that represents the hosts you surveyed.
You can survey a subnet or individual host. In a multidomain deployment, you can survey an entire domain, or you can survey across domains. Surveying an ancestor domain causes the system to survey that domain's descendants.
In addition to the added target, the survey also populates the white list with one host profile for each operating system detected in the survey. These host profiles allow all the clients, application protocols, web applications, and protocols that the system has detected on the applicable operating systems.
After you survey a target network (or skip the survey), refine the target. You can exclude hosts by IP address, or constrain target networks by host attribute or VLAN.
Targeting Domains with Compliance White Lists
In a multidomain deployment, domains and target networks are closely linked.
-
Leaf-domain administrators can create white lists that evaluate hosts within their leaf domains.
-
Higher-level domain administrators can create white lists that evaluate hosts across domains. You can target different subnets in different domains in the same white list.
Consider a scenario where you are a Global domain administrator, and you want to apply the same compliance criteria to web servers across the entire deployment. You can create one white list in the Global domain that defines the compliance criteria. Then, constrain the white list with target networks that specify the IP space (or individual IP addresses) of the web servers in each leaf domain.
Note |
In addition to targeting IP addresses and ranges in leaf domains, you can also constrain a target network using a higher-level domain. Targeting a subnet in a higher-level domain targets the same subnet in each of the descendant leaf domains. The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal IP addresses to constrain this configuration can have unexpected results. |
Compliance White List Host Profiles
In a compliance white list, host profiles specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts. There are three types of host profile you can use in a compliance white list; each type appears differently in the compliance list editor.
Host Profile Type |
Appearance |
Description |
---|---|---|
global |
Any Operating System |
specifies what is allowed to run on target hosts, regardless of operating system |
operating-system specific |
is listed in plain text |
specifies what is allowed to run on target hosts of a particular operating system |
shared |
is listed in italics |
specifies operating-system criteria that can be used in multiple white lists |
Operating System-Specific Host Profiles
In a compliance white list, operating-system specific host profiles indicate not only which operating systems are allowed to run on your network, but also the application protocols, clients, web applications, and protocols that are allowed to run on those operating systems.
For example, you could require that compliant hosts run a particular version of Microsoft Windows. As another example, you could allow SSH to run on Linux hosts on port 22, and further restrict the vendor and version of the SSH client.
Create one host profile for each operating system you want to allow on your network. To disallow an operating system on your network, do not create a host profile for that operating system. For example, to make sure that all the hosts on your network are running Windows, configure the white list to only contain host profiles for that operating system.
Note |
Unidentified hosts remain in compliance with all white lists until they are identified. You can, however, create a white list host profile for unknown hosts. Unidentified hosts are hosts about which the system has not yet gathered enough information to identify their operating systems. Unknown hosts are hosts whose operating systems do not match known fingerprints. |
Shared Host Profiles
In a compliance white list, shared host profiles are tied to specific operating systems, but you can use each shared host profile in more than one white list.
For example, you might have offices worldwide with a separate white list for each location, but you want to use the same profile for all hosts running Apple Mac OS X. You can create a shared profile for that operating system and use it in all your white lists.
The default white list uses a special category of shared host profiles, called built-in host profiles. These profiles use built-in application protocols, web applications, protocols, and clients. In the compliance white list editor, the system marks these profiles with the Built-In Host Profile icon.
In a multidomain deployment, the system displays shared host profiles created in the current domain, which you can edit. It also displays shared host profiles from ancestor domains, which you cannot edit. To view and edit shared host profiles created in a lower domain, switch to that domain.
Note |
If you modify a shared host profile (including built-ins), or modify a built-in application protocol, protocol, or client, your change affects every white list that uses it. If you make unintended changes to or delete these built-in elements, you can reset to factory defaults. |
White Violation Triggers
The white list compliance of a host can change when the system:
-
detects a change in a host’s operating system
-
detects an identity conflict for a host’s operating system or an application protocol on the host
-
detects a new TCP server port (for example, a port used by SMTP or web servers) active on a host, or a new UDP server running on a host
-
detects a change in a discovered TCP or UDP server running on a host, for example, a version change due to an upgrade
-
detects a new client or web application running on a host
-
drops a client or web application from its database due to inactivity
-
detects that a host is communicating with a new network or transport protocol
-
detects a new jailbroken mobile device
-
detects that a TCP or UDP port has closed or timed out on a host
In addition, you can trigger a compliance change for a host by using the host input feature or the host profile to:
-
add a client, protocol, or server to a host
-
delete a client, protocol, or server from a host
-
set the operating system definition for a host
-
change a host attribute for a host so that the host is no longer a valid target
Note |
To avoid overwhelming you with events, the system does not generate white list events for non-compliant hosts on its initial evaluation, nor hosts made non-compliant as a result of you modifying an active white list or shared host profile. The violations, however, are still recorded. If you want to generate white list events for all non-compliant targets, purge discovery data. Rediscovering network assets may trigger white list events. |
Operating System Compliance
If your white list specifies that only Microsoft Windows hosts are allowed on your network, and the system detects a host running Mac OS X, the system generates a white list event. In addition, the host attribute associated with the white list changes from Compliant to Non-Compliant for that host.
For the host in this example to come back into compliance, one of the following must occur:
-
you edit the white list so that the Mac OS X operating system is allowed
-
you manually change the operating system definition of the host to Microsoft Windows
-
the system detects that the operating system has changed back to Microsoft Windows
Deleting a Non-Compliant Asset from the Network Map
If your white list disallows the use of FTP, and you then delete FTP from the application protocols network map or from an event view, hosts running FTP become compliant. However, if the system detects the application protocol again, the system generates a white list event and the hosts become non-compliant.
Triggering on Complete Information Only
If your white list allows only TCP FTP traffic on port 21, and the system detects indeterminate activity on port 21/TCP, the white list does not trigger. The white list triggers only when the system identifies the traffic as something other than FTP, or you use the host input feature to designate the traffic as non-FTP traffic. The system does not record a violation with only partial information.