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

Step 5: VPN and Remote Access Audit

Evaluate VPN configuration security on both platforms.

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

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:

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.

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

Finding	Severity	Rationale
---------	----------	-----------
[ASA] `permit ip any any` in interface ACL	Critical	Permits all IP traffic — no access restriction
[FTD] ACP default action set to Allow	Critical	All unmatched traffic permitted without inspection
[FTD] Prefilter Trust rule with broad match (any/any)	Critical	Traffic bypasses all Snort inspection
[ASA] No global service-policy applied	High	No application-layer inspection on any traffic
[FTD] Allow rule without Intrusion Policy binding	High	Traffic permitted without IPS inspection
[FTD] SSL policy not decrypting internet-bound traffic	High	Snort inspects only metadata on encrypted flows
VPN using DES/3DES or DH group 1/2/5	High	Weak cryptographic algorithms — vulnerable to attack
Static NAT with no restricting ACL	High	Published server accessible on all ports
Failover configured but standby not monitoring	High	HA not providing redundancy
[FTD] Snort in passive mode (production)	High	IPS detects but cannot block threats
[ASA] ACE with hitcnt=0 for >90 days	Medium	Unused rule — cleanup candidate
[FTD] File/Malware policy not bound on file-carrying rules	Medium	Malware detection gap on HTTP/SMTP/FTP
VPN split tunneling enabled	Medium	Remote user traffic may bypass corporate security controls
Logging severity below informational (level 6)	Medium	Security events not captured in logs
[ASA] Security levels equal with same-security-traffic disabled	Low	Traffic between equal interfaces blocked (may be intentional)

IPS / Inspection Maturity

Coverage	Maturity	Guidance
----------	----------	----------
[FTD] All Allow rules have Intrusion + File/Malware policies	Mature	Maintain; tune Snort rules quarterly
[FTD] Most Allow rules have Intrusion Policy, some gaps	Developing	Bind Intrusion Policy to remaining Allow rules
[ASA] Global inspection policy active, custom maps defined	Developing	Evaluate FTD migration for deeper inspection
[ASA] Default global_policy only, no custom inspections	Immature	Add custom inspection maps for critical protocols

Decision Trees

Access Policy Gap Remediation

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

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

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

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.

Cisco Firewall Audit

概述