Are STIGID and CIS identifiers or references?

[carlosmmatos]

per issue #6905 - @cipherboy posted the following:

If I understand correctly, references have historically been to external benchmarks. Identifiers have to be unique to a rule though.

Typically though, Identifiers are product-specific. Some products (such as SUSE and RHEL) have CCE numbers and assign them. Functionally, AFAICT, CCEs are the only identifiers in the build system.

References (with the exception of stigid and cis) are typically product-independent. They're not unique and multiple rules might have the same reference number and one rule might have multiple reference numbers.

But does this distinction matter?

Does it make sense to move stigid and cis to the identifier section and drop the strict uniqueness check?

Especially with the auto-profile tool based on product-independent reference controls -- we'd either need to add product-specific-ness into this tooling if we wanted to add e.g., CIS or STIG (essentially, in my view, recreating profiles) -- or we could agree that the definitions of "identifier" and "references" are a bit loose, given that the rule_id is the real identifier ;-)

My 2c.

We'd like to open up a discussion with the community surrounding the use of references/identifiers and how we can better understand their relevance in the overall project.

[alexhaydock]

While it's very helpful to have the references/identifiers in the compliance output for ease-of-auditing, as someone who deals with CIS a lot, their references/identifiers are... not super helpful. Not only do they differ between product but they also differ between version within the same product. A quick glance at the Summary Table Appendix in the RHEL 7 and RHEL 8 CIS benchmarks shows that while most of the rules have the same identifiers when they appear in both, it's not always the case. To pick a quick example, CIS 3.3.2 for RHEL 8 deals with disabling SCTP, while CIS 3.3.2 for RHEL 7 is about ICMP redirects.

As long as we can provide every rule from the benchmark to audit against, I'm not 100% sure it's that useful to be carrying out all the extra legwork to make sure all the references and identifiers are present. Honestly, I'd personally be more interested in the static rule_id myself if it was made more visible and was consistent across products and versions.

[cipherboy]

I was just not sure if you are suggeting differentiating among CIS references based on benchmark versions. Are you? like cis@[email protected]?

Ohhhh no. I just meant in the profile :D

e.g., from the draft PR for Ubuntu 20.04:

description: |-
 This baseline aligns to the Center for Internet Security
 Ubuntu 20.04 LTS Benchmark, v1.0.0, released 07-21-2020.

That's where I'd record the version number.

I think maintaining historical references (cis@[email protected]) would be wayyyy more work than I'd want to do ;-)

[yuumasato]

I think maintaining historical references (cis@[email protected]) would be wayyyy more work than I'd want to do ;-)

Agree, maintaining historical references would be too much work.

@alexhaydock

I can only speak for myself, but personally I'd benefit much more from static rule_ids being exposed more visibly since I'd rather rely on those.

Can you expand on this?
I'm not sure where you are headed, cause I think the HTML reports list the rule ID.

[alexhaydock]

Can you expand on this?
I'm not sure where you are headed, cause I think the HTML reports list the rule ID.

I think what I was thinking was mostly that CIS references/identifiers have been a pain point for me before personally when auditing a diverse environment, since the rule identifiers aren't consistent between systems or versions of the same system. But inside CaC, that static rule ID exists for each rule which is a great way to unify the same rule across all the different CIS benchmarks.

It's not something I'm doing yet but I think for my own audit & reporting purposes I was thinking I might switch away from using CIS identifiers and towards using the CaC rule IDs. On that basis, I figured it would be nice if they were "more visible" in the HTML reports. Ideally in the main table alongside the Severity / Result columns. But the rule IDs can be quite long so, when I think about it, there's probably not a clean way of doing this without destroying the well-formatted HTML tables that currently exist. And you're right to point out that the rule ID is already available in the output if you look for it specifically by clicking the rule name. I think that will probably serve me well enough for my needs currently.

[yuumasato]

Not sure if you meant HTML tables or report. Some policies have HTML tables for the references, did you mean that?

RHEL products generate these tables for CIS for example: build/tables/table-rhel8-cisresfs.html
Does that seem useful?
Looking at it now, I see it doesn't list the rule ID, so that is probably what you meant, :)

[matejak]

FYI, are also new-style tables at build/tables/tables-<prodname>-all.html that generate the table HTML based on a Jinja template using the tiny gen_tables.py script. That script could be extended with little effort to be able to provide reference tables to support significant workflows.

Another thing that you may find interesting is that we contemplate to introduce a simplified JSON output for the OpenSCAP scanner. That output would come as an addition to current SCAP-compliant outputs, and it would make it easy to take the results, and process them in a higher-level application. See e.g. OpenSCAP/openscap#1555 and if you have concrete ideas what such output should consist of, open a new feature request issue in the project.