Method
What is portable, and what is not
The method is shared across platforms; the query text is platform-specific. This page shows where that boundary is.
The short answer
The specification is platform-neutral; execution is not. A check must use the language and tables of the platform where it runs. Here, 13 objectives are implemented as 39 queries in three languages.
The shared objectives, evidence schemas, parameters, and outcome vocabulary stay the same across all three implementations.
Vendor-neutral: the method itself
- 13 control objectives
- NIST SP 800-53 Rev. 5. A United States federal catalogue, published by a standards body, implemented by no vendor and owned by none.
- 23 answerable federal performance goals
- CISA's Cross-Sector Cybersecurity Performance Goals, of which 13 carry a published check, mapped per control. Also federal, also vendor-neutral.
- 6 evidence contracts
- Open CSV schemas — hr_termination_events.csv, privileged_role_register.csv, change_approvals.csv, asset_inventory.csv, approved_exposure_register.csv, kev_catalog.csv. Plain files with published column names. Any system that can export a spreadsheet can satisfy them, and no product is named in any of them.
- 9 normalised sourcetypes
- A vendor-neutral vocabulary for incoming records — auth:success, authentication:events, backup:jobs, config:snapshot, credential:inventory, directory:users, network:rules, privileged:assignments, vulnerability:findings. A product forwarded under one of these names is read by the existing query with nothing rewritten.
- 5 bounded outcomes
- POTENTIAL_FINDING, NO_FINDING_DETECTED, REVIEW_REQUIRED, INSUFFICIENT_EVIDENCE, NOT_ASSESSED. The result vocabulary is the project's own and is identical on every platform.
- 3 validation states
- Not tenant-validated, lab-validated, field-reported — recorded per control and platform, in one file, in the same words regardless of vendor.
- 1 machine-readable profile format
- JSON carrying the objective, its source, the organization-defined parameters, the evidence contract, the outcome vocabulary, the human-review boundary and the content hash. The same structure is emitted for every platform.
Vendor-bound: the query text, and nothing else
39 published queries are written in KQL, Athena SQL and SPL, plus the deployment configuration that schedules each one. These are the only artifacts in the project that could not be moved to another platform unchanged.
Each query uses a specific engine, its tables, and its syntax. Everything above the query stays shared, so adding another platform means adding query implementations rather than changing the method.
How far the neutral layers actually reach
27 technologies are catalogued, 26 of them with a route to a published query. 13 are read directly by a query naming their own tables. The other 13 are reached through the neutral layers, with no query written for any of them:
| Route | Count | Technologies | What it depends on |
|---|---|---|---|
| Direct query | 13 | AWS Backup, AWS Config, AWS IAM, AWS Security Hub, Active Directory, Amazon Web Services, Azure Backup, Azure resource/configuration inventory, Backup jobs in Splunk, Microsoft Azure, Microsoft Entra ID, Microsoft Sentinel, Splunk Enterprise Security | The platform's own tables — vendor-specific by definition |
| Normalised sourcetype | 10 | Commvault, Google Cloud, Google Cloud Asset Inventory, Google Cloud Backup and DR, Google Cloud IAM, Okta, Other or custom backup tool, Rubrik, VMware or virtualized infrastructure, Veeam | The published sourcetype vocabulary — vendor-neutral |
| Evidence contract | 3 | CMDB or asset inventory, Git-based change history, Ticketing or change system | An open CSV schema — vendor-neutral |
| No route in this release | 1 | Amazon CloudWatch | Stated rather than implied |
Several products are covered without their own query because the shared layers above the query use common schemas.
What this page does not claim
The published queries only run on their documented platforms. Some catalogued technologies have no route in this release, and the control pages state those limits.
The practical promise is simple: the objective, evidence, settings, and result vocabulary stay consistent even when the query language changes.
Where to see it
- The control library — every objective with all three implementations side by side.
- Coverage of the federal baseline — the goals answered, and those not.
- Terraform and infrastructure-as-code evidence — intended configuration, change history, and the runtime limits.
- The glossary — every term used here, defined.