[New Rule] AWS IAM Access Analyzer Finding Suppression

**Description**

Identifies attempts to suppress IAM Access Analyzer findings without deleting the analyzer outright, or deletion of the analyzer itself. Adversaries with Access Analyzer permissions can delete the analyzer (`DeleteAnalyzer`) or create an archive rule with a filter broad enough to auto-archive every public-exposure finding (`CreateArchiveRule` with `filter.isPublic.eq: true`). This silently hides evidence of public resource exposure before or during an exfiltration attempt, while leaving no obvious "analyzer disabled" signal for a narrower rule to catch.

No rule in this repo touches `accessanalyzer.amazonaws.com` at all (checked via `gh api`/`gh search`). This mirrors the already-accepted `AWS GuardDuty Detection Suppression` rule's pattern (soft-disable/suppress vs. outright delete), applied to a service that has no suppression-focused rule of its own.

Built and validated against real AWS activity, not synthetic documents: confirmed IAM permissions first (`aws sts get-caller-identity`/`list-attached-group-policies`), then generated genuine API calls in a real AWS account: a benign analyzer creation, a narrowly-scoped legitimate archive rule (a static-site bucket, intentionally public), the actual broad `isPublic: true` suppression pattern, and analyzer deletion. Pulled the real raw CloudTrail records via `aws cloudtrail lookup-events` and shipped them through the actual installed `aws` integration's CloudTrail ingest pipeline (`pipeline=logs-aws.cloudtrail-7.1.1`) rather than hand-building documents. Verified the exact final query against the real processed data: 3/3 true positives (2 `DeleteAnalyzer` + the broad `CreateArchiveRule`), 0 false positives against the benign analyzer creation and the narrowly-scoped legitimate archive rule. Test resources were deleted immediately after capturing the events, and the AWS account was left clean.

The query's `aws.cloudtrail.flattened.request_parameters.filter.isPublic.eq` dotted-path pattern follows the exact convention already used by the accepted GuardDuty-suppression rule for the same class of check (a flattened CloudTrail `request_parameters` field), rather than inventing a new query style.

**Target Ruleset**: aws

**Target Rule Type**: Custom (KQL or Lucene)

**Tested ECS Version**: 9.4.0

**Query**
```sql
data_stream.dataset: "aws.cloudtrail"
and event.provider: "access-analyzer.amazonaws.com"
and event.outcome: "success"
and (
event.action: "DeleteAnalyzer"
or
(event.action: "CreateArchiveRule" and aws.cloudtrail.flattened.request_parameters.filter.isPublic.eq: ("true" or true))
)
```

**New fields required in ECS/data sources for this rule?**

None. Uses only fields already populated by the standard `aws` integration's CloudTrail data stream (`data_stream.dataset`, `event.provider`, `event.outcome`, `event.action`, `aws.cloudtrail.flattened.request_parameters.*`).

**Related issues or PRs**

None found for Access Analyzer specifically. The design mirrors the accepted GuardDuty suppression rule (`defense_evasion_guardduty_finding_suppression.toml`, PR #6441).

**References**
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-archive-rules.html
- https://docs.aws.amazon.com/IAM/latest/APIReference/API_access-analyzer_CreateArchiveRule.html
- https://docs.aws.amazon.com/IAM/latest/APIReference/API_access-analyzer_DeleteAnalyzer.html
- https://attack.mitre.org/techniques/T1562/001/

**Redacted Example Data**

Real CloudTrail record (captured from a real AWS account during testing, account ID/access key/principal ID/IP redacted):
```json
{"eventVersion": "1.11", "userIdentity": {"type": "IAMUser", "principalId": "", "arn": "arn:aws:iam:::user/llm_study", "accountId": "", "accessKeyId": "", "userName": "llm_study"}, "eventTime": "2026-08-02T16:23:08Z", "eventSource": "access-analyzer.amazonaws.com", "eventName": "DeleteAnalyzer", "awsRegion": "eu-north-1", "sourceIPAddress": "", "requestParameters": {"analyzerName": "detlab-test-analyzer-2", "clientToken": "00bf0c86-1823-4ba1-b3dd-5d6dfd3a2ce9"}, "responseElements": null, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "", "eventCategory": "Management"}
```

Start by reading defense_evasion_guardduty_finding_suppression.toml and the existing aws ruleset conventions, then review the supplied query and CloudTrail field paths. Done means adding the Access Analyzer suppression rule with the stated DeleteAnalyzer and broad CreateArchiveRule detections, while preserving the benign archive-rule exclusions described in the issue.

Written by the indexing model from the issue text.