cisco-firewall-audit

What this skill does

# 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