Cisco Cisco Firepower Management Center 4000

the system detects a new mobile device that is jailbroken

the system 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

For example, if your white list specifies that only Microsoft Windows hosts are allowed on your network, 
and the system detects that the host is now running Mac OS X, the system generates a white list event. 
In addition, the host attribute associated with the white list changes its value 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

In any case, the host attribute associated with the white list changes its value from N

on-Compliant

 to 

Compliant

 for that host.

As another example, if your compliance 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.

Note that if the system generates an event that contains insufficient information for the white list, the 
white list does not trigger. For example, consider a scenario where your white list specifies that you 
allow only TCP FTP traffic on port 21. Then, the system detects that port 21, using the TCP protocol, 
has become active on one of the white list targets, but the system is unable to determine whether the 
traffic is FTP. In this scenario, the white list does not trigger until either the system identifies the traffic 
as something other than FTP traffic or you use the host input feature to designate the traffic as non-FTP 
traffic.

During the initial evaluation of a white list, the system does not generate white list events for 
non-compliant hosts. If you want to generate white list events for all non-compliant targets, you must 
purge the Defense Center database. This causes the hosts on your network and their associated clients, 
application protocols, web applications, and protocols to be rediscovered, which may trigger white list 
events. For more information, see 

.

Finally, you can configure the system to trigger responses automatically when it detects a white list 
violation. Responses include remediations (such as running an Nmap scan), alerts (email, SNMP, and 
syslog alerts), or combination of alerts and remediations. For more information, see 

.

FireSIGHT