1. DnDAF security views

2. SecV-1a Asset Security Domain & Valuation Rating
Purpose: “SecV-1 provides the opportunity to both, capture risk assessment and risk management within a general architecture design context, to help introduce security consideration early on in the architecture project and track them through the life of the project architecture.” Definition: “The SecV-1 documents the association of threats, vulnerabilities, residual risks to assets and the security control objectives recommended to mitigate the risk.”

3. SecV-1a Asset Security Domain & Valuation Rating

4. SecV-1a Asset Security Domain & Valuation Rating
The Valuation Rating is essentially a property and can therefore be managed easily.
Security Domain is part of MODAF, MODEM as well as UPDM but may not be applicable directly here. It would seem that a property would serve equally well here.
A statement of sensitivity also needs to be dealt with. This could be viewed as a constraint however that can be applied in MODEM to anything (individuals or types).
Looking at the class diagram there are a few entities that may need special consideration namely knowledge resource and financial resource. A knowledge resource would seem to be something that fits under information and data. A possible way of dealing with this is shown in the next slide.

5. SecV-1a Asset Security Domain & Valuation Rating
DNDasset can be either instances or classes. This can be done by subsetting IndividualResource as well as ResourceType.

6. SecV-1a Asset Security Domain & Valuation Rating

7. SecV-1b Asset – at – Node Security Strength Requirement
“The logical Asset classified & valued via SecV-1a deployed” (assigned) to a Node (OV-2) Initiates a Threat Risk Assessment (TRA) being now referred to as Asset-At-Node. SecV-1b enables the capture of relevant information from the TRA, including links to threats, vulnerabilities, impacts, and control objectives.”

8. SecV-1b Asset – at – Node Security Strength Requirement

9. SecV-1b Asset – at – Node Security Strength Requirement
The assignment of assets to logical resources can be dealt with by using the concept of known resources. There is a logical argument that indicates that this is a good idea. Since Nodes can exchange resources, information as well as energy it follows that these would have to have been assigned to them in the first place in order for them to be exchangeable.

10. SecV-1b Asset – at – Node Security Strength Requirement

11. SecV-2 Data Element Security Matrix
Purpose: “The SecV-2 is used to document the security classification of the data elements used in a given architecture design.” Definition: “The Data Element Security Matrix is a listing of all Data Elements and their associated security classification, and security classification parameters.”

12. SecV-2 Data Element Security Matrix

13. SecV-2 Data Element Security Matrix
This seems to be a subset of the possible parameters that can be assigned in OV-3 as well as in SV-6 and can therefore be supported by MODAF/ MODEM/ UPDM.

14. SecV-2 Data Element Security Matrix

15. SecV-2 Data Element Security Matrix

16. SecV-3 Aggregated Information Security Matrix
Purpose: “The purpose of this view is to help in the assessment of either Operational Information Exchanges or System Data Exchanges to prevent information aggregation security issues.” Definition: “The SecV-3 is a matrix of all information aggregation issues known to exist among the Operational Information Exchanges and System Data Exchanges within the architecture project. Included in this sub view is a description of the type of aggregation issues. For example, aggregation may be caused by summary data such as adding together the sum of all torpedo inventories across all ships and ammunition dumps, which would result in the total of all torpedoes, which are classified as SECRET. Another example is a combination of information, such as the number of gun barrels for the CF tanks and the maintenance schedule of the tanks, which together could allow the deduction of the number of operational tanks, which is also classified as SECRET.”

17. SecV-3 Aggregated Information Security Matrix

18. SecV-3 Aggregated Information Security Matrix
MODEM/ MODAF/ UPDM allows for the creation of aggregation of information elements as well as data elements and these can be associated with properties that discuss the security classification.

19. SecV-3 Aggregated Information Security Matrix
IEPPV needs to deal with this since the classification rating can be due to the kind of data being contained in a given structure. The place at which the data exists is also of importance.

20. SecV-4 Security Control Specification
Presentation statement: “SecV-4 enables definition and maintenance of Security Controls in a taxonomy Security Controls reusable objects that can be shared and associated to Assets; Allows Security Control XREF to policies, legislation and regulations, standards, other knowledge artefacts, e.g.: ITSG 33 Annex 3 (CSEC) NIST Rev 3 SecV-4 provides for the definition and organization of security controls.”

21. SecV-4 Security Control Specification

22. SecV-4 Security Control Specification
It seems as though the best way to deal with these is to make use of them as capabilities that deal with security. It would furthermore seem as the actions described might well be dealt with as standard activities.

23. SecV-4 Security Control Specification

24. SecV-4 Security Control Specification

25. SecV-5 Security Control Profile
Presentation statement: “SecV-5 enables the association of Security Controls that are applicable to an Asset (FoS). This is referred to as the Asset Security Control Profile. SecV-5 further allows the Security Officer to create and maintain a similar Profile for the Asset-At-Node; The Asset-at-Node would automatically inherit (as default) the Asset Security Control Profile as a starting point. The end result is titled the Asset-At-Node Security Control Profile. The purpose of the Asset Security Control Profile is to identify the set of security controls for a logical asset. This is useful as a checklist and default starting point when the Asset-At-Node Security Control Profile is created.”

26. SecV-5 Security Control Profile

27. SecV-5 Security Control Profile
The need to adapt the security controls to the specific node can be accommodated in MODEM by making use of specialisations of existing elements.

28. SecV-5 Security Control Profile

29. SecV-6 Security Control Service Profile
Presentation statement:
“SecV-6 does two distinct things:
enables the specification and maintenance of the Security Service
links a subset of Security Services to a Security Control; this is referred to as the Security Control Service Profile.
Security Services
reusable security mitigation mechanisms.
can be automated or manual
automated security services can be further defined in terms of its hardware and software components.
Similar to SecV-4 (Security Control Specification), SecV-6 enables the creation and maintenance of Security Services. These in turn are reusable objects that can be shared and linked to assets.
Once the Security Services have been created, they in turn can be linked to a Security Control called a Security Control Service Profile.”

30. SecV-6 Security Control Service Profile

31. SecV-6 Security Control Service Profile
In MODEM/ MODAF and UPDM there is nothing strange about services, they can all be defined and can easily be used as a means of handling security.
Automation or non-automation can be dealt with both by service categories as well as by different implementation descriptions.
Contracts and suppliers handling can be dealt with by invoking parts of the MODEM acquisition view.

32. SecV-6 Security Control Service Profile

33. SecV-7 Asset – at – Node Threat Mitigation
Presentation statement:
“SecV-7 enables creation and maintenance of an Asset-At- Node Threat Mitigation Package:
comprises a subset of Security Services needed by the Security Controls to protect the Asset-at-Node.
Selection is influenced by the Strength Requirement Rating
This is where all the magic happens…Where based on all the previous work, the necessary services are brought together that are deemed necessary to protect the asset at the node. The construction of this view requires that the Security Architect assembles the necessary services from the required controls that satisfy the Strength Requirement.”

34. SecV-7 Asset – at – Node Threat Mitigation

35. SecV-7 Asset – at – Node Threat Mitigation
Given that services can be assigned to activities performed at nodes it would seem that views that show threat mitigation can be defined based on existing elements within MODEM/ MODAF/ UPDM. The difference here is that while MODAF and UPDM presumably would require additional stereotypes to deal with this, this would not be the case in MODEM.

36. SecV-7 Asset – at – Node Threat Mitigation