Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event?

Changes have been made to TRAK to support the description of risk and event sequences in the guise of the SVp-11 Solution Event Causes and SVp-13 Solution Risk Viewpoints. This has been a piece of work underway for at least 3 years but it seemed necessary to publish it so that the viewpoints and tuples can be exposed to wider testing i.e. used in anger.

As with most of this sort of work there is a limit to the amount of theorising that is possible and it’s necessary to test the pragmatism and utility. It’s likely therefore to undergo some tweaking. If any relationship or metamodel entity is not needed then it should be removed since the overall aim is to work with the minimum metamodel needed to just be adequate. A larger metamodel is not only harder to maintain and keep consistent but because it is only there to support the concerns in the set of TRAK viewpoints (specifications for views cf ISO/IEC/IEEE 42010:2011) it follows that a larger metamodel makes definition of a consistent set of viewpoints harder. With more entities and relationships it is also likely that an architecture description can become more complex and require more effort to present it clearly to get the meaning across (at least to a Mk 1 Human Being since being based on triples a TRAK architecture description is machine-readable and analysable). Every tuple in the TRAK metamodel has therefore to earn its keep / justify not being removed.

Solution Risk

In a previous posting I identified why we think, in TRAK at least, that a risk is a type of event and why many of the current definitions of risk do not actually define what a risk is (only how you might calculate a number or metric i.e. probability of occurrence x impact severity).

We’ve tied risk to the solution because we think that this is where it most often manifests itself in terms of design features or changes to the design of the system of interest to mitigate it. In engineering terms it is really the cumulative risk exposure to people that drives design change hence it makes sense to be able to relate risk, vulnerability, threats and mitigation to a solution design whether the causing agent or the impacted one.

TRAK therefore supports the following triples / tuples for describing risk:-

https://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons” href=“https://commons.wikimedia.org/wiki/File%3ATRAK_metamodel_part_2_safety_security.jpg”>

• Resource (System, Software, Physical, Role, Job or Organisation) has Vulnerability
• Function has Vulnerability - what the Resource does
• Resource Interaction has Vulnerability - the exchange between Resources
• Interaction Element has Vulnerability - what is exchanged between Resources
• Resource poses Threat (synonym Hazard)
• Threat exploits Vulnerability
• Threat to Resource
• Threat to Function
• Threat to Resource Interaction
• Threat to Interaction Element
• Threat poses Risk
• Resource exposed to Risk
• Risk is managed by Mitigation
• Mitigation uses Function
• Mitigation uses Resource

By way of a small example using a small subset of the above we have a nuclear reactor.

It is possible to identify an external actor as the origin of the threat (hazard) - ‘Resource 1 poses Threat to Resource 2’. Similarly mitigation might be a result of a part of the same resource or it might require a different one (‘Resource 1 is exposed to Risk is managed by Mitigation uses Resource 2’).

In all of this the description of Risk, Vulnerability, Threat (Hazard) and Mitigation can be linked to the description of the solution or part of the solution. This therefore enables the solution design to be modified in response or the mitigation to be altered in response to a design change so the cause and effect is always visible in the architecture description.

So far all of this is pretty straightforwards. The “toughie” is:-

• Risk is a Event

This is tricky not because there is any doubt that a Risk is a type of Event. A risk typically is associated with a probability of occurrence and an impact severity. If we are thinking about an event in the way it would be used in, say, Fault Tree Analysis (FTA) then it also has a probability of occurrence. It too can have an impact severity. So are there differentiating attributes of a risk (event)? We couldn’t think of any - suggestions welcome. The rationale for having a separate Risk metamodel element was simply that people might expect to see elements labelled as ‘Risk’ because they might not equate ‘Event’ with the description of a risk (affordance and visibility).

Note. Although there isn’t a difference in the attributes there is a distinction in the possible values A Risk and an Event can take. A Risk, by definition is always uncertain but possible therefore 0 < probability of occurrence_Risk < 100% whereas a ‘straight‘ Event may be impossible or certain and therefore 0 ≤ probability of occurrence_Event ≤ 100%. Risk therefore seems to occupy a subset of the range of values for Event.

• Risk caused by Risk
• Risk impacts on Resource
• Risk caused by Resource
• Risk AND / OR / etc. Risk

and this is less clear when Risk and Event are separate entities on the metamodel diagram.

If there was the one element, Event, then it would still allow risks (Events) to be clustered or grouped which would allow the SVp-11 to be used to describe and identify common causal risk (events) and therefore suggest ways in which risks might be managed. The only penalty seems therefore to be 1) visibility - can risks be identified as such when typed as Event? 2) affordance - is it obvious that an Event element can be used to describe a risk?

Can anyone justify why Risk and Event should be distinct or why they should be subsumed into Event? Clearly from a TRAK-management point of view it would be better to apply the Highlander Principle (“there shall only be one”) but this might overridden by the UI / HCI aspects.

Thoughts?

Comments

Comment on this article

Related Articles

• Risk and Threats - The Common Ground Between Security and Safety?

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (70% )
• Definitions - What Exactly is a Risk Part 2? (60% )
• Definitions - What Exactly is a Risk? (30% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
• Just When You Thought It Was Safe - EntiTy Returns (10% )

External Links

• TRAK00001. TRAK. Enterprise Architecture Framework. Viewpoints. 1st January 2016
• TRAK00002. TRAK. Enterprise Architecture Framework. Metamodel. 1st January 2016
• TRAK Metamodel fragment - Safety & Security 1st January 2016 - Wikimedia Commons - https://commons.wikimedia.org/wiki/File%3ATRAK_metamodel_part_2_safety_security.jpg

NATO Architecture Framework Metamodel v3.1 Surfaces

A definition/description of the NATO Architecture Framework Metamodel version 3.1 is now publicly available (the definition of the framework had previously disappeared from public view).

Currently only the document that specifies the metamodel is available - this is one part of the overall definition of the NATO Architecture Framework. The documentation that specifies the architecture views for version 3.1 isn’t yet available. The document that is available is Chapter 5 - NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) .

Without a complete document set and without a change record yet it’s hard to make an assessment, but ...

• NAF 3.1 now seems to be much closer to the MODAF 1.2.003 metamodel (MODAF is now at 1.2.004)
• The number of subviews has increased in total from 47 at 3.0 to 49 at 3.1 - with notable changes in the NATO Service-Oriented Views (NSOVs) which now align with MODAF
• the usage context of Resources (Capability Configuration, Artefact, Role, Post, Organisation, Software) can now be specified - this is a way of allowing exchange of models which were previously unexchangeable owing to the choices allowed by the NAF metamodel in typing a real world thing e.g. system vs platform vs artefact with the result that different architects would choose different stereotypes. The conflict in choice is still present but the usage context allows the architect to say, for example, this Platform is being used as a System. This is identical to MODAF from 1.2.003.
• any Resource is allowed to have a function now (NAF previously divided Resources up into ‘functional’ and ‘non-functional’
• any Resource can now interact with another Resource

Some niggles still remain e.g. the ‘system’ stereotype is really not a first class player and cannot itself contribute to capability or have parts which are other resource-like things - so no complex system or including the man with the machine as part of the system. This looks as though it has to be achieved using a Capability Configuration as a system and ignoring the fact that the System stereotype cannot represent a system. The new definition of System in v 3.1 doesn’t help - ‘The usage of an artefact as a System in a CapabilityConfiguration’ - as it doesn’t actually define what a system is.

Still the increased flexibility wrt Resources is a significant step forwards in representing the real world.

Update 11th November 2010
The definition for the NATO architecture framework seems to have disappeared again.

Comments

Comment on this article

Related Articles

• Has the NATO Architecture Framework v3 Definition “Naffed-Off”?

Sharing tags:

• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (25% )
• MODAF is Dead - Long Live ‘NAF’? (25% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (13% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (13% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (13% )

External Links

• Chapter 5 - NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES)
• Architecture Framework Comparison - wiki on trak-community.org
• NAF 3.1 - wiki on trak-community.org

TRAK is in the Wild - Now an Open Source Enterprise Architecture Framework

TRAK has been released, thanks to the foresight of London Underground Ltd., under an open source license.

Releasing TRAK under open source is important because

• it is a standard to facilitate the exchange of architecture models
• it recognises that there are many who could contribute expertise if allowed to do so - any with the need or energy/motivation can participate
• it provides a feasible maintenance and support system - one where TRAK has the wherewithall to heal itself
• it keeps the cost of using the standard to a minimum - since architecture is a form of communication we shouldn’t tax it!
• it represents pragmatism in terms of releasing early, not waiting for perfection and in collaborating for the common good

The UK Department for Transport are the sponsor of TRAK as part of a wider systems engineering initiative.

The release of TRAK has been split into 4 products.

The first 2 parts form the logical definition of TRAK.

• the TRAK metamodel. This specifies the allowable object types and relationships that can be used. In essence it provides the language that an architect can use through the set of nouns and verbs. It includes a simplified metamodel for easy reference. It also includes a detailed comparison against MODAF 1.2 in order to set an initial baseline. One of the reasons for release using the GNU Free Documentation License (GFDL) is that the History section is preserved together with attribution to those who help develop TRAK. The metamodel is at trakmetamodel.sourceforge.io
• the TRAK architecture viewpoint definitions. TRAK adopts ISO 42010 / IEEE 1471 practice by having a viewpoint for each architectural view that specifies the concerns addressed, the allowable objects (from the metamodel), the suggested presentation format and the consistency rules. It includes a comparison against MODAF 1.2 view set. It is released as open source under the GFDL at trakviewpoints.sourceforge.io

The second 2 parts are implementations against the logical definition.

• the MDG Technology for TRAK. This is a Sparx Systems Enterprise Architect (EA) file that contains the architectural model used to create both the MDG plugin that implements TRAK in Enterprise Architect and the UML profile for TRAK which is used by Enterprise Architect and any other UML modelling tool. It represents the implementation of both the TRAK metamodel and the TRAK viewpoint definition as far as is possible. It contains the EA plugin and the source EA project file. It is released under the GNU Public License version3 (GPL v3) at mdgfortrak.sourceforge.io
• the UML profile for TRAK. This provides the set of objects and relationships defined within the TRAK Metamodel in a way that any decent UML modelling tool can use. It is released under the GPL v3 at trakumlprofile.sourceforge.io

Not saying it’s perfect - we know it isn’t. It’s good enough for practical purposes and we have a list of things that need looking at. What I hope is, being open source, that anyone needing to apply it in a particular situation and finding it lacking can then get involved to solve the problem. Application and usability are all important - more so than any theoretical underpinning. The framework is not a system - this only arises when you add tools, people, organisations and therefore you always have to address visibility, navigation, affordance etc - in short the user interface for the whole thing. We hope in this way that TRAK will be user-centric and problem-led rather than specification-centric.

If you do want to get involved there are forums set up at the TRAK Viewpoints and TRAK Metamodel sites.

Comments

Comment on this article

Related Articles

Sharing tags:

• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (25% )
• Definitions - What Exactly is a Risk? (13% )
• Just When You Thought It Was Safe - EntiTy Returns (13% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (6% )
• Definitions - What Exactly is a Risk Part 2? (6% )

External Links