Defining and Implementing Assurance Levels for CCC

[mlysaght2017]

Feature Request

Description of Problem:

We currently lack a structured approach to define and differentiate the assurance levels associated with the implementation and evidencing of CCC controls.

The NIST Risk Management Framework (RMF) emphasizes the importance of assurance in determining the effectiveness of security controls through activities like security control assessments, continuous monitoring, and risk assessments. However, in our current CCC framework, we have not yet defined similar assurance levels that correspond to varying degrees of control implementation and evidence required to achieve different levels of trustworthiness.

For example, evidencing compliance with a basic set of controls might achieve a low assurance level (AL1). In contrast, a higher assurance level (AL2) would require more comprehensive measures, such as controls informed by detailed threat modelling of the service. The highest assurance level could be achieved through advanced activities like a full red-team assessment of the service or solution architecture. The absence of these defined assurance levels creates ambiguity in assessing compliance and security maturity across different cloud services.

Potential Solutions:

1. Documentation of Assurance Levels: A formal document will be created and persisted in the CCC repository, outlining the defined assurance levels (e.g., AL1, AL2, AL3) and the corresponding criteria required to achieve each level.

2. Guidelines for Mapping Controls to Assurance Levels: Development of clear guidelines and procedures for mapping specific controls to the appropriate assurance levels. This will help stakeholders understand how to achieve different levels of assurance based on the control sets they implement and evidence.

3. Certification Equivalency: Establish which assurance levels will equate to full certification, providing clarity on the requirements for achieving the highest level of security assurance. For instance, AL3 might correspond to full certification, indicating that a cloud service has undergone comprehensive threat modeling and red-team testing.

4. Alignment with NIST RMF: Ensure that the CCC’s assurance levels align with and complement the NIST RMF, enabling organizations to integrate these levels seamlessly into their existing risk management processes.

5. Assessment and Reporting Framework: Develop a framework for assessing and reporting on the assurance levels

[mlysaght2017]

@eddie-knight - as discussed, appreciate any support to rally some folks to start working on this issue while I'm out next week. Will sync up when I'm back.

[eddie-knight]

As a starting point, here are two general approach options for an assurance levels (ALs) discussion, based on a few early discussions I've had. This needs substantially more discussion and feedback, and is not intended as a proposal for the final ALs.

Option 1: Scope assurance levels to individual component definitions

Assigning an AL to each set of controls would mean that full compliance with that definition gives the specified level of assurance for users. The released component definition asset would be promoted as each AL criteria is met.

Example Assurance Levels using approach Option 1

0. A version-controlled Component Definition contains actionable controls released by CCC
1. All of the above, and controls have been mapped to MITRE ATT&CK threats
2. All of the above, and controls have been mapped to threats from an applicable threat model
3. All of the above, and the threat model has been informed by a red teaming activity against an applicable service

Option 2: Scope ALs to the certification process

While this project does not intend to be a certifying authority, we may outline the certification requirements— essentially dictating that a certification may not be issued unless a deployed resource meets a certain criteria.

According to this scoping, a certification may be issued to a secure-by-default managed service or IaC module (a resource) with varying assurance levels.

Example Assurance Levels using approach Option 2

0. The resource is portable according to the corresponding CCC Taxonomy
1. All of the above, and the resource is secure according to the corresponding CCC component definition
2. All of the above, and a threat model for this service informed the corresponding CCC controls
3. All of the above, and a red-teaming activity against this service informed the corresponding CCC controls

[eddie-knight]

I will be working with @mlysaght2017 to draft a proposal that can be voted on at the next SteerCo meeting.

[eddie-knight]

@mlysaght2017 I've proposed an addition related to this in #327

After reviewing your doc, and spending more time in the definitions, I'm thinking that we should include details regarding what assurance level our assets are able to deliver. Curious to hear what others think.

[github-actions[bot]]

This issue will be closed as stale in 7 days. Please update this issue if it is still needed.