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

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

• Keep Clear Separation Between the Concerns that Each Architecture View Addresses

Sharing tags:

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

Forums

• See discussion thread in forums

External Links

• DEF STAN 00-56/4 Part 1 / Part 2 Safety Management Requirements For Defence Systems.  [registration needed to access]
• MIL STD 882D. Department Of Defense Standard Practice For System Safety. February 2000
• Cabinet Office. Security Policy Framework. V7 October 2011.
• Security Ontology. Stefan Fenz.
• Secure Business Austria. Security Ontology.
• HIPAA Security Series. 6 Basics of Risk Analysis and Risk Management.
• Safety & Functional Safety. ABB Brochure 1SFC001008B0201.

Putting the Architectural Modelling Community First - What You Can Expect to See

This current site is really only a interim site. What is intended is a site that properly supports the folks using TRAK or other MDAF-based architecture frameworks and one which represents the ethos behind it:-

• pragmatic - led by need and application - the human interface to the framework (usability, affordance etc.)
• open - decisions, rationale, explanation
• democratic - involve the community in the site content rather than broadcast top down what I/we think folks need. The centre of gravity ought to be with the users rather than the specifiers-of the framework
• fun - why not? Systems thinkers/engineers and architects are real, dare I say it ‘whole’ people and all sides need to be addressed
• dynamic - the content needs to be able to change and adapt to new circumstances, thinking or practice

What You Might Expect

The features that you should expect to see are:-

• each section of the site is a ‘blog’
  • articles can be discussed and commented on by site members
  • updates notified by RSS news feeds
• articles can be linked together, tagged, put into categories and dynamically sorted/displayed and searched for by users
• discussion forums
  • tool support
  • use of architecture frameworks
  • modelling / repository organisation - not governed by frameworks but important and common to all
• architects can submit examples of views to help others
• wiki to hold facts on architecture frameworks e.g. metamodel elements, use of UML tools, tips, plugins etc.
• single sign-on to comment, add a forum discussion or to add to the wiki
• everyone can see everything - nothing hidden
  • only site members can contribute or comment - contributors and commenters recognised and stand up to the mark!
• fun / anarchic humour
  • the lighter side
  • not taking life too seriously

Comments

Comment on this article

Related Articles

{REL[135][related1_blog]HCDa77KTREL}

Sharing tags:

• This is But One Part of a Bigger “Whole” (29% )
• Risk and Threats - The Common Ground Between Security and Safety? (14% )
• Architecture Description Language (ADL) vs Architecture Framework (14% )
• Standards - Site Appearance in Internet Explorer 8 vs Anything Else (14% )
• Keep Clear Separation Between the Concerns that Each Architecture View Addresses (14% )

External Links