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

Prerequisites

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

show access-list  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:

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:

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:

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:

[FTD] Snort IPS and File/Malware policies:

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:

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

Step 6: Logging and Monitoring

Evaluate logging configuration and coverage.

[ASA] Syslog configuration:

show logging
show running-config logging

[FTD] Firepower event logging:

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  tcp    

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  tcp    

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

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  tcp    

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