Cisco Firewall Audit

Cisco ASA / FTD Firewall Security Policy Audit

Policy-audit-driven analysis covering both Cisco ASA (classic) and Firepower Threat Defense (FTD). Unlike generic firewall checklists that check for open ports and default-deny, this skill evaluates the platform-specific security architecture: ASA security levels with interface-bound ACLs and Modular Policy Framework, or FTD Access Control Policy with Snort IPS integration and Firepower Management Center (FMC) orchestration.

Where platforms diverge, sections use [ASA] and [FTD] labels. Shared concepts apply to both platforms unlabeled. Covers ASA 9.x+ and FTD 6.x+ / 7.x+ managed by FMC or FDM. Reference references/policy-model.md for the ASA security-level model and FTD ACP evaluation chain, and references/cli-reference.md for dual-platform read-only commands.

When to Use

• ACL review after rule changes or migration from ASA to FTD
• Annual or quarterly compliance audit requiring per-rule justification
• Post-incident rule assessment to identify how traffic was permitted
• [ASA] Security level and interface ACL gap analysis
• [ASA] Modular Policy Framework audit — verifying inspection maps
• [FTD] Access Control Policy rule ordering and IPS coverage review
• [FTD] Snort IPS policy tuning assessment — false positive vs detection gap balance
• NAT policy validation after network re-addressing or migration
• VPN configuration security review — site-to-site and remote access
• Failover / HA posture verification
• Pre-migration baseline before ASA-to-FTD conversion

Prerequisites

• [ASA] Privilege level 5+ (read-only show commands) or ASDM read-only access
• [FTD] Read-only analyst access to FMC web UI or FMC REST API; Expert shell access for Snort-level diagnostics
• Understanding of the interface topology — which interfaces exist, their security levels ([ASA]), and network segment assignments
• Knowledge of expected access policies per interface pair or zone
• For multi-context ASA: access to system and each security context
• [FTD] Knowledge of IPS policy baseline — which Snort ruleset and network analysis policy are expected
• Active configuration — audit evaluates the running configuration, not pending changes

Procedure

Follow this audit flow sequentially. Each step builds on prior findings. The procedure moves from platform identification through access policy, NAT, inspection/IPS, VPN, and logging.

Step 1: Platform Identification and Architecture Inventory

Determine the platform and collect architectural baseline.

show version

Identify: ASA vs FTD, software version, hardware platform (ASA 5500-X, Firepower 1000/2100/4100/9300, virtual), licensed features.

[ASA] Inventory interfaces, security levels, and context mode:

show interface ip brief
show nameif
show mode

Security levels (0–100) determine implicit traffic flow: traffic from a higher security level to a lower is permitted by default (unless ACLs override); lower-to-higher is denied by default. Record each interface name, security level, and IP address.

For multi-context ASA:

show context
changeto context <name>
show interface ip brief

[FTD] Identify management model and registered devices:

show managers

FTD managed by FMC: policy is pushed from FMC — audit via FMC UI/API. FTD managed by FDM (local): policy configured on-device — audit via FDM web UI or REST API.

Check failover/HA status on both platforms:

show failover
show failover state

Record active/standby status, failover interface, and last failover time.

Step 2: Access Policy Analysis

[ASA] ACL-based access control:

show access-list
show running-config access-list
show running-config access-group

ASA uses interface-bound ACLs. Each ACL is applied inbound or outbound on an interface via access-group. Evaluate:

• ACL evaluation order: Top-down within each ACL. First matching ACE (Access Control Entry) is applied. Implicit deny at the bottom.
• Global ACL: If configured, applies to all interfaces. Interface ACLs are evaluated before the global ACL.
• Overly permissive ACEs: permit ip any any or permit tcp any any entries are Critical findings — they permit all traffic of that protocol.
• Unused ACEs: ACEs with zero hit counts (check show access-list output for hitcnt=0) over 90+ days are cleanup candidates.
• EtherType ACLs: Used on transparent firewall interfaces. Review for overly broad EtherType permits.

show access-list <acl-name> brief

[FTD] Access Control Policy (ACP):

Access the ACP via FMC UI or REST API. The ACP evaluates traffic through a defined chain (see references/policy-model.md). Evaluate:

• Prefilter policy: Hardware-level rules that bypass Snort. Overly broad prefilter Trust rules skip all inspection.
• SSL policy: Determines which TLS flows are decrypted for inspection.
• Access Control rules: Top-down evaluation. Actions: Allow (with or without IPS), Trust (bypass Snort), Block, Monitor.
  • Rules with Action=Allow and no Intrusion Policy pass traffic without IPS inspection.
  • Rules with Action=Trust bypass all further inspection including IPS and file/malware — use only for verified trusted flows.
• Default action: Applied when no rule matches. Should be Block with logging, not Allow.
• Intrusion Policy binding: Each Allow rule can bind an Intrusion Policy (Snort ruleset). Rules without one pass traffic uninspected.

system support diagnostic-cli
show access-control-config

Step 3: NAT Policy Audit

[ASA] NAT order of operations:

show nat
show nat detail
show running-config nat
show xlate

ASA NAT evaluates in three sections:

• Section 1 (Manual NAT / Twice NAT): Explicit rules, top-down. Highest priority. Used for fine-grained control.
• Section 2 (Auto NAT / Object NAT): Per-object NAT definitions. Evaluated after Section 1. Ordering: static rules first, then dynamic.
• Section 3 (Manual NAT after-auto): Low-priority manual rules evaluated after auto NAT. Used for catch-all translations.

Check for NAT rule conflicts — a Section 1 rule that matches the same traffic as a Section 2 object NAT always wins. Verify that static NAT entries for published servers have corresponding ACL entries restricting access.

[FTD] NAT rules in FMC:

FTD NAT follows the same three-section model as ASA but is configured via FMC. Review NAT rules in the FMC NAT policy. Verify:

• Manual NAT rules take precedence over auto NAT
• NAT rules align with ACP rules — ensure translated addresses match ACP source/destination references
• No unnecessary identity NAT rules consuming processing

Cross-reference NAT entries with access policy on both platforms — static NAT that exposes internal servers must have restrictive access rules.

Step 4: Inspection and IPS Assessment

[ASA] Modular Policy Framework (MPF):

show running-config class-map
show running-config policy-map
show running-config service-policy
show service-policy

ASA inspection uses MPF: class-maps define traffic → policy-maps bind inspections → service-policies apply to interfaces. Evaluate:

• Default inspection: ASA enables inspection for common protocols (HTTP, DNS, FTP, etc.) via the global_policy. Verify the global policy is applied (service-policy global_policy global).
• Custom inspections: Additional class-maps/policy-maps for specific traffic patterns. Verify they are applied to correct interfaces.
• Missing inspections: Traffic not matching any class-map in the service-policy receives no application-layer inspection — only ACL enforcement.
• Connection limits: MPF can set connection limits and timeouts. Review for overly permissive or missing connection limits on internet-facing interfaces.

[FTD] Snort IPS and File/Malware policies:

• Intrusion Policy: Each ACP Allow rule can reference an Intrusion Policy that determines the Snort ruleset. Check that internet-facing Allow rules bind an Intrusion Policy.
• Snort rule sets: Verify the base policy (Balanced Security and Connectivity, Connectivity Over Security, Security Over Connectivity, Maximum Detection). For production environments, "Balanced Security and Connectivity" is the minimum recommended baseline.
• Network Analysis Policy (NAP): Controls protocol decoder settings and preprocessor configuration. Misconfigured NAP can cause Snort detection gaps.
• File and Malware Policy: Detects and blocks malware file transfers. Verify binding on rules permitting file-carrying protocols (HTTP, SMTP, FTP, SMB).
• Snort deployment mode: Inline (can block) vs passive (alert only). Production deployments should use inline mode for active prevention.

system support diagnostic-cli
show snort statistics