Normative specification as a benchmark in an audit - CIS or DISA

[naman]

Is your feature request related to a problem? Please describe.
Currently, the project doesn't have a normative specification that can be used as a benchmark in an audit - we can use CIS or DISA . A security baseline standard should be a norm for auditing purposes.

Describe the solution you'd like
We could either add support for a baseline standard or mention deviations from it.

Here is the original issue raised in the ansible-os-hardening repo dev-sec/ansible-collection-hardening#76

[chris-rock]

Thank you @naman for raising the issue. I think it is a very valid question.

The dev-sec baselines are not following one specific ruleset by intention. There are many regulations out there and you named CIS and DISA STIG as two examples. Other non-US countries have others. Most approaches I've seen follow just one regulation but if you look into those specs they share (in most cases) about 80% of the same rules. In addition, dev-sec hardening modules and baselines are split by logical components e.g. linux core, ssh. CIS and DISA aggregate everything into one baseline. The CIS/DISA approach has a lot of disadvantages from maintenance perspective since e.g. ssh controls should really just be defined once. In addition all CIS/DISA baselines have known challenges with minimal-linux environments like Docker containers. Therefore, I believe the following approach works best:

• by combining many dev-sec baselines (eg. linux + ssh) users should be able to cover or be close to meet CIS/DISA requirements
• it is okay to implement controls defined by CIS and NIST
• it is important that our dev-sec controls are not following the same number scheme as one baseline e.g CIS in specific is changing number schemes between release versions which leads to a very unreliable baseline implementation, CIS and DISA control ids should be mapped via InSpec tags
• dev-sec splits controls by logical component not by baseline

Does that make any sense?

[artem-sidorenko]

@naman this is a very good point. I share the view of @chris-rock here completely

Just to bring a similar example from my employer: I had a similar discussion within DT last week. DT has its own security papers and requirements, 80-90% of them are identical with CIS/DISA/.... So my colleagues are trying to establish internally something like dev-sec.io: basically a marketplace where any project or technical user can just pull the baseline/implementations and after executing them you can be sure that the system is compliant to the given security requirements.

It's not possible for DT to rely completely on dev-sec.io:

• because of compliance rules (dev-sec.io is independent OpenSource project)
• and dev-sec.io might cover (or not) different things differently then DT wants.

The idea we had in this discussion is:

• to establish new baselines/implementations in a wrapper way
• to mirror dev-sec.io git repos to the internal code hosting system
• to wrap around dev-sec.io artefacts
• to use the fixed version bindings in dependency relations to dev-sec.io artefacts
• time-to-time to review the changes within dev-sec.io and to update the version bindings
• to push and use everything that makes sense from generic view to dev-sec.io
• everything else (DT specific things, things dev-sec sees differently) can be implemented within local wrappers of DT

[chris-rock]

@artem-sidorenko I recommend to use InSpec overlay profiles for that use case. Overlays can add additional tags to existing controls.

[artem-sidorenko]

@chris-rock thanks! this is the idea, we will see how it evolves..