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; every session starts from inside your network. See Network Requirements for the full destination list and the appliance's inbound posture.

Transport security

Every connection the Connector makes to Connect and to the update service uses TLS with full hostname and certificate validation, and that validation is always on. Connecting to an on-prem integration with a self-signed certificate, such as a lab Panorama, is a separate 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 Connect, in batches over HTTPS to the same API endpoint (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, FMC dynamic objects and domains, FortiManager ADOMs, address objects, policy packages and devices, 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 the log level is the control you have over it. 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 Connect. The key is written to a local credentials file that is readable only by the account running the Connector (0600 permissions on Linux/macOS; on Windows the file relies on the permissions of %LocalAppData%), 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 revoke 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, no SSH. The base image ships with no default credentials, and SSH is disabled, so there is 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 access, as with most virtual appliances. Because the appliance has no default password and no network login service, the console is its only administrative path. 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, and so on) is processed in memory and not written to disk, with one exception: so a long Infoblox discovery can resume, the Connector saves the Infoblox references of the networks it has already read, which name each network's address range. What persists:

Contents	Sensitive?
API key and Connector identity	Yes (the API key)
Environment, version, and log/update settings	No secrets
Rotated local logs (~60 MB cap)	Operational data (IPs, object names); no credentials
Working state: Infoblox discovery progress, Panorama pushes waiting to retry, and downloaded updates waiting to install	Counts, timestamps, and Infoblox network references; no secrets

The credentials file relies on those file permissions (0600 on Linux/macOS, restricted to the service account that runs the Connector) rather than application-level encryption.

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. For a VM appliance this is more effective than application-level encryption, since a key stored on the same disk offers little protection once the disk is stolen.

Snapshots and backups

A vSphere snapshot or backup of the Connector VM captures the API key and local logs. Restrict access to snapshots and backups the same way you restrict access to the running appliance. If you can't use datastore encryption and snapshots are unavoidable, decommission the appliance (below) before archiving or exporting a snapshot; decommissioning revokes the API key server-side.

Decommissioning an appliance

Revoking the API key server-side is the critical step. Once the key is revoked, the copy of it on any leaked disk, snapshot, or backup no longer authenticates to Connect. Follow all three steps for a clean decommission:

1. Revoke server-side (required). In Connect, open Settings > Connectors, find the Connector, and remove it. This deletes its API key immediately.

2. Wipe local state (defense in depth). On the appliance, stop the service and run the built-in decommission command:

   sudo systemctl stop firemon-connector.service
   sudo /usr/local/bin/firemon-connector --decommission

   The command lists what it's about to remove (the credentials file, its quarantined credentials.json.invalid sibling if one exists, and the log directory) and then requires you to type the word decommission to proceed; anything else cancels. Add --yes to skip the prompt for scripted use. Configuration and working state stay, since they hold no secrets. It does not revoke the Connector server-side; that's step 1.

3. 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.