Customizing Import Applicability Levels

[eddie-knight]

I'm coming up against an issue we anticipated but kicked down the road: imported applicability levels.

We suspected this would become an issue, but avoided addressing it until we hit it in reality. Here it is:

As the author of an upcoming control catalog I would like to import a number of entries from a previous authoritative catalog with my catalog's applicability groups applied to the imported controls.

Specifically, the CRAB-FOMA catalog is not designed for nuance — everything is considered applicable in all situations. So by that measure, the baseline controls need to have a new applicability level appended so that downstream tools know to run every imported control instead of using applicability filtering.

This could be split into two problems or addressed together... I'm okay with skipping the first as unnecessary, but want to ensure it's considered.

1. Do we create a mechanism for flagging everything as applicable without requiring re-statement inside of every requirement?
   • e.g. applicability: [all]
2. How do we custom tailor imports to use applicability overrides or extensions?
   • e.g. Add an applicability field to the imports entries.

[jpower432]

Can we start with an ADR?

The core question I have is what happens to source applicability values when a catalog imports or extends controls from another catalog.

A few things the ADR could work through:

• Does the importing catalog replace, extend, or inherit the source's applicability?
• Bulk (import-level) vs per-entry granularity
• What downstream tools resolve — original values, overrides, or both

We could scope it narrowly to the immediate problem: letting an importing catalog assign its own applicability context to imported controls. Finer-grained cases (per-entry overrides, additive applicability) can follow once the base mechanism is in place.

WDYT?

[eddie-knight]

Agree that this needs to become an ADR after it's been properly considered, to lock it in before any changes are made.

Does the importing catalog replace, extend, or inherit the source's applicability?

I'm thinking that it will inherit the source applicability by default, and overwrite if any values are supplied.

Bulk (import-level) vs per-entry granularity

If we allow for bulk rewrites then it would need to be a mapping of sorts: X becomes Y. I don't know whether I'm a fan of that. My initial thought was to only allow for import entries to be modified one at a time.

What downstream tools resolve — original values, overrides, or both

Importing tools will ideally know to use the overrides if they are provided.

[jpower432]

Sounds like we we are aligned. So when flattened, the applicability-groups will include all inherited groups along with the child catalog groups. Any groups with matching ids will prefer the child catalog interpretation.

Imported items can we labeled with any group? Can child items be labels with any group?

If we allow for bulk rewrites then it would need to be a mapping of sorts: X becomes Y. I don't know whether I'm a fan of that. My initial thought was to only allow for import entries to be modified one at a time.

I agree. I was thinking about whether we should do this for extend or only for import. For just import, per entry makes a lot of sense to me too at first.

Importing tools will ideally know to use the overrides if they are provided.

Sounds like something good for the SDK to abstract away