Security & Data Protection
This page summarizes how the Connector and the OVA appliance are secured, what data they retain locally, and how to decommission an appliance.
Network posture
The Connector makes outbound-only connections — see Network Requirements for the full destination list. Nothing needs to connect to it. The OVA appliance additionally runs a host firewall with a default-deny inbound policy and ships with SSH disabled, so it presents no listening network service at all.
Transport security
Every connection the Connector makes — to FireMon Connect and to the update service — uses TLS with full hostname and certificate validation. There is no option to disable certificate validation on the FireMon-facing connections. (Connecting to an on-prem integration with a self-signed certificate, such as a lab Panorama, is a separate, explicit, opt-in setting on that integration — see Integrations.)
Log forwarding
The Connector writes structured logs locally (see Installation — where logs live) and also forwards entries at INFO level and above to FireMon, over the same outbound TLS connection to api.prod.firemon.cloud it uses for job traffic. This lets FireMon Support diagnose a Connector without asking you to collect files off the appliance.
Forwarded entries contain operational data: hostnames, IP addresses, and the names of objects the Connector reads or writes — Connect Groups, Panorama device groups and Dynamic Address Groups, NSX Groups, Infoblox networks. The Connector does not log its API key, and does not log the credentials you provide for on-prem integrations.
Forwarding is on by default and has no separate off switch. Raising the Connector's log level — FIREMON_LOG_LEVEL=WARN, or logLevel in its config file — reduces what is written locally and therefore what is forwarded.
Pairing and credentials
- Pairing uses a short-lived (24-hour), single-use registration code you generate in Connect. The code is consumed the moment it's used, so it can't be replayed.
- Once paired, the Connector authenticates with an API key issued by FireMon. The key is written to a local credentials file that is readable only by the account running the Connector (
0600permissions on Linux/macOS), and is not written to logs. - Removing the Connector from Settings > Connectors in Connect immediately revokes its API key — this is the authoritative way to cut off a Connector's access.
The OVA appliance
The appliance is a minimal, hardened Ubuntu Linux VM built specifically to run the Connector:
- No default passwords, SSH locked down. The base image ships with no default credentials, and SSH is disabled — there's no network-facing login surface.
- Runs as a restricted, non-root service account with a locked-down filesystem and Linux capabilities dropped to the minimum the Connector needs.
- Security updates apply automatically, including a maintenance-window reboot for updates that require one, so the OS stays current without manual intervention.
- Console access is equivalent to root/physical access, the same as most virtual appliances. Because the appliance has no default password and no network login service, the console is its only administrative path — so restrict who can open it the same way you'd restrict physical access to a device. In vSphere, scope the Console Interaction privilege to the administrators who should have it. See Deploying the OVA appliance.
- Every self-update is cryptographically signed and verified before it's installed — see Updates.
What the appliance stores locally
Job and inventory data (from Panorama, Infoblox, etc.) is processed in memory and is never written to disk. What does persist:
| Contents | Sensitive? |
|---|---|
| API key, Connector ID, client ID | Yes — API key |
| Environment, version, and log/update settings | No secrets |
| Rotated local logs (~50 MB cap) | Operational data (IPs, object names) — no credentials |
The credentials file is restricted to the service account that runs the Connector (0600 on Linux/macOS) and is not additionally encrypted at the application level.
For sensitive deployments, enable vSphere VM or datastore encryption on the Connector VM. This protects the disk — and every snapshot or backup taken from it — against theft of the underlying storage, which is a more effective control for a VM appliance than application-level encryption (a key stored on the same disk protects little against someone who already has the disk).
Snapshots and backups
A vSphere snapshot or backup of the Connector VM captures the API key and local logs. Treat Connector snapshots and backups as sensitive, access-restricted material — the same as the running appliance. If you can't use datastore encryption and snapshots are unavoidable, decommission the appliance (below) — which revokes the API key server-side — before archiving or exporting a snapshot.
Decommissioning an appliance
Revoking the API key server-side is the control that actually matters. Once revoked, a leaked disk, snapshot, or backup is worthless — the key no longer authenticates anything. Follow all three steps for a clean decommission:
-
Revoke server-side (required). In FireMon Connect, open Settings > Connectors, find the Connector, and remove it. This deletes its API key immediately.
-
Wipe local state (defense-in-depth). On the appliance, stop the service and run the built-in decommission command:
sudo systemctl stop firemon-connector.servicesudo -u firemon-connector /usr/local/bin/firemon-connector --decommissionThe command lists what it's about to remove — the credentials file, its quarantined
credentials.json.invalidsibling if one exists, and the log directory — and then requires you to type the worddecommissionto proceed; anything else cancels. Add--yesto skip the prompt for scripted use. It does not revoke the Connector server-side — that's step 1. -
Delete the VM, including its datastore files and any snapshots or backups taken from it.
Steps 1 and 3 are sufficient on their own — a deleted VM whose key has been revoked leaks nothing usable. Step 2 covers the window between revocation and disk deletion, and any disk image that outlives the VM.