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.

text

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:

text

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:

text

show context
changeto context <name>
show interface ip brief

[FTD] Identify management model and registered devices:

text

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:

text

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:

text

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.

text

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.

text

system support diagnostic-cli
show access-control-config

Step 3: NAT Policy Audit#

[ASA] NAT order of operations:

text

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):

text

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.

text

system support diagnostic-cli
show snort statistics

Step 5: VPN and Remote Access Audit#

Evaluate VPN configuration security on both platforms.

text

show crypto ipsec sa
show crypto ikev2 sa
show vpn-sessiondb

Check:

• Site-to-site tunnels: Verify IKE version (IKEv2 preferred over IKEv1), encryption algorithms (AES-256-GCM recommended; DES/3DES are findings), DH groups (group 14+ recommended; groups 1/2/5 are weak), and PFS settings.

• Crypto maps / tunnel groups: [ASA] Review crypto map entries and tunnel group definitions. [FTD] Review site-to-site VPN topology in FMC.

• AnyConnect / remote access VPN: If configured, evaluate:

  • Authentication method (certificate + MFA preferred over password-only)
  • Split tunneling settings (full tunnel recommended for security; split tunnel for performance — document the choice)
  • Connection profiles and group policies
  • Client certificate validation settings
  • Banner and session timeout configuration

text

show running-config tunnel-group
show running-config group-policy

• IKE/IPSec SA lifetimes: Very long lifetimes (>24h IKE, >8h IPSec) increase exposure if keys are compromised.

Step 6: Logging and Monitoring#

Evaluate logging configuration and coverage.

[ASA] Syslog configuration:

text

show logging
show running-config logging

• Syslog severity: Verify logging level is set to at least "informational" (level 6) for security-relevant events. Level 5 (notifications) misses connection teardown events. Level 7 (debugging) generates excessive volume.
• Syslog destinations: Verify syslog server(s) are configured and reachable. Check for encrypted syslog (TCP/TLS) for log integrity.
• SNMP: If configured, verify community strings are not defaults and SNMP v3 is used for authentication/encryption.

[FTD] Firepower event logging:

• Connection events: In FMC, verify connection logging is enabled on ACP rules. "Log at End of Connection" is standard; "Log at Beginning" adds volume but provides immediate visibility.
• Intrusion events: Automatically logged by Snort when rules trigger. Verify events are forwarded to the SIEM.
• eStreamer: The Firepower event streaming API for SIEM integration. Verify eStreamer client connectivity if in use.
• Security Analytics / SecureX: If integrated, verify telemetry forwarding is active.

text

show logging
show running-config logging

Verify logging covers: denied connections (ACL denials), permitted connections (for audit trail), VPN events, failover events, and administrative access.

Threshold Tables#

Policy Rule Severity Classification#

FindingSeverityRationale**[ASA]** permit ip any any in interface ACLCriticalPermits all IP traffic — no access restriction**[FTD]** ACP default action set to AllowCriticalAll unmatched traffic permitted without inspection**[FTD]** Prefilter Trust rule with broad match (any/any)CriticalTraffic bypasses all Snort inspection**[ASA]** No global service-policy appliedHighNo application-layer inspection on any traffic**[FTD]** Allow rule without Intrusion Policy bindingHighTraffic permitted without IPS inspection**[FTD]** SSL policy not decrypting internet-bound trafficHighSnort inspects only metadata on encrypted flowsVPN using DES/3DES or DH group 1/2/5HighWeak cryptographic algorithms — vulnerable to attackStatic NAT with no restricting ACLHighPublished server accessible on all portsFailover configured but standby not monitoringHighHA not providing redundancy**[FTD]** Snort in passive mode (production)HighIPS detects but cannot block threats**[ASA]** ACE with hitcnt=0 for >90 daysMediumUnused rule — cleanup candidate**[FTD]** File/Malware policy not bound on file-carrying rulesMediumMalware detection gap on HTTP/SMTP/FTPVPN split tunneling enabledMediumRemote user traffic may bypass corporate security controlsLogging severity below informational (level 6)MediumSecurity events not captured in logs**[ASA]** Security levels equal with same-security-traffic disabledLowTraffic between equal interfaces blocked (may be intentional)

IPS / Inspection Maturity#

CoverageMaturityGuidance**[FTD]** All Allow rules have Intrusion + File/Malware policiesMatureMaintain; tune Snort rules quarterly**[FTD]** Most Allow rules have Intrusion Policy, some gapsDevelopingBind Intrusion Policy to remaining Allow rules**[ASA]** Global inspection policy active, custom maps definedDevelopingEvaluate FTD migration for deeper inspection**[ASA]** Default global_policy only, no custom inspectionsImmatureAdd custom inspection maps for critical protocols

Decision Trees#

Access Policy Gap Remediation#

text

Overly permissive access rule identified
├── Platform?
│   ├── [ASA] permit ip any any in ACL
│   │   ├── Is ACL applied to an interface?
│   │   │   ├── Yes → CRITICAL: All traffic permitted on that interface
│   │   │   │   └── Analyze connections: show conn [interface]
│   │   │   │       → Replace with specific permit entries
│   │   │   └── No → ACL exists but not applied; verify intent
│   │   └── Global ACL?
│   │       └── Applies to all interfaces → assess scope of exposure
│   │
│   └── [FTD] Allow rule without Intrusion Policy
│       ├── What traffic does the rule match?
│       │   ├── Internet-bound → Bind Intrusion Policy (Balanced minimum)
│       │   │   └── Also bind File/Malware policy
│       │   ├── Inter-zone → Bind Intrusion Policy
│       │   └── Trusted internal → Evaluate risk; bind at minimum
│       │
│       └── Is it a Trust rule?
│           ├── Yes → Bypasses ALL inspection
│           │   └── Verify traffic is truly trusted (e.g., backup)
│           │       └── Consider changing to Allow + Intrusion Policy
│           └── No (Allow) → Add Intrusion Policy binding
│
└── Action = Trust vs Allow?
    ├── Trust → Zero inspection; use sparingly
    └── Allow → Inspection possible; bind policies

NAT Conflict Resolution#

text

NAT rule conflict suspected
├── [ASA] Which section is each rule in?
│   ├── Section 1 (Manual) vs Section 2 (Auto) → Section 1 always wins
│   ├── Both in Section 2 → Static evaluates before dynamic; check overlap
│   └── Section 1 vs Section 3 → Section 1 wins; Section 3 may be unreachable
│
├── [FTD] Same three-section model via FMC
│   └── Review NAT policy → identify ordering conflicts
│
└── Verify with packet tracer:
    packet-tracer input <iface> tcp <src> <sport> <dst> <dport>

Report Template#

text

CISCO ASA / FTD SECURITY POLICY AUDIT REPORT
===============================================
Device: [hostname]
Platform: [ASA model / FTD model]
Software: [ASA version / FTD version]
Management: [ASDM / FMC hostname / FDM]
Mode: [routed / transparent] [single / multi-context]
Failover: [active-standby / active-active / standalone]
Audit Date: [timestamp]
Performed By: [operator/agent]

INTERFACE / ZONE SUMMARY:
[ASA]: Interfaces: [count] (security levels: [list]) | Multi-context: [yes/no]
[FTD]: Zones: [count] ([list]) | Managed by: [FMC/FDM]

ACCESS POLICY:
[ASA]: ACLs: [count] | ACEs total: [n] | hitcnt=0 (>90d): [n] | Global service-policy: [yes/no]
[FTD]: ACP rules: [n] (Allow:[n] Block:[n] Trust:[n])
       IPS-bound: [n]/[allow] | File/Malware-bound: [n]/[allow] | Default: [Block/Allow]

NAT: Section 1: [n] | Section 2: [n] | Section 3: [n] | Static: [n] | Conflicts: [n/none]

INSPECTION / IPS:
[ASA]: Service-policy: [applied/missing] | Inspected: [protocols]
[FTD]: IPS policy: [name] | Snort: [inline/passive] | SSL decrypt: [n rules/none]

VPN: Tunnels: [n] | IKE: [v1/v2] | Crypto: [algs] | AnyConnect: [yes/no] | Split: [yes/no]

FINDINGS:
1. [Severity] [Category] — [Description]
   Platform: [ASA/FTD] | Rule: [id] | Interface/Zone: [name]
   Issue: [problem] → Recommendation: [remediation]

RECOMMENDATIONS: [Prioritized by severity]
NEXT AUDIT: [CRITICAL: 30d, HIGH: 90d, clean: 180d]

Troubleshooting#

ASA-to-FTD Migration Assessment#

When evaluating an ASA for migration to FTD, document: ACL count, NAT rules, MPF inspections, VPN configurations (crypto maps don't migrate directly), and multi-context usage (FTD does not support multi-context). The Cisco Firepower Migration Tool provides a baseline but audit the migrated policy for accuracy — automated migration often produces suboptimal rule ordering.

Multi-Context ASA Audits#

Each security context is an independent firewall with its own interfaces, ACLs, NAT, and routing. Audit each context separately via changeto context <name>. Use show context in the system context to list all contexts and show resource allocation for per-context limits.

Large ACLs (>1000 ACEs)#

Export the configuration ( show running-config access-list) and parse programmatically. Prioritize by hit count — high-hit-count ACEs carry the most traffic. Zero-hit-count ACEs over 90 days are removal candidates.

FTD Diagnostic CLI#

FTD runs Snort on top of an ASA-derived data plane. Use system support diagnostic-cli for ASA-style show commands. The canonical policy source is FMC — the diagnostic CLI shows deployed results.

Packet Tracer for Policy Verification#

Both platforms support packet tracer for simulating traffic:

text

packet-tracer input <interface> tcp <src-ip> <src-port> <dst-ip> <dst-port>

Shows each processing phase: ACL/ACP evaluation, NAT translation, inspection, routing, and egress. Use to verify audit findings.