How to Map Resource Configurations to Compliance Criteria

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 & 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_identifier': 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 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.

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.

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)

Action items