RW - Navigation

RW - Recent

Last 10 entries [comments]:


Last 10 posts [threads/views]:


Last 10 pages updated:

There are 484 wiki pages in total.

RSS logoRSS Feed

The Residual World::Tag = 'Viewpoint'

Entries that have been tagged with 'Viewpoint'.-

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:-], via Wikimedia Commons” href=“”>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.



Comment on this article

Related Articles

    Sharing tags:

    External Links

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

    by Nic Plum on Tuesday 10 April, 2012 - 21:25 GMT

    Posted in Architecture FrameworkTRAK

    Tags: def standefenceforumiso42010mil stdontologyrisksafetysecuritysolutionsourceforgestandardthreattrakviewviewpointvulnerability

    TRAK Logo

    This is something that has been bumbling around for some considerable time - safety and security. By that I whether there is something useful that an enterprise architecture view can be used for in the system safety and security disciplines.

    On the face of it there is quite a bit of overlap. Both are ultimately concerned with risk inherent in a solution design which arises from threats (security) or hazards (safety). Both involve management with the aim to reduce the risk, threat or accident (safety) to an acceptable or tolerable target. I suspect also that security management also uses categories to classify acceptable severity or probability in much the same way that the various system safety management standards in defence do (MIL STD 882D, DEF STAN 00-56). Both also involve mitigation of risk by design - through structure, behaviour, or adherence to a normative process of some sort.

    There are bound to be some differences, not the least of which is terminology. In the security area we seem to have constructs like:

    • Threat poses Risk
    • Threat exploits Vulnerability
    • design aka TRAK:Resource (System, Software, Organisation, Job or Role) exposed to Risk (and subsequently that Risk is mitigated by the (improved) Resource or Function (of that Resource)

    In the safety area we seem to have constructs like:

    • Failure may present Hazard
    • Hazard can cause Accident
    • Accident poses Risk
    • Resource exhibits Failure

    and attributes such as probability, impact, severity.

    Anyway it seems sensible to open up the debate so I’ve posted some thoughts in the forums within the TRAK Viewpoints project site on Sourceforge. Something is definitely needed and my hunch is that there is so much overlap that it would be possible to create a Viewpoint that addresses the risk within a solution design. This may of course end up being two viewpoints depending on the concerns and therefore concepts (metamodel stereotypes) and relationships involved. What is needed is more debate and input from those involved with system safety and system security - hence the post. As ever with TRAK the objective is economy so that we have something that is just or barely adequate to describe the concerns and concepts involved and no more.



    Comment on this article

    Related Articles

      Sharing tags:


      External Links

      Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint

      by Nic Plum on Sunday 08 April, 2012 - 12:42 GMT

      Posted in Architecture FrameworkTRAK

      Tags: concepttrakviewpoint

      TRAK Logo

      Every viewpoint in TRAK is a specification for an architecture description view. In accordance with ISO/IEC 42010 each address one or more typical concerns using a combination of tuples (stereotype - relationship - stereotype combination taken from the TRAK metamodel). The tuples have therefore to contain the right types and relationships to address the concern and the concerns (and therefore the tuple sets) must be distinct from those addressed by other viewpoints. This keeps clear water between viewpoints and it means that the number of viewpoints needed is kept to a minimum because they aren’t driven by domain or application of viewpoints.

      What then of the TRAK CVp-02 Concept Viewpoint? This is currently defined as answering concerns has the concept purpose been identified? and How is it seen as being used? and the tuples as:

      Expected to be largely textual and scenario based but with use of other concept perspective architecture views to illustrate, expand, define.The set of tuples will be those from the mandatory sets of the concept perspective views used against CVp-01, CVp-03, CVp-04, CVp-05 and CVp-06.The selection of concept views used to illustrate the scenarios is left to the architect.

      from TRAK. Enterprise Architecture Framework Viewpoints. 2nd October 2011

      This isn’t good enough. None of this needs anything which isn’t already provided by one or more of the other viewpoints in the TRAK Concept Perspective. The purpose of a concept is embodied through its relationships with the solution or potential solutions that realise it and its relationship with the enterprise and the enterprise goals. The content of a concept is already covered by existing viewpoints and there is nothing that makes this viewpoint distinct from any others. Historically it was an analogue of the MODAF OV-1 which included a high level graphic and a textual version used to present ideas to senior management in an easy to digest form:

      The OV-1a provides a graphical executive summary of the architectural endeavour, which describes the interactions between the subject architecture and its environment, and between the architecture and external systems. A textual description accompanying the graphic is essential, with labels on the graphic and a detailed description in the OV-1b. Graphics alone are not sufficient for capturing the necessary architecture data.
      The purpose of OV-1a is to provide a quick, high-level description of the business objective that the architecture is addressing, and how that objective might be achieved. An OV-1a can be used to orient and focus detailed discussions. Its main utility is to communicate the purpose of the architecture to non-technical, high-level decision makers.

      from The MODAF Operational Viewpoint. 26th April 2010.

      In TRAK any view can be presented using graphical elements as long as the type of object is shown and with simple text labels on relationships it is easy to produce something that most people can simply read in a natural way so the presentation is never a justification for a separate viewpoint.

      On the face of it there is no good reason for keeping this viewpoint and the best thing is to remove it. The recommendation has been made as a change request (#3475115) and unless anyone makes a good reason to keep it the sentence will soon be carried out ....



      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.