KSI-SVC-ACMAutomating Configuration Management

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
• ●recipe · 1 recipeCM-02CM▪▪▪In baseline B, C, D
• ●recipe · 1 recipeCM-02 (02)CM▫▪▪In baseline C, D
• ◐KSI onlyCM-02 (03)CM▫▪▪In baseline C, D
• ●recipe · 1 recipeCM-06CM▪▪▪In baseline B, C, D
• ●recipe · 1 recipeCM-07 (01)CM▫▪▪In baseline C, D
• ◐KSI onlyPL-09PL▫▫▫In no class baseline
• ◐KSI onlyPL-10PL▪▪▪In baseline B, C, D
• ◐KSI onlySA-05SA▪▪▪In baseline B, C, D
• ●recipe · 1 recipeSI-05SI▪▪▪In baseline B, C, D
• ◐KSI onlySR-10SR▪▪▪In baseline B, C, D

Collect evidence (2)

Authored AWS recipes whose output is evidence for KSI-SVC-ACM. 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 plus the State Manager association list proving a defined configuration is actually applied and re-applied to every managed node — instances are under SSM management, and the associations that carry your baseline report COMPLIANT on a schedule rather than driftingcontinuouscli
  ssm-configuration-baseline-enforcedAWS Config · AWS Systems Manager

  The telemetry proves a configuration is being enforced and drift corrected — it does not prove the enforced content IS your approved baseline. That the association's SSM document encodes the hardened settings you baselined (CIS/STIG content, approved through your change process) is the human judgement half; keep the document version and its approval record alongside this output. Two limits to state plainly: EC2_INSTANCE_MANAGED_BY_SSM does not flag a stopped instance whose agent is running, and this whole recipe is EC2-only — container images, Lambda, and managed-service settings need their own baseline evidence. CM-08 inventory is a separate recipe, not this one.

• ◐partialThe machine-maintained component inventory — Config's recorder status and discovered-resource counts proving supported resources are tracked continuously and the list stays current without anyone editing a spreadsheet, plus Systems Manager Inventory's node and installed-application metadata for what runs inside themdailycli
  config-asset-inventoryAWS Config · AWS Systems Manager Inventory

  This proves the inventory is machine-maintained and current (CM-08.01, and the automated-currency half of CM-02.02) — it does not prove the inventory is complete. Config sees only supported resource types, only in the regions and accounts where a recorder runs, and only within the recording group you configured; unsupported types, an un-recorded region, on-premises hosts, SaaS components and in-container software are invisible here and need their own source. SSM Inventory covers only managed nodes with a running agent and an inventory association, collects no more often than every 30 minutes, and the console's Inventory cards hide stopped and terminated nodes even though the API still returns them. The accountability attributes CM-08 asks for — system owner, function, criticality — live in your tags or CMDB, not in a resource count, so join them before calling this an inventory. Substitute your real instance id. Detecting unauthorized components (CM-08.03) is a different question; the prohibited-software half is in the least-functionality recipe.

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 (4)

Drift

Changes to information resources that cause deviations from the intended and assessed state; common forms of drift include changes to configurations, deployed software, privileges, running processes, and availability.

Information Resource

Has the meaning from 44 USC § 3502 (6): "information and related resources, such as personnel, equipment, funds, and information technology." This includes any aspect of the cloud service offering, both technical and managerial, including everything that makes up the business of the offering from non-machine-based information resources like organizational policies, procedures, employees, etc. to machine-based information resources like hardware, software, cloud services, code, etc.

Machine-Based (Information Resources)

Any information technology information resource—including systems, processes, software, hardware, services, cloud-native capabilities, and any other such capability, component, or resource—that relies primarily on mechanical or electronic devices (i.e. computers) for operation.

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.

• ●2 authored recipesKSI-SVC-ACMAutomating Configuration Managementyou are here
• ●2 authored recipesKSI-SVC-ASMAutomating Secret Management
• ●4 authored recipesKSI-SVC-EISEvaluating and Improving Security
• ○no authored recipeKSI-SVC-PRRPreventing Residual Risk
• ○no authored recipeKSI-SVC-RUDRemoving Unwanted Data
• ●7 authored recipesKSI-SVC-SINSecuring Information
• ●2 authored recipesKSI-SVC-VCMValidating Communications
• ●3 authored recipesKSI-SVC-VRIValidating Resource Integrity