dev-sec
Normative specification as a benchmark in an audit - CIS or DISA
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 https://github.com/dev-sec/ansible-os-hardening/issues/76
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?
@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
@artem-sidorenko I recommend to use InSpec overlay profiles for that use case. Overlays can add additional tags to existing controls.