Draft Proposal for Threat Catalog and Control Catalog Taxonomy

[mlysaght2017]

This PR is draft and is an initial proposal from Damien and myself on structure to a basic threat catalog and control catalog taxonomy in basic md format, with example mappings to the generic CCC object storage service as a starting point

The PR addresses some of the questions posed in #139 as well as #11 within #126

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: mlysaght2017 / name: Michael Lysaght (09377cf, 8662419, 8eb34e3, a66d7f7, 4bd0f12, 1170a01, 88451b6, 0f940ec, 1af7831, ea20e65, d6296e3, e740917, 7d6012c, 95d79c3, 9a9cba2, c5d8fb3, 04aa77c, 54ec5f3, 51f5c64, 681e4b8, a28a9fe, 64e4335, e6658ed, 191a98c)
• ✅ login: damienjburks / name: Damien Burks (66e358b)

[mlysaght2017]

@eddie-knight @rowan-baker @jonmuk @AdrianHammond @iMichaela - can you please add yourself as reviewers so we can keep the momentum on feedback. Please add anyone else that makes sense.

The overview of the PR at the last all-hands call was well received with good positive feedback, but would like to keep momentum on the PR review so that we can start iterating on the respective threat and control catalogs and keep overall momentum in parallel to more formalisation on the WGs via the steerco

Thanks!

[eddie-knight]

This may need to be captured elsewhere instead of blocking the PR...

@robmoffat and I were brainstorming previously regarding the scope of work and the need to reuse existing material. With the values proposed here, how much do we anticipate we will be able to reuse tools from folks such as MITRE Engenuity?

Relatedly, is there a way we can confirm that our structure is best suited to harness work that's already been done by the greater cybersecurity community?

[eddie-knight]

Regarding the Test column:

In our taxonomy work, @smendis-scottlogic and I proposed keeping taxonomy tests in a parallel gherkin file for each service.

I like the idea of keeping things simple in one place, but I'm not sure how well it reads in this format. Curious to hear feedback on whether Test should be included here.

[eddie-knight]

Regarding the NIST CF column:

Do we anticipate that any controls will fall outside of the Protect category?

[mlysaght2017]

This is an interesting question. On Detect, I can see benefit in assessing the CSP's native threat detection capabilities (as well as basic audit logging of specific APIs) for a given service - e.g. data stores exposed outside of given data perimeters - here we'd also have the option of mapping to MITRE ATT&CK Data Sources e.g. for Cloud Storage: https://attack.mitre.org/datasources/DS0010/

However...this would naturally be a lot more work...It feels like our priority should be on maturing our thinking on Protect with more Protect examples within and across the services and continuing to think/experiment on Detect? Feels like an early decision for steerco too.

[mlysaght2017]

Totally agree that the Test values in Gherkin don't read well in that format. We can shift to a separate gherkin file as you suggest.

[AdrianHammond]

Hi @mlysaght2017 thanks for picking this up and driving

I like the idea of having top level info to help users navigate into CCC as I see the most common user entry point is going to be the cloud service taxonomy that is being consumed.

I just have a couple of comments / questions:

1. Do we need all of this information here (objective, description and test) as this could become a maintenance overhead in the future? I think having just the Objective would be sufficient.
2. Is Control id and Service Taxonomy always going to have a 1-2-1 relationship? If so should we use Service Taxonomy id as top level id?
3. Should we take this opportunity to update the format of the Service taxonomy id to CCC-xx-nnnn where xx is 2 characters representing the service, like you have used in control id

[mlysaght2017]

Thanks @AdrianHammond

1. Do we need all of this information here (objective, description and test) as this could become a maintenance overhead in the future? I think having just the Objective would be sufficient.

ML:

• We're discussing shifting the Test out into a separate gherkin file - see discussion with @eddie-knight above.
• I think we can also remove the Service Taxonomy Id as this is already contained within the separate threats.md file (i.e. the threat catalog) - in effect a duplication
• Objective/Description: I'm pretty sure I agree with you here In my head right now, individual logical controls underly a high level control Objective with a 1-to-many relationship between control Objective and controls Description in effect. Maybe we can stick to just Objective and see how it goes as we think more about the "Assessment Layer"?

3. Is Control id and Service Taxonomy always going to have a 1-2-1 relationship? If so should we use Service Taxonomy id as top level id?

ML: I can see the Service Taxonomy having a 1-2-Many relationship with the Threats

5. Should we take this opportunity to update the format of the Service taxonomy id to CCC-xx-nnnn where xx is 2 characters representing the service, like you have used in control id

ML: I think there's been a new issue created to standardize on this - will check, but either way will align asap.

[mlysaght2017]

Thanks @eddie-knight - all great points!

This may need to be captured elsewhere instead of blocking the PR...

@robmoffat and I were brainstorming previously regarding the scope of work and the need to reuse existing material. With the values proposed here, how much do we anticipate we will be able to reuse tools from folks such as MITRE Engenuity?

Relatedly, is there a way we can confirm that our structure is best suited to harness work that's already been done by the greater cybersecurity community?

Realise we've had a couple of discussions on the mappings MITRE Engenuity have done between ATT&CK and NIST 800-53 Rev 4...
Thinking here is that while the project scope continues to get ironed out we continue to provide examples that will help with some of the decision making. It still feels like we need more examples of what Service -> Threats -> Controls -> Assessment would look like and at the same time continue to investigate what's out there already that we can leverage (both in terms of catalogs and mappings)...?