Data Collector

What Is a Data Collector?

A Data Collector is a FireMon Security Manager component that connects to firewalls and other network devices to retrieve configurations, monitor changes, and collect usage logs. It communicates with devices over protocols like SSH, REST API, and syslog, then normalizes and sends that data back to Security Manager for policy analysis, auditing, and reporting.

Key takeaways

• Retrieves device configurations, changes, and usage logs using read-only or network-operator credentials, so it never pushes changes to a device.
• Devices are assigned to a Data Collector Group, which can hold multiple collectors working together to retrieve data on a schedule or when changes occur.
• Relies on device packs, FireMon-specific software packages that define how to communicate with and parse data from a given vendor's device.
• Keeps Security Manager's policy analysis, change detection, and reporting current by feeding it fresh, normalized device data.

Why It Matters

Teams managing firewalls across multiple vendors need a reliable, automated way to pull configurations and usage data without logging into every device by hand. Without a dedicated collection layer, admins would have to script retrievals per vendor, manage credentials manually, and reconcile what changed and when on their own. The Data Collector handles that work so every device's rule base, object definitions, and traffic logs reach Security Manager on a predictable schedule, giving the team a trustworthy source of truth for policy decisions, change tracking, and audit evidence.

How It Works

When a device is onboarded in Security Manager's Administration module, it's assigned to a Data Collector Group — the collector or group of collectors responsible for retrieving its configuration. The Data Collector connects to the device using the protocol its device pack specifies, commonly SSH, a vendor's REST API, or syslog, and does so with a read-only or network-operator account built only to retrieve data, not change it. Devices can also be configured to send syslog messages to the Data Collector so it can detect configuration changes and collect usage data for rule hit-count analysis. Retrievals run on a schedule, after a detected change, or on demand. Before posting a new revision to Security Manager, the Data Collector can perform change verification to confirm something actually changed, which keeps storage use efficient. Collected data is then normalized using the device's device pack so Security Manager can compare rules and objects across different vendors in a consistent format.

A Realistic Example

Picture a team running Cisco Nexus switches, Palo Alto Panorama-managed firewalls, and a Fortinet FortiManager deployment. Each vendor's devices send syslog or API data to a Data Collector assigned through a Data Collector Group. One collector retrieves Nexus configurations over syslog and SSH, while another pulls Panorama's managed firewalls over SSH and the REST API. Each uses its own read-only account, so none of the three vendors' management consoles ever see a write operation coming from the collection process. The team never touches a vendor console to run a manual backup or export a rule base; it all arrives in Security Manager the same way, on the same schedule, ready to compare.

The Operational Consequence

When a Data Collector goes down, loses credentials, or can't validate the certificate presented by the Security Manager server, retrievals fail until someone checks device status. That means stale configurations, missed changes, and incomplete usage data feeding into reports and audits. Because change monitoring, policy normalization, and even rule documentation updates in Security Manager depend on fresh device data, a healthy, properly scaled set of Data Collectors is what keeps policy visibility and audit evidence current rather than days or weeks out of date.

Key Components and Best Practices

• Data Collector Groups: logical groupings of collectors assigned to devices. Best practice is an odd number, such as three or five, per group, with collectors kept in the same data center for reliability.
• Device packs: vendor-specific packages that tell a Data Collector how to communicate with and parse data from a given device type; they're updated as vendors change their software.
• Credentials: read-only or network-operator accounts dedicated to retrieval, kept separate from any accounts used for policy automation.
• Monitoring settings: change monitoring, log monitoring, and scheduled or check-for-change retrieval intervals that control how often data comes in.

Common Challenges

Scaling collectors to match device count and network topology takes planning. Too few collectors in a group can create retrieval bottlenecks, and placing collectors far from their devices can introduce latency or connectivity issues. Remote Data Collectors deployed where DNS isn't available need extra certificate configuration to join the Security Manager ecosystem securely, since the Data Collector enforces strict validation of the certificate presented by the server. Expired credentials on a monitored device are also a common cause of failed retrievals, since the Data Collector will never attempt to update its own device access automatically.

How It Connects to Network Security Policy Management and FireMon

Data Collectors are the retrieval layer underneath FireMon's broader policy visibility and control. Policy is the Control Plane for Network Security, and that control starts with accurate, current data about what's actually configured on every firewall, cloud security group, and segmentation platform in the environment. FireMon, the founder of NSPM, built the Data Collector as a core piece of Security Manager's distributed architecture so that policy analysis, change detection, and compliance reporting are always working from current device state rather than guesswork. For the broader discipline this supports, see FireMon's Network Security Policy Management glossary page.