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 = 'Standard'

Entries that have been tagged with 'Standard'.-

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

    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.

     

    Comments

    Comment on this article

    Related Articles

      Sharing tags:

      Forums

      External Links

      ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released

      by Nic Plum on Friday 11 November, 2011 - 11:45 GMT

      Posted in NewsStandards

      Tags: ieeeisoiso42010newsstandard

      International Standards Organisation logo

      Just received news from Rich Hilliard via the IEEE 1471 Users List (to become the “ISO/IEC/IEEE 42010 Users List):

      Today I was notified that IEEE P42010 was approved as a revised standard by the IEEE-SA Standards Board on 31 October 2011.

      This standard replaces IEEE 1471:2000 and is identical to the ISO standard approved in July with 21 approvals and 0 disapprovals from member bodies.

      The new standard, designated ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description, is available from IEEE and ISO.

      The IEEE 1471 website will become the ISO/IEC/IEEE 42010 website.

      The old website will redirect to the new URL which is:

      Looking at the website I noticed

      Per IEEE rules: An approved IEEE standard will remain active for   ten years. If the Sponsor does not complete a revision process   within ten years, the standard will be transferred to inactive   status.

      Curious to know whether this means a standard has to be revised or whether the requirement is simply to review - it might still be a perfectly good standard even if it hasn’t been revised since the decision might be on review that it’s good enough.

      Having to say ISO/IEC/IEEE every time is a bit of a mouthfull and therefore inevitably will be shortened in everyday use. Is there an acceptable shortform(s) e.g. ISO 42010, IEC 42010 and IEEE 42010? It’s unlikely in speech that the full qualification will be used.

      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.