Skip to main content

Cisco FMC

Visualize your Cisco Secure Firewall Management Center (FMC) deployment in JupiterOne — the FTD firewalls it manages, the access control and NAT policies assigned to each device and the rules inside them, and the hosts and network vulnerabilities discovered by FMC network discovery — so you can see which rules apply to which firewall, find exposed services and vulnerable hosts, and monitor changes through queries and alerts.

Installation​

This integration connects to your on-premises Cisco Secure Firewall Management Center (FMC) using the FMC REST API and ingests managed FTD devices, access control policies and their access rules, FTD NAT policies and their NAT rules, and the hosts and vulnerabilities discovered by FMC network discovery. The FMC is usually on your own network, so the integration normally runs on a JupiterOne Collector that can reach the FMC over HTTPS.

Cloud-delivered FMC (cdFMC) is not supported. The integration only works with an on-premises or virtual FMC appliance.

Configuration in Cisco FMC​

Before you configure the integration in JupiterOne, prepare the following in your FMC:

  • The base URL of your FMC, for example https://fmc.example.com. The JupiterOne Collector must be able to reach it.

  • The REST API enabled. It is enabled by default; to confirm, choose System > Configuration > REST API Preferences and check that Enable REST API is selected.

  • A dedicated FMC user for the integration, with a read-only role that can use the REST API and view devices, access control policies, NAT policies, and network discovery hosts and vulnerabilities. The integration only makes read (GET) requests, plus the POST that generates its access token.

    Do not reuse an account that people sign in to the FMC web interface with. FMC does not allow the same credentials to be used for the web interface and the REST API at the same time, and logs the other session out without warning. Cisco also recommends keeping UI users and API users separate and not using an admin account for the API.

  • The username and password of that user. The integration sends them as HTTP Basic authentication to POST /api/fmc_platform/v1/auth/generatetoken and then uses the returned X-auth-access-token for every other request. Access tokens are valid for 30 minutes; the integration requests a new one automatically when a token expires during a run.

  • If the FMC presents a self-signed or internal-CA TLS certificate, get the CA certificate in PEM format so the collector can verify the connection.

Once you have obtained the information above, proceed to JupiterOne to finalize the integration.

Configuration in JupiterOne​

To install the Cisco FMC integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Cisco FMC. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Cisco FMC account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The FMC Base URL of your on-premises FMC, for example https://fmc.example.com (required).

  • The API Username and API Password of the dedicated read-only FMC user created above (required).

  • Optionally, a CA Certificate to trust a self-signed or internal-CA certificate, or enable Disable TLS Verification to skip certificate validation (not recommended).

When you save the instance, JupiterOne validates the credentials by requesting an access token from the FMC.

Data Sources​

Each data source can be enabled or disabled on its own. All data sources are disabled by default, so enable the ones you want to ingest. The account (cisco_fmc_account) and service (cisco_fmc_service) entities are always created.

Data SourceDescriptionEntities Created
Managed DevicesFTD devices managed by the FMC, with hostname, model, software version, FTD mode, health status, and deployment statuscisco_fmc_device
Access Control PoliciesAccess control policies with their default action, and the access rules inside each policy (action, enabled state, logging, source and destination networks and ports, and applications)cisco_fmc_access_policy, cisco_fmc_access_rule
NAT PoliciesFTD NAT policies and their auto and manual NAT rules (NAT type, section, original and translated source, and source and destination interfaces)cisco_fmc_nat_policy, cisco_fmc_nat_rule
Discovered HostsHosts discovered by FMC network discovery, with IP and MAC addresses, hostname, operating system, exposed services, and detected applicationscisco_fmc_host
Host FindingsNetwork vulnerabilities (CVEs) that FMC network discovery detected on hosts, one finding per CVE, host IP address, and portcisco_fmc_host_finding

The relationships between data sources are built only when both sides are enabled:

  • Device to access control policy (ASSIGNED) requires Managed Devices and Access Control Policies.
  • Device to NAT policy (ASSIGNED) requires Managed Devices and NAT Policies. Only policies assigned directly to a device are linked; NAT policies assigned to a high-availability pair or a cluster are not linked to the member devices.
  • Discovered host to host finding (HAS) requires Discovered Hosts and Host Findings. Findings are matched to hosts by IP address.

The integration does not create relationships to entities from other integrations.

Keep the following in mind:

  • Only one FMC domain is ingested. The integration collects the domain that the FMC returns for the API user when it signs in (the DOMAIN_UUID of the token response) and does not enumerate or query any other domain.
  • "Access lists" means access control policies and their rules. Extended ACL objects are not ingested.
  • Host findings carry no severity or CVSS score. The FMC network map does not return one, so every finding is ingested with severity: informational and numericSeverity: 0, along with its cveId and an NVD reference link.
  • Large deployments take a while. Cisco documents a REST API limit of 120 GET requests per minute from a single IP address. The integration paces all of its requests just below that (about 114 per minute) on every FMC release, requests up to 1000 objects per page, and fetches access and NAT rules one policy at a time, so a run against a FMC with many policies, rules, or discovered hosts can take a long time.

Click Create once all values are provided to finalize the integration.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​