FMC Policies, Objects, and Deployment

Introduction

Firewall Management Center (FMC) is the centralized brain behind Cisco Secure Firewall deployments. While individual Firewall Threat Defense (FTD) devices handle traffic inspection and enforcement, it is FMC that defines what those devices enforce — through policies, objects, and carefully orchestrated deployment workflows.

In this lesson, we focus on how FMC organizes access control policies and reusable objects, how the deployment pipeline pushes configuration to managed devices, and how modern tooling like the Policy Analyzer and Infrastructure as Code (IaC) workflows streamline day-two operations. By the end, you will understand how to structure policies effectively, leverage object reuse, optimize rulesets with built-in analysis tools, and automate configuration through Terraform — all critical skills for the CCNP Security track.

---

Key Concepts

FMC Domain and Object Hierarchy

FMC organizes its entire configuration under a domain model. The top-level domain is called Global, and beneath it you define all the building blocks that policies reference. The object hierarchy inside FMC follows a logical data structure:

Category	Examples
Objects	Hosts, Networks, Ports
Policies	Access Control, Intrusion, Prefilter
Devices	Standalone FTD, Clustered FTD
System Settings	Platform policies, health policies

Every controller or device configuration follows a well-defined data structure. That data must be both human-readable and machine-readable — a principle that becomes especially important when you move toward automation.

Core Object Types

Objects are reusable definitions that policies reference. Instead of hard-coding IP addresses or subnets into every rule, you create an object once and reference it across multiple policies. Key object types include:

• Host objects — represent a single IP address (e.g., 10.64.100.200)
• Network objects — represent a subnet (e.g., 10.64.100.0/24)
• Network groups — bundle multiple host objects and network literals together into a single referenceable group
• Port objects — define protocols and port numbers for service matching

Access Control Policy (ACP)

The Access Control Policy is the primary policy type in FMC. It determines which traffic is permitted, blocked, or inspected. ACP rules can match on a variety of criteria including application, user identity, and Security Group Tags (SGT). Rules are evaluated top-down, and each rule references objects for source, destination, ports, and other match criteria.

Prefilter Policy

The Prefilter policy operates before the ACP and handles traffic that needs early-stage decisions — typically tunnel traffic or traffic that should bypass deep inspection entirely. In emergency scenarios where management connectivity is lost, FTD supports CLI-based prefilter configuration as part of the recovery CLI.

---

How It Works

Policy Deployment Workflow

When you create or modify policies in FMC, those changes exist only on the management center until you explicitly deploy them to managed FTD devices. The deployment process packages the updated policy configuration and pushes it to each target device. This separation between "staged" and "deployed" configuration gives administrators a review window before changes take effect on the network.

Starting with FMC 7.7, the upgrade and deployment experience has been significantly improved. A new Upgrade Wizard provides a single landing page where you can complete the entire upgrade process without leaving the product. Backup time has been reduced by 75 percent, and the need for a separate readiness check before upgrade has been eliminated — bringing the upgrade down to a three-click process on FMC. Upgrade image sizes have been reduced by 25 percent, and devices can now perform a direct pull of the image in a single click.

Recovery CLI for Emergency Changes

When management connectivity between FTD and FMC is unavailable, a Recovery CLI allows emergency local configuration changes directly on the firewall. This capability is always available but is intended strictly for FMC-down emergencies. The Recovery CLI currently supports changes to:

• Static routes
• Dynamic routing (BGP and OSPF)
• Prefilters
• Site-to-site VPN
• Interface configurations

Once the firewall reconnects to FMC, a manual reconciliation step is required to synchronize the locally applied changes with the central manager's configuration database.

Policy Analyzer and Optimizer

Available in FMC 7.6 and later, the Policy Analyzer and Optimizer provides an expanded set of ACP rule conflict and anomaly detection. It identifies:

• Partially overlapping (shadowed) rules — where a broader rule above prevents a more specific rule from ever matching
• Fully redundant objects and rules — duplicate definitions that add complexity without value
• Expired time-based rules — rules with time ranges that have passed
• Unused rules — rules with zero hit counts that may be stale
• Mergeable rules — similar adjacent rules that can be consolidated into one

All detected conflicts support user-supervised automated remediation. The system can remove fully redundant objects and rules, clean up unused and expired rules, and merge similar adjacent rules — but only after the administrator reviews and approves each action. This ensures no accidental policy changes slip through.

Best Practice: Run the Policy Analyzer regularly after any major policy change. Accumulated redundant and shadowed rules degrade both security posture and firewall performance.

AI-Powered Assistance

FMC 7.6 and later includes an AI Interactive Assistant within the management interface. Additionally, through Security Cloud Control, AI Ops and Insights capabilities provide features such as:

• Capacity planning for Remote Access VPN (RAVPN) — predictable headend capacity analysis that stops capacity issues before they occur
• Best practice recommendations — hundreds of best practices applied in real time from a TAC-curated database
• Elephant flow detection — quick identification and remediation of elephant flows before they cause network issues

---

Configuration Example

Defining Objects and Network Groups with Terraform

FMC supports Infrastructure as Code workflows through Terraform. The Terraform FMC provider uses resources — the most important element in the Terraform language. Each resource block describes one or more infrastructure objects such as network objects, device configurations, or access control policy configurations.

Below is an example of defining a network group that contains both a host object reference and a network literal:

resource "fmc_network_groups" "example" {
  items = {
    My_Net_Grp1 = {
      objects = [
        {
          id = data.fmc_host.example.id
        }
      ]
      literals = [
        {
          value = "10.1.1.0/24"
        }
      ]
    }
  }
}

This resource creates a network group called My_Net_Grp1 that references an existing host object (resolved via data.fmc_host.example.id) and includes the 10.1.1.0/24 literal network.

YAML-Driven Data Model with the Terraform FMC Module

The Terraform FMC Module supports an inventory-driven approach where the entire FMC configuration — or parts of it — is modeled in YAML files. Existing objects are declared separately from desired-state objects:

existing:
  fmc:
    domains:
      - name: Global
        objects:
          hosts:
            - name: Gateway

fmc:
  domains:
    - name: Global
      objects:
        network_groups:
          - name: My_Net_Grp1
            objects:
              - Gateway
            literals:
              - 10.1.1.0/24

The module reads this YAML input, resolves the existing Gateway host object by looking up its ID, and generates the appropriate Terraform plan. The resulting plan output shows exactly what will be created:

# fmc_network_groups.example will be created
+ resource "fmc_network_groups" "example" {
    + id    = (known after apply)
    + items = {
        + "My_Net_Grp1" = {
            + id       = (known after apply)
            + literals = [
                + { value = "10.1.1.0/24" },
              ]
            + objects  = [
                + { id = "005056B0-A31C-0ed3-0000-004294967348" },
              ]
          },
      }
  }

Desired State vs. Actual State

Terraform maintains a state file that records the actual state of managed infrastructure. The workflow operates in three phases:

1. Terraform Refresh — polls the current/actual state from FMC
2. Terraform Plan — compares desired state (your .tf files) against actual state and computes the delta
3. Terraform Apply — pushes only the delta changes to FMC and updates the state file

Warning: Never manually change infrastructure that Terraform manages, and never modify the state file directly. Doing so creates drift between desired and actual state that can cause unpredictable behavior on the next apply.

---

Real-World Application

Enterprise Policy Management at Scale

In production environments with dozens of FTD devices, FMC's centralized policy model is essential. You define ACP rules, prefilters, and intrusion policies once on FMC and deploy them uniformly across all managed firewalls. Object reuse ensures consistency — when a subnet changes, you update one network object and redeploy rather than editing every rule individually.

Zero Trust Network Access

FMC 7.7.1 introduces Universal Zero Trust Network Access (ZTNA) that bridges on-premises and cloud enforcement. The architecture works as follows: Secure Access provisions private firewall instances with appropriate access policies. Secure Client on remote user endpoints creates a control connection to Secure Access for authentication and authorization. Per-application tunnels to private applications are automatically directed to the closest FTD instance for full threat inspection. This provides unified management with distributed enforcement, and dynamic steering of traffic through the nearest enforcement point via Trusted Network Detection (TND).

Infrastructure as Code for Firewall Automation

Organizations adopting DevOps practices use the Terraform FMC modules to manage firewall configuration alongside their application infrastructure. The Network as Code approach reduces time to value by lowering the barrier of entry to network orchestration through simplification and abstraction. Users describe the intended configuration in YAML while the modules handle object references, dependencies, and ordering automatically. This eliminates the need to understand the low-level FMC object model or manually track object IDs.

Workload Segmentation

For data center environments, Secure Workload provides micro-segmentation across container, bare-metal, and virtual machine workloads. Integration with NVIDIA DPUs adds advanced micro-segmentation in hybrid cloud environments with expanded inter-application visibility through a resident workload agent, with future capabilities for inline inspection and crypto acceleration.

---

Summary

• FMC centralizes policy and object management across all managed FTD devices, with a clear separation between staged configuration and deployed state.
• The Recovery CLI provides emergency local configuration capability for static routes, dynamic routing, prefilters, VPN, and interfaces when FMC connectivity is lost — followed by manual reconciliation upon reconnection.
• The Policy Analyzer and Optimizer (FMC 7.6+) detects shadowed rules, redundant objects, expired rules, unused rules, and mergeable rules — with user-supervised automated remediation.
• Terraform integration enables Infrastructure as Code workflows where FMC configuration is defined declaratively in YAML or HCL, with a clear desired-state-versus-actual-state model.
• Universal ZTNA (FTD 7.7.1) provides consistent zero trust access across hybrid environments with dynamic traffic steering to the nearest enforcement point.

In the next lesson, we will explore advanced threat defense features including intrusion policy tuning and malware defense integration within the Secure Firewall platform.