Skill: vahagn-madatyan/cisco-firewall-audit (version 1.0.0)

--- name: cisco-firewall-audit description: >- Dual-platform Cisco ASA and Firepower Threat Defense (FTD) firewall audit with ACL analysis, NAT policy validation, Modular Policy Framework / Access Control Policy evaluation, Snort IPS assessment, VPN configuration review, and logging completeness verification. license: Apache-2.0 metadata: safety: read-only author: network-security-skills-suite version: "1.0.0" openclaw: '{"emoji":"🛡️","safetyTier":"read-only","requires":{"bins":["ssh"],"env":[]},"tags":["cisco","asa","ftd","firewall"],"mcpDependencies":[],"egressEndpoints":[]}' --- # 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 <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: ``` 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.

path: references/cli-reference.md
content: # Cisco ASA and FTD CLI Reference — Audit Commands

Read-only commands organized by audit category for Cisco ASA and Firepower
Threat Defense (FTD) firewall assessment. All commands are non-modifying
(`show`, `display`, diagnostic queries). Commands are labeled **[ASA]**,
**[FTD]**, or **[Both]** to indicate platform applicability.

Access methods:
- **[ASA]** SSH/console to ASA CLI (privilege level 5+ for `show` commands)
- **[FTD]** SSH/console to FTD CLI → `system support diagnostic-cli` for ASA-style commands
- **[FTD]** FMC REST API for policy and event queries
- **[Both]** ASDM (ASA) or FDM (FTD) web UI for visual inspection

## System and Platform Identification

| Function | Command | Platform |
|----------|---------|----------|
| Software version, model, uptime | `show version` | Both |
| Running configuration | `show running-config` | Both |
| Hardware and serial number | `show inventory` | Both |
| License status | `show license` | ASA |
| License status | `show license status` | FTD |
| Feature license summary | `show license usage` | FTD |
| Routed vs transparent mode | `show firewall` | Both |
| Multi-context mode | `show mode` | ASA |
| Context list | `show context` | ASA |
| Management model (FMC/FDM) | `show managers` | FTD |
| Enter diagnostic CLI | `system support diagnostic-cli` | FTD |

### System Notes

- **[FTD]** `system support diagnostic-cli` enters an ASA-compatible CLI. Most `show` commands work here but reflect the deployed policy, not FMC pending changes.
- **[ASA]** `show mode` confirms single vs multi-context. In multi-context, use `changeto context <name>` to audit each context separately.

## Interface and Security Level Inventory

| Function | Command | Platform |
|----------|---------|----------|
| Interface summary (IP, status) | `show interface ip brief` | Both |
| Interface names and security levels | `show nameif` | ASA |
| Interface detail (counters, errors) | `show interface <name>` | Both |
| Interface security zones | Via FMC UI → Devices → Interfaces | FTD |
| VLAN sub-interfaces | `show running-config interface` | Both |
| Same-security-traffic setting | `show running-config same-security-traffic` | ASA |

### Interface Notes

- **[ASA]** Security levels are the foundation of ASA access control. Document each interface's level — it determines default traffic flow behavior.
- **[FTD]** FTD uses security zones instead of security levels. Zone assignments are visible in FMC UI or via `show running-config interface` on the diagnostic CLI.

## Access Policy

| Function | Command | Platform |
|----------|---------|----------|
| All ACLs with hit counts | `show access-list` | ASA |
| Specific ACL | `show access-list <name>` | ASA |
| ACL-to-interface bindings | `show running-config access-group` | ASA |
| Global ACL | `show running-config access-list` (grep for global) | ASA |
| Access Control Policy summary | `show access-control-config` | FTD |
| ACP rule details (diagnostic CLI) | `show access-list` (deployed ACLs) | FTD |
| Object groups | `show running-config object-group` | Both |
| Network objects | `show running-config object network` | Both |

### Access Policy Notes

- **[ASA]** `show access-list` includes `hitcnt=N` per ACE. Zero-hitcount ACEs over 90 days are cleanup candidates.
- **[FTD]** `show access-control-config` in the diagnostic CLI shows the deployed ACP as ACL-like entries. The authoritative policy view is in FMC.
- **[Both]** Object groups consolidate addresses and services. Review object-group membership to understand ACE scope — an ACE referencing a broad object group may be more permissive than it appears.

## NAT Policy

| Function | Command | Platform |
|----------|---------|----------|
| NAT rules (all sections) | `show nat` | Both |
| NAT rules with detail | `show nat detail` | Both |
| NAT configuration | `show running-config nat` | Both |
| Active translations | `show xlate` | Both |
| Translation count | `show xlate count` | Both |
| NAT by interface pair | `show nat interface <iface>` | ASA |

### NAT Notes

- `show nat` displays rules in evaluation order: Section 1 (manual) → Section 2 (auto) → Section 3 (after-auto). Each rule shows translated and untranslated addresses.
- `show xlate` shows active translation slots. High counts near the xlate limit may indicate NAT pool exhaustion.
- Cross-reference static NAT entries with ACL entries to verify that published servers are restricted to necessary ports.

## Inspection and IPS

| Function | Command | Platform |
|----------|---------|----------|
| Service-policy (applied MPF) | `show service-policy` | ASA |
| Service-policy configuration | `show running-config service-policy` | ASA |
| Class-map configuration | `show running-config class-map` | ASA |
| Policy-map configuration | `show running-config policy-map` | ASA |
| Inspection counters | `show service-policy inspect <protocol>` | ASA |
| Connection limits | `show service-policy | include conns` | ASA |
| Snort statistics | `show snort statistics` | FTD |
| Snort counters | `show snort counters` | FTD |
| Intrusion event summary | Via FMC UI → Analysis → Intrusions | FTD |
| File/Malware events | Via FMC UI → Analysis → Files | FTD |
| Deployed intrusion policy | Via FMC REST API: `/api/fmc_config/v1/domain/{domainUUID}/policy/intrusionpolicies` | FTD |

### Inspection Notes

- **[ASA]** `show service-policy` shows which inspections are active and their counters. A missing global service-policy means no application-layer inspection.
- **[FTD]** `show snort statistics` on the FTD CLI shows Snort engine performance: packets inspected, alerts, drops, and pass verdicts.
- **[FTD]** Intrusion event review is best done via FMC UI or API — the FTD CLI has limited event visibility.

## VPN

| Function | Command | Platform |
|----------|---------|----------|
| IPSec SA summary | `show crypto ipsec sa` | Both |
| IKEv2 SA summary | `show crypto ikev2 sa` | Both |
| IKEv1 SA summary | `show crypto ikev1 sa` | Both |
| VPN session database | `show vpn-sessiondb` | Both |
| AnyConnect sessions | `show vpn-sessiondb anyconnect` | Both |
| Tunnel group configuration | `show running-config tunnel-group` | Both |
| Group policy configuration | `show running-config group-policy` | Both |
| Crypto map configuration | `show running-config crypto map` | ASA |
| Certificate trustpoints | `show running-config crypto ca trustpoint` | Both |
| Certificate details | `show crypto ca certificates` | Both |

### VPN Notes

- `show crypto ipsec sa` shows each tunnel's encryption algorithm, packet counters, and SA lifetime. Check for DES/3DES or weak DH groups.
- `show vpn-sessiondb` provides active VPN session count and type (IPSec, AnyConnect, clientless). High session counts may indicate capacity issues.
- **[FTD]** Site-to-site VPN is configured via FMC (Devices → VPN → Site to Site). The diagnostic CLI shows the deployed result.

## Failover and High Availability

| Function | Command | Platform |
|----------|---------|----------|
| Failover status | `show failover` | Both |
| Failover state | `show failover state` | Both |
| Failover history | `show failover history` | Both |
| Failover interface | `show failover | include interface` | Both |
| Configuration sync status | `show failover | include Config` | Both |
| Cluster status (4100/9300) | `show cluster info` | Both |

### Failover Notes

- `show failover state` reveals Active/Standby/Failed status for each unit. Both units should show healthy state.
- `show failover history` shows recent failover events and reasons. Frequent failovers indicate stability issues.
- Configuration sync: verify "Last Failover" timestamps and config sync status. Mismatched configs between active/standby are a risk.

## Connections and Sessions

| Function | Command | Platform |
|----------|---------|----------|
| Connection summary | `show conn count` | Both |
| Connection detail (filtered) | `show conn address <IP>` | Both |
| Connection by interface | `show conn state <state>` | Both |
| Connection rate | `show perfmon` | ASA |
| Top talkers | `show local-host | include host` | Both |
| Session table utilization | `show resource usage` | ASA |
| CPU utilization | `show cpu usage` | Both |
| Memory utilization | `show memory` | Both |
| Process status | `show process cpu-usage sorted non-zero` | Both |

### Connection Notes

- `show conn count` provides current and peak connection counts. Compare against platform limits to assess headroom.
- `show perfmon` (ASA) shows connection rates per second — useful for capacity planning.

## Logging and Monitoring

| Function | Command | Platform |
|----------|---------|----------|
| Logging configuration | `show logging` | Both |
| Logging configuration detail | `show running-config logging` | Both |
| Log buffer (recent messages) | `show logging | tail 50` | Both |
| SNMP configuration | `show running-config snmp-server` | Both |
| SNMP statistics | `show snmp-server statistics` | Both |
| AAA server status | `show aaa-server` | Both |
| eStreamer status | Via FMC UI → System → Integration | FTD |
| Connection events | Via FMC UI → Analysis → Connections | FTD |

### Logging Notes

- `show logging` displays current logging configuration: buffer size, console level, syslog servers, and trap level.
- Verify at least one syslog destination is configured with level "informational" (6) or higher for audit trail.
- **[FTD]** Connection event logging is configured per ACP rule in FMC. Rules without connection logging produce no audit trail.

## FMC REST API Examples

For programmatic audit of FTD environments, the FMC REST API provides
comprehensive policy and event access.

| Function | API Endpoint |
|----------|-------------|
| Authentication | `POST /api/fmc_platform/v1/auth/generatetoken` |
| List devices | `GET /api/fmc_config/v1/domain/{domainUUID}/devices/devicerecords` |
| Access policies | `GET /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies` |
| ACP rules | `GET /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies/{policyId}/accessrules` |
| NAT policies | `GET /api/fmc_config/v1/domain/{domainUUID}/policy/ftdnatpolicies` |
| Intrusion policies | `GET /api/fmc_config/v1/domain/{domainUUID}/policy/intrusionpolicies` |
| Connection events | `GET /api/fmc_config/v1/domain/{domainUUID}/health/alerts` |
| System status | `GET /api/fmc_platform/v1/domain/{domainUUID}/deployment/deployabledevices` |

### API Notes

- Authentication returns a token in the `X-auth-access-token` header. Pass this header on subsequent requests.
- API supports pagination (`offset`, `limit`) for large result sets.
- Use `expanded=true` query parameter to get full object details instead of summary references.
- For audit, create a read-only API user role in FMC (Analysis → Read Only).


path: references/policy-model.md
content: # Cisco ASA and FTD Policy Models

Reference for the ASA security-level model, Modular Policy Framework,
multi-context architecture, and FTD Access Control Policy evaluation chain.
This documents how each platform evaluates traffic — the foundation for
understanding policy audit findings.

## ASA Security-Level Model

ASA uses security levels (0–100) on named interfaces to establish a trust
hierarchy. The security level determines the default traffic flow behavior
before ACLs are applied.

### Default Traffic Flow

```
Higher Security Level (e.g., inside = 100)
       │
       │  Permitted by default (higher → lower)
       ▼
Lower Security Level (e.g., outside = 0)
       │
       │  Denied by default (lower → higher)
       ▼
Higher Security Level
```

| Direction | Default Behavior | Override |
|-----------|-----------------|----------|
| Higher → Lower | Permitted (implicit allow) | ACL can deny specific traffic |
| Lower → Higher | Denied (implicit deny) | ACL must explicitly permit |
| Same → Same | Denied by default | `same-security-traffic permit inter-interface` enables |

### Interface ACL Processing

```
Packet arrives on interface
       │
       ▼
┌─────────────────────────┐
│  Input ACL              │  Interface-bound ACL (access-group in)
│  Top-down, first match  │  Explicit permit/deny entries
│  Implicit deny at end   │  
└────────┬────────────────┘
         │ (permitted)
         ▼
┌─────────────────────────┐
│  NAT Translation        │  Section 1 → Section 2 → Section 3
│  (if applicable)        │
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Security Level Check   │  Higher-to-lower: allowed
│  (if no ACL override)   │  Lower-to-higher: denied
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Inspection Engine      │  Modular Policy Framework
│  (MPF)                  │  Protocol inspection, conn limits
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Output ACL             │  Interface-bound ACL (access-group out)
│  (if configured)        │  Less common than input ACL
└────────┬────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Egress Interface       │  Forward to destination
└─────────────────────────┘
```

### Global ACL

A global ACL applies to all interfaces. Interface-specific ACLs are
evaluated before the global ACL. If an interface ACL exists and matches
(permit or deny), the global ACL is not consulted for that traffic.

## Modular Policy Framework (MPF)

MPF provides application-layer inspection on ASA. It uses a three-tier
model: classify, apply policy, activate.

### MPF Hierarchy

```
class-map (classify traffic)
       │
       ▼
policy-map (bind inspections/actions to classified traffic)
       │
       ▼
service-policy (apply policy-map to interface or globally)
```

### MPF Components

| Component | Purpose | Example |
|-----------|---------|---------|
| **class-map** | Matches traffic by protocol, ACL, port, or any | `class-map inspection_default` → matches default inspection ports |
| **policy-map** | Binds actions (inspect, police, set connection) to class | `policy-map global_policy` → `inspect http`, `inspect dns` |
| **service-policy** | Applies policy-map to interface or globally | `service-policy global_policy global` |

### Default Inspection Policy

ASA ships with a default global policy (`global_policy`) that inspects
common protocols via `inspection_default` class-map:

| Protocol | Default Inspect | Notes |
|----------|----------------|-------|
| DNS | Yes | Length enforcement, dynamic DNS rewrite |
| FTP | Yes | Command inspection, active/passive mode |
| H.323 (H225/RAS) | Yes | Signaling/media pinhole |
| HTTP | No (optional) | Must add `inspect http` for app inspection |
| ICMP | No | ICMP inspection must be explicitly added |
| SIP | Yes | Signaling/media pinhole |
| SMTP/ESMTP | Yes | Command filtering |
| SNMP | Yes | Version enforcement |
| SQL*Net | Yes | Oracle protocol inspection |
| TFTP | Yes | Dynamic pinhole for data channel |

Protocols not in the `inspection_default` class-map receive no
application-layer inspection. They are still subject to ACL enforcement
and stateful connection tracking.

## ASA Multi-Context Architecture

Multi-context mode partitions a single ASA into multiple virtual firewalls.

```
┌──────────────────────────────┐
│  System Context              │  Hardware management, context allocation
│  (admin context)             │  Cannot process transit traffic
├──────────────────────────────┤
│  Context A                   │  Independent firewall instance
│  - Own interfaces            │  Own ACLs, NAT, routing
│  - Own security policy       │  Own admin credentials
├──────────────────────────────┤
│  Context B                   │  Independent firewall instance
│  - Own interfaces            │  Isolated from Context A
│  - Own security policy       │  Own resource allocation
└──────────────────────────────┘
```

### Multi-Context Considerations

| Aspect | Implication |
|--------|-------------|
| **Interface allocation** | Physical interfaces are assigned to contexts; shared interfaces use VLAN sub-interfaces |
| **Resource classes** | Define per-context limits (connections, routes, NAT translations) |
| **Failover** | Active/standby operates at the context level — individual contexts can fail over independently (with ASA clustering) |
| **No inter-context routing** | Traffic between contexts must traverse an external device (router/switch) |

## ASA NAT Order of Operations

```
Packet arrives
       │
       ▼
┌─────────────────────────────────────────────┐
│  Section 1: Manual NAT (Twice NAT)          │
│  - Explicit rules in `nat` command          │
│  - Evaluated top-down                       │
│  - Can match source AND destination         │
│  - Highest priority                         │
└────────┬────────────────────────────────────┘
         │ (no match)
         ▼
┌─────────────────────────────────────────────┐
│  Section 2: Auto NAT (Object NAT)          │
│  - Defined on network objects               │
│  - Internal ordering:                       │
│    1. Static rules (longest prefix first)   │
│    2. Dynamic rules (longest prefix first)  │
│  - Cannot match both source and dest        │
└────────┬────────────────────────────────────┘
         │ (no match)
         ▼
┌─────────────────────────────────────────────┐
│  Section 3: Manual NAT (after-auto)         │
│  - Manual rules placed after auto NAT       │
│  - Lowest priority                          │
│  - Used for catch-all translations          │
└─────────────────────────────────────────────┘
```

## FTD Access Control Policy (ACP) Evaluation Chain

FTD uses a multi-stage evaluation pipeline. Traffic passes through several
policy stages in order. Each stage can take action (allow, block, trust,
decrypt) or pass the traffic to the next stage.

### ACP Evaluation Flow

```
Packet arrives on FTD interface
       │
       ▼
┌─────────────────────────────────────────────┐
│  Stage 1: Prefilter Policy                  │
│  Actions: Fastpath / Block / Analyze        │
│  - Fastpath: bypass Snort entirely          │
│  - Block: drop immediately                  │
│  - Analyze: continue to next stages         │
│  Uses: L3/L4 criteria, tunnel rules         │
│  No application awareness                   │
└────────┬────────────────────────────────────┘
         │ (Analyze or no match)
         ▼
┌─────────────────────────────────────────────┐
│  Stage 2: SSL / TLS Policy                  │
│  Actions: Decrypt / Do Not Decrypt / Block  │
│  - Decrypt (Known Key): inbound server      │
│  - Decrypt (Resign): outbound client        │
│  - Do Not Decrypt: pass encrypted           │
│  - Block: terminate TLS connection          │
│  Determines what Snort can see              │
└────────┬────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────┐
│  Stage 3: Access Control Rules              │
│  Evaluated top-down, first match            │
│  Actions per rule:                          │
│  - Allow: permit + optional inspection      │
│  - Trust: permit, bypass ALL further stages │
│  - Block: deny (with or without reset)      │
│  - Monitor: log and continue evaluating     │
│  - Interactive Block: user warning page     │
│                                             │
│  Match criteria:                            │
│  - Zones, Networks, VLAN tags               │
│  - Ports, Protocols                         │
│  - Applications (OpenAppID)                 │
│  - URLs (category/reputation)               │
│  - Users/Groups (via Realm/AD)              │
│  - SGT/ISE attributes                       │
└────────┬────────────────────────────────────┘
         │ (Allow action)
         ▼
┌─────────────────────────────────────────────┐
│  Stage 4: Intrusion Policy (Snort IPS)      │
│  Applied only if rule action = Allow AND    │
│  an Intrusion Policy is bound to the rule   │
│  - Snort 2 or Snort 3 rule engine           │
│  - Preprocessor + detection engine          │
│  - Actions: Drop/Alert/Pass per rule        │
└────────┬────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────┐
│  Stage 5: File / Malware Policy             │
│  Applied if bound to the rule               │
│  - File type detection and blocking         │
│  - Malware cloud lookup (AMP for Networks)  │
│  - Dynamic analysis (Threat Grid sandbox)   │
│  - Local malware detection (custom sigs)    │
└────────┬────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────┐
│  Stage 6: Default Action                    │
│  Applied when no Access Control rule matches│
│  Options:                                   │
│  - Block All Traffic                        │
│  - Network Discovery Only (no IPS)          │
│  - Intrusion Prevention (IPS on unmatched)  │
│  Recommended: Block All Traffic             │
└─────────────────────────────────────────────┘
```

### Trust vs Allow Actions

| Action | Snort Inspection | File/Malware | SSL Decrypt | Logging |
|--------|-----------------|--------------|-------------|---------|
| **Trust** | Bypassed | Bypassed | Bypassed | Connection only |
| **Allow** | Applied (if bound) | Applied (if bound) | Respected | Full |
| **Block** | N/A | N/A | N/A | Connection only |
| **Monitor** | Continues to next rule | Continues | Continues | Logged |

Trust should be reserved for flows that are verified safe and high-volume
(e.g., backup replication between known servers). Using Trust broadly
creates inspection-free paths through the firewall.

### Snort Deployment Modes

| Mode | Behavior | Use Case |
|------|----------|----------|
| **Inline** | Snort sits in the traffic path; can drop/modify packets | Production IPS — active prevention |
| **Inline Tap** | Copy of traffic sent to Snort; original traffic passes unmodified | Testing IPS policy before enabling inline |
| **Passive** | Snort receives mirrored traffic only; no blocking capability | Monitoring and detection only |

### Snort Base Policies

| Policy | Posture | Description |
|--------|---------|-------------|
| **Connectivity Over Security** | Least restrictive | Fewest rules enabled; minimal performance impact |
| **Balanced Security and Connectivity** | Moderate | Recommended baseline; balances detection and performance |
| **Security Over Connectivity** | Restrictive | More rules; higher CPU; more false positives |
| **Maximum Detection** | Most restrictive | All applicable rules; highest resource usage; tuning required |

## FMC Management Model

```
Firepower Management Center (FMC)
       │
       │  Management channel (sftunnel, TCP 8305)
       ▼
┌─────────────────────────────┐
│  FTD Device 1               │  Receives deployed policy
│  (Snort + ASA data plane)   │  Reports events to FMC
├─────────────────────────────┤
│  FTD Device 2               │  Independent policy possible
│  (Snort + ASA data plane)   │  or shared ACP
└─────────────────────────────┘
```

FMC is the canonical policy source. The FTD device enforces the deployed
policy. Changes made via the FTD diagnostic CLI do not persist across
policy deployments from FMC.

### FDM (Local Management)

FTD devices not managed by FMC can use Firepower Device Manager (FDM) —
an on-device web interface. FDM supports basic ACP, NAT, VPN, and
Intrusion Policy configuration but lacks FMC's advanced features (custom
Snort rules, multi-device management, advanced event correlation).


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)