Page 1 of 9 pages  1 2 3 >  Last ›

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:

• Conformance Assessment vs ISO/IEC 42010:2011 (18% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (12% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (12% )
• TRAK Article Published by The Institution of Engineers (Singapore) (6% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (6% )

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.

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

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

Comments

Comment on this article

Related Articles

• TRAK Viewpoints

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (67% )
• Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views (33% )
• Conformance Assessment vs ISO/IEC 42010:2011 (33% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (33% )
• TRAK Article Published by The Institution of Engineers (Singapore) (33% )

External Links

• Sourceforge. TRAK Viewpoints. Feature Request. #3475115. CVp-02 Concept Viewpoint Not Unique - Remove?
• MODAF. Operational View Viewpoint.
• TRAK. Enterprise Architecture Framework Viewpoints. 2nd October 2011.

TRAK Article Published by The Institution of Engineers (Singapore)

This is one of those slightly strange happenstance events - completely unplanned although not beyond the original intent.

At the 2010 INCOSE Annual Systems Engineering Conference Chris Lowe and I presented on ‘Human Factors - On the Right TRAK?’ which looked at the consideration of human factors in the design or TRAK itself and the use of TRAK for human factors work’. At the time INCOSE only really wanted the presentation and anything else was optional. In the end we decided to go over the top and produce an accompanying document in some detail. As much as anything this was to make sure the essence / thinking was preserved since looking at some thinly-worded slides might not convey what was done in person at the time.

Some months later the Singapore Institution of Engineers approached INCOSE to ask if they could reproduce the article. Naturally we said “yes” - the original is on Slideshare in any case. Many more months passed and nothing happened and then in September 2011 they asked for the source files but had some problems using them which meant their deadline was missed. Anyway it looks to have been published at long last.

Having had a look it looks as though they’ve missed Chris off the headline (but he is in the acknowledgement at the end). Had we have been asked we could have provided decent graphics since it looks as though something has got munged in the publication.

Comments

Comment on this article

Related Articles

• 2 TRAK Papers to be Presented at the INCOSE Annual Systems Engineering Conference (ASEC) 2010

Sharing tags:

• TRAK is a Finalist in the 2011 IET Innovation Awards (40% )
• Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views (20% )
• Conformance Assessment vs ISO/IEC 42010:2011 (20% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (20% )
• Risk and Threats - The Common Ground Between Security and Safety? (20% )

External Links

• The Singapore Engineer Magazine (December 2011)
• INCOSE ASEC TRAK Content on Slideshare

Page 1 of 9 pages  1 2 3 >  Last ›