FireSIGHT System User Guide Version 5.4.1

---

Understanding White List Targets

License: FireSIGHT

When you create a white list, you first specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual hosts. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a valid target (or target ). A valid target:

• must be in one of the IP address blocks you specify. You can also exclude blocks of IP addresses.
• must have at least one of the host attributes you specify.

For example, you could configure a white list to evaluate only hosts that have a high host criticality. For information on host attributes, including host criticality, see Working with User-Defined Host Attributes and Working with the Predefined Host Attributes.

• must belong to one of the VLANs you specify.

If a host does not meet all of these criteria, it is not evaluated against the white list, regardless of whether its host profile is in violation of the white list.

If your white list contains more than one target, a host must meet the criteria specified in only one of them to be considered valid. For example, if you create a target that includes the 10.10.x.x network and one that excludes the 10.10.x.x network, a host in that network is considered a valid target. Note that if your white list does not contain any targets, none of the hosts on your network will be evaluated against the white list.

The target networks for your white list are listed on the left of the Create White List page. Note that the default white list uses targets of 0.0.0.0/0 and ::/0, which represent the entire monitored network. If you choose to use this white list, you can leave the target network as-is or modify it to reflect your network environment.

For information on creating white list targets, see Configuring Compliance White List Targets.

Understanding White List Host Profiles

License: FireSIGHT

After you specify which targets the white list evaluates, the next step is to configure host profiles . Host profiles in a white list specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts.

There are three kinds of host profiles you can configure in a white list: global host profiles, host profiles for specific operating systems, and shared host profiles. Each type of host profile appears differently when you are creating a white list.

The following table explains how to identify and access the different kinds of host profiles.

Understanding the Global Host Profile

License: FireSIGHT

Every white list contains a global host profile, which specifies the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system.

For example, instead of editing multiple Microsoft Windows and Linux host profiles to allow Internet Explorer, you can configure the global host profile to allow it regardless of the operating system on which it was detected. Note that the ARP, IP, TCP, and UDP protocols are always allowed to run on every host; you cannot disallow them. For more information, see Configuring the Global Host Profile.

Understanding Host Profiles for Specific Operating Systems

License: FireSIGHT

You must 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 Microsoft Windows, configure the white list to only contain host profiles for that operating system.

When you create a host profile for an operating system, you can also require that it have a particular version. For example, you could require that compliant hosts run Windows 7 or Server 2008 R2.

After you create a host profile for a particular operating system, you can specify the application protocols, clients, web applications, and protocols that are allowed to run on target hosts running that operating system. For example, you could allow SSH to run on Linux hosts on port 22. You could also restrict the particular vendor and version to OpenSSH 4.2.

Note that 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.

---

Note Unidentified hosts are not the same as 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 traffic has been analyzed by the system, but whose operating systems do not match any of the known fingerprints.

For more information, see Creating Host Profiles for Specific Operating Systems.

Understanding Shared Host Profiles

License: FireSIGHT

Shared host profiles are tied to specific operating systems, but you can use each shared host profile in more than one white list. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

For example, if you have offices worldwide and you want to create a separate white list for each location, but always 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 represents recommended “best practices” settings for allowed operating systems, clients, application protocols, web applications, and protocols. This white list uses a special category of shared host profiles, called built-in host profiles . Note that built-in host profiles are marked with the built-in host profile icon ( ).

Built-in host profiles use built-in application protocols, protocols, and clients. You can use these elements as-is in both the default white list and in any custom white list that you create or you can modify them to suit your needs. They are displayed in italics within the built-in host profile and in any other host profile that uses them.

Keep in mind that like all shared host profiles, if you modify a built-in host profile, it affects every white list that uses it. Likewise, if you modify a built-in application protocol, protocol, or client, it affects every white list that uses it.

For more information on shared host profiles, Working with Shared Host Profiles.

Understanding White List Evaluations

License: FireSIGHT

After you create white list host profiles and save the white list, you can add the white list to a correlation policy, just as you would a correlation rule. For more information, see Configuring Correlation Policies and Rules.

After you activate the correlation policy, the system evaluates the targets of the white list against the white list criteria.You can then use the host attributes network map to gain an overall view of the white list compliance of the hosts on your network.

Every host on the network is assigned a host attribute that has the same name as the white list. This host attribute has one of the following values:

• Compliant , for valid targets that are compliant with the white list
• Non-Compliant , for valid targets that violate the white list
• Not Evaluated , for invalid targets and hosts that have not yet been evaluated for any reason

Note that if your network is large and the system is in the process of evaluating all the valid targets in the network map against the white list, targets that have not yet been evaluated are marked as Not Evaluated . As the system completes its processing, more hosts move from Not Evaluated to either Compliant or Non-Compliant . The system can evaluate approximately 100 hosts per second.

Additionally, a host may be marked as Not Evaluated if the system has insufficient information to determine whether the host is in compliance. For example, this may occur if the system has detected a new host but has not yet gathered relevant information on the operating system, clients, application protocols, web applications, or protocols running on the host.

---

Note If you change or delete a host attribute from a host and that change or deletion means that the host is no longer a valid target, the host changes from either Compliant or Non-Compliant to Not Evaluated.

For more information on host attributes, see Working with the Host Attributes Network Map.

Understanding White List Violations

License: FireSIGHT

After the initial white list evaluation, the system generates a white list event when it detects that a valid target is violating the white list. White list events are a special kind of correlation event, and are logged to the Defense Center correlation event database. You can view white list events in a workflow, or search for specific white list events. For more information, see Working with White List Events.

White list violations occur when the system generates an event that indicates that a host is out of compliance. Similarly, discovery events may indicate that a previously non-compliant host is now compliant, although the system does not generate a white list event when this occurs.

The following events can change the compliance of a host:

• the system detects a change in a host’s operating system
• the system detects an identity conflict for a host’s operating system or an application protocol on the host
• the system 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
• the system detects a change in a discovered TCP or UDP server running on a host, for example, a version change due to an upgrade
• the system detects a new client running on a host
• the system drops a client from its database due to inactivity
• the system detects a new web application running on a host
• the system drops a web application from a host profile due to inactivity
• the system detects that a host is communicating with a new network protocol, such as Novell Netware or IPv6, or a new transport protocol, such as ICMP or EGP
• 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.

---

Note 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 Purging Discovery Data from the Database.

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 Adding Responses to Rules and White Lists.

---

---

Surveying Your Network

License: FireSIGHT

When you begin creating a compliance white list, you can survey either your entire network or a specific network segment.

Surveying your network gathers data from the database about the application protocols, clients, web applications, and protocols running on the different detected operating systems. Then, the system creates one host profile within the white list for each detected operating system. By default, these host profiles allow all of the detected clients, application protocols, web applications, and protocols that the system has detected on each applicable operating systems.

This creates a baseline white list so that you do not have to manually create and configure multiple host profiles. After you survey your network, you can then edit or delete the host profiles that the survey created to suit your needs; you can also add any other host profiles you might need.

Note that you can survey your network at any time during the white list creation process. This can add additional allowed clients, application protocols, web applications, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. If you resurvey your network within a white list that is used within an active correlation policy, and the survey changes either your targets or host profiles, the target hosts are re-evaluated when you save the white list. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

To begin creating a compliance white list by surveying your network:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Click New White List .

The Survey Network page appears.

Step 3 Do you want to survey your network?

• If yes , continue with the next step.
• If no , click Skip .

The Create White List page appears and displays a blank white list. Continue with the procedure in the next section, Providing Basic White List Information.

Step 4 In the IP Address and Netmask fields, enter the IP address and network mask (in special notation such as CIDR) that represent the hosts you want to survey.

Make sure to specify a network that you configured the system to monitor in the network discovery policy. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

---

Tip To survey the entire monitored network, use the default values of 0.0.0.0/0 and ::/0.

Step 5 Click OK .

The Create White List page appears.

The white list is pre-populated; its targets are the hosts in the network you surveyed and its allowed host profiles are those of the targets.

Step 6 To survey additional networks, click Target Network and repeat steps 4 and 5 for each additional network you want to survey.

Surveying an additional network can add additional allowed clients, application protocols, web applications, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. Surveying an additional network also adds a target to the white list that represents the hosts in the network segment that you surveyed. You can then edit or delete this target.

Step 7 Continue with the next section, Providing Basic White List Information.

 

Providing Basic White List Information

License: FireSIGHT

You must give each white list a name, and, optionally, a short description. In addition, you can choose whether jailbroken mobile devices should cause a white list violation.

To provide basic white list information:

Access: Admin

---

Step 1 In the Name field, type a name for the new white list.

Step 2 In the Description field, type a short description of the white list.

Step 3 To allow jailbroken mobile devices on your network, enable Allow Jailbroken Mobile Devices . To cause all jailbroken devices evaluated by the white list to generate a white list violation, disable the option.

Step 4 Continue with the next section, Configuring Compliance White List Targets.

 

Configuring Compliance White List Targets

License: FireSIGHT

When you create a compliance white list, you must specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual hosts. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a target . For a more detailed introduction to white list targets, see Understanding White List Targets.

When you are finished creating compliance white list targets, continue with Configuring Compliance White List Host Profiles.

---

Note If you change or delete a host attribute from a host and that modification means that the host is no longer a valid target, the host is no longer evaluated by the white list and is considered neither compliant nor non-compliant.

For information on how to modify and delete targets, see:

• Modifying Existing Targets
• Deleting Existing Targets

When you create a target for a compliance white list, you specify the criteria a host must meet to be evaluated against the white list. A valid target:

• must be in one of the IP address blocks you specify. You can also exclude blocks of IP addresses.
• must have at least one of the host attributes you specify.
• must belong to one of the VLANs you specify.

Note that if you add a target to a white list that is used by an active correlation policy, after you save the white list, the new target hosts are evaluated for compliance. However, this evaluation does not generate white list events.

To create a compliance white list target:

Access: Admin

---

Step 1 On the Create White List Page, next to Target Networks , click the add icon ( ).

The settings for the new target appear.

---

Tip You can also create a new target by surveying a network segment. On the Create White List page, click Target Network, then follow steps 4 and 5 in Surveying Your Network. The new target is created and is named according to the IP addresses you specified. Click the target you just created and continue with the rest of this procedure to rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions.

Step 2 In the Name field, type a name for the new target.

Step 3 Target a specific set of IP addresses by clicking the add icon ( ) next to Targeted Networks .

Step 4 In the IP Address and Netmask fields, enter the IP address and network mask (in special notation, such as CIDR) that represent the hosts you want to target or exclude from targeting.

You should make sure that you specify a network that you configured the system to monitor in your network discovery policy. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

---

Tip To target the entire monitored network, use 0.0.0.0/0 and ::/0.

Step 5 If you want to exclude the network from monitoring, select Exclude .

Step 6 To add additional networks, repeat steps 4 and 5.

Step 7 Target hosts that have a specific host attribute by clicking Add next to Targeted Host Attributes .

Step 8 From the Attribute and Value drop-down lists, specify the host attribute.

Step 9 To add additional host attributes, repeat steps 7 and 8.

A host must have at least one of the host attributes you specify to be evaluated against the white list.

Step 10 Target hosts that belong to a specific VLAN by clicking Add next to Targeted VLANs .

Step 11 In the VLAN ID field, specify the VLAN IDs of the hosts you want to evaluate against the white list. This can be any integer between 0 and 4095 for 802.1q VLANs.

Step 12 To add additional VLAN IDs, repeat steps 10 and 11.

The host must be a member of one of the VLANs you specify to be evaluated against the white list.

---

Tip To remove a network, host attribute restriction, or VLAN restriction, click the delete icon () next to the element you want to delete.

 

Modifying Existing Targets

License: FireSIGHT

After you modify a target, you must save the white list for your changes to take effect. Note that if you modify a target in a white list that is used by an active correlation policy, after you save the white list, any new target hosts are evaluated for compliance. However, this evaluation does not generate white list events. In addition, the system changes the white list host attribute of previously valid targets to Not Evaluated .

To modify an existing target:

Access: Admin

---

Step 1 On the Create White List page, under Targets , click the target you want to modify.

The settings for the target appear.

Step 2 Make changes as needed.

You can rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions. For more information, see Configuring Compliance White List Targets.

 

Deleting Existing Targets

License: FireSIGHT

After you delete a target, you must save the white list for your changes to take effect. Note that if you delete a target from a white list that is used by an active correlation policy, the system changes the white list host attribute of previously valid targets to Not Evaluated .

To delete a white list target:

Access: Admin

---

Step 1 Next to the target you want to delete, click the delete icon ( ).

Step 2 When prompted, confirm that you want to delete the target.

The target is deleted.

 

Configuring Compliance White List Host Profiles

License: FireSIGHT

Host profiles in a compliance white list specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts. There are three kinds of host profiles you can configure in a white list:

• global host profiles, which specify the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system
• host profiles for specific operating systems, which specify 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
• shared host profiles, which function exactly like the host profiles for specific operating systems, except they are not tied to a single white list; you can use them across multiple white lists

For a more detailed introduction to compliance white list host profiles, see Understanding White List Host Profiles.

When you are finished creating compliance white list host profiles, you can add the white list to an active correlation policy to begin evaluating the target hosts for compliance, generating white list events when a host violated the white list, and optionally, triggering responses based on white list violations.

For information on how to create, modify, and delete compliance white list host profiles, see:

• Configuring the Global Host Profile
• Creating Host Profiles for Specific Operating Systems
• Adding a Shared Host Profile to a Compliance White List
• Modifying Existing Host Profiles
• Deleting Existing Host Profiles

Configuring the Global Host Profile

License: FireSIGHT

Every white list contains a global host profile, which specifies the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system. For a more detailed introduction to the global host profile, see Understanding the Global Host Profile.

To configure the global host profile:

Access: Admin

---

Step 1 On the Create White List page, under Allowed Host Profiles , click Any Operating System .

The settings for the global host profile appear.

Step 2 To specify the application protocols you want to allow, follow the directions in Adding an Application Protocol to a Host Profile.

Step 3 To specify the clients you want to allow, follow the directions in Adding a Client to a Host Profile.

Step 4 To specify the web applications you want to allow, follow the directions in Adding a Web Application to a Host Profile.

Step 5 To specify the protocols you want to allow, follow the directions in Adding a Protocol to a Host Profile.

Note that ARP, IP, TCP, and UDP are always allowed.

 

Creating Host Profiles for Specific Operating Systems

License: FireSIGHT

Host profiles for specific operating systems 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 a more detailed introduction, see Understanding Host Profiles for Specific Operating Systems.

To create a new compliance white list host profile for a specific operating system:

Access: Admin

---

Step 1 Next to Allowed Host Profiles , click the add icon ( ).

The settings for the new host profile appear.

Step 2 In the Name field, type a descriptive name for the host profile.

Step 3 From the OS Vendor , OS Name , and Version drop-down lists, pick the operating system and version for which you want to create a host profile.

Step 4 Specify the application protocols you want to allow. You have three options:

• To allow all application protocols, leave the Allow all Application Protocols check box selected.
• To allow no application protocols, clear the Allow all Application Protocols check box.
• To allow specific application protocols, follow the directions in Adding an Application Protocol to a Host Profile.

Step 5 Specify the clients you want to allow. You have three options:

• To allow all clients, leave the Allow all Clients check box selected.
• To allow no clients, clear the Allow all Clients check box.
• To allow specific clients, follow the directions in Adding a Client to a Host Profile.

Step 6 Specify the web applications you want to allow. You have three options:

• To allow all web applications, leave the Allow all Web Applications check box selected.
• To allow no web applications, clear the Allow all Web Applications check box.
• To allow specific web applications, follow the directions in Adding a Web Application to a Host Profile.

Step 7 Specify the protocols you want to allow.

To add a protocol, next to Allowed Protocols , follow the directions in Adding a Protocol to a Host Profile. Note that ARP, IP, TCP, and UDP are always allowed.

 

Adding an Application Protocol to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain application protocols to run on specific operating systems. You can also configure a white list to allow certain application protocols to run on any valid target; these are called globally allowed application protocols.

For any allowed application protocol, you can either specify the type of application protocol that you want to allow — FTP and SSH are examples of application protocol types — or you can allow a custom application protocol by specifying an application protocol type of any . You must also specify the protocol the allowed application protocol uses (TCP or UDP). You can allow the application protocol on any port, or restrict it to a port that you specify.

Optionally, you can require that the application protocol server have a specific vendor or version. For example, you could allow SSH to run on Linux hosts on port 22. You could also restrict the particular vendor and version to OpenSSH 4.2.

To add an application protocol to a compliance white list host profile:

Access: Admin

---

Step 1 While you are creating or modifying a white list host profile, click the add icon ( )next to Allowed Application Protocols (or next to Globally Allowed Application Protocols if you are modifying the Any Operating System host profile).

A pop-up window appears. The application protocols listed are:

• application protocols that you created within the white list
• application protocols that existed in the network map when you surveyed your networks as described in Surveying Your Network
• application protocols that are used by other host profiles in the white list, which may include built-in application protocols created by the VRT for use in the default white list

Step 2 You have two options:

• To add an application protocol already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple application protocols. You can also click and drag to select multiple adjacent application protocols.

The application protocol is added. Note that if you added a built-in application protocol, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the application protocol’s values (such as the port or protocol), click the application protocol you just added to display the application protocol editor.

• To add a new application protocol, select <New Application Protocol> and click OK .

The application protocol editor appears.

Step 3 From the Type drop-down list, select the application protocol type. For custom application protocols, select any .

Step 4 Specify the application protocol port. You have two options:

• To allow the application protocol to run on any port, check the Any port check box.
• To allow the application protocol to run only on a specific port, type the port number in the port field.

Step 5 From the Protocol drop-down list, select the protocol: TCP or UDP .

Step 6 Optionally, in the Vendor and Version fields, specify a vendor and version for the application protocol.

If you do not specify a vendor or version, the white list allows all vendors and versions as long as the type and protocol match. Note that if you restrict the vendor and version, you must make sure to specify them exactly as they would appear in an event view or in the application protocols network map.

Step 7 Click OK .

The application protocol is added. Note that you must save the white list for your changes to take effect.

If you added an application protocol to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

 

Adding a Client to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain client applications to run on specific operating systems. You can also configure a white list to allow certain clients to run on any valid target; these are called globally allowed clients.

Optionally, you can require that the client be a specific version. For example, you could allow only Microsoft Internet Explorer 8.0 to run on Microsoft Windows hosts.

To add a client to a compliance white list host profile:

Access: Admin

---

Step 1 While you are creating or modifying a white list host profile, click the add icon ( ) next to Allowed Clients (or next to Globally Allowed Clients if you are modifying the Any Operating System host profile).

A pop-up window appears. The clients listed are:

• clients that you created within the white list
• clients that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network
• clients that are used by other host profiles in the white list, which may include built-in clients created by the VRT for use in the default white list

Step 2 You have two options:

• To add a client already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple clients. You can also click and drag to select multiple adjacent clients.

The client is added. Note that if you added a built-in client, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the client’s values (such as its version), click the client you just added to display the client editor.

• To add a new client, select <New Client> and click OK .

The client editor appears.

Step 3 From the Client drop-down list, select the client.

Step 4 Optionally, in the Version field, specify a version for the client.

If you do not specify a version, the white list allows all versions as long as the name matches. Note that if you restrict the version, you must specify it exactly as it would appear in a table view of clients.

Step 5 Click OK .

The client is added. Note that you must save the white list for your changes to take effect.

If you added a client to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

 

Adding a Web Application to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain web applications to run on specific operating systems. You can also configure a white list to allow certain web applications to run on any valid target; these are called globally allowed web applications.

To add a web application to a compliance white list host profile:

Access: Admin

---

Step 1 While you are creating or modifying a white list host profile, click the add icon ( ) next to Allowed Web Applications (or next to Globally Allowed Web Applications if you are modifying the Any Operating System host profile).

A pop-up window appears, listing all web applications detected by the system.

Step 2 Select a web application and click OK . Use Ctrl or Shift while clicking to select multiple web applications. You can also click and drag to select multiple adjacent web applications.

The web application is added. Note that you must save the white list for your changes to take effect.

If you added a web application to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

 

Adding a Protocol to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain protocols to run on specific operating systems. You can also configure a white list to allow certain protocols to run on any valid target; these are called globally allowed protocols. Note that ARP, IP, TCP, and UDP are always allowed to run on any host; you cannot disallow them.

For any allowed protocol, you must specify its type (Network or Transport) and number.

To add a protocol to a compliance white list host profile:

Access: Admin

---

Step 1 While you are creating or modifying a white list host profile, click the add icon ( ) next to Allowed Protocols (or next to Globally Allowed Protocols if you are modifying the Any Operating System host profile).

A pop-up window appears. The protocols listed are:

• protocols that you created within the white list
• protocols that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network
• protocols that are used by other host profiles in the white list, which may include built-in protocols created by the VRT for use in the default white list

Step 2 You have two options:

• To add a protocol already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple protocols. You can also click and drag to select multiple adjacent protocols.

The protocol is added. Note that if you added a built-in protocol, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the protocol’s values (such as the type or number) click the protocol you just added to display the protocol editor.

• To add a new protocol, select <New Protocol> and click OK .

The protocol editor appears.

Step 3 From the Type drop-down list, select the protocol type: Network or Transport .

Step 4 Specify the protocol. You have two options:

• Select a protocol from the drop-down list.
• Select Other (manual entry) to specify a protocol that is not in the list. For network protocols, type the appropriate number as listed in http://www.iana.org/assignments/ethernet-numbers/ . For transport protocols, type the appropriate number as listed in http://www.iana.org/assignments/protocol-numbers/ .

Step 5 Click OK .

The protocol is added. Note that you must save the white list for your changes to take effect.

If you added a protocol to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

 

Adding a Shared Host Profile to a Compliance White List

License: FireSIGHT

Shared host profiles are also tied to specific operating systems, but you can use them across white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

You can add any of the built-in shared host profiles to your compliance white lists, or you can add shared host profiles that you created. For more information, see Understanding Shared Host Profiles and Creating Shared Host Profiles.

To add a shared host profile to a compliance white list:

Access: Admin

---

Step 1 On the Create White List page, click Add Shared Host Profile .

The Add Shared Host Profile page appears.

Step 2 From the Name drop-down list, select the shared host profile you want to add to your white list, and click OK .

The shared host profile is added to your white list and the Create White List page appears again. The shared host profile’s name appears in italics under Allowed Host Profiles.

---

Tip You can edit a shared host profile from within a white list that uses it by clicking on the profile name under Allowed Host Profiles. For more information, see Modifying Existing Host Profiles.

 

Modifying Existing Host Profiles

License: FireSIGHT

After you modify a host profile within a compliance white list, you must save the white list for your changes to take effect.

If a host profile you modify belongs to a white list used in an active correlation policy, modifying the profile may bring hosts into or out of compliance but does not generate white list events. Further, modifying a shared host profile affects every white list that uses it. This may bring hosts into or out of compliance not only in the white list you are working with, but in other white lists as well.

---

Tip As with other shared host profiles, you can edit the built-in host profiles used by the default white list. You can also reset them to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults.

To modify an existing host profile:

Access: Admin

---

Step 1 On the Create White List page, click the name of the host profile you want to modify.

The settings for the host profile appear. Note that if you are editing a shared host profile, an Edit link appears next to the name of the host profile. If you are editing a built-in host profile, the built-in host profile icon ( ) also appears.

Step 2 You have two options:

• If you are modifying a shared host profile, click Edit .

A pop-up window appears. Make changes as needed as described in the table below. Click Save All Profiles to save the profile, then click Done to close the pop-up window.

For more information editing shared host profiles, see Modifying a Shared Host Profile.

• If you are modifying either the white list’s global host profile or a host profile for a specific operating system, perform one of the actions described in the procedures below.

 

To rename the host profile:

Access: Admin

---

Step 1 Type a new name in the Name field.

 

To change the operating system for the host profile:

Access: Admin

---

Step 1 Select the new operating system and version from the OS Vendor , OS Name , and Version drop-down lists.

If you change these values, you may also want to rename the host profile. Note that a white list’s global host profile has no operating system associated with it, so you cannot change it.

 

To add an application protocol:

Access: Admin

---

Step 1 Follow the directions in Adding an Application Protocol to a Host Profile.

 

To add a client:

Access: Admin

---

Step 1 Follow the directions in Adding a Client to a Host Profile.

 

To add a web application:

Access: Admin

---

Step 1 Follow the directions in Adding a Web Application to a Host Profile.

 

To add a protocol:

Access: Admin

---

Step 1 Follow the directions in Adding a Protocol to a Host Profile.

 

To allow all application protocols:

Access: Admin

---

Step 1 Under Allowed Application Protocols , select the Allow all Application Protocols check box.

Note that the check box does not appear until you delete any application protocols you have previously allowed.

 

To allow all clients:

Access: Admin

---

Step 1 Under Allowed Clients , select the Allow all Clients check box.

Note that the check box does not appear until you delete any clients you have previously allowed.

 

To allow all web applications:

Access: Admin

---

Step 1 Under Allowed Web Applications , select the Allow all Web Applications check box.

Note that the check box does not appear until you delete any web applications you have previously allowed.

 

To modify an application protocol, client, web application, or protocol:

Access: Admin

---

Step 1 Click the element you want to modify.

For more information on the properties you can change, see:

• Adding an Application Protocol to a Host Profile
• Adding a Client to a Host Profile
• Adding a Protocol to a Host Profile

---

Note The changes you make to an application protocol, client, web application, or protocol are reflected in every host profile that uses that element.

 

To delete an application protocol, client, web application, or protocol:

Access: Admin

---

Step 1 Next to the element you want to delete, click the delete icon ( ).

To survey your network:

Access: Admin

---

Step 1 Click Survey Network . Surveying your network can add additional allowed clients, application protocols, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during any initial survey. For more information, see Surveying Your Network.

Deleting Existing Host Profiles

License: FireSIGHT

After you delete a host profile from a compliance white list, you must save the white list for your changes to take effect. Note that deleting a shared host profile removes it from the white list, but does not delete the profile or remove it from any other white lists that use it. You cannot delete a white list’s global host profile.

If the host profile you delete belongs to one or more white lists used in an active correlation policy, deleting the profile may force hosts out of compliance, but does not generate white list events.

To delete a compliance white list host profile:

Access: Admin

---

Step 1 On the Create White List page, next to the host profile you want to delete, click the delete icon ( ).

Step 2 When prompted, confirm that you want to delete the host profile.

The host profile is deleted.

 

Modifying a Compliance White List

License: FireSIGHT

When you modify a compliance white list that is included in an active correlation policy, the system re-evaluates the target hosts. Note that the system does not generate white list events — and therefore does not trigger any responses you associated with the white list — during this re-evaluation, even if the white list is included in an active correlation policy and a previously compliant host becomes non-compliant with the updated white list.

To modify an existing compliance white list:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Next to the white list you want to modify, click the edit icon ( ).

The Create White List page appears.

Step 3 Make modifications as necessary and click Save White List .

The white list is updated.

 

Deleting a Compliance White List

License: FireSIGHT

You cannot delete a compliance white list that you are using in one or more correlation policies; you must first delete the white list from all policies where it is used. For information on deleting a white list from a policy, see Editing a Correlation Policy.

Deleting a white list also removes the host attribute associated with the white list from all hosts on your network.

To delete an existing compliance white list:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Next to the white list you want to delete, click the delete icon ( ).

The white list is deleted.

 

Creating Shared Host Profiles

License: FireSIGHT

Create a shared host profile if you want to use the same host profile to evaluate hosts running a particular operating system across multiple white lists.

---

Tip You can also create a shared host profile for your compliance white lists using the host profile of a specific host. For more information, see Creating a White List Host Profile from a Host Profile.

To create a shared host profile:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Click Edit Shared Profiles .

The Edit Shared Profiles page appears.

Step 3 Optionally, survey your network.

Surveying your network creates several baseline shared white lists based on the data the system has accumulated about your network. This saves you from manually creating and configuring multiple shared host profiles. You have two options:

• To survey your network, click Survey Network . For more information, see Surveying Your Network.

The system creates one or more baseline shared host profiles. You can edit or delete these shared host profiles as described in Modifying a Shared Host Profile and Deleting a Shared Host Profile. To add any other shared host profiles you might need, continue with the next step.

• To skip surveying your network, continue with the next step.

Step 4 Next to Shared Host Profiles , click the add icon ( ).

The settings for the new shared host profile appear.

Step 5 In the Name field, type a descriptive name for the shared host profile.

Step 6 From the OS Vendor , OS Name , and Version drop-down lists, pick the operating system and version for which you want to create a shared host profile.

Step 7 Specify the application protocols you want to allow. You have three options:

• To allow all application protocols, select the Allow all Application Protocols check box.
• To allow no application protocols, leave the Allow all Application Protocols check box cleared.
• To allow specific application protocols, next to Allowed Application Protocols , follow the directions in Adding an Application Protocol to a Host Profile.

Step 8 Specify the clients you want to allow. You have three options:

• To allow all clients, select the Allow all Clients check box.
• To allow no clients, leave the Allow all Clients check box cleared.
• To allow specific clients, follow the directions in Adding a Client to a Host Profile.

Step 9 Specify the web applications you want to allow. You have three options:

• To allow all web applications, select the Allow all Web Applications check box.
• To allow no web applications, leave the Allow all Web Applications check box cleared.
• To allow specific web applications, follow the directions in Adding a Web Application to a Host Profile.

Step 10 Specify the protocols you want to allow.

To add a protocol, next to Allowed Protocols , follow the directions in Adding a Protocol to a Host Profile. Note that ARP, IP, TCP, and UDP are always allowed.

Step 11 Click Save all Profiles to save your changes.

The shared host profile is created. You can now add the shared host profile to any compliance white list.

 

Modifying a Shared Host Profile

License: FireSIGHT

Modifying a shared host profile changes the profile for all the white lists it belongs to. For the white lists that use the shared host profile and are also used in an active correlation policy, modifying a shared host profile may bring hosts into or out of compliance, but does not generate white list events.

The following table describes the actions you can take to modify a shared host profile.

Deleting a Shared Host Profile

License: FireSIGHT

If the shared host profile you delete belongs to one or more white lists used in an active correlation policy, deleting the profile may force hosts out of compliance, but does not generate white list events.

---

Tip If you delete a built-in shared host profile that is used by the default white list, you can restore it by resetting the built-in profiles to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults.

To delete a shared host profile:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Click Edit Shared Profiles .

The Edit Shared Profiles page appears.

Step 3 Do you want to delete one of the built-in shared host profiles?

• If yes, expand Built-in Host Profiles to display those host profiles.
• If no, continue with the next step.

Step 4 Next to the shared host profile you want to delete, click the delete icon ( ).

Confirm that you want to delete the shared host profile.

Step 5 Click Save all Profiles to save your changes.

The shared host profile is deleted and removed from all compliance white lists that use it.

 

Resetting Built-In Host Profiles to Their Factory Defaults

License: FireSIGHT

The default white list uses a special category of shared host profiles, called built-in host profiles . Built-in host profiles use built-in application protocols, protocols, and clients. You can use any these elements as-is in both the default white list and in any custom white list that you create, or you can modify them to suit your needs. For more information, see Understanding Shared Host Profiles.

If you make changes to the built-in profiles, application protocols, protocols, web applications, or clients that you need to undo, you can reset to factory defaults. When you reset to factory defaults, the following things occur:

• All built-in host profiles, application protocols, protocols, and clients that you modified are reset to their factory defaults.
• All built-in host profiles, application protocols, protocols, and clients that you deleted are restored.
• All white lists (including the default white list) that are used by active correlation policies and that used any of the reset built-in host profiles, application protocols, protocols, or clients are re-evaluated. Although this re-evaluation may change the compliance of some hosts into compliance, it does not generate any white list events.

To reset built-in host profiles, application protocols, protocols, and clients:

Access: Admin

---

Step 1 Select Policies > Correlation , then click White List .

The White List page appears.

Step 2 Click Edit Shared Profiles .

The Edit Shared Profiles page appears.

Step 3 Click Built-in Host Profiles .

The Built-in Host Profiles page appears.

Step 4 Click Reset to Factory Defaults .

Step 5 Confirm that you want to reset to factory defaults by clicking OK .

All built-in host profiles, application protocols, protocols, and clients are reset to factory defaults. Any white list that is used by an active correlation policy and that used any of the reset built-in host profiles, application protocols, protocols, or clients is re-evaluated.

 

---

Viewing White List Events

License: FireSIGHT

You can use the Defense Center to view a table of compliance white list events. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access white list events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of white list events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on an white list events workflow page.

Understanding the White List Events Table

License: FireSIGHT

You can use the correlation policy feature to build correlation policies that let the system respond in real time to threats on your network. Correlation policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on correlation policies, see Configuring Correlation Policies and Rules.

When a compliance white list is violated, the system generates a white list event. The fields in the white list events table are described in the following table.

Searching for Compliance White List Events

License: FireSIGHT

You can search for specific compliance white list events. You may want to create searches customized for your network environment, then save them to re-use later. The following table describes the search criteria you can use.

Viewing White List Violations

License: FireSIGHT

You can use the Defense Center to view a table of white list violations. Then, you can manipulate the event view depending on the information you are looking for. The page you see when you access white list violations differs depending on the workflow you use. There are two predefined workflows:

• The Host Violation Count workflow provides a series of pages that list all the hosts that violate at least one white list. The first page sorts the hosts based on the number of violations per host, with the hosts with the greatest number of violations at the top of the list. If a host violates more than one white list, there is a separate row for each violated white list. The workflow also contains a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation.
• The White List Violations workflow includes a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation.

Both predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on a white list violations workflow page.

Understanding the White List Violations Table

License: FireSIGHT

You can use the correlation policy feature to build correlation policies that let the system respond in real time to threats on your network. Correlation policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on correlation policies, see Configuring Correlation Policies and Rules.

When a compliance white list is violated, the system records the violation. Note that you can not set event time constraints in the table view because the table view displays only the current host violations on your network. The fields in the white list violations table are described in the following table.

Searching for White List Violations

License: FireSIGHT

You can search for specific compliance white list violations. You may want to create searches customized for your network environment, then save them to re-use later. The following table describes the search criteria you can use.