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

Activity

1. chris-rock commented on Feb 13, 2019

   

   chris-rock

   on Feb 13, 2019

   Last edited by chris-rock

   Member

   More actions

   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?

   👍React with 👍3Reacted by Naman Gupta, Artem Sidorenko and Steven Haddox
2. artem-sidorenko commented on Feb 13, 2019

   

   artem-sidorenko

   on Feb 13, 2019

   Member

   More actions

   @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
3. chris-rock commented on Feb 13, 2019

   

   chris-rock

   on Feb 13, 2019

   Member

   More actions

   @artem-sidorenko I recommend to use InSpec overlay profiles for that use case. Overlays can add additional tags to existing controls.
4. artem-sidorenko commented on Feb 13, 2019

   

   artem-sidorenko

   on Feb 13, 2019

   Member

   More actions

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