I'm personally of the view that yourself and @aldwin-ms are our security experts. We can discuss on office hours, but I think if this is your proposal we should adopt it, certainly this is not yet in active use so we're not going to break anyone.

A couple of questions I would have though are:

• Should it be control-statement to be explicit? I know it is in a control so is implicit but in the same way we use control-id rather than unique-id may be stronger?
• If we add this, does is sufficiently replace description that it's just duplicative?

Tag: @LeighFinegold, @rocketstack-matt, @dc-ms

From the #745, statement would be in a more specific type than control requirement?

*If we add this, does is sufficiently replace description that it's just duplicative?

I would say no, as the statement is a hard definition, I'd expect it to contain this MUST do X. Like in https://datatracker.ietf.org/doc/html/rfc2119. However, the description would be more of an internal description or relevant information.
e,g,

• Control statement: you MUST implement encryption in Transit
• Description: To encrypt data in transit use one of the accepted standards which you can find at http://MyAcceptedStandards, this includes TLS 1.3 and SSH

@jpgough-ms I do think the next question on this is going to be about evaluation of control-statements, in the example you created there was a rego statement.
Is this something to look at implementing in the CALM hub?

Additionally you could argue that to enforce any controls that you want to put in a policy do you just re-use Spectral or should it be another tool like OPA?

At this point in time, nothing will evaluate control statements.

What is a Control Requirement?

• In effect you're writing a JSON schema to capture the details of what you believe is needed to effectively allow a Technical Architect or developer to show how they will comply with the requirement.
• However, given the 'lite' nature of controls as they exist today (id, name, description), what is actually captured depends on the specification of the requirement. This is going to be entirely dependent on the domain architect specifying the requirement (JSON) schema.

What is a Control Configuration?

• Documentation of how the control will be met, this could be technical detail or could be verbiage.
• The example you give where rego was captured is possible, in so far as the person writing the control believes the control requirement could be measured using ergo and wants the developer or architect attesting to it to specify how it will be done.
• Equally, the requirement could simply state you need to provide details of some document repository where some procedure would be captured.

But what? How does that make sense?

• Keep in mind controls will be grouped by 'domain', e.g. security or resilience.
• The type of information you need to capture to evidence how a system will conform will vary massively depending on the domain as well as the specific requirement.

Given all of the above, the lack of detail means it's not really feasible for us to build generic tooling around controls at this time. We will be able to pull them into our documentation generation and use them to enable traceability / capture evidence / etc. but for controls where we want to provide systematic enforcement, I believe they would need to either be user specific (the organisation specifying their controls would need to build their bespoke tools to understand their specifications).

Overtime, if we have consensus in the community that there are common control requirements in specific domains with more strongly typing, then we could start talking about central tooling to support that domain.