Network Discovery Policies

The following topics describe how to create, configure, and manage network discovery policies:

Network discovery policies overview

The network discovery policy on the Firewall Management Center controls how the system collects data on the network assets of your organization and which network segments and ports are monitored.

Discovery rule configuration

Discovery rules in the policy specify which networks and ports you monitor to collect discovery data from traffic, and the zones where you deploy the policy. Within a rule, choose whether to discover hosts, applications, and non-authoritative users. Create rules to exclude networks and zones from discovery that you do not want to monitor. Set up discovery for data from NetFlow exporters as needed. You can also restrict which protocols on your network are used for discovering user data.

By default, the network discovery policy has a single rule that discovers applications from all observed traffic without excluding any networks, zones, or ports. Host and user discovery is not enabled, nor is NetFlow exporter monitoring. The policy is deployed automatically to managed devices when you register them to the Firewall Management Center. To collect host or user data, add or modify discovery rules and deploy the policy to a device.

If you want to adjust the scope of network discovery, you can create additional discovery rules and modify or remove the default rule.

The access control policy for each managed device determines which traffic you permit and, therefore, the traffic you can monitor with network discovery. If you block certain traffic with access control, the system does not examine that traffic for host, user, or application activity. For example, when you block access to social networking applications in an access control policy, discovery data is not collected on those applications.

Enable traffic-based user detection in your discovery rules to detect non-authoritative users based on login activity in traffic across specific application protocols. Disable discovery in certain protocols across all rules if necessary. Disabling some protocols helps prevent reaching the user limit for your Firewall Management Center model and reserves user count for other protocols.

Use advanced network discovery settings to control what data is logged, how discovery data is stored, which indications of compromise (IOC) rules are active, how you map vulnerabilities for impact assessment, and how you resolve conflicting discovery data from multiple sources.

You can also add sources for host input and NetFlow exporters to monitor.

Requirements and prerequisites for network discovery policies

The following requirements and prerequisites apply to network discovery policies:

Requirement

Description

Model support

Any

Supported domains

Only Leaf domains are supported

User roles

  • Admin

  • Discovery Admin

Network discovery customization

The information about your network traffic collected by the system is most valuable to you when the system can correlate this information to identify the hosts on your network that are most vulnerable and most important.

As an example, if you have several devices on your network running a customized version of SuSE Linux, the system cannot identify that operating system and so cannot map vulnerabilities to the hosts. However, knowing that the system has a list of vulnerabilities for SuSE Linux, you may want to create a custom fingerprint for one of the hosts that can then be used to identify the other hosts running the same operating system. You can include a mapping of the vulnerability list for SuSE Linux in the fingerprint to associate that list with each host that matches the fingerprint.

Customization capabilities

The system also allows you to input host data from third-party systems directly into the network map, using the host input feature. However, third-party operating system or application data does not automatically map to vulnerability information. If you want to see vulnerabilities and perform impact correlation for hosts using third-party operating system, server, and application protocol data, you must map the vendor and version information from the third-party system to the vendor and version listed in the vulnerability database (VDB). You also may want to maintain the host input data on an ongoing basis. Note that even if you map application data to system vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.

If the system cannot identify application protocols running on hosts on your network, you can create user-defined application protocol detectors that allow the system to identify the applications based on a port or a pattern. You can also import, activate, and deactivate certain application detectors to further customize the application detection capability.

You can also replace detection of operating system and application data using scan results from the Nmap active scanner or augment the vulnerability lists with third-party vulnerabilities. The system may reconcile data from multiple sources to determine the identity for an application.

Configure the network discovery policy

Configure the Network Discovery Policy to establish how the system identifies and monitors network resources, user traffic, and host operating systems in your environment.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Configure the following components of your policy:

Network discovery rules

Network discovery rules allow you to tailor the information discovered for your network map to include only the specific data you want. Rules in your network discovery policy are evaluated sequentially. You can create rules with overlapping monitoring criteria, but doing so may affect your system performance.

Network discovery rule behavior

When you exclude a host or a network from monitoring, the host or network does not appear in the network map and no events are reported for it. However, when the host discovery rules for the local IP are disabled, the detection engine instances are impacted by a higher processing load, as it builds data from each flow afresh rather than using the existing host data.

We recommend that you exclude load balancers (or specific ports on load balancers) and NAT devices from monitoring. These devices may create excessive and misleading events, filling the database and overloading the Firewall Management Center. For example, a monitored NAT device might exhibit multiple updates of its operating system in a short period of time. If you know the IP addresses of your load balancers and NAT devices, you can exclude them from monitoring.


Tip

The system can identify load balancers and NAT devices by examining your network traffic.

In addition, if you need to create a custom server fingerprint, you should temporarily exclude from monitoring the IP address that you are using to communicate with the host you are fingerprinting. Otherwise, the network map and discovery event views will be cluttered with inaccurate information about the host represented by that IP address. After you create the fingerprint, you can configure your policy to monitor that IP address again.

Cisco also recommends that you not monitor the same network segment with NetFlow exporters and managed devices. Although ideally you should configure your network discovery policy with non-overlapping rules, the system does drop duplicate connection logs generated by managed devices. However, you cannot drop duplicate connection logs for connections detected by both a managed device and a NetFlow exporter.

Configure network discovery rules

You can configure discovery rules to tailor the discovery of host and application data to your needs.


Tip

In most cases, we recommend restricting discovery to the addresses in RFC 1918.

Before you begin

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Add Rule.

Step 3

Set the Action for the rule as described in Actions and discovered assets.

Step 4

Set optional discovery parameters:

Step 5

Click Save.

What to do next

Actions and discovered assets

When you configure a discovery rule, you must select an action for the rule. The effect of that action depends on whether you are using the rule to discover data from a managed device or from a NetFlow exporter.

The table describes what assets are discovered by rules with the specified action settings in those two scenarios.

Table 1. Discovery rule actions

Action

Option

Managed Device

NetFlow Exporter

Exclude

--

Excludes the specified network from monitoring. If the source or destination host for a connection is excluded from discovery, the connection is recorded but discovery events are not created for excluded hosts.

Excludes the specified network from monitoring. If the source or destination host for a connection is excluded from discovery, the connection is recorded but discovery events are not created for excluded hosts.

Discover

Hosts

Adds hosts to the network map based on discovery events. (Optional, unless user discovery is enabled, then required.)

Adds hosts to the network map and logs connections based on NetFlow records.

Discover

Applications

Adds applications to the network map based on application detectors. Note that you cannot discover hosts or users in a rule without also discovering applications.

Adds application protocols to the network map based on NetFlow records and the port-application protocol correlation in 
/etc/sf/services.

Discover

Users

Adds users to the users table and logs user activity based on traffic-based detection on the user protocols configured in the network discovery policy.

n/a

Log NetFlow Connections

--

n/a

Logs NetFlow connections only. Does not discover hosts or applications.

If you want the rule to monitor managed device traffic, application logging is required. If you want the rule to monitor users, host logging is required. If you want the rule to monitor exported NetFlow records, you cannot configure it to log users, and logging applications is optional.


Note

The system detects connections in exported NetFlow records based on the Action settings in the network discovery policy. The system detects connections in managed device traffic based on access control policy settings.

Monitored networks

A discovery rule causes discovery of monitored assets only in traffic to and from hosts in the specified networks. For a discovery rule, discovery occurs for connections that have at least one IP address within the networks specified, with events generated only for IP addresses within the networks to monitor. The default discovery rule discovers applications from all observed traffic (0.0.0.0/0 for all IPv4 traffic, and ::/0 for all IPv6 traffic).

If you configure a rule to handle NetFlow discovery and log only connections data, the system also logs connections to and from IP addresses in the specified networks. Note that network discovery rules provide the only way to log NetFlow network connections.

You can also use network object or object groups to specify the networks to monitor.

Restrict the monitored network

Network discovery rules require at least one network to be specified for monitoring purposes. This task enables you to define which networks should be included in the discovery process.

Every discovery rule must include at least one network.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Add Rule.

Step 3

Click Networks, if it is not already open.

Step 4

Add network objects to the Available Networks list as described in Create network objects during discovery rule configuration.

If you modify a network object used in the network discovery policy, the changes do not take effect for discovery until you deploy the configuration changes.

Step 5

Specify a network:

  • Choose a network from the Available Networks list. If the network does not immediately appear on the list, click Reload (reload icon).

  • Enter the IP address into the text box below the Available Networks label.

Step 6

Click Add.

Step 7

Click Save.

What to do next

Configure rules for NetFlow data discovery

The system can use data from NetFlow exporters to generate connection and discovery events, and to add host and application data to the network map.

If you choose a NetFlow exporter in a discovery rule, the rule is limited to discovery of NetFlow data for the specified networks. Choose the NetFlow device to monitor before you configure other aspects of rule behavior, as the available rule actions change when you choose a NetFlow device. You cannot configure port exclusions for monitoring NetFlow exporters.

Before you begin

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Add Rule.

Step 3

Choose NetFlow Device.

Step 4

From the NetFlow Device drop-down list, choose the IP address of the NetFlow exporter to be monitored.

Step 5

Specify the type of NetFlow data you want the system managed device to collect:

  • Connection only — Choose Log NetFlow Connections from the Action drop-down list.
  • Host, Application, and Connection — Choose Discover from the Action drop-down list. The system automatically checks the Hosts check box and enables collection of connection data. Optionally, you can check the Application check box to collect application data.

Step 6

Click Save.

What to do next

Create network objects during discovery rule configuration

You can add new network objects to the list of available networks that appears in a discovery rule by adding them to the list of reusable network objects and groups.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

In Networks, click Add Rule.

Step 3

Click Add (add icon) next to Available Networks.

Step 4

Create a network object as described in Create a network object.

Step 5

Finish adding the network discovery rule as described in Configure network discovery rules.

Port exclusions

Just as you can exclude hosts from monitoring, you can exclude specific ports from monitoring.

Port exclusion use cases

Port exclusions are useful in these scenarios:

  • Load balancers can report multiple applications on the same port in a short period of time. You can configure your network discovery rules so that they exclude that port from monitoring, such as excluding port 80 on a load balancer that handles a web farm.

  • Your organization may use a custom client that uses a specific range of ports. If the traffic from this client generates excessive and misleading events, you can exclude those ports from monitoring. Similarly, you may decide that you do not want to monitor DNS traffic. In that case, you could configure your rules so that your discovery policy does not monitor port 53.

When adding ports to exclude, you can decide whether to use a reusable port object from the Available Ports list, add ports directly to the source or destination exclusion lists, or create a new reusable port and then move it into the exclusion lists.


Note

You cannot exclude ports in rules handling NetFlow data discovery.
Exclude ports in network discovery rules

Excluding ports in network discovery rules allows you to prevent the system from monitoring traffic on specific source and destination ports, helping to optimize network discovery performance and focus on relevant traffic patterns.

You cannot exclude ports in rules handling NetFlow data discovery.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Add Rule.

Step 3

Click Port Exclusions.

Step 4

Optionally, add port objects to the Available Ports list as described in Create port objects during discovery rule configuration.

Step 5

Exclude specific source ports from monitoring, using either of these methods:

  • Choose a port or ports from the Available Ports list and click Add to Source.
  • To exclude traffic from a specific source port without adding a port object, under the Selected Source Ports list, choose a Protocol, enter a Port number (a value from 1 to 65535), and click Add.

Step 6

Exclude specific destination ports from monitoring, using either of these methods:

  • Choose a port or ports from the Available Ports list and click Add to Destination.
  • To exclude traffic from a specific destination port without adding a port object, under the Selected Destination Ports list, choose a Protocol, enter a Port number, and click Add.

Step 7

Click Save to save the changes you made.

What to do next

Create port objects during discovery rule configuration

You can add new port objects to the list of available ports that appears in a discovery rule by adding them to the list of reusable port objects and groups that can be used anywhere in the system.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

In Networks, click Add Rule.

Step 3

Click Port Exclusions.

Step 4

To add a port to the Available Ports list, click Add (add icon).

Step 5

Enter Name.

Step 6

In the Protocol field, specify the protocol of the traffic you want to exclude.

Step 7

In the Port field, enter the ports you want to exclude from monitoring.

You can specify a single port, a range of ports using the dash (-), or a comma-separated list of ports and port ranges. Allowed port values are from 1 to 65535.

Step 8

Click Save.

Step 9

If the port does not immediately appear on the list, click Refresh.

What to do next

Zones in network discovery rules

To improve performance, discovery rules can be configured so that the zones in the rule include the sensing interfaces on your managed devices that are physically connected to the networks-to-monitor in the rule.

Unfortunately, you may not always be kept informed of network configuration changes. A network administrator may modify a network configuration through routing or host changes without informing you, which may make it challenging to stay on top of proper network discovery policy configurations. If you do not know how the sensing interfaces on your managed devices are physically connected to your network, leave the zone configuration as the default. This default causes the system to deploy the discovery rule to all zones in your deployment. (If no zones are excluded, the system deploy the discovery policy to all zones.)

Configuring zones in network discovery rules
Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Add Rule.

Step 3

Click Zones.

Step 4

Choose a zone or zones from the Available Zones list.

Step 5

Click Save to save the changes you made.

What to do next

Traffic-based detection identity sources

Traffic-based detection is the only non-authoritative identity source supported by the system. When configured, managed devices detect LDAP, AIM, POP3, IMAP, Oracle, SIP (VoIP), FTP, HTTP, MDNS, and SMTP logins on the networks you specify. The data gained from traffic-based detection can be used only for user awareness. Unlike authoritative identity sources, you configure traffic-based detection in your network discovery policy as described in Configure Traffic-Based user detection.

Traffic-based detection limitations

  • Traffic-based detection interprets only Kerberos logins for LDAP connections as LDAP authentications. Managed devices cannot detect encrypted LDAP authentications using protocols such as SSL or TLS.

  • Traffic-based detection detects AIM logins using the OSCAR protocol only. They cannot detect AIM logins using TOC2.

  • Traffic-based detection cannot restrict SMTP logging. This is because users are not added to the database based on SMTP logins; although the system detects SMTP logins, the logins are not recorded unless there is already a user with a matching email address in the database.

Traffic-based detection also records failed login attempts. A failed login attempt does not add a new user to the list of users in the database. The user activity type for detected failed login activity detected by traffic-based detection is Failed User Login.


Note

The system cannot distinguish between failed and successful HTTP logins. To see HTTP user information, you must enable Capture Failed Login Attempts in the traffic-based detection configuration.


Caution

Enabling or disabling non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols, using the network discovery policy restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the assigned device handles traffic. Refer to Snort restart traffic behavior.
Traffic-based detection data

When a device detects a login using traffic-based detection, it sends the following information to the Firewall Management Center to be logged as user activity:

  • The user name identified in the login.

  • The time of the login.

  • The IP address involved in the login, which can be the IP address of the user’s host (for LDAP, POP3, IMAP, and AIM logins), the server (for HTTP, MDNS, FTP, SMTP and Oracle logins), or the session originator (for SIP logins).

  • The user’s email address (for POP3, IMAP, and SMTP logins).

  • The name of the device that detected the login.

If the user was previously detected, the Firewall Management Center updates that user’s login history. Note that the Firewall Management Center can use the email addresses in POP3 and IMAP logins to correlate with LDAP users. This means that, for example, if the Firewall Management Center detects a new IMAP login, and the email address in the IMAP login matches that for an existing LDAP user, the IMAP login does not create a new user; rather, it updates the LDAP user’s history.

If the user was previously undetected, the Firewall Management Center adds the user to the users database. Unique AIM, SIP, and Oracle logins always create new user records, because there is no data in those login events that the Firewall Management Center can correlate with other login types.

The Firewall Management Center does not log user activity or user identities in the following cases:

  • If you configured the network discovery policy to ignore that login type

  • If a managed device detects an SMTP login, but the users database does not contain a previously detected LDAP, POP3, or IMAP user with a matching email address

The user data is added to the users table.

Traffic-based detection strategies

You can restrict the protocols where user activity is discovered to reduce the total number of detected users so you can focus on users likely to provide the most complete user information. Limiting protocol detection helps minimize user name clutter and preserve storage space on your Firewall Management Center.

Consider these factors when selecting traffic-based detection protocols:

  • Obtaining user names through protocols such as AIM, POP3, and IMAP may introduce user names not relevant to your organization due to network access from contractors, visitors, and other guests.

  • AIM, Oracle, and SIP logins may create extraneous user records. This occurs because these login types are not associated with any of the user metadata that the system obtains from an LDAP server, nor are they associated with any of the information contained in the other types of login that your managed devices detect. Therefore, the Firewall Management Center cannot correlate these users with other types of users.

Configure Traffic-Based user detection

Configure traffic-based user detection to automatically enable host discovery and monitor user login activities across various protocols in your network.

When you enable traffic-based user detection in a network discovery rule, host discovery is automatically enabled. For more information about traffic-based detection, see Traffic-based detection identity sources.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Users.

Step 3

Click Edit (edit icon).

Step 4

Check the check boxes for protocols where you want to detect logins, or clear check boxes for protocols where you do not want to detect logins. Then choose whether you want to Capture Failed Login Attempts.

Step 5

Click Save.

Traffic-based user detection is configured for the selected protocols, enabling the system to monitor user login activities and automatically discover hosts in your network.

What to do next


Caution

Enabling or disabling non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols, using the network discovery policy restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the assigned device handles traffic. Refer to Snort restart traffic behavior.

Configure advanced network discovery options

The Advanced section of the network discovery policy allows you to configure policy-wide settings. You can define which events are detected, how long discovery data is retained, how often it is updated, which vulnerability mappings are used for impact correlation, and how operating system and server identity conflicts are resolved. In addition, you can add host input sources and NetFlow exporters to allow import of data from other sources.


Note

Database event limits for discovery and user activity events are set in system configuration.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) or Add (add icon) next to the setting you want to modify:

Step 4

Click Save.

What to do next

Network discovery general settings

The general settings control how often the system updates network maps and whether server banners are captured during discovery.

Capture banners

Select this check box if you want the system to store header information from network traffic that advertises server vendors and versions (“banners”). This information can provide additional context to the information gathered. You can access server banners collected for hosts by accessing server details.

Update interval

The interval at which the system updates information (such as when any of a host's IP addresses was last seen, when an application was used, or the number of hits for an application). The default setting is 3600 seconds (1 hour).


Note

Setting a lower interval for update timeouts provides more accurate information in the host display, but generates more network events.

Configuring network discovery general settings

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to General Settings.

Step 4

Update the settings as described in Network discovery general settings.

Step 5

Click Save to save the general settings.

What to do next

Network discovery identity conflict settings

The system identifies the operating system and applications running on a host by matching fingerprints for operating systems and servers against patterns in traffic. It collects fingerprint information from several sources to give you reliable operating system and server identity information.

The system uses all passive data to derive operating system identities and assign a confidence value.

By default, unless there is an identity conflict, identity data added by a scanner or third-party application overrides identity data detected by the system. You can use the Identity Sources settings to rank scanner and third-party application fingerprint sources by priority. The system retains one identity for each source, but only data from the highest priority third-party application or scanner source is used as the current identity.


Note

User input data overrides scanner and third-party application data, regardless of priority.

An identity conflict occurs when the system detects an identity that conflicts with an existing identity from active scanner, third-party application sources listed in the Identity Sources settings, or a system user. By default, identity conflicts are not automatically resolved and you must resolve them through the host profile or by rescanning the host or re-adding new identity data to override the passive identity. However, you can set your system to automatically resolve the conflict by keeping either the passive identity or the active identity.

Generate identity conflict event

Specifies whether the system generates an event when an identity conflict occurs.

Automatically resolve conflicts

From the Automatically Resolve Conflicts drop-down list, choose one of these options:

  • Disabled if you want to force manual conflict resolution of identity conflicts.

  • Identity if you want the system to use the passive fingerprint when an identity conflict occurs.

  • Keep Active if you want the system to use the current identity from the highest priority active source when an identity conflict occurs.

Configure network discovery identity conflict resolution

Network discovery may encounter conflicts when multiple sources provide different information about the same network device or host. Configure these settings to define how the system resolves such conflicts.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to Identity Conflict Settings.

Step 4

Update the settings in the Edit Identity Conflict Settings pop-up window as described in Network discovery identity conflict settings.

Step 5

Click Save to save the identity conflict settings.

What to do next

Network discovery vulnerability impact assessment options

You can configure how the system performs impact correlation with intrusion events.

Your choices are:

  • Check the Use Network Discovery Vulnerability Mappings check box if you want to use system-based vulnerability information to perform impact correlation.

  • Check the Use Third-Party Vulnerability Mappings check box if you want to use third-party vulnerability references to perform impact correlation. For more information, see the Firepower System Host Input API Guide.

You can check either or both of the check boxes. If the system generates an intrusion event and the host involved in the event has servers or an operating system with vulnerabilities in the selected vulnerability mapping sets, the intrusion event is marked with the Vulnerable (level 1: red) impact icon. For any servers which do not have vendor or version information, note that you need to enable vulnerability mapping in the Firewall Management Center configuration.

If you clear both check boxes, intrusion events will never be marked with the Vulnerable (level 1: red) impact icon.

Enable network discovery vulnerability impact assessment

Configure network discovery vulnerability impact assessment. This configuration determines which vulnerabilities are evaluated when you assess the potential impact of security threats on your network assets.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to Vulnerabilities to use for Impact Assessment.

Step 4

Update the settings in the Edit Vulnerability Settings pop-up window as described in Network discovery vulnerability impact assessment options.

Step 5

Click Save to save the vulnerability settings.

What to do next

Indications of compromise

An indication of compromise (IOC) tag is a security detection marker that

  • signifies a host is likely compromised by malicious means,

  • is generated based on IOC rules that correlate network and host activity, and

  • specifies the nature and type of potential compromise, aiding investigation and remediation.

IOC tagging conditions

The Firewall Management Center can tag the host and user involved when one of these things occurs:

  • The system correlates data gathered about your monitored network and its traffic, using intrusion, connection, Security Intelligence, and file or malware events, and determines that a potential IOC has occurred.

  • The Firewall Management Center can import IOC data from your Secure Endpoint deployments via the AMP cloud. Because this data examines activity on a host itself, such as actions taken by or on individual programs, it can provide insights into possible threats that network-only data cannot. For your convenience, the Firewall Management Center automatically obtains any new IOC tags that Cisco develops from the AMP cloud.

To configure this feature, refer to Enable indications of compromise rules.

You can also write correlation rules against host IOC data and compliance allow lists that account for IOC-tagged hosts.

To investigate and work with tagged IOCs, see Cisco Secure Firewall Management Center Administration Guide.

Enable indications of compromise rules


Tip

To disable IOC rules for individual hosts or their associated users, see the Discovery Events chapter in the Cisco Secure Firewall Management Center Administration Guide.

Before you begin

Because IOC rules trigger based on data provided by other components of the system and by Secure Endpoint, those components must be correctly licensed and configured for IOC rules to set IOC tags. Enable the system features associated with the IOC rules you plan to enable, such as intrusion detection and prevention (IPS) and Advanced Malware Protection (AMP). If an IOC rule’s associated feature is not enabled, no relevant data is collected and the rule cannot trigger.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to Indications of Compromise Settings.

Step 4

To toggle the entire IOC feature off or on, click the slider next to Enable IOC.

Step 5

To globally enable or disable individual IOC rules, click the slider in the rule's Enabled column.

Step 6

Click Save to save your IOC rule settings.

What to do next

Add NetFlow exporters to a network discovery policy

Use this procedure to add NetFlow exporters.


Note

You cannot delete an exporter if it is currently in use in a disocvery rule.

Before you begin

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Add (add icon) next to NetFlow Devices.

Step 4

Enter the IP Address of the exporter.

Step 5

Click Save.

What to do next

Network discovery data storage settings

Discovery data storage settings include the host limit and timeout settings.

When host limit reached

The number of hosts a Secure Firewall Management Center can monitor, and therefore store in the network map, depends on its model. The When Host Limit Reached option controls what happens when you detect a new host after you reach the host limit. You can:

Drop hosts

The system drops the host that has remained inactive for the longest time, then adds the new host. This is the default setting.

Don't insert new hosts

The system does not track any newly discovered hosts. Only after the host count falls below the limit does the system resume tracking new hosts. This can occur if an administrator increases the domain's host limit, manually deletes hosts from the network map, or the system identifies hosts as timed out due to inactivity.

Table 2. Reaching the host limit with multitenancy

Setting

Domain Host Limit Set?

Domain Host Limit Reached

Ancestor Domain Host Limit Reached

Drop hosts

yes

Drops oldest host in the constrained domain.

Drops the oldest host among all descendant leaf domains configured to drop hosts.

If no host can be dropped, does not add the host.

no

n/a

Drops the oldest host among all descendant leaf domains configured to drop hosts and that share the general pool.

Don't insert new hosts

yes or no

Does not add the host.

Does not add the host.

Host timeout

The amount of time that passes, in minutes, before the system drops a host from the network map due to inactivity. The default setting is 10080 minutes (one week). Individual host IP and MAC addresses can time out individually, but a host does not disappear from the network map unless all its associated addresses time out.

To avoid premature timeout of hosts, make sure that the host timeout value is longer than the update interval in the network discovery policy general settings.

Server timeout

The amount of time that passes, in minutes, before the system drops a server from the network map due to inactivity. The default setting is seven days (10,080 minutes).

To avoid premature timeout of servers, make sure that the service timeout value is longer than the update interval in the network discovery policy general settings.

Client application timeout

The amount of time that passes, in minutes, before the system drops a client from the network map due to inactivity. The default setting is 10080 minutes (one week).

To ensure optimal performance, set the client timeout value to exceed the update interval in the network discovery policy general settings.

Configure network discovery data storage

Configure network discovery data storage settings to control how the system stores and manages network discovery information, including retention policies and storage limits.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to Network Discovery Data Storage Settings.

Step 4

Update the settings in the Data Storage Settings dialog as described in Network discovery data storage settings.

Step 5

Click Save to save the data storage settings.

What to do next

Configure network discovery event logging

The Event Logging Settings control whether discovery and host input events are logged. If you do not log an event, you cannot retrieve it in event views or use it to trigger correlation rules.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to Event Logging Settings.

Step 4

Check or clear the check boxes next to the discovery and host input event types you want to log in the database , described in the Discovery Events chapter of the Cisco Secure Firewall Management Center Administration Guide.

Step 5

Click Save to save the event logging settings.

What to do next

Add network discovery OS and server identity sources

In Advanced section of the network discovery policy, add new active sources or change the priority or timeout settings for existing sources.

Adding a scanner to this page does not add the full integration capabilities that exist for the Nmap scanners, but does allow integration of imported third-party application or scan results.

If you import data from a third-party application or scanner, make sure that you map vulnerabilities from the source to the vulnerabilities detected in your network.

Procedure

Step 1

Choose Policies > + Show more > Advanced > Network Discovery.

Step 2

Click Advanced.

Step 3

Click Edit (edit icon) next to OS and Server Identity Sources.

Step 4

To add a new source, click Add Source.

Step 5

Enter a Name.

Step 6

Choose the input source Type from the drop-down list:

  • Choose Scanner if you plan to import scan results using the AddScanResult function.
  • Choose Application if you do not plan to import scan results.

Step 7

To indicate the duration of time that should elapse between the addition of an identity to the network map by this source and the deletion of that identity, choose Hours, Days, or Weeks from the Timeout drop-down list and enter the appropriate duration.

Step 8

Optionally:

  • To promote a source and cause the operating system and application identities to be used in favor of sources below it in the list, choose the source and click the up arrow.
  • To demote a source and cause the operating system and application identities to be used only if there are no identities provided by sources above it in the list, choose the source and click the down arrow.
  • To delete a source, click Delete (delete icon) next to the source.

Step 9

Click Save to save the identity source settings.

What to do next

Troubleshoot your network discovery strategy

Before you make any changes to the system’s default detection capabilities, you should analyze what hosts are not being identified correctly and why, so you can decide what solution to implement.

Are your managed devices correctly placed?

If network devices such as load balancers, proxy servers, or NAT devices reside between the managed device and the unidentified or misidentified host, place a managed device closer to the misidentified host rather than using custom fingerprinting. Custom fingerprinting is not recommended in this scenario.

Do unidentified operating systems have a unique TCP stack?

If the system misidentifies a host, you should investigate why the host is misidentified to help you decide between creating and activating a custom fingerprint or substituting Nmap or host input data for discovery data.


Caution

If you encounter misidentified hosts, contact your support representative before creating custom fingerprints.

  • If a host is running an operating system that is not detected by the system by default and does not share identifying TCP stack characteristics with existing detected operating systems, you should create a custom fingerprint.

  • For example, if you have a customized version of Linux with a unique TCP stack that the system cannot identify, you would benefit from creating a custom fingerprint, which allows the system to identify the host and continuing monitoring it, rather than using scan results or third-party data, which require you to actively update the data yourself on an ongoing basis.

  • Note that many open source Linux distributions use the same kernel, and as such, the system identifies them using the Linux kernel name. If you create a custom fingerprint for a Red Hat Linux system, you may see other operating systems (such as Debian Linux, Mandrake Linux, Knoppix, and so on) identified as Red Hat Linux, because the same fingerprint matches multiple Linux distributions.

  • Do not use a fingerprint in every situation.

    For example:

    • A modification may have been made to a host’s TCP stack so that it resembles or is identical to another operating system.

    • If an Apple Mac OS X host is altered, making its fingerprint identical to a Linux 2.4 host, causing the system to identify it as Linux 2.4 instead of Mac OS X. If you create a custom fingerprint for the Mac OS X host, it may cause all legitimate Linux 2.4 hosts to be erroneously identified as Mac OS X hosts. In this case, if Nmap correctly identifies the host, you could schedule regular Nmap scans for that host.

Third-party data integration

If you import data from a third-party system using host input, you must map the vendor, product, and version strings that the third party uses to describe servers and application protocols to the Cisco definitions for those products. Note that even if you map application data to system vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.

  • The system may reconcile data from multiple sources to determine the current identity for an operating system or application.

  • For Nmap data, you can schedule regular Nmap scans. For host input data, you can regularly run the Perl script for the import or the command line utility. However, note that active scan data and host input data may not be updated with the frequency of discovery data.

Can the system identify all applications?

If a host is correctly identified by the system but has unidentified applications, create a user-defined detector to provide the system with port and pattern matching information to help identify the application.

If the system correctly identifies a host but cannot identify some applications, create a user-defined detector that provides the system with port and pattern matching information. This will help the system identify the application.

Have you applied patches that fix vulnerabilities?

If the system correctly identifies a host but does not reflect applied fixes, you can use the host input feature to import patch information. When you import patch information, you must map the fix name to a fix in the database.

Do you want to track third-party vulnerabilities?

If you have vulnerability information from a third-party system that you want to use for impact correlation, you can map the third-party vulnerability identifiers for servers and application protocols to vulnerability identifiers in the Cisco database and then import the vulnerabilities using the host input feature. For more information on using the host input feature, see the Firepower System Host Input API Guide. Note that even if you map application data to system vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.