Background
To support compliance reporting, SIMP modules should map which resources have been configured to support particular compliance requirements, with supporting annotations where needed.
The CCE is a unique and immutable reference used by compliance-checking solutions such as OpenSCAP.
The Proposed Approach: Embed CCE->Resource Mappings in the Catalog
Our approach within modules will be to record the CCE->resource mapping in the Puppet catalog itself:
Use Puppet Resource tags to refer to CCE ids.(Trevor doesn't like tags because they are mutable under some circumstances)- Provide an inert custom type to track CCE->resource mappings as metadata in the catalog.
- It will accept:
- The CCE ID
- A collection of mapped resources (as a list or individually)
- Additional (optional) annotations for a given CCE(s)
Hypothetical example:
cce{ 'cce_indentifier':resources => [Package['foo'], Service['foo']. File['/etc/foo.bar']] comments => 'An optional annotation about this particular mapping'
}
- It will accept:
- Use the catalog compiled for a given system to compil relevant security-compliance documentation.
To take advantage of these features:
- SIMP will provide a tool (TBD) that uses this information to generate compliance reports from Puppet catalogs
- PuppetDB (or local catalogs) can be queried to generate point-in-time compliance reports, with resources mapped to each CCE.
NOTE: Mapping is not Validation
It is important to note that the mapping of resources necessary to satisfy a CCE is not a validation that the CCE's requirements have been enforced.
- OpenSCAP validates CCEs and this is not an attempt to re-implement it.
- The presence of a CCE->resource mapping in the Puppet catalog is not proof that it has been implemented correctly.
Puppet-managed resources may differ from a CCE's requirements under many circumstances:
- Class parameters may be tweaked (via Hiera, ENC, or due to internal logic such as ::params)
- Different CCEs may prescribe mutually-exclusive requirements for the same resource.
- SIMP must support multiple compliance profiles, which may recommend CCEs that are mutually-exclusive wrt a given resource.
The Benefits: Better Compliance Tooling
- Provide a security officer a detailed mapping of which resources have been prescribe to fite
Problems
- Potential for catalog bloat
- Additional complexity in module design (e.g., mapping.pp in the new standard layout)
- Mapping CCEs to resources managed across multiple modules could get ugly
- Following current PuppetLabs practices, the recommended solution would be to manage this from a Profile.
- However, Profiles aren't good Puppet Forge
- IDEA: would it be better to provide a module ("simp-ccemappings") that provides mappings (ala the selinux-policy-targeted RPM)
- Following current PuppetLabs practices, the recommended solution would be to manage this from a Profile.