How do the CIS benchmarks here map to the ones published by CIS?

[alexhaydock]

I've been looking at the CIS benchmarks provided here and I'm struggling to understand or find any documentation about how they map to the benchmarks published by CIS.

CIS publishes 4 different levels of benchmark (at least for RHEL, which is what I've been testing with):

• Level 1 - Server
• Level 1 - Workstation
• Level 2 - Server
• Level 2 - Workstation

Can anyone help me understand how the one "unified" CIS benchmark file maps to the published standards?

Is there any appetite to expand coverage to the Level 2 benchmarks in future?

[vojtapolasek]

Hello @alexhaydock , currently CIS profiles do not distinguish among various CIS mappings at all. I believe you could use CIS references to keep track of levels, but I understand this is not what you want.
Creating profiles with only level1 or leve2 mappings should not be very difficult. We can use our recent implementation for policy specification which is currently used for ANSSI profiles.
It is planed but I am not able to tell you when it will be available.

[alexhaydock]

Thanks for the info! I've been looking into it and whether there's any way I could contribute but I just wanted to understand the landscape first.

It seems like the XCCDF benchmarks published by CIS themselves might not be fully compatible with oscap and in any case I think they're only available to CIS SecureSuite members with access to CIS-CAT Assessor Pro.

I have a use case for applying and auditing against Level 2 benchmarks specifically and it'd be super useful to get this working with OpenSCAP so I can handle all the compliance & remediation through Satellite without needing CIS's own tool.

Do you have any links or information to current roadmaps/progress with regard to creating specific "Level 1" / "Level 2" style mappings? I'd love to be able to see where things are and whether I'm able to contribute.

Thanks!

[alexhaydock]

I've been having a look at this and I can see how the .profile files work, and I can see cis.profile. I can also see how the rules are defined. This seems relatively easy to understand as someone with Ansible experience so hopefully I might be able to contribute a bit here.

I've looked at the ANSSI profiles you've suggested and I can see where they're clearly split into Minimal, Intermediary, High, and Enhanced. This does definitely seem very similar to the CIS approach, but I'm struggling to work out where the modular .policy files for ANSSI pull their rules from.

I see references like:

selections:
  - anssi:all:intermediary

and I'm not entirely sure where it's pulling the "intermediary" definitions from. Where would this be?

If I can find this out then I'm willing to do the legwork of trying to update the CIS profiles to use a modular approach if a PR would be welcomed for that.

[vojtapolasek]

Great to hear that. You can see ANSSI definitions here, it should be prety self-explanatory.
https://github.com/ComplianceAsCode/content/blob/master/controls/anssi.yml
How does that look?

[alexhaydock]

Ah yes, this makes total sense. Looks nice and easy to work with!

I'll see what I can do when it comes to CIS though sadly my ability to contribute might be restricted just to RHEL. Hopefully modular-izing the current RHEL CIS content this way wouldn't compromise the CIS profiles for other OSes.

[vojtapolasek]

No problem at all. You can apply this only to rhel profiles, other products can follow later. We will be very grateful if you contribute this change.

[alexhaydock]

I'm trying to do some work on this now but I'm struggling to work out how the levels are applied. I can see, for example, this in the ANSSI intermediary policy file:

selections:
  - anssi:all:intermediary

And I can see clearly how that maps to rules inside anssi.yml which you linked above.

But how does the levels declaration at the start of anssi.yml get applied?

I see it defines 4 levels, which matches up with the 4 levels of benchmark:

levels:
  - minimal
  - intermediary
  - enhanced
  - high

And then throughout the rest of the file, the rules are mapped to one of these levels. But I notice that each rule is only mapped to a single level. The developer docs don't make it clear how these are being applied. It would make sense for there to be a lot of overlap between policies so, for example, the high profile might include all of the rules from the intermediary or minimal profiles as well as some extra, but I can't see how this logic is being applied.

Is it the case that the "levels" are evaluated in order and the lowest on the list automatically includes all the rules from the levels above?

I'm concerned that this approach might not work for CIS since it's only based on levels of severity to some degree - there is "Level 1" and "Level 2" which operate the way I described above, but the CIS benchmarks are also split into "Workstation" and "Server" categories which don't have 100% overlap.

If anyone can help me understand exactly how the selections: in the .profile file maps to the definitions in the controls/anssi.yaml file that would be super helpful, thanks!

[alexhaydock]

Edit: This was getting long and straying from the original point so I moved this post to a more sensible place in its own thread and expanded it.

[gunchamalik]

@alexhaydock Hi.. I am new to ComplianceAsCode and would like to contribute.. please let me know if you need any help with the work you were planning to start

[alexhaydock]

@alexhaydock Hi.. I am new to ComplianceAsCode and would like to contribute.. please let me know if you need any help with the work you were planning to start

Hi @gunchamalik! It's great that you'd like to get involved. I'm quite new to the project myself so perhaps others can provide you with some good pointers on first issues to solve - I'm aiming to take inspiration from what @vojtapolasek has done to improve CIS support on RHEL 7 with #7108 and rework a PR I already opened (#6976) to do the same for RHEL 8. I'm not sure if there' much else to be done there but I'd be happy for you to look over it when I update it.

When it comes to CIS compliance though, there's still quite a few outstanding issues for RHEL 8 in particular before all of the CIS controls are covered. I'm not sure if it's the kind of thing you're looking for, but there's a project here with a bunch of outstanding issues that need resolving before we're at complete CIS coverage for RHEL 8. I've been working on a few myself but I'm still learning the structure of the project overall and the maintainers have been a great help along the way.

[cipherboy]

Definitely, welcome @gunchamalik!

If you need help or pointers with the upstream CIS Security community (https://www.cisecurity.org/), feel free to ask. But in general, find something you're interested in and go from there. :-) @alexhaydock gave some good pointers into the CIS world, but there's a lot of open issues unrelated to CIS but would benefit CIS still -- if you've experienced something (and want to fix it) feel free to open a PR or file an issue if you want to discuss how to. Or even if you find a new bug, feel free to point it out and fix it.

There's a documentation pull request by @vojtapolasek (#7063) that I'd definitely take a look at -- we need fresh eyes on our documentation to tell all of us who've been around forever what we're missing due to familiarity :D

[marcusburghardt]

@alexhaydock and @gunchamalik , thanks for the interest and participation.
I just would like to mention about the good first issues, which is a great starting point to contribute. Any contribution is welcome!