DnDAF security views

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.”

SecV-1a Asset Security Domain & Valuation Rating

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.

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.

SecV-1a Asset Security Domain & Valuation Rating

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.”

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

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.

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

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.”

SecV-2 Data Element Security Matrix

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.

SecV-2 Data Element Security Matrix

SecV-2 Data Element Security Matrix

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.”

SecV-3 Aggregated Information Security Matrix

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.

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.

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 800-53 Rev 3 SecV-4 provides for the definition and organization of security controls.”

SecV-4 Security Control Specification

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.

SecV-4 Security Control Specification

SecV-4 Security Control Specification

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.”

SecV-5 Security Control Profile

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.

SecV-5 Security Control Profile

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.”

SecV-6 Security Control Service Profile

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.

SecV-6 Security Control Service Profile

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.”

SecV-7 Asset – at – Node Threat Mitigation

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.

SecV-7 Asset – at – Node Threat Mitigation