KSI-PIY-GIVGenerating Inventories
Authoritative sources are used to automatically generate real-time inventories of all information resources when needed.
Mapped NIST 800-53 controls (7)
- recipe5
- KSI only2
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
Collect evidence (2)
Authored AWS recipes whose output is evidence for KSI-PIY-GIV. 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.
- 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 themdailycliconfig-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.
- partialA Region-by-Region inventory of the resources that can hold information, the classification tags you asserted on them, and — where Macie exists — a sampled machine judgement about which S3 buckets actually contain sensitive datamonthlycliinformation-location-and-classificationAWS Config · AWS Resource Groups Tagging API · Amazon Macie · Amazon S3
Three different qualities of evidence are stacked here, and conflating them is the trap. The Config aggregate query is solid on where storage lives — resource type by Region, across accounts — and that is the part of CM-12 most often undocumented. The tag query is only as true as your tagging: GetResources by design never returns untagged resources, so an unclassified bucket is absent from the answer rather than flagged, which is precisely backwards for an inventory control; run it beside the aggregate count and treat the difference as your unclassified population. Macie is the only machine-derived opinion about information type, and it is a sample rather than a census — automated sensitive data discovery continually selects representative objects from your buckets and scores each bucket from those, so a MONITORED bucket with a low score means ‘nothing sensitive in what was sampled’, never ‘no sensitive data here’. The unclassifiable object count is the population Macie could not read at all because of storage class or file format, and per-file size quotas mean a large archive can be skipped entirely, so read coverage before reading scores. Macie also only looks at S3: nothing above inspects an RDS table, an EFS volume, a DynamoDB item or a Parameter Store value, and the Region field tells you where a bucket is, which is the CM-12 question, not what is in it. What no command produces is CM-12 itself — the documented location of each information type, the users authorized to access it and the purpose it is held for. That is a record you write and then check against this telemetry, not one you derive from it.
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)
- 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.
The Policy and Inventory run (5)
2/5 have an authored AWS recipe- 2 authored recipesKSI-PIY-GIVGenerating Inventoriesyou are here
- no authored recipeKSI-PIY-RESReviewing Executive Support
- no authored recipeKSI-PIY-RISReviewing Investments in Security
- 3 authored recipesKSI-PIY-RSDReviewing Security in the SDLC
- no authored recipeKSI-PIY-RVDReviewing Vulnerability Disclosures