Page Comparison

...

The CCE is a unique and immutable reference used by compliance-checking solutions such as OpenSCAP.

The Proposed Approach: Embed CCE->Resource Mappings & Compliance Results in the Catalog

• This is hastily written down after an after-hours TrevoRant
• Embed CCE-to-resource mapping data in the module itself, including how to determine the expected value
• During catalog compiles on the Puppet Server, use a function to build a data structure of the CCE-to-resource mappings, their compliant values, and the actual values.
• After the data structure is complete, add it to the catalog.
• Create tool to build using the data structure in the catalog

An Older 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_indentifieridentifier': resources => [Package['foo'], Service['foo']. File['/etc/foo.bar']] comments => 'An optional annotation about this particular mapping' }

• Use the catalog compiled for a given system to compil relevant security-compliance documentation.

The Benefits: Advanced Compliance Tooling

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 already validates CCEs CCE compliance 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.

...

• 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)

...