Definitions - What Exactly is a Risk?

Creating a definition sounds as thought it ought to be easy. It isn’t for many reasons - some of these are not so much technical as the process by which consensus is reached and the need to get consensus. For example the need to get consensus might mean that at times a weaker definition escapes because it was too difficult to get consensus with a tighter one.

Why do we care? Well there is a particular and a more general reason. The more general one is that the graphic blocks we use to represent the real world things have definitions and therefore the architect is supposed to select the most appropriate block to represent the real world thing based on the description. We can’t just choose anything otherwise we end up “head-modelling” where the verbal description we provide is not supported by the semantics of the model we’ve created (the model in our head is not the one on paper). If the description is wrong it might not be the right block to use (you wouldn’t represent ‘tank’ with a ‘tree’).

The particular reason is that we’ve a working group in TRAK looking to see if and how it is possible to extend TRAK to enable it to be used to address typical safety-related and security-related concerns. One of the starting points is therefore a review of general literature and particularly standards to identify the potential concepts or entities likely to be needed. In doing so we’ve found some potential problems with definitions.

A candidate entity is risk. What is a risk?

IEC 61508:2010

combination of the probability of occurrence of harm and the severity of that harm

MIL STD 882E

Mishap Risk. An expression of the impact and possibility of a mishap in terms of potential mishap severity and probability of occurrence.

NIST

The net mission/business impact considering (1) the likelihood that a particular threat source will exploit, or trigger, a particular information system vulnerability and (2) the resulting impact if this should occur.

There is a common thread. Many other standards also have very similar forms of definition. None of these, however, defines what a risk actually is The analogy is defining force as the product of mass and acceleration - it tells us nothing of what force is. None of the above are therefore definitions of risk they just indicate how we might derive a metric for it. One of the principles in defining something has to be that the definition is independent of other variables or an implementation. In the above if risk didn’t involve probability of occurrence it would mean that the concept of risk itself had changed which isn’t true.

My dictionary provides:

a possibility of harm or damage

IEC 61508:2010 defines a Hazard:

potential source of harm [Guide 51 ISO/IEC:1990]..

’ which is fine but then in the note that follows it states ‘….for example, release of a toxic substance…’ which looks to be a hazardous event not a hazard.

All of this means that it is harder and takes longer than it should do to analyse and form a view of a pragmatic compromise because you have to examine every word and be selective in what you choose to accept and what you choose to reject. You cannot blindly assume that any standard is correct since it is as much the product of gaining consensus as it is the technical content. You have to be a skeptical enquirer and constantly challenge. Too often folks put such committees on pedestals and don’t stop and think.

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? (50% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (30% )
• Just When You Thought It Was Safe - EntiTy Returns (30% )
• Definitions - What Exactly is a Risk Part 2? (20% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )

External Links

• IEC 61508-4:2010 Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems. Definitions and Abbreviations. June 2010
• National Institute Standards Technology. Special Publication 800-27 Rev A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A. June 2004
• Department of Defense. MIL STD 882E. Standard Practice for System Safety. 11th May 2012.
• Sourceforge. TRAK Viewpoints. Discussion Forums. Working Groups. Safety & Security

DODAF 2 - Now That Systems Views Deprecated, What Happens?

In releasing DODAF 2 significant changes were made from DODAF 1.5 not the least of which are the changes to the definition and use of ‘System’ which can now perform functions, be made from materiel and personnel rather than just computer hardware - all good and very necessary when representing a real system. The trouble is that there are then some very odd statements and advice made with respect to describing systems.

From DODAF Viewpoints and Models:

The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.

and from the Systems Viewpoint

The Systems DoDAF-described Models are available for support of legacy systems. As architectures are updated, they should transition from Systems to Services and utilize the models within the Services Viewpoint.

So it seems that Systems Views are being withdrawn and the official advice is to transition from Systems Views to Services views. This is worrying for a number of reasons:

• you cannot equate a System with a Service. A System is a thing characterised by emergent behaviour. A Service is usually an abstract activity-like thing with no notion of technology or implementation. A System is very definitely part of the implementation. If they are considered to be the same why have both sets of views?
• if the Systems Views disappear you cannot then describe any implementation using DODAF. It is surely very important to be able to describe the things we see in the real world. So what happens to the companies that design and develop these systems if they no longer have any means to describe the architecture of the things they develop and deliver? Enterprise architecture should bring different communities together for the common good not cut them out.
• if Systems Views disappear the means to gather the data relating to systems for the underlying DODAF Data Model disappears. This is owned by the DoD so they alone probably feel the effects of this.
• the linkage to the Operational, Project, Services and Capability Viewpoints disappears. Without the Systems Views and systems you lose the ability to describe how systems realise capabilities or the operational needs. Equally without Systems you can’t describe when these are delivered or removed from service and therefore the effects on capability. How can you then implement a service?

All in all this is pretty serious. I therefore posted a question on the DODAF Group on LinkedIn asking what people were planning to do as a result of the advice to migrate the Systems Views to the Service Views. I only got one responder, but a valuable one in Charles Thornburgh. He correctly pointed out that it wasn’t mandatory. It is still, however, official DoD advice. He also pointed out that a lot of the best brains were engaged in looking at this including DoDAF Meta-model Working Group to determine if there is a difference in modeling Services vs. Systems. I pointed out that I’d thought that this would have been done before advising users.

It could be quite a while before the analysis and impact assessment is complete. The easiest action would be to remove the official advice from the DODAF 2 website until such time that the way forwards has been agreed. Maintaining the advice knowing that there are significant problems doesn’t seem like a sensible idea - what happens if the advice is acted on? There will be some very unhappy bunnies in industry if the advice is withdrawn much later.

Has anyone actually followed this advice? What did you do / how did you approach this? Any helpful suggestions for the rest of us?

Comments

Comment on this article

Related Articles

{REL[6049][related1_blog]E6crJesgREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (10% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )
• Definitions - What Exactly is a Risk? (10% )
• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (10% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (10% )

External Links

• DODAF 2 website - DODAF Viewpoints and Models
• DODAF 2 website - Systems Viewpoint