The case for a 'Control' element.
As a security architect, I work a lot with the Motivation elements and, following the guidance of the AchiMate 3.1 specification, model 'Control Objectives' as Goals that are then realised by a set of Requirement and Constraint elements.
What these models lack however is a clear and explicit way of demonstrating how and where these Requirements and Constraints are actually implemented (realised) by real-world elements in the core layers. As a consequence, it's not easy to verify that all Goals have been met without digging deep into the documentation of the element at the stem of the realisation relationship.
To solve this issue, I'd like to propose the introduction of a 'Control' element in the next or future release. A metamodel for the use of this Control element is shown in the diagram below.
Working round the lack of a 'Control'
To give examples of how the lack of a 'Control' element impacts security models, I'll show some diagrams from an attempt to model The Open Group's OpenFAIR risk methodology. In this model I have co-opted the use of the 'Device' element as the nearest conceptual match for a control but pls note that I am not advocating it as a solution.
The OpenFAIR Risk Taxonomy (O-RT) and Assessment methodology (O-RA) make multiple references to the need to model controls (see O-RT Vulnerability (Section 3.4.3) Resistance Strength (Section 3.4.5) and O-RA Stage 5: Model the effect of Controls, as reproduced below:
Vulnerability is identical to the probability that the Threat Agent’s force applied, the Threat Capability (or TCap) against the Asset in a specific loss scenario exceeds the Resistance Strength (or RS) of the controls protecting that Asset.
Resistance Strength (RS) is the strength of a control as compared to the probable level of force (as embodied by the time, resources, and technological capability; measured as a percentile) that a Threat Agent is capable of applying against an Asset.
Open FAIR defines four categories of controls: Avoidance, Deterrent, Vulnerability, and Responsive. These controls affect specific Open FAIR factors, but their overall effect is to reduce either the likelihood of a Loss Event, the effect of Loss Prevention Controls, or to mitigate losses once a Loss Event has begun to occur, the effect of Loss Mitigation Controls.
Design Considerations when modelling a 'Control'
There are two main considerations when modelling a Control: its type and its form.
Many security frameworks classify controls by type (e.g. the NIST CSP classification has 5 types: Identify, Protect, Detect, Respond & Recover). OpenFAIR identifies 4 types (Avoid, Deter, Vulnerability & Response) and links them to the way they influence the event chain.
The diagram below models these as specialisations as a means of connecting them to their point of influence. In the real world however, controls may exhibit more than one type: a surveillance camera contributes as both deterrent and response (detection capability). Our models could support this through multiple inheritance (specialisation) or by granting the control membership of multiple Groupings as shown below.
The other design consideration is that real-world controls take many forms. They can be physical (a lock in a door), contractual (a clause in a policy or end-user agreement), logical (a secure hash on a data record), procedural (a personnel background check as part of on-boarding process) or organisational (the allocation of accountability to an Actor). Generally though, a control appears to be a sub-component of something of the same type which would suggest that it should be modelled as a kind of 'Marker Interface' [https://en.wikipedia.org/wiki/Marker_interface_pattern] that can be composed into its parent element
Finally, the introduction of a Control would be 100% backwards compatible. Suggested icon could be something like the one below.