Amazon Web Services solution: consolidate AWS log-tampering analytic rules into tiered High/Low detections, fix MITRE mapping (remove T1070 & T1685.002, standardize on T1562.008), remove duplicate rule, and refresh the Data Connectors section in createUiDefinition (v3.0.12)

[v-utpalkumar (v-utpalkumar)]

Change(s):

• AWS_LogTampering.yaml (High severity) — renamed to "AWSCloudTrail - Successful Tampering with AWS CloudTrail Logs" (from "AWSCloudTrail - Tampering to AWS CloudTrail logs"). Reworded the description to open with "Identifies…". Added the AWSS3 data connector and the UserAgent custom detail. Bumped to 1.0.6.
• AWS_ClearStopChangeTrailLogs.yaml (Low severity) — renamed to "AWSCloudTrail - Failed Attempts to Change AWS CloudTrail Logs" (from "…Changes made to AWS CloudTrail logs"). Rewrote the description to scope the rule to failed/denied attempts (successful tampering is now covered by the High rule) and reformatted the existing reference links onto separate lines. Query updated: added a (isnotempty(ErrorMessage) or isnotempty(ErrorCode)) filter so it fires only on failed attempts — making it mutually exclusive with the High rule — and expanded the event coverage to mirror it (DeleteLogGroup plus the UpdateTrail weakening checks). MITRE: removed T1070 and standardized on T1562.008. Bumped to 1.0.6.
• Removed AWS_ConfigServiceResourceDeletion.yaml — it was a functional duplicate (identical query) of the former CloudTrail-changes rule. Reference removed from Solution_AmazonWebServices.json.
• MITRE mapping — the Low rule (AWS_ClearStopChangeTrailLogs) changed from T1070 to T1562.008. The High rule (AWS_LogTampering) was already mapped to T1562.008 (unchanged). T1685.002 was trialed during development but removed, so both committed rules use T1562.008 under DefenseEvasion.
• Solution version bumped to 3.0.12; ReleaseNotes.md updated accordingly.
• createUiDefinition.json (solution UI) — refreshed the Data Connectors step to display the three connectors as individually labeled sections — Amazon Web Services, Amazon Web Services S3, Amazon Web Services S3 WAF — each with its own description, matching the layout used for Workbooks, Analytics, and Hunting Queries. Replaced the previous near-duplicate/generic text blocks.

---

Reason for Change(s):

• The solution previously shipped three near-identical rules with the same detection query, which can produce duplicate incidents for the same AWS activity. This consolidates them into a clean two-tier model: High for confirmed successful log tampering (immediate response) and Low for failed/denied attempts (early-warning/recon signal), with no overlap.
• Aligned the Low rule's event coverage to the High rule (added DeleteLogGroup and the trail-weakening UpdateTrail checks), and added the AWSS3 connector to the High rule for parity.
• The subsequently trialed T1685.002 mapping caused a "No valid tactic corresponding to the technique T1685" save error in Sentinel — T1685 is an ATT&CK v19 technique whose tactic ("Defense Impairment") is not yet supported in the Sentinel data model and did not correspond to any tactic in the rules' tactics field. Removing T1685.002 and standardizing on T1562.008 (which correctly maps to DefenseEvasion) resolves the save error while keeping an accurate cloud-log-tampering classification.
• T1070 (Indicator Removal) was too generic and host/OS-oriented (bash history, registry, file metadata) — it did not accurately represent AWS API-driven logging tampering, so it was removed in favor of the cloud-specific T1562.008 ("Impair Defenses: Disable or Modify Cloud Logs").
• The Data Connectors section in createUiDefinition.json previously used generic, partly duplicated text and did not clearly present each connector. Updating it to a per-connector labeled layout (consistent with the Workbooks/Analytics/Hunting sections) gives users clear, accurate information about each data connector during solution installation.

---

Version Updated:

• Solution: 3.0.11 → 3.0.12
• AWS_LogTampering.yaml: 1.0.5 → 1.0.6
• AWS_ClearStopChangeTrailLogs.yaml: 1.0.5 → 1.0.6
• AWS_ConfigServiceResourceDeletion.yaml: removed

---

Testing Completed:

• Packaged the solution and deployed the generated mainTemplate successfully.
• Both analytic rules saved successfully in Microsoft Sentinel (the previous T1685 save error no longer occurs).
• Logically the two rules are mutually exclusive (High fires on successful events, Low on failed/denied), so no duplicate incidents.
• Confirmed the packaged mainTemplate.json and createUiDefinition.json reflect version 3.0.12 and no longer reference the removed rule (GUID 093fe75e-…).
• Verified the updated Data Connectors blade in createUiDefinition.json renders correctly during deployment, showing the three connectors (Amazon Web Services, Amazon Web Services S3, Amazon Web Services S3 WAF) as separate labeled sections with their descriptions.

---

Checked that the validations are passing and have addressed any issues that are present:

• Yes. YAML/JSON lint shows no errors for both rules and Solution_AmazonWebServices.json.
• MITRE technique↔tactic validation passes (T1562.008 ↔ DefenseEvasion).
• ReleaseNotes follows the required format (semantic version, DD-MM-YYYY date, descending order).
• No remaining references to the deleted rule anywhere in the solution source.
• createUiDefinition.json is valid JSON and passed packaging/UI validation; the Data Connectors section renders as expected with no schema errors.
• All checks have passed.

[contentautomationbot]

Hello how are you I am GitHub bot
😀😀
I see that you changed templates under the detections/analytic rules folder. Did you remember to update the version of the templates you changed?
If not, and if you want customers to be aware that a new version of this template is available, please update the version property of the template you changed.

[Jason Heard (jlheard)]

This connector looks good from a connector configuration standpoint; I've requested a review from Ofer Inbar (@oferInbar) for the analytic rules and backward compatibility concerns.

[rahul0216]

Changes look good.