KSI-MLA-RVLReviewing Logs

The mark says whether an authored AWS recipe fetches evidence for the control; the tier strip shows which Rev5 baselines also require it — where automated KSI evidence doubles as Rev5 control evidence. ▪▪▫ = in the class B, C and D baselines, left to right

• ●recipe— an authored recipe collects evidence for this control
• ◐KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
• ○orphan— no Key Security Indicator reaches it — a person writes it up instead

• ●recipe · 1 recipeAC-02 (04)AC▫▪▪In baseline C, D
• ◐KSI onlyAC-06 (09)AC▫▪▪In baseline C, D
• ●recipe · 1 recipeAU-02AU▪▪▪In baseline B, C, D
• ●recipe · 1 recipeAU-06AU▪▪▪In baseline B, C, D
• ●recipe · 1 recipeAU-06 (01)AU▫▪▪In baseline C, D
• ●recipe · 1 recipeSI-04SI▪▪▪In baseline B, C, D
• ◐KSI onlySI-04 (04)SI▫▪▪In baseline C, D

Collect evidence (2)

Authored AWS recipes whose output is evidence for KSI-MLA-RVL. This mapping is this project’s opinion (overlay v3.0.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.

• ◐partialAWS Config compliance results proving continuous security monitoring is switched on account-wide — GuardDuty threat detection enabled (optionally centralized to a delegated admin) and Security Hub aggregating control findingscontinuousconfig-rule
  config-threat-monitoring-enabledAWS Config · Amazon GuardDuty · AWS Security Hub

  This proves the monitoring capability is ON, which is the automatable half of SI-04. Whether findings are triaged and acted on within your SLA is the review workflow — surface that with the GuardDuty finding-plus-response recipe (see guardduty-suspicious-iam-activity-response) and AU-06 log review. Set CentralMonitoringAccount to your delegated-administrator account id in a multi-account org so member accounts are evaluated against the aggregation point. Both rules are evaluated per Region, so GuardDuty disabled in any Region other than the one queried is invisible; and whether findings are analyzed and acted on — SI-04(a), (b), (d) — is a human workflow. Partial for both reasons.

• ◐partialThe metric filters that turn audit log events into metrics, the alarms built on them, and Config's confirmation that those alarms actually notify someone — the automated-mechanism half of audit reviewweeklycli
  cloudwatch-log-review-alertingAmazon CloudWatch Logs · Amazon CloudWatch · AWS Config

  AU-06 asks that audit records be reviewed and analysed and findings reported; AU-06.01 asks that the review use automated mechanisms. What these calls prove is the automated half — the pipeline exists, it fires, and it reaches a human. No API proves a person read the alert, judged it, and reported the finding, so pair this with your ticket or case record; do not present an alarm list as a completed review. Metric filters only publish for events after the filter was created and are supported only on Standard-class log groups, so a filter created yesterday says nothing about last month. cloudwatch-alarm-action-check defaults to requiring an ALARM and INSUFFICIENT_DATA action; pass action1..action5 to assert alarms route to a specific SNS topic. Trail existence and protection is the separate cloudtrail recipe (AU-02/03/09/12).

Default evidence owed by every indicator (5)

From info.default_artifacts.KSI — no indicator carries its own artifacts; requirement-specific evidence lives on /evidence.

• Explanation of measures (and their objectives) that demonstrate the Key Security Indicator, or an explanation of the reason and resulting risk to customers for not having measures available for that Key Security Indicator.
• Explanation of the cycle for any measures that are implemented persistently (if applicable).
• Verification that the measures demonstrate the Key Security Indicator, or that the reason for not having them is accepted.
• Verification that the automation in place is accurate and sufficient to demonstrate appropriate measures for the Key Security Indicator, or that automation is not necessary for each measure.
• Validation that the measures are accurately produced and are in place and working as intended, or that the reason for not having them is valid.

Defined terms used (1)

Persistently

Occurring in a firm, steady way that is repeated over a long period of time in spite of obstacles or difficulties. Persistent activities may vary between actors, may occur irregularly, and may include interruptions or waiting periods between cycles. These attributes of persistent activities should be intentional, understood, and documented; the status of persistent activities will always be known.

• ○no authored recipeKSI-MLA-ALAAuthorizing Log Access
• ●2 authored recipesKSI-MLA-EVCEvaluating Configurations
• ●3 authored recipesKSI-MLA-LETLogging Event Types
• ●4 authored recipesKSI-MLA-OSMOperating SIEM Capability
• ●2 authored recipesKSI-MLA-RVLReviewing Logsyou are here