In modern network security operations, visibility is foundational. Cisco Secure Firewall provides a powerful feature known as Network Discovery which enables administrators to gain deep insights into their network’s users, hosts, and applications without launching intrusive scans.

 

What Is Network Discovery?

Network Discovery in Cisco Secure Firewall is a passive monitoring feature designed to identify users, hosts, and applications traversing the network. The key benefit is that this intelligence is gathered without performing active scans, which could otherwise disrupt network performance or trigger alerts on sensitive systems.

 

Core Objectives of Network Discovery

  • Visibility into:
    • Applications (enabled by default)
    • Hosts (optional)
    • Users (optional)
  • Collection of telemetry that feeds into Host Profiles for deeper analytics

 

How It Works

Unlike traditional network scanners, Secure Firewall uses Network Discovery rules defined by administrators. These rules monitor allowed traffic only, meaning the data collection process is constrained to what’s already permitted by access control policies. This reduces risk and overhead while providing actionable intelligence.

There is only one Discovery Policy per FMC (Firewall Management Center), which applies to all managed devices. This centralized configuration ensures consistency and simplifies policy enforcement.

 

 

The Evolution of Network Discovery

Previously known as “Firesight” technology, Network Discovery has matured significantly. Starting with version 6.0 of Secure Firewall, application discovery is enabled by default, while host and user discovery must be explicitly enabled by administrators. In earlier versions such as 5.4, hosts and applications were enabled by default.

 

Be Cautious with Default Network Ranges

By default, Secure Firewall configures Network Discovery to monitor:

  • 0.0.0.0/0 (all IPv4)
  • 0::/0 (all IPv6)

While these settings provide comprehensive coverage, they can also create problems. For example, if a user accesses a public site like Yahoo.com, the system sees both the internal source IP and the external destination IP, profiling both as hosts. This can quickly exhaust host/user limits, especially in virtual deployments.

For reference:

  • On a virtual FMC, the host limit is 50,000 – 150,000 depending on whether it is an FMCv2/10/25 or an FMCv300.
  • Exceeding this can impact system performance and visibility.

 

Best Practice:

Always customize the subnets and networks included in your Discovery Policy to limit scope to only trusted internal segments. This conserves resources and keeps the Secure Firewall running efficiently.

 

 

What Does Network Discovery Collect?

All gathered data is stored in a Host Profile, which serves as a central intelligence record for each discovered entity. This includes:

  • Operating Systems: Windows (7, 8, 10), macOS, etc.
  • Client Applications: Browsers (Firefox, Chrome, Internet Explorer), etc.
  • Server Applications: Web servers (Apache, IIS), mail servers, etc.
  • Protocols: TCP, UDP, ICMP, etc.
  • Users: Mapped via identity policies or integrations like Active Directory

This data becomes incredibly valuable when combined with Secure Firewall’s access control policies, identity-based rules, and intrusion detection/prevention capabilities.

Network Discovery is a cornerstone for building network visibility and contextual awareness. But to use it effectively, administrators must fine-tune their Discovery Policies to avoid overwhelming the system with unnecessary data. When configured properly, Network Discovery can turn your firewall into a rich source of threat intelligence and operational insight—without scanning a single host.

 

 

Accessing the Network Discovery Policy

To make the most of this powerful feature, administrators need to carefully configure which networks to monitor and what types of entities to discover.

To configure or review the existing Network Discovery settings:

  • Navigate to Policies > Network Discovery in the FMC.

 

  • This screen will show your current Discovery Policy.
  • From here, you can define:
    • Which networks to monitor
    • Whether to discover hosts, users, or applications
    • Whether to include or exclude specific subnets

Administrators can create rules for each subnet or network segment, assigning specific discovery actions such as “Discover” or “Exclude.” This ensures precision in which traffic is analyzed and helps avoid performance issues from overly broad policies.

 

 

Add a Network Object to the Discovery Policy

To specify which networks are subject to discovery:

  • Edit the Network Discovery policy

 

  • Check the + box next to the Available Networks in the Edit Rule pop-up window

 

  • Create a new network object to include all the addresses you wish to monitor.  These objects can be used to group related subnets (e.g., DMZ, internal LAN, departments).

By using network object groups, you simplify policy management and reduce human error when defining Discovery rules across large environments.

 

 

Configuring Rules to the Network Discovery Policy

  • In the Network Discovery policy, click Add Rule

 

  • In the Add Rule dialog box, we can choose to discover or exclude based on criteria in the rule.

 

  • Discovery is enabled by default for applications and cannot be disabled. We can also choose to enable it for Hosts and Users in the rule.

 

  • We already know we can pick which networks to do discovery on so we will look at the other options instead. Under the Zones tab, we can choose which Zones to discovery on such as inside and DMZ interfaces.

 

  • We can also add source and destination port exclusions into the rule under the Port Exclusions tab.

 

 

User-Based Discovery: Identifying Who Is on Your Network

Secure Firewall also supports user identification through traffic analysis, which is configured under the Users tab within the Network Discovery Policy.

 

Here, you can specify which types of protocols should be analyzed for user identity information. Examples of supported protocols include:

Protocol Enabled by Default
AIM Yes
IMAP Yes
LDAP Yes
Oracle Yes
POP3 Yes
SIP Yes
FTP Yes
HTTP Yes
mDNS Yes

 

Note: I’m not a fan of the SIP protocol being enabled to look for users. This can sometimes add a lot of noise in the form of phone numbers to the user table in the FMC. Given the user count limitations on certain FMC platforms, I have seen the phone numbers collected from the SIP traffic fill up the user table in very large environments.

You can even enable “Capture Failed Login Attempts“, which helps identify unsuccessful user authentications that might indicate credential stuffing or brute-force attacks.

This user data is invaluable for incident response and behavioral analytics, especially when integrated with identity services like Cisco ISE or Active Directory.

 

Best Practices for Network Discovery Configuration

  • Avoid broad discovery networks like 0.0.0.0/0 unless absolutely necessary.
  • Segment your policy by DMZ, internal zones, and trusted hosts to avoid unnecessary profiling of external traffic.
  • Regularly prune unused or low-value host data to stay under FMC’s resource limits.
  • Use traffic-based detection to map users accurately to IPs and applications without deploying agents.

 

 

Advanced Settings in the Network Discovery Policy

Once you’ve defined which networks to monitor and what traffic to inspect, you can fine-tune Secure Firewall’s Network Discovery behavior through the Advanced tab in the Discovery Policy. This is where power users can customize storage behaviors, resolve identity conflicts, integrate NetFlow, and more.

 

General Settings

There are only two settings under this section:

  • Capture Banners – Disabled by default. Enabling this option allows the firewall to collect and store banner information from network traffic, such as server vendor and version details. These banners, often seen in protocols like HTTP, FTP, or SSH, provide valuable context for identifying and profiling networked assets. Once enabled, administrators can view this data in the server details pane for deeper host analysis and security insights.
  • Update Interval (seconds) – The firewalls uses an update interval to refresh host-related information such as last-seen IP addresses, application usage, and application hit counts. By default, this interval is set to 3600 seconds (1 hour). Lowering the interval improves the accuracy and freshness of host data but can increase the volume of generated network events, potentially impacting performance or event storage.

 

Identity Conflict Settings

In complex environments, Secure Firewall may receive conflicting identity data (e.g., OS info from passive inspection versus AD logins). These settings define how the system resolves those discrepancies:

  • Generate Identity Conflict – Enable/disable alerts for mismatched data
  • Automatically Resolve Conflicts –  Optionally use external identity sources (e.g., Nmap scans, AD) to resolve the conflict

This ensures that the Host Profile remains accurate and can be trusted for correlation and policy enforcement.

 

Vulnerability Mapping for Impact Assessment

When an IPS rule is triggered, the impact level is automatically calculated based on system context:

  • Use Network Discovery Vulnerability Mappings: Determines impact using discovered OS/application data
  • Use Third-Party Vulnerability Mappings: Leverage external threat intel feeds for more context

Example: If an IPS signature triggers on a Linux vulnerability but Network Discovery shows the host is running Windows, the impact level will be reduced, reducing false positives.

 

Indicators of Compromise (IOC) Settings

This feature enables correlation of subtle indicators—such as protocol anomalies or behavioral changes—to flag potential compromises:

  • Enabled by default
  • 40/40 rules active by default
  • Highly recommended to leave this feature on for real-time alerting of suspicious activity across discovered hosts.

 

NetFlow Integration

You can enhance discovery coverage by integrating with external NetFlow-capable devices:

  • Add devices via NetFlow Device configuration
  • Useful when some segments aren’t directly inspected by the firewall
  • Secure Firewall ingests and correlates NetFlow data to extend visibility

This is especially useful in hybrid designs where Secure Firewall is not in-line on every segment.

 

Network Discovery Data Storage Settings

This section controls what happens when Secure Firewall reaches its maximum host capacity and how long it retains discovered data.

  • When Host Limit Reached: The default is to drop new hosts once the limit is reached. This prevents resource exhaustion. Admins can instead choose to replace old hosts if desired.
  • Host/Server/Client Timeout: These define how long (in minutes) the system should retain discovered information. The default is 10,080 minutes (7 days)

Use these settings to tailor how long host data is relevant for your environment and avoid stale host information over time.

 

Event Logging Settings

  • All logging is enabled by default, including:
    • TCP port timeouts
    • VLAN tags
    • Session statistics

Unless you’re troubleshooting or dealing with logging constraints, you shouldn’t need to disable any of these.

 

OS and Server Identity Sources

Secure Firewall can enrich passive Network Discovery by integrating with active tools like Nmap. This provides another mechanism to validate host OS and service identity, supplementing the passive observations.

 

 

Creating Custom OS Fingerprints

While Cisco Secure Firewall includes robust built-in fingerprinting for operating systems and services, there may be situations where you want to define your own custom OS profile, particularly for niche or legacy systems that may not be automatically detected.

  • You can do this by navigating to Policies > Network Discovery → Click Custom Operating Systems (top right)

 

  • From there, you can select Create Custom Fingerprint, which opens a detailed form to define and map a new OS signature.

 

  • What You Can Define in a Custom Fingerprint
    • Create Fingerprint:
      • Device – The management center or device you want to use to collect the fingerprint.
      • Fingerprint Name – Give this fingerprint a name.
      • Fingerprint Description – Optional description you can add.
      • Fingerprint Type –  You have the option for client or server from this dropdown.
    • Device Target Information:
      • Target IP address – This is the IP address of the host you want to fingerprint.
      • Number of hops to the target – Number of hops between the host and the device you are using to obtain the fingerprint. Best practice is to use the same subnet if you can.
      • Interface used – Select the interface from the device that is connected to the subnet or the closest subnet the host is on.
      • Server port to query – The port that you want your device to collect the fingerprint from or you can choose Get Active Ports.
    • OS Metadata:
      • Vendor string – Enter the operating system’s vendor name.
      • Product string – Enter the operating system’s product name.
      • Version string – Enter the operating system’s version number.
    • Vulnerability Mapping:
      • Vendor, product, version info – You can define the operating system’s vendor, product, and optionally, version details (major, minor, revision, build, patch, extension) to enable vulnerability correlation. At minimum, specifying the Vendor and Product is required for the fingerprint to be used in vulnerability mapping—especially if no custom OS display is defined. You can leave version fields blank to apply the mapping broadly, but note that without any mappings, the fingerprint won’t trigger vulnerability associations for matched hosts.
      • Optional: build, patch, and extension fields

This enables Secure Firewall to accurately classify the device during passive discovery and align it with correct vulnerability data for risk scoring.

 

 

Defining a Custom Network Topology

If you want greater control over how your network structure is represented, you can also define a Custom Topology within the Network Discovery Policy. This is particularly useful for administrative clarity, audit documentation, and environments where automatic discovery is incomplete or undesirable.

  • Navigate to Policies > Network Discovery → Click Custom Topology (next to Custom Operating Systems)
  • Click the Create Topology button

 

  • You’ll then be able to:
    • Define named topologies and give it an optional description

 

  • From here you can click on the Import Policy Networks button to import to load a network from the current Network Discovery policy

 

  • You may also add subnets manually by clicking on the Add Network button.
  • This is especially helpful for:
    • Documenting physical or logical network design
    • Segmenting discovery views by business function or geography
    • Manually correcting discovered topology data

 

Why Custom OS and Topology Matter

These advanced features may not be required for every deployment—but in complex or highly regulated environments, they provide critical visibility and clarity:

  • Custom OS detection improves vulnerability accuracy and reduces false positives.
  • Manual topology labeling helps security teams understand traffic paths, enforce segmentation, and detect lateral movement faster.

When used in tandem with host and user discovery, NetFlow integration, and impact-based IPS assessments, Cisco Secure Firewall becomes a centralized platform for contextual, threat-informed network visibility.

 

 

Viewing Host Discovery Data

Once you’ve configured your Network Discovery Policy, you’ll want to analyze the results—who’s on the network, what devices they’re using, and what applications they’re running. Cisco Secure Firewall gives you rich visibility into this data through the Network Map and Host Profile views.

Navigating to the Network Map

  • To view all discovered hosts, go to Analysis > Hosts > Network Map

 

  • This interface displays all hosts that have been passively discovered through monitored traffic. It includes IPv4, IPv6, and MAC-level host segmentation.

 

  • You can drill down on individual hosts for deep inspection.

 

Host Profile Overview

  • Clicking on any host IP address opens a detailed Host Profile, which aggregates all intelligence Secure Firewall has gathered for that system. This includes:

 

 

 

    • IP address and MAC
    • NetBIOS name
    • Device Hop count
    • Current user identity
    • Operating system and version
    • Running applications
    • Active services/ports
    • Historical user logins
    • Device type classification
    • Event navigation shortcuts

This data helps correlate network activity with identity and asset posture, which is crucial for threat hunting, incident response, and policy tuning.

 

Jumping to Related Events

From within the Host Profile, you can immediately pivot to related event data:

  • Context Explorer
  • Connection Events
  • Intrusion Events
  • File Events
  • Malware Events

Clicking on any of these filters your event view to only show data related to that specific host. This streamlined access makes it easy to trace malicious behavior or network anomalies tied to a particular device.

 

Host Actions: Scan or Whitelist

Administrators can take additional actions from within the Host Profile:

  • Scan Host: Initiates an active probe (if permitted) to gather more details
  • Generate Whitelist Profile: Creates a baseline “known-good” profile to compare against anomalies or apply trusted filters

These features are especially helpful for managing secure zones, known endpoints, or troubleshooting endpoint classification issues.

 

Scheduling Active Nmap Scans

While passive discovery is the cornerstone of Cisco Secure Firewall’s visibility, you can also configure active scanning using Nmap to supplement your host data. This is especially helpful for verifying services, open ports, or operating systems in dynamic or untrusted environments.

Step 1: Navigate to the Scanner Configuration

  • To start, go to Policies > Actions > Scanners

 

  • From here, click Add Nmap Instance to configure your scanning engine.

 

Step 2: Add and Configure an Nmap Instance

  • You’ll be prompted to provide:
    • Instance Name
    • Optional Description
    • Blacklist for excluded subnets or hosts
    • Optionally exclude the Secure Firewall Management Center itself
  • Click Create to save.

 

Step 3: Add a Remediation of Type “Nmap Scan”

  • Once your Nmap instance is saved, you’ll see a new section for Configured Remediations.
  • Click Add, and select Nmap Scan as the remediation type.

 

Step 4: Customize Scan Options

  • You’ll have full control over scan behavior, including:
    • Scan direction (source, destination, or both)
    • Scan type:
      • TCP Connect
      • TCP SYN
      • TCP ACK
      • Window, Maimon, etc.
    • Host discovery method (TCP SYN recommended)
    • Service/version detection
    • OS detection
    • Timing template (higher number = faster scan)
    • Port ranges, e.g. U:1-1024,T:1-1024
  • Click Create once configured.
  • Click Save on the Edit Instance menu.

 

Step 5: Launch Scan or Schedule It

  • After the remediation is created, you can:
    • Manually initiate the scan from the Nmap instance
    • Or, schedule it to run automatically at desired intervals
  • You’ll be prompted to enter IP ranges and ports for the scan.
  • Note: When you choose the Scan Host option under the Host Profile, you can choose the Nmap Instance you configured.

 

Step 6: Automate with Scheduled Tasks (Optional)

To set up recurring scans:

  • Go to System > Tools > Scheduling

 

  • Click Add Task

 

  • Select Job Type: Nmap Scan
  • Choose the remediation instance you created
  • Define start time and recurrence
  • Click Save to schedule the task.

 

Use Cases for Scheduled Scanning

  • Verify passive host fingerprinting
  • Discover unmanaged services or rogue ports
  • Feed validated OS/app info into IPS and correlation rules
  • Cross-check VLAN segmentation by service exposure

By combining scheduled Nmap scans with the passive telemetry of Network Discovery, you create a rich, validated asset intelligence layer that improves the accuracy of IPS, IOC detection, and access control decisions.

 

 

Generate Allow List Profile

In Cisco Secure Firewall, shared host profiles allow you to reuse the same host evaluation criteria across multiple compliance allow lists, especially for hosts running a specific operating system. This streamlines policy management when evaluating similar hosts in different contexts. In multidomain deployments, you can view and edit shared host profiles created within your current domain, but profiles from ancestor domains are read-only. To modify shared host profiles from a lower domain, you must switch to that domain directly.

  • Click on the Generate Allow List Profile button on the Host Profile.
  • Here you can confugure the allowed application profiles, allowed clients, allowed web applications, allowed protocols, and target network on this allowed profile.

 

  • Click Save All Profiles once you complete your configuration.

 

 

Host Profile Subsections: What You Can Learn

After discovering hosts through Network Discovery, Secure Firewall builds a comprehensive Host Profile. But the true power lies in its ability to break that data down into actionable intelligence using dedicated tabs and contextual views. Each discovered host in the Network Map contains a variety of subsections that present enriched telemetry and threat data:

  • Indications of Compromise (IOC) – Identifies suspicious activity or confirmed threats related to the host.
  • Operating System – Lists detected OS vendor, product, and version.
  • Servers – Shows open ports and the application-layer services running.
  • Applications – Provides protocol-specific application insights like POP3, HTTP, RDP, etc.
  • User History – Tracks login activity over time, mapped to specific users.
  • Attributes – Includes classification metadata like criticality or trust level.
  • Host Protocols – Identifies transport or application protocols used (e.g., TCP, UDP).
  • Vulnerabilities – Displays potential vulnerabilities based on discovered OS/app versions. (Note: Not all are exploitable—the system may already be patched.)

Important: These vulnerabilities are used by the IPS engine to auto-prioritize threats. If a host is flagged as vulnerable to a specific signature, the IPS will inspect for it more aggressively.

 

User History: Behavioral Timeline

You can track which users logged in from a host across time, useful for tracing lateral movement or credential usage.

This can be viewed directly within the Host Profile > User History tab.

 

Host Cleanup: Purging Old Entries

If you’re looking to manage storage or remove outdated entries:

  • Use Tools > Data Purge from the FMC

 

  • Select and delete host records or events en masse

Although you can remove individual hosts from the Network Map, the purge tool is faster for bulk cleanup.

 

Additional Host Tabs

Secure Firewall further segments discovered endpoints into the following views:

  • Network Devices Tab – Shows infrastructure gear like switches, routers, APs.
  • Mobile Devices Tab – Displays phones, tablets, and other mobile clients discovered through DHCP, mDNS, or traffic patterns.

 

 

Indicators of Compromise (IOC)

The Indications of Compromise tab provides a threat-centric view of discovered hosts. You can group and investigate hosts by types of threats they’ve triggered, such as:

  • Malware Detected
  • C2 (Command and Control) Connection
  • Exploit Attempts

This makes it easy for analysts to prioritize endpoints under active compromise, reducing the dwell time of adversaries.

 

Vulnerabilities Tab – Threat Context at a Glance

 

In the Vulnerabilities tab of the Network Map, Secure Firewall provides detailed information about potential CVEs linked to that host. You can drill down by Vulnerability ID, view descriptions, severity, and align remediation or IPS tuning strategies accordingly.

These entries are often generated via passive fingerprinting and enhanced by third-party mappings. Remember, not all flagged vulnerabilities are exploitable—administrators should verify patch state as part of the triage process.

Cisco Secure Firewall’s Host Profile architecture isn’t just about collecting data. It’s about presenting that data in clear, actionable slices for operations, security, and compliance. By using views like IOC, Vulnerabilities, and User History, you gain critical insight into what’s happening on your network –  who’s involved, what’s running, and what’s at risk.