[Cisco ASA][Cisco FTD]: Event code 302021 always uses the outbound source/destination mapping

Note: This issue has been drafted with :robot: Cursor/Claude Opus 5 under my supervision.

### Integration Name

Cisco ASA [cisco_asa], Cisco FTD [cisco_ftd]

### Dataset Name

cisco_asa.log, cisco_ftd.log

### Integration Version

cisco_asa 2.45.15, cisco_ftd 3.13.10

### Agent Version

9.4.1

### Agent Output Type

elasticsearch

### Elasticsearch Version

9.4.1

### OS Version and Architecture

N/A (pipeline logic issue, reproducible with `elastic-package test pipeline`)

### Software/API Version

Cisco ASA / FTD syslog

### Error Message

No error is raised. The grok matches and silently assigns `source` and `destination` the wrong way round for inbound flows.

### Event Original

```
%ASA-6-302021: Teardown ICMP connection for faddr 192.168.2.2/1 gaddr 192.168.2.3/0 laddr 192.168.2.3/0 type 8 code 0
```

### What did you do?

While fixing #16716 (302020 `Built ... ICMP connection` reporting `source` and `destination` swapped for inbound connections, see #20838) I checked the teardown counterpart, message ID **302021**, and found it has a related but distinct problem.

Message 302020 carries an explicit `{inbound|outbound}` keyword, and [the Cisco syslog reference](https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/asa-syslog/syslog-messages-302003-to-342008.html) documents two different formats for it, with the address roles swapped between them:

```
(Inbound) ... for faddr src_ip_address/src_port gaddr dest_ip_address/dest_port laddr dest_ip_address/dest_port ...
(Outbound) ... for faddr dest_ip_address/dest_port gaddr src_ip/src_port laddr src_ip/src_port ...
```

Message **302021 carries no direction keyword at all**, and the reference documents only a single format for it — the one using the *inbound* role names:

> Error Message `%ASA-6-302021: Teardown ICMP connection for faddr src_ip_address/src_port outside_idfw_user gaddr dest_ip_address/dest_port laddr dest_ip_address/dest_port inside_idfw_user [(user)] type type code code ...`
>
> faddr — Specifies the IP address of the foreign host
> gaddr — Specifies the IP address of the global host
> laddr — Specifies the IP address of the local host

Both packages parse 302021 with a single grok that hardcodes the **outbound** mapping (`faddr` → `destination.address`, `laddr` → `source.address`, `gaddr` → `source.nat.ip`):

- `packages/cisco_asa/data_stream/log/elasticsearch/ingest_pipeline/default.yml`, tag `parse_302xxx`
- `packages/cisco_ftd/data_stream/log/elasticsearch/ingest_pipeline/default.yml`, tag `parse_teardown_message`

### What did you see?

The `Built` and `Teardown` events for the same inbound ICMP flow disagree about which host is the source. This is visible in the existing `cisco_asa` fixture `test-sgt-tag-name.log`, where lines 6 and 7 are the built/teardown pair for one flow (`faddr 192.168.2.2`, `gaddr`/`laddr 192.168.2.3`). With #20838 applied:

| Event | Message | `source.address` | `destination.address` |
|---|---|---|---|
| Built (302020, inbound) | `Built inbound ICMP connection for faddr 192.168.2.2/1 ... laddr 192.168.2.3/0` | `192.168.2.2` | `192.168.2.3` |
| Teardown (302021) | `Teardown ICMP connection for faddr 192.168.2.2/1 ... laddr 192.168.2.3/0` | `192.168.2.3` | `192.168.2.2` |

For outbound flows the two agree, because the hardcoded mapping happens to be the outbound one.

Note this is not a regression introduced by #20838 — 302021 has always used the outbound mapping, and before that fix 302020 did too, so the two were consistently wrong together for inbound flows. Fixing 302020 leaves 302021 as the remaining half.

Equivalent fixtures exist in `cisco_ftd` (`test-sample.log`, `test-not-ip.log`).

### What did you expect to see?

For an inbound ICMP flow, the teardown event should report the same `source` and `destination` as the corresponding built event, i.e. `faddr` as the source and `laddr` as the destination, along with the derived `*.nat.ip`, `*.geo.*`, `*.as.*` and `related.ip` fields.

### Anything else?

There is no purely local fix, which is why I am raising this for discussion rather than opening a PR: the 302021 message contains no direction indicator, so the direction cannot be recovered from the event itself. Possible directions:

1. **Follow the documented format literally** and map `faddr` → source, `laddr` → destination for 302021. This matches Cisco's reference and makes inbound flows self-consistent, but inverts outbound teardown events, which are correct today. It would be a breaking change for existing users and detection rules.
2. **Treat the Cisco reference as showing only the inbound variant** (by analogy with 302020, which is documented twice) and accept that 302021 is ambiguous, leaving the current behaviour and documenting the caveat.
3. **Ask Cisco to confirm** whether 302021 address ordering follows the direction of the original connection, as 302020 does. There is precedent for this: in #5648 a contributor opened a TAC case which established that the `inbound`/`outbound` keyword is derived from interface security levels on ASA and is unreliable on FTD (all FTD security levels are 0). That finding is why `cisco_asa` swaps on `outbound` for 302013/302015 while `cisco_ftd` deliberately does not.

Related:
- #16716 — 302020 source/destination swapped for inbound connections (fixed by #20838)
- #20838 — the 302020 fix for both packages
- #5647 / #5648 — FTD 302013/302015, and the TAC finding about the direction keyword
- #5149 / #4563 — the ASA and FTD 302013/302015 direction handling
- #4199 — 302020 previously misclassified as a teardown event

Read the `parse_302xxx` grok in `packages/cisco_asa/data_stream/log/elasticsearch/ingest_pipeline/default.yml` and `parse_teardown_message` in the corresponding Cisco FTD pipeline. Run `elastic-package test pipeline` with the named `cisco_asa` and `cisco_ftd` fixtures, then resolve the documented ambiguity and update behavior and coverage so 302021 teardown events are handled consistently with the chosen direction semantics.

Written by the indexing model from the issue text.