Rule identifiers should be “lifetime identifiers”

[bgro]

The XCCDF specification should require that identifiers stay valid for the complete lifetime of a rule and must not depend on chapter-section-subsection structures which are bound to change from revision to revision of a document, as is, e.g., currently the case with CIS benchmarks.

Even if the content of a rule changes from one version of a baseline to the next version, the identifier must remain the same -- identifiers are not the same as a configuration enumeration!

[wmunyan]

Agreed. If it is agreed that the Rule ID is that identifier, I'm OK with that. If there is another globally-unique "lifetime" identifier attached to the rule that remains with that rule as long as it exists that is OK too. Definitely agree with the intent of this issue, though.

[redhatrises]

Wondering if we are suggesting something other than CCE?

[bgro]

I'd love to have a CCE that actually works and is up-to-date, but that is a separate issue. What I really need is that a rule that had a certain number in V1.1 of a document does not suddenly have a completely different number in V1.2 of the document. Everything else creates a huge amount of work whenever we have to deal with the update of some baseline.

[wmunyan]

@bgro I am curious, have you seen this issue arise in content other than CIS benchmarks? As a CIS representative here, I can confirm this behavior in our benchmarks, but if its just us, then obviously we need to fix it sooner rather than later (and its already later)

[bgro]

Well, CIS is the main culprit, so to speak. I am not terribly fond of DISA's way of including the revision number of a rule in the rule's id, but in that case you can really argue both ways and the important thing is: you do get a clear relationship between older and newer rules.

So yes, ANYTHING to solve that issue with CIS quickly would be welcome -- and if it's only a reference citing the primary key of the rule in the database of the workbench: anything, as long as it stays the same over different versions of a benchmark and can be included quickly in the XML export somehow!

[DavidRies]

I agree that we need a better way to track rules across benchmark versions. But, we will need to give this some more thought. There isn't always a 1-to-1 relationship between rules across versions. Sometimes multiple rules are refactored into a single rule and vice-versa.

[bgro]

Yes, but it seems that 95% of rules that are transfered from one version of a baseline to the next have a 1:1 relationship: most are essentially unchanged (other for removal of typos, changes of wording, some additional explanation, all of which makes an automated matching that cannot rely on identifiers hard), some are changed in their essence (making an automated match even harder).

So, 1:1 relationships are the rule rather than the exception, and that should be reflected by the way in which identifiers are handled, I think. For the case that a rule really is refactored, then yes, we need new identifiers and an additional mechanism for tracking these relationships.

Making life easier for dealing with the 95% by clearly defining the way in which identifiers are intended seems to me to be the very definition of a low-hanging fruit ... :grapes:

[DavidRies]

I agree. Perhaps we can do both. What about this type of approach...?

When a new version of a Benchmark is released (i.e. the Benchmark ID remains the same and the Benchmark/version is incremented), we REQUIRE:

• If there is a 1-to-1 relationship between a rule in the benchmark and a rule in the immediately previous version of the benchmark then either:
  • the rule@id remains the same
  • OR the id changes and there is a new element under the rule specifying which rule@id was replaced by this new rule@id
• If the rule is new (does not replace one or more rules in the immediate previous version of the benchmark), the rule@id should be new (not present in immediate previously version of the benchmark)
• If there is a 1-to-many or many-to-1 or many-to-many relationship between one or more rules in the benchmark and one or more rules in the immediately previous version of the benchmark:
  • the rules in the benchmark should have new rule@ids
  • AND, the rules in the benchmark should have new element(s) under the each rule specifying which rule@id(s) they replaced

Does that make sense?

Examples

Example 1: Rule with new id replaces exactly one rule in previous benchmark version:

<xccdf:Rule id="xccdf_stig.disa.mil_rule_123" severity="low" weight="10.0">
     <xccdf:replaces_rule benchmark_version="7" rule_id="xccdf_stig.disa.mil_rule_120" />
     ...

Example 2: Rule replaces exactly two rules in previous benchmark version:

<xccdf:Rule id="xccdf_stig.disa.mil_rule_123" severity="low" weight="10.0">
     <xccdf:replaces_rule benchmark_version="7" rule_id="xccdf_stig.disa.mil_rule_120" />
     <xccdf:replaces_rule benchmark_version="7" rule_id="xccdf_stig.disa.mil_rule_121" />
     ...

Example 2: 2 rules replace one rule in previous benchmark version:

<xccdf:Rule id="xccdf_stig.disa.mil_rule_123" severity="low" weight="10.0">
     <xccdf:replaces_rule benchmark_version="7" rule_id="xccdf_stig.disa.mil_rule_120" />
     ...

<xccdf:Rule id="xccdf_stig.disa.mil_rule_124" severity="low" weight="10.0">
     <xccdf:replaces_rule benchmark_version="7" rule_id="xccdf_stig.disa.mil_rule_120" />
     ...

This would give authors the flexibility to change rule ids and refactor rules (combine, decompose, etc.) while allowing content consumers to track rules across benchmark versions.

[shawndwells]

If interpreting correctly, the issue is something like the following:

SCAP Datastream Version 1

Chapter 1 - Authentication
1.1 Rule Whiskey
1.2 Rule Foxtrot

Then future editions have some table of content restructuring, such as:

SCAP Datastream Version 2

Chapter 1 - Firewalls
1.1 Rule A
1.2 Rule B

Chapter 2 - Auditing 
2.1 Rule Whiskey
2.2 Rule Tango
2.3 Rule Foxtrot

In those scenarios, it behooves users to request their SCAP content producers to use CCE as static identifiers. That's what the CCE spec was made for.

Rule content can reasonably be expected to change. For example how RHEL moved from iptables in RHEL 6 to firewalld in RHEL 8 for "enable firewall" style guidance. In these scenarios the CCE would remain static (e.g. CCE-12345 Enable RHEL Firewall).

If content producers don't like CCE, they could always create their own <xccdf:ident> URI.

As an aside, OVAL does support having a version attribute but (to my knowledge) XCCDF does not.

Instead of a complicated replaces_rule scheme, could we update XCCDF to have version?

[DavidRies]

I agree that consistent use of <xccdf:ident> could address this.

But, I don't know much about CCEs. Do you know if CCEs are typically the same granularity as rules? I.e. is there typically a 1:1 CCE:Rule relationship? If not, this may not be a good solution.

Also, I was under the impression that there was some sort of overhead to creating and maintaining CCEs? Is that right? If so, that could be a challenge for this use.

If not, any idea why many rules don't have CCEs? For example, it looks like the current release of ssg-rhel8-ds.xml has CCEs for 533 of 1176 rules.

[shawndwells]

I agree that consistent use of <xccdf:ident> could address this.

👍

But, I don't know much about CCEs. Do you know if CCEs are typically the same granularity as rules? I.e. is there typically a 1:1 CCE:Rule relationship? If not, this may not be a good solution.

Each XCCDF rule has exactly one CCE.

Admittedly there is variation between how vendors use them though.

For example, at Red Hat, multiple versions of RHEL may have the same rule (e.g. Enable Host-Based Firewall). On RHEL 6 this would be implemented via iptables and RHEL 8 changed to firewalld. In such cases, Red Hat chose to create net-new XCCDF rules and each would have their own static CCE.

Also, I was under the impression that there was some sort of overhead to creating and maintaining CCEs? Is that right? If so, that could be a challenge for this use.

Our experience has been really great. Send an EMail to NIST, they give us a huge pool of CCEs, and we self-assign them to rules.

We choose to publish the pool of unused CCEs and let anyone in the community help with assigning them: https://github.com/ComplianceAsCode/content/blob/master/shared/references/cce-redhat-avail.txt

Example of a recent pull request that assigned CCEs to XCCDF rules lacking them: https://github.com/ComplianceAsCode/content/pull/5021

If not, any idea why many rules don't have CCEs? For example, it looks like the current release of ssg-rhel8-ds.xml has CCEs for 533 of 1176 rules.

Our build system only ensures CCEs are added to rules selected in enabled profiles. There are likely hundreds of rules added into the catalog but not enabled in profiles.

That said, my comment on consumers leaning on their content producers to have CCEs certainly applies to Red Hat too :) I'll look into the missing CCEs.

[DavidRies]

It seems we have general agreement on the problem to be solved and several good ideas. Perhaps we could specify that Rule IDs must remain the same when there is a 1:1 relation between the Rules across benchmark versions.

And, we could specify the CCEs should be used whenever possible to allow tracking of controls across versions including the 1:1 scenario as well as n:n.

[djhaynes]

CCE related discussion should be moved to a new ticket. There would be value in being able to validate CCEs and the mapping to rules (e.g., CCE between Windows 7 and Windows 8 are different, but, they reference the same control). Do we want to provide guidance around what is a rule and what changes to a rule indicate a revision to a rule versus what changes indicate a new rule.

ACTION: Bernd will go through the XCCDF specification, find occurrences of identifiers, and propose new text. Bernd will also provide guidance around changes to rules.

[shawndwells]

We (Red Hat) will specifically push against this. This would prevent us from following any future XCCDF standard that incorporates such things. Will most likely make following the standard commercially infeasible.

[DavidRies]

@shawndwells, I'm surprised to hear that--that certainly wasn't our intention! I, for one, expected this to be non-controversial, easy to implement, etc. We certainly wouldn't want to alienate content creators. I hope you can share a bit more about your perspective so we can solve the problem we are trying to solve in a way that doesn't not have a negative impact on Red Hat or other content creators.

The goal is to make it easier to track rules across versions of the same benchmark. Typically, when new versions of benchmarks are released, most the rules are identical or have minor modifications. However, some vendors change their Rule@IDs, making it harder to, for example:

• track Rule results over time (even as Benchmarks are versioned)
• migrate Tailorings from one Benchmark version to the next
• analyze the changes in Rules between Benchmark versions

We thought that maintaining consistent Rule@IDs across benchmark versions when the rules are the same would be a simple way to start addressing these issues. But, it sounds like that poses some sort of operational problem for Red Hat... is that right? Can you tell us more about the issues that would impose and share any thoughts you have on how we might avoid them?

[DavidRies]

I should also say that this was intended to be a "soft" requirement--a SHOULD, not a SHALL--with some language further qualifying the SHALL, leaving room for a content author to determine when the Rule is the same, etc.

[djhaynes]

The CCE related discussion should be moved to a new issue. There would be value in being able to validate CCEs and the mapping to rules (e.g., CCE between Windows 7 and Windows 8 are different, but, they reference the same control). Do we want to provide guidance around what is a rule and what changes to a rule indicate a revision to a rule versus what changes indicate a new rule.

ACTION: Bernd will go through the XCCDF specification, find occurrences of identifiers, and propose new text. Bernd will also provide guidance around changes to rules.

[bgro]

@shawndwells Can you elaborate a bit on what the problem is that you see? I certainly don't intend to make the creation and maintenance of XCCDF baselines commercially infeasible.

I'd like to understand why something that seems like a moderate and sensible change to me (amongst others) is seen as a major threat to the use of XCCDF by Redhat.

My motivation for wanting identifiers to stay the same as much as possible (even if the exact requirement posed by the rule changes from requiring setting ABC to setting XYZ for a certain configuration item) is to make tracking of what has changed and how I need to react easier.

After the meeting yesterday, I thought of an analogy: A parliament passes laws and numbers these laws. So for a given law, I have "§0815" or whatever. From time to time, laws are changed by parliamant. But parlimanent does not completely remove "§0815" in order to pass "§4711" which legislates the same issue but in a somewhat different way. No, parliament changes "§0815" and tells everybody that "§0815" has changed in the "release notes" provided with the law. That way, everybody can easily see that he has to update the provisions he took to follow law "§0815" and can still refer to all his activities, compliance check results etc. under the heading "with respect to §0815", rather than having to deal with a new "§4711" and always keeping in mind that the new "§4711" is really the old "§0815" ...

But: I don't want to create problems, I want to solve problems, so if stable identifiers are really a massive problem, then we need to rely on CCE, something CCE-like, or (if CCE does not work because it refers to the complete setting (i.e., configuration issue and chosen setting rather than only the configuration issue)), explicit relationships between rule IDs.

The beauty of keeping the ID stable would be that most authors are aware that they should not mess with IDs, whereas maintaining CCE or relationship info tends to be forgotten...

[redhatrises]

I have a bunch of concerns with requiring rule IDs for a global identifier.

1. It is a complete duplicate of the <ident/> element. From the spec, <ident/> is A long-term globally meaningful identifier for the issue, vulnerability, platform, etc.
2. Rule ID is truly not unique enough across multiple benchmarks and especially where benchmarks might be the same but produced from different vendors. Who wins when a benchmark with the same name but is implemented differently.
3. Reduces the flexibility of the spec for the cases where XCCDF is a top-level policy document that lower level XCCDF documents are then created. Rule IDs change in top-level policy documents breaking this. Also, there are no global identifiers in top-level XCCDF policy documents by design.
4. Doesn't really follow what the cybersecurity market already established for identifying security identifiers. e.g. CVE, CCE, CERT IDs, etc.

Having a stable Rule ID is like having a stable API which is good for downstream users, but it is not a good global rule identifier by any means.

[shawndwells]

On 12/19/19 2:59 PM, David E. Ries wrote:

I should also say that this was intended to be a "soft" requirement--a SHOULD, not a SHALL--with some language further qualifying the SHALL, leaving room for a content author to determine when the Rule is the same, etc.

Unfortunately that is not a meaningful or useful distinction. Well meaning procurement officers often take "SHOULD" and turn them into "SHALL" thinking their requirement is particularly special, without understanding the chain reaction of requirements this imposes on content producers.

[shawndwells]

On 12/19/19 4:08 PM, Danny Haynes wrote:

The CCE related discussion should be moved to a new issue. There would be value in being able to validate CCEs and the mapping to rules (e.g., CCE between Windows 7 and Windows 8 are different, but, they reference the same control). Do we want to provide guidance around what is a rule and what changes to a rule indicate a revision to a rule versus what changes indicate a new rule.

The existence and proper use of CCE seems to void need for this modification. They seem intrinsically linked.

If Microsoft is using CCEs improperly, that would be a conversation between NIST and Microsoft -- and an opportunity for NIST to start enforcing their standards.

ACTION: Bernd will go through the XCCDF specification, find occurrences of identifiers, and propose new text. Bernd will also provide guidance around changes to rules.

[shawndwells]

Red Hat had a global shutdown from prior to Christmas to this week. Don't mean for Gabe (@redhatrises) and I to seem like we're piling on. More like we're just getting back to EMails after several weeks. Thanks for understanding!

On 12/20/19 6:58 AM, Bernd Grobauer wrote:

@shawndwells https://github.com/shawndwells Can you elaborate a bit on what the problem is that you see? I certainly don't intend to make the creation and maintenance of XCCDF baselines commercially infeasible.

I'd like to understand why something that seems like a moderate and sensible change to me (amongst others) is seen as a major threat to the use of XCCDF by Redhat.

Vendors have lifecycle commitments. For Red Hat and our SCAP content, that means we are required to support SCAP tools and content for 10+ years after release. There's no way we can guarantee static XCCDF rule IDs for 10 years.

An example is when Linux transitioned from "init" to "systemd".

In that case, Linux vendors had existing rules regarding services, such as a generic "CCE-XXXXX: Enable System Firewall." Those rules most likely said something about "service firewalld start" in the past, and the new versions were updated to "systemctl enable firewalld." Same CCE, new version of the XCCDF rule.

From an XCCDF Rule ID perspective, that means rule IDs transitioned from something like "service_enable_firwall" to "systemd_enable_firewall." But the same CCE was kept since the rule was still evaluating the same purpose/action.

When Linux switched from iptables to firewalld is another example. Or when Linux dropped docker support and switched to CRI-O. Or the switch from Xen hypervisor to KVM years ago. There are many examples, and due to the 10+ year lifecycle, cannot be foreseen.

My motivation for wanting identifiers to stay the same as much as possible (even if the exact requirement posed by the rule changes from requiring setting |ABC| to setting |XYZ| for a certain configuration item) is to make tracking of what has changed and how I need to react easier.

After the meeting yesterday, I thought of an analogy: A parliament passes laws and numbers these laws. So for a given law, I have "§0815" or whatever. From time to time, laws are changed by parliamant. But parlimanent does not completely remove "§0815" in order to pass "§4711" which legislates the same issue but in a somewhat different way. No, parliament changes "§0815" and tells everybody that "§0815" has changed in the "release notes" provided with the law. That way, everybody can easily see that he has to update the provisions he took to follow law "§0815" and can still refer to all his activities, compliance check results etc. under the heading "with respect to §0815", rather than having to deal with a new "§4711" and always keeping in mind that the new "§4711" is really the old "§0815" ...

XCCDF addressed this with the version property:

https://github.com/scapcommunity/XCCDF/blob/master/docs/6_xccdf_model.md#641-properties

Akin to how there is NIST 800-53 rev3, NIST 800 rev5, etc.... there is CCE-XXXX ver1, CCE-XXXX ver2. Release notes from content vendors should cover the differences when versions are incremented.... but admittedly, not all vendors are created equally.

But: I don't want to create problems, I want to solve problems, so if stable identifiers are really a massive problem, then we need to rely on CCE, something CCE-like, or (if CCE does not work because it refers to the complete setting (i.e., configuration issue and chosen setting rather than only the configuration issue)), explicit relationships between rule IDs.

The beauty of keeping the ID stable would be that most authors are aware that they should not mess with IDs, whereas maintaining CCE or relationship info tends to be forgotten...

Strong agreement regarding the need to track what changed. That capability exists today between CCE and XCCDF version properties.If/when content authors are misusing them (eg not maintaining relationships, reassigning already used CCEs, etc) then we really should be pushing on NIST to properly enforce how CCEs are assigned/distributed/recognized.

Also -- the irony of me pushing for proper use/awareness of XCCDF version elements isn't lost. While Red Hat uses the version element for OVAL checks we've yet to implement them for XCCDF rules. No true reason why not though. At the end of the month Red Hat's global SCAP team will be together in person. Implementing XCCDF versions is on the agenda to discuss, largely in part because of this thread! :)

[bgro]

Thank you @shawndwells and @redhatrises for the detailed explanation of the problems you see with having stable rule IDs. I will try to come up with an overview of which of my problems would be solved by a working CCE scheme, and which would not be.

I usually talk about CCE in the past tense, because the latest complete mapping/description of existing CCEs I can find is from 2013 (https://nvd.nist.gov/config/cce/index) and I cant't find a CCE search field in the NVD. But from what @shawndwells writes about Redhat registering CCEs, CCE obviously is still alive.

Is there a mapping/search facility for CCE that also contains post-2013 CCEs?

Meanwhile:

As @shawndwells said, part of the problem may be that Microsoft uses/used CCE wrongly. For example, for the setting Auditing of 'Policy Change: Authentication Policy Change' events on failure should be enabled or disabled as appropriate. we have CCE-10874-6 for Win2k8r2 and CCE-10014-9 for Windows 7. Same setting, different CCE for different versions of the OS.

[DavidRies]

It looks like Red Hat and CIS use XCCDF:Rule@Ids that are closely tied to the check implementation and/or guidance in the Rule:

CIS Sample XCCDF:Rule@Ids:

• xccdf_org.cisecurity.benchmarks_rule_1.2.2_L1_Ensure_Account_lockout_threshold_is_set_to_10_or_fewer_invalid_logon_attempts_but_not_0
• xccdf_org.cisecurity.benchmarks_rule_2.3.6.2_L1_Ensure_Domain_member_Digitally_encrypt_secure_channel_data_when_possible_is_set_to_Enabled

Red Hat XCCDF:Rule@Ids:

• xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd
• xccdf_org.ssgproject.content_rule_kernel_module_freevxfs_disabled

This helped me understand why it could be challenging to maintain consistent Rule@Ids at least when guidance changes.

I had expected the rule ids to be opaque or something tied to the rule at a higher level.

[djhaynes]

1/15: Bernd Grobauer will go through this issue at the next teleconference.

[bgro]

@DavidRies : For CIS, what I think of as the rule's identifier is the 2.3.6.2 part in xccdf_org.cisecurity.benchmarks_rule_2.3.6.2_L1_Ensure_Domain_member_Digitally_encrypt_secure_channel_data_when_possible_is_set_to_Enabled. Around the time you wrote the comment, I had myself realized, that what I really want is a stable "handle" by which somebody will refer to a given rule. Whether the id field is used for this (probably not, as the discussion so far shows) or the ident element, is not so important. But when we go through the issue in a little while, I will show why "CCE" is not quite what is needed, either...

[bgro]

In order to stay neutral about how the feature for which requirements are described below, I shall not call it 'identifier' or 'reference' or similar, but will use the somewhat artificial term "handle".

Requirements:

1) Requirements

Consumers of a baseline refer to a rule in the baseline by its handle. Consumers have the following requirements on the handle:

a) The handle of a rule MUST allow users to reference the rule in a unique way (possibly in combination with a second piece of information identifying, e.g., the document in which the rule is contained.

  Note: The CIS chapter number fulfills this requirement for a handle,
  as long as it is combined with an identifier for the baseline
  *AND* the baseline's version (see c and d below)

b) The handle SHOULD displayed prominently when viewing the rule in a document or PDF such that everybody understands immediately that the handle is used to refer to a particular rule. Digital representations of a baseline SHOULD allow access to rules via the handle (search in a web interface, API access)

  Rationale: When exchanging information about a rule 
  (asking for exceptions, referencing the rules in scripts,
  scan policies, just talking about rules between IT personnel
  and InfoSec personnel), something is needed to reference
  that rule in a meaningful way. It must be obvious what that
  something should be.

c) In different versions of a baseline, the handle of a rule MUST stay the same, if (1) the new version of the rule is concerned with the same issue (even though the prescribed requirement may have changed) and (2) there is a clear one-to-one relationship between the old version of a rule and a corresponding rule in the new version of the baseline.

  Remarks:

  - there is, e.g., not a clear one-to-one relationship, if a
    single rule is refactored into many rules or the the other way
    around).

  - what is "the same issue" will be debatable once in a while
    (witness Redhat's example of a rule for which the CCE
    stayed the same, but the name changed because it applied
    to a different piece of software. For such cases, see
    a) below.

  Rationale: 

  This is expected behavior: something that treats the
  same issue (even though there are changes in what is
  prescribed) is referred to by its established name.
  Otherwise, all existing references that exist
  in people's minds, paper or some digital form
  become meaningless (or at least hard to track down).

d) Handles MUST NOT be reused/reassigned from one issue to an unrelated issue.

  Rationale: anything else will lead to confusion.

e) If the handle of a rule cannot be kept from one version to the other (e.g., because is refactored or there are very good reasons for changing the handle so as to keep in line with user expectations) there SHOULD be references from the newly created rule(s) back to the rule(s) in the old version of the document which use the corresponding handle(s) of the rule(s) in the old document, using the XCCDF referencing mechanism.

f) Rules treating the same issue in different documents SHOULD have handles which make the 1-1 correspondence between the rules obvious, e.g. by re-using a part that is common to both handles.

  Example: a handle could be multi part, containing both a document
  id and a part that corresponds to the issue treated in the rule.
  If the same issue is treated in a different document, e.g., 
  a baseline for a related OS (Windows 10 vs Windows Server 2016),
  the document id would vary but the issue-part would stay the same.

Issuers of baselines have additional requirements:

Notes.

a) The syntax of handles MUST be as flexible as possible, allowing issuers to call rules pretty much anyway they like.

b) (related to g): The ability to assign handles lies with the baseline issuer rather than a central authority (such as NIST for CCE). (That is not to say that a central registry would not make sense, but the issuer MUST be able to issue handles without asking somebody else.)

c) Is the handle the same as a CCE number?

No:

1) There may be a need for constituency-specific handles within baselines -- this is very different from registering a CCE number

2) Depending on how a baseline is structured, there is not necessarily a 1-to-1 relationship between rules and CCEs:

  - different requirements for a given setting/issue (= one CCE) may
    be formulated as different rules. For example:

    - different rules for member server vs domain controller
      for the same setting in CIS baselines
    - different rules for the same setting/issue with respect
      to different criticality levels

3) Is the handle the same as a rule identifier:

No, because handle in most cases will have to be shorter than a full identifier, which in most cases will include also a part denoting the issuer and possibly document.

But an identifier could be built such that it contains the handle.

4) What options do we have

a) Specify that a rule SHOULD (or even MUST) contain a handle using the XCCDF reference/ident mechanism b) Specify that the identifier of a rule should contain a handle

I would favor (b), because I have little confidence that the reference/ident field will be treated with the same diligence as the rule identifier, simply because the rule identifier is absolutely necessary for the workings of XCCDF

The thread above shows strong opposition to (b), but I wonder whether 1e above (which states that there may be reasons that a handle is not kept and stipulates "only" that a back-reference is given) might maybe help to remove the main obstacle to stable handles as part of the identifier.

[djhaynes]

David Ries: Seconds the need for handles. We are getting more and more requests to help people who are consuming benchmarks to migrate tailorings across benchmark versions and change tailorings across benchmarks. One of the challenges at the mechanical level is the correspondence between rules in the benchmark and is not trivial and is an obstacle and some type of handle would be valuable for organizations that are using benchmarks upstream and preparing them for users.

[djhaynes]

Gabe: This impacts everyone and needs discussion from the broader group.

David Ries: Bernd and Joval would like to have something that serves as a handle. This really puts a burden on the content creator (e.g., CIS or Red Hat), but, Bernd is flexible. Assuming the content creators are opposed, it would be great to hear their approaches to solving this that wouldn't be burdensome.

Bill: We are pretty flexible and willing to continue the discussion since we have a platform for managing this information. Those options wouldn't be okay and we have identifiers in our content and this wouldn't be a huge lift for us, but, more of needing to understand how it goes into the benchmarks and how it might differ across different versions of benchmarks. We are okay with what the group decides.

Gabe: we see this as a duplicative effort because we are mandated to use CCEs, but, there are questions about handling handler collisions where you have a central authority come into play. Is the identifier something someone can fake. DISA create upstream policies in XCCDF, if they don't have a handle, what happens. How are we going to validate that something has changed. Maybe this should be an optional component.

Bernd: I don't know enough about how Red Hat uses CCEs, is it both your software and benchmark about the software, can't that be managed.

Gabe: the question becomes for those who don't have to go through SCAP Validation and have a CCE per rule. If you don't have to use CCEs Bernd's point is valid.

Bernd: Looking at the CCE spreadsheet each one is aligned with a setting (e.g., GPO, etc.).

Gabe: Every rule has a CCE.

Bernd: Where can I learn more about the new process for CCE? Gabe: We asked NIST to document the process for CCE.

David Ries: Looking at CCE there isn't content for newer content. There is a difference between there being a CCE for every rule and there actually being a CCE for every rule.

Gabe: Yeah, as far as RHEL 8, if there isn't one it is because it hasn't been validated yet. The ident is a unique identifier.

David Ries: I don't think it is. I think it is an identifier to an external system. Maybe this is a case where we aren't following our own rules.

Adam: Are we talking about aligning CCEs with rules?

David Ries: A bunch of us would like to have a mechanism to correlate rules across benchmark versions. CCE is one approach.

Adam: I think that using CCEs as a way to identify a rule is a mistake. It is the setting not the recommendation for that setting.

Bernd: That was my understanding.

Bill: The ident element for XCCDF is something to consider.

Bernd: Maybe an approach for presenting this is we could discuss the consumer side of this issue and then the content side of the issue.

ACTION: Bernd, David Ries, and Bill would be willing to help out on this issue for the workshop

[redhatrises]

Suggestion from today's workshop:

Use <xccdf:ident> and reference unique identifier like:

<ident system="https://mysite.com/myids">MYID</ident>

An optional attribute could be added to the above like xccdf-id="true" like:

<ident xccdf-id="true" system="https://mysite.com/myids">MYID</ident>

[bgro]

I will fork the Markdown-version of the current XCCDF content and make a proposal of what kind of guidance could be added regading this issue.

[bgro]

Please refer to

https://github.com/scapcommunity/XCCDF/pull/28/files

for a proposal of how to address this issue with an update of the XCCDF specification.

The proposal builds on the consensus reached during the SCAP workshop in March 2020 that the ident element should be used.

I have added a proposal that ident with an additional attribute should also be used to provide references in cases where a lifetime reference identifier cannot stay the same or there is noe clear one-to-one relationship.

Currently, the proposal speaks of 'lifetime reference identifier' rather than 'handle': I am not sure what the best terminology would be.

[bgro]

In preparation for todays meeting: an examination of the scope of LRIs:

Requirement: the following two rules are essentially the same rule, the first in the CIS Baseline for Windows 10 (1909), the second for Windows 10 (1809)

 <xccdf:Rule id="xccdf_org.cisecurity.benchmarks_rule_18.8.49.1_L2_Ensure_Turn_off_the_advertising_ID_is_set_to_Enabled" role="full" selected="false" weight="1.0">
          <xccdf:title xml:lang="en">(L2) Ensure 'Turn off the advertising ID' is set to 'Enabled'</xccdf:title>
          <xccdf:description xml:lang="en">
            <xhtml:p>This policy setting turns off the advertising ID, preventing apps from using the ID for experiences across apps.</xhtml:p>
            <xhtml:p>
The recommended state for this setting is:               <xhtml:span class="inline_block">Enabled</xhtml:span>
.            </xhtml:p>
          </xccdf:description>
          <xccdf:rationale xml:lang="en">
            <xhtml:p>Tracking user activity for advertising purposes, even anonymously, may be a privacy concern. In an enterprise managed environment, applications should not need or require tracking for targeted advertising.</xhtml:p>
          </xccdf:rationale>
          <xccdf:ident cc6:controlURI="http://cisecurity.org/20-cc/v6.1/control/13" system="http://cisecurity.org/20-cc/v6.1"/>
          <xccdf:ident cc7:controlURI="http://cisecurity.org/20-cc/v7.0/control/13/subcontrol/3" system="http://cisecurity.org/20-cc/v7.0"/>
          <xccdf:ident system="http://cce.mitre.org">CCE-33823-6</xccdf:ident>
          <xccdf:fixtext xml:lang="en">

<xccdf:Rule id="xccdf_org.cisecurity.benchmarks_rule_18.8.47.1_L2_Ensure_Turn_off_the_advertising_ID_is_set_to_Enabled" role="full" selected="false" weight="1.0">
    <xccdf:title xml:lang="en">(L2) Ensure 'Turn off the advertising ID' is set to 'Enabled'</xccdf:title>
    <xccdf:description xml:lang="en">
    <xhtml:p>This policy setting turns off the advertising ID, preventing apps from using the ID for experiences across apps.</xhtml:p>
    <xhtml:p>
The recommended state for this setting is:               <xhtml:span class="inline_block">Enabled</xhtml:span>
.            </xhtml:p>
    </xccdf:description>
    <xccdf:rationale xml:lang="en">
    <xhtml:p>Tracking user activity for advertising purposes, even anonymously, may be a privacy concern. In an enterprise managed environment, applications should not need or require tracking for targeted advertising.</xhtml:p>
    </xccdf:rationale>
    <xccdf:ident cc6:controlURI="http://cisecurity.org/20-cc/v6.1/control/13" system="http://cisecurity.org/20-cc/v6.1"/>
    <xccdf:ident system="http://cce.mitre.org">CCE-33823-6</xccdf:ident>
    <xccdf:fixtext xml:lang="en">

Currently I have to use all kinds of heuristics and tooling to match these two rules. Here, the title is the same, but that is nothing which I can rely upon.

So I want to have something like the following

• Option 1:

  both rules have exactly the same LRI, say

  <xccdf:ident system="uri:xccdf:lri:cisecurity.com">BL3HBL</ident>

  where BL3HBL is a shortish but unique string (shorter than a uuid or a hash, because I want to be able to refer to it verbally).

  Consequence: you CANNOT use BL3HBL for constructing a URL which displays one rule, because it refers to several rules at the same time (namely the rule in 1809, in 1909, ...)

• Option 2:

  the rules have a two-component LRI:

  <xccdf:ident system="uri:xccdf:lri:cisecurity.com">1809-BL3H</ident>

  and

  <xccdf:ident system="uri:xccdf:lri:cisecurity.com">1909-BL3H</ident>

  where

  • 1809 and 1909 refer to the baseline (could be anything else, ABC, X0511, whatever)
  • BL3His a shortish but unique string (shorter than a uuid or a hash, because I want to be able to refer to it verbally); here it can be very short, because it must only be unique within the family of baselines that are the Windows OS baselines

• Option 3:

  Like option 2, but we make this two-component structure explicit

  <xccdf:ident system="uri:xccdf:lri:cisecurity.com" variant='1809'>BL3H</ident>

  and

  <xccdf:ident system="uri:xccdf:lri:cisecurity.com" variant='1909'>BL3H</ident>

  where I call the first component "variant", because it is the variant of rule BL3H present in the baseline for release 1809.

If we want to provide two-component LRIs, then option 3 is probably the cleaner solution. If an issuer does not want/need variants (such as would be the case for Compliance as code, I think,), then the variant can be left away.

Alternatively: option 1, but the consequence is that you cannot use the LRI to derive a URL pointing to a specific rule in a specific document, but to a set of rules (e.g. all rules with the same LRI in the most current documents of a given publisher).

[DavidRies]

Hi Bernd,

At the risk of being pedantic, I have a process/scope question. It sounds to me like we are changing the scope of the problem we are trying to solve. That’s ok—I just want to be clear about it so we all agree on the problems we are addressing.

Initial Problem: rule@ids often change between versions of the same benchmark making it hard to identify that rule_a in benchmark_v1 is actually the same as rule_b in benchmark_v2. Primarily we wanted a simple solution for this type of 1:1 relationship. Secondarily, we also wanted to have some lightweight support for when rules are refactored and there is an n:n relationship (simply an indication that the refactored rules are related, without needing to specially define the nature of the relation).

New Problem: we don’t have a reliable way to identify when rules in different benchmarks are essentially the same rule. This seems similar to what CCEs are intended for, but I think the issue is that CCE are platform-specific so they can be used to identify the “same rule” in benchmarks for different platforms.

Put another way, initially, we were trying to fix a rule@id problem and now we are trying to solve a CCE problem.

Is that a fair summary?

-David David E. Ries Co-Founder, Business Development ries@jovalcm.com mailto:ries@jovalcm.com https://jovalcm.com/ https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring

On Nov 12, 2020, at 6:55 AM, Bernd Grobauer notifications@github.com wrote:

In preparation for todays meeting: an examination of the scope of LRIs:

Requirement: the following two rules are essentially the same rule, the first in the CIS Baseline for Windows 10 (1909), the second for Windows 10 (1809)

(L2) Ensure 'Turn off the advertising ID' is set to 'Enabled' This policy setting turns off the advertising ID, preventing apps from using the ID for experiences across apps. The recommended state for this setting is: Enabled . Tracking user activity for advertising purposes, even anonymously, may be a privacy concern. In an enterprise managed environment, applications should not need or require tracking for targeted advertising. CCE-33823-6 (L2) Ensure 'Turn off the advertising ID' is set to 'Enabled' This policy setting turns off the advertising ID, preventing apps from using the ID for experiences across apps. The recommended state for this setting is: Enabled . Tracking user activity for advertising purposes, even anonymously, may be a privacy concern. In an enterprise managed environment, applications should not need or require tracking for targeted advertising. CCE-33823-6 Currently I have to use all kinds of heuristics and tooling to match these two rules. Here, the title is the same, but that is nothing which I can rely upon. So I want to have something like the following Option 1: both rules have exactly the same LRI, say BL3HBL where BL3HBL is a shortish but unique string (shorter than a uuid or a hash, because I want to be able to refer to it verbally). Consequence: you CANNOT use BL3HBL for constructing a URL which displays one rule, because it refers to several rules at the same time (namely the rule in 1809, in 1909, ...) Option 2: the rules have a two-component LRI: 1809-BL3H and 1909-BL3H where 1809 and 1909 refer to the baseline (could be anything else, ABC, X0511, whatever) BL3His a shortish but unique string (shorter than a uuid or a hash, because I want to be able to refer to it verbally); here it can be very short, because it must only be unique within the family of baselines that are the Windows OS baselines Option 3: Like option 2, but we make this two-component structure explicit BL3H and BL3H where I call the first component "variant", because it is the variant of rule BL3H present in the baseline for release 1809. If we want to provide two-component LRIs, then option 3 is probably the cleaner solution. If an issuer does not want/need variants (such as would be the case for Compliance as code, I think,), then the variant can be left away. Alternatively: option 1, but the consequence is that you cannot use the LRI to derive a URL pointing to a specific rule in a specific document, but to a set of rules (e.g. all rules with the same LRI in the most current documents of a given publisher). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or unsubscribe .

[bgro]

Summary of the results of the discussion during workgroup meeting on 2020-11-13:

• An LRI has the form

  <xccdf:ident system="urn:xccdf:lri:PUBLISHER">LRI_STRING</ident>

  i.e., the an LRI is always qualified by the publisher, e.g. 'cisecurity.org', 'siemens.com', ...

• An LRI MUST be unique within a baseline document.

• When a baseline evolves in its versions/revisions, the expectation is that LRIs do not change, even though the contents of the rule may change, as long as the publisher considers the new version of the rule an evolution of the older version.

• The same LRI may occur in related baselines of the publisher (e.g., there may be baslines for Windows Client operating systems and Windows Server operating systems which are two separate documents but where many rules are the same or at least closely related). The clear expectation is that if two rules in two different document have the same LRI, they are closely related (e.g., they treat the same configuration setting).

• Because the same LRI may occur in different documents, a URI for the rule must be derived from two components: (1) the baseline in which the rule is contained and (2) the LRI of the rule.

• LRIs are different from CCE because

  • a baseline may very well contain two rules that map to the same CCE (e.g., a rule concerning the same configuration setting, but one variant is applicable for member servers, the other for domain controllers)
  • LRIs can be managed by a publisher, wheras CCEs must be managed or at least co-ordinated by a central body