Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties
label
Status
Status
colourYellow
titleIn progress
StakeholdersTrevor Vaughan Chris Tessmer 
Outcome
Due date
OwnerChris Tessmer 

Background

In order to To support compliance reporting, SIMP modules should map which resources have been configured to support particular compliance requirements, with supporting annotations where needed.

The Proposed Approach

The The CCE is a unique and immutable reference used by compliance-checking solutions such as OpenSCAP.  Our approach is to use the abstraction and tooling already provided by Puppet modules to 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 optional (and inert ) custom type to provide additional 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)
    as metadata in the catalog
    • Hypothetical example:

      cce{ 'cce_indentifier': 
        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 compile the relevant security compliance document. 

...

  • SIMP will provide a tool (TBD) that uses this information to generate compliance reports from Puppet catalogs 
  • The tool will PuppetDB (or local catalogs) can be queried to generate point-in-time compliance reports.

Problems

  • SIMP supports multiple compliance profiles, which may differ on recommendations for which CCEs to implement, even for the same resources. 

NOTE: Mapping is not Validation

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.

It is important to note that the mapping of resources necessary to satisfy a CCE is not a validation of the CCE itself.  

  • OpenSCAP validates CCEs and this is not an attempt to re-implement it.

Advantages 

Enables the development of tools:

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

Action items

  •