Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Definition'

Entries that have been tagged with 'Definition'.-

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

by Nic Plum on Thursday 07 January, 2016 - 19:37 GMT

Posted in Architecture FrameworkTRAK

Tags: definitionhazardmetamodelontologyriskstandardthreattrakviewpointvulnerability

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:-

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

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

SV-13 Solution Risk View (fragment) - 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 occurrenceRisk < 100% whereas a ‘straight‘ Event may be impossible or certain and therefore 0 ≤ probability of occurrenceEvent ≤ 100%. Risk therefore seems to occupy a subset of the range of values for Event.

Is this worth having 2 distinct elements, particularly since the inheritance (‘is a’) means that we also have:-

  • 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

    Sharing tags:

    External Links

    Definitions - What Exactly is a Risk Part 2?

    by Nic Plum on Monday 05 August, 2013 - 21:46 GMT

    Posted in Architecture FrameworkTRAK

    Tags: definitionhazardontologyriskstandardthreat

    In part 1 we established that a lot of the current definitions of risk don’t actually define what a risk is - they simply define a formula for calculating it or prioritising it which doesn’t help us get at what a risk is and therefore whether it is a distinct entity.

    The OED has a definition:

    (Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility

    Dissecting this with the old semantic scalpel we have parts:

    • possibility or chance
    • adverse circumstance
    • a situation

    Possibility or Chance

    A risk always has a probability of occurring. This therefore means that the metamodel entity has ‘probability of occurrence’ as an attribute. It also means that there are qualifying values in order for it to be a risk - the probability of occurrence cannot be zero since there is then no possibility and it cannot be 100% either because it is then a certainty not a risk.

    Adverse Circumstance

    A risk is associated with a harmful outcome (the positive flip side is an opportunity). We can represent this using a relationship between risk (if the vehicle for risk is an event) and hazard (threat).

    A Situation

    This starts to sound like an event through which the unlucky recipient is exposed to the risk. Is this a risk or is it really a description of a risky-event? 

    Much the same thing happens to hazard where at least one definitions defines a hazardous event not a hazard. In IEC 61508:2010 part 4 Hazard is defined as:

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

    but then add

    NOTE – The term includes danger to persons arising within a short time scale (for example, fire and explosion) and also those that have a long-term effect on a person’s health (for example, release of a toxic substance).

    which isn’t correct because the release of a toxic substance is not a hazard but a hazardous event. The toxic substance represents the hazard. This is important because we’d represent hazard and hazardous event differently with a relationship between a Hazard and Event and the combination becomes the ‘hazardous event’.

    Is something similar happening with risk in common parlance or definitions?

    If a Risk is a distinct entity we have:

    • Hazard (syn. Threat) poses Risk
    • Risk is a Event (where 100 > probability of occurrence > 0)

    and we can have

    • Hazard (syn. Threat) to Resource (i.e System, Physical, Software, Organisation, Job or Role) 

    to introduce the required ‘harm’ or ‘adverse circumstance’.

    The limits on probability of occurrence have to be applied because if it is 100% it isn’t a possibility it’s a certainty and therefore no longer a risk.  Similarly it cannot be zero because it can never happen and is therefore not a risk.

    We could of course just represent a Risk using Event where the value of an attribute ‘probability of occurrence’ takes a value between these limits when representing a risk and is otherwise null or 100% if representing a ‘straight’ Event.

    Of course even if it is a type of event there are advantages in making it a distinct entity since as an element in a tool it makes it easy to find, to navigate to or from and to distinguish it from a straight event. This utility might justify it being distinct.

    So, is a risk a type of event?

    Comments

    Comment on this article

    Related Articles

      Sharing tags:

      External Links

      Definitions - What Exactly is a Risk?

      by Nic Plum on Tuesday 12 March, 2013 - 22:30 GMT

      Posted in Architecture FrameworkTRAKStandards

      Tags: defencedefinitiondodiecnistsafetysecuritystandardtrakusa

      NIST logoIEC logoUS DoD logo

      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

        Sharing tags:

        External Links

        1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
         

        All articles/posts © of the respective authors

        Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.