AI SIEM — MITRE ATT&CK Coverage

AI SIEM classifies every detected threat against the MITRE ATT&CK cloud (AWS) matrix, framework v14. The mapping is a maintained lookup table — a detection's tactic and technique are assigned deterministically from the underlying signal, never guessed by a language model. Those tags drive the kill-chain view in the timeline and are stored on each threat record.

Deterministic by design. ATT&CK classification is derived by rules from the observed event — a CloudTrail API call, a GuardDuty finding type, a VPC Flow pattern, or a static rule. AI is used only to explain a threat in prose, never to decide its tactic, technique, or severity.

Signals we map

CloudTrail — management and data-plane API calls, mapped by event name (60+ events).
GuardDuty — finding types (credential exfiltration, port probes, C2/DGA traffic, S3 exfiltration, crypto-mining, and behavioral findings). Named finding types map to a precise technique; any other finding falls back to its ThreatPurpose prefix (Recon, UnauthorizedAccess, CryptoCurrency, Backdoor, and so on), so new and less-common GuardDuty findings are still tactic-tagged rather than left blank.
VPC Flow Logs — network patterns: port sweeps, large egress, non-standard ports, lateral movement, DNS tunneling.
Static rules — impossible travel, credential stuffing, root usage, trail-disabled, public bucket, wildcard policy, port scanning.
Custom rules (advanced+) — detections you author (by hand, from a plain-English description, or imported from Sigma) can carry their own ATT&CK tactic and technique, so your own rules extend this coverage and appear in the same kill-chain view.

Tactic coverage

AI SIEM addresses 13 of the 14 enterprise ATT&CK tactics — the full cloud kill chain from Reconnaissance through Impact. Representative techniques and the signals that trigger them:

Tactic	Representative technique(s)	Example signals AI SIEM detects
Reconnaissance	`T1595.001` Active Scanning (Port)	GuardDuty PortProbe/Portscan; VPC Flow port-sweep; scheduled Athena scan-sweep backstop
Initial Access	`T1078` / `T1078.004` Valid / Cloud Accounts	ConsoleLogin; federation, SAML, and OIDC assume-role; GuardDuty malicious-IP login; impossible-travel rule; root-account usage
Execution	`T1204.003` Malicious Image	RunInstances / StartInstances
Persistence	`T1098`, `T1136.003`, `T1546`, `T1098.004`	CreateAccessKey, CreateUser/Role, login-profile changes, Lambda code changes, SSH key import, security-group creation
Privilege Escalation	`T1484.002`, `T1548`	Policy / trust-policy writes (AttachRolePolicy, PutUserPolicy, UpdateAssumeRolePolicy, CreatePolicyVersion), AssumeRole, PassRole, wildcard policy
Defense Evasion	`T1562.008`, `T1562.001`, `T1070`, `T1578`	StopLogging / DeleteTrail / DeleteFlowLogs / PutEventSelectors, DeleteDetector, Config-recorder tampering, access-key deletion, instance-attribute changes, and AI SIEM's own configuration changed outside the editor (self-integrity check)
Credential Access	`T1552.005`, `T1556`, `T1110`	GetSecretValue / GetParametersByPath, MFA-device deletion, SAML/OIDC provider tampering, GuardDuty brute-force
Discovery	`T1580`, `T1087.004`	ListBuckets/Objects, DescribeInstances/SecurityGroups, GetCallerIdentity, ListRoles/Users
Lateral Movement	`T1550.001`, `T1021`	GuardDuty inside-AWS credential exfiltration; VPC Flow lateral-movement pattern
Collection	`T1530` Data from Cloud Storage	GetObject, CreateDBSnapshot, RestoreDBInstanceFromDBSnapshot
Command and Control	`T1071`, `T1568.002`, `T1571`, `T1071.004`	GuardDuty blackhole/DGA traffic; VPC Flow unusual-port and DNS-tunneling patterns
Exfiltration	`T1537`, `T1048`	PutBucketPolicy/Acl, snapshot/AMI/DB-snapshot sharing, public-access-block removal, security-group egress, large-egress flows, GuardDuty S3 exfiltration
Impact	`T1485`, `T1490`, `T1496`	ScheduleKeyDeletion/DisableKey, DeleteBucket, bucket-versioning changes, crypto-mining findings

What we deliberately do not claim

Resource Development is the one enterprise tactic AI SIEM does not map — on purpose. It covers an adversary building infrastructure (registering domains, acquiring servers, staging tooling) before and outside the victim's account. Those actions leave no trace in your CloudTrail, GuardDuty, or VPC Flow Logs, so any tool claiming to detect them from in-account telemetry would be guessing. We would rather be accurate about the boundary than pad a coverage chart.

Why this matters

ATT&CK tags turn isolated alerts into a narrative. When AI SIEM correlates events for one principal — a valid-accounts login, a policy change, then a data-store share — the timeline shows the kill chain advancing across tactics, so responders see how far an intrusion has progressed, not just that something happened.

That narrative gets richer when AI SIEM is deployed alongside the rest of the Perfware suite. A metric anomaly from AI Monitor (say, a network-egress spike) or a log-pattern detection from Log Processor lands on the same timeline as the ATT&CK-tagged threat, corroborating the tactic progression with signals infrastructure tools miss. To be precise: those companion signals add context, not coverage — the ATT&CK tactic and technique are still classified from the CloudTrail, GuardDuty, VPC Flow, and rule signals above; the suite is not itself mapped in this matrix.

Mapping source: threat_detector/mitre_mapping.json (ATT&CK v14, cloud/AWS matrix). Reference: attack.mitre.org — Enterprise / Cloud / AWS. Coverage expands as new event and finding mappings are added; the framework version is stated in the mapping file.