KSI-MLA-OSMOperating SIEM Capability

Together these prove audit-record generation (AU-02/AU-12) and protection of the audit information — integrity via log-file validation and confidentiality via SSE-KMS (AU-09). This is the trail's existence and protection, not review of its contents: pair with the log-review/alerting recipe (MLA) for AU-06. Pass the S3/CloudWatch parameters to CLOUD_TRAIL_ENABLED to assert delivery to your specific log destination. A trail existing proves generation, not content — AU-03 is not claimed, because no Config rule reads record content. AU-02's organization-defined event types and AU-12's component list (OS, container and application audit are components) are SSP parameters a human compares this output against, and AU-09's protection from unauthorized access and deletion needs the log bucket's policy, Object Lock and MFA-delete posture, which is not collected here.

This is the capacity and durability of the audit pipeline, not proof that it is adequate. AU-04 asks that storage capacity be sufficient for your defined requirement — S3 has no fixed ceiling to report, so the honest evidence is the consumption trend plus the retention and lifecycle settings that bound it, and the judgement that the headroom is enough stays yours. AU-05 is answered here only in its detection half: get-trail-status surfaces the delivery failure, and the alerting and the real-time response — notify these people, shut down or overwrite oldest records — is process, with the alarm-side telemetry living in the AU-06 log-review recipe (CLOUDWATCH_ALARM_ACTION_CHECK). AU-11 is the retention setting, which these commands read directly, but conformance to your record-retention period is a comparison against policy: note that cw-loggroup-retention-period-check marks a Never-expire group COMPLIANT, so an unbounded group passes the rule while potentially violating a maximum-retention or data-disposal requirement — read the raw retentionInDays, not just the rule verdict. Substitute your real bucket, trail and window; run get-trail-status per trail (it is a single-trail call) and against the trail's home Region. BucketSizeBytes is a once-daily storage metric and CloudWatch metric delivery is best-effort, so a missing data point is not by itself an incident. Pass expectedDeliveryWindowAge to cloud-trail-cloud-watch-logs-enabled if you want the rule to fail on stale delivery rather than only on an unconfigured CloudWatch Logs destination; the trail's existence, integrity and encryption are the AU-02/03/09/12 recipe's job.

The clock is telemetry; the mapping and the granularity are not. AU-8 wants time stamps for audit records that use an internal clock mapped to UTC and meet a granularity you defined — chrony proves the host clock is disciplined to an authoritative UTC source and by how much it is off, and CloudTrail's eventTime is UTC by contract, so the AWS-generated half of your audit trail satisfies the mapping without any work of yours. What no command proves is that your own application writes its records from that clock in UTC: chrony can be flawless while code stamps local time or truncates to the second, and comparing the measured offset against your defined granularity is a judgement against a policy number. Scope honesty matters here too — this is a point-in-time sample of the instances Run Command could reach, so an unmanaged, stopped or unreachable instance is silently absent; join the results against your managed-instance inventory before calling the fleet covered, and remember containers and serverless compute have no chrony to query. If you claim sub-millisecond granularity, note that a PTP hardware clock passes no error bound to chrony (chrony then assumes an error bound of 0): read /sys/bus/pci/devices/<pci-slot>/phc_error_bound and add it, or run ClockBound. Leap seconds are smeared on the NTP endpoints but not on the PHC, so do not configure both smeared and non-smeared sources. Substitute your real targets, bucket and command id; send-command returns the CommandId that the second call consumes, and plugin Output is truncated at 2500 characters, which is why the S3 output bucket is worth setting.

AU-7 asks for a capability, so the honest evidence is a query that ran rather than a configuration that exists — run one and keep the query text beside its output. AU-7(1), processing and sorting records by event criteria, is exactly what the filter and sort clauses in the Insights query and the WHERE and ORDER BY in the Lake and Athena statements demonstrate; pick criteria an assessor cares about — a named principal, a source IP, an event name, a bounded window — rather than a bare SELECT *. The half of AU-7 that no output proves is the requirement that reduction not alter the original content or time ordering of the records: these are read APIs, and Athena queries the CloudTrail objects in place in S3 rather than rewriting them, but that is an argument from the API contract, not a line in the result set — the property is actually carried by log file validation and object immutability, which belong to the integrity recipe, not this one. Two limits deserve to be read before the query power is. A query can only reduce records that reached the log group or the event data store, so a 90-day retention makes an annual report impossible no matter how good the SQL, which is why the retention fields are pulled alongside. And the Insights ceilings — 100,000 events per query, 10,000 per page, 50 log groups, 60 minutes — mean a broad search across a year of CloudTrail truncates silently rather than failing, so a result set sitting exactly at the limit is a truncated report and must not be filed as a complete one; Athena and CloudTrail Lake have no such row ceiling and are the right tools for a long look-back. Whether the resulting report actually supports after-the-fact investigation is a human judgement about the query, which is what keeps this partial rather than full.