Page 1 of 4 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.

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

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:

• http://www.iso-architecture.org/42010/

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

• Conformance Assessment vs ISO/IEC 42010:2011

Sharing tags:

• Conformance Assessment vs ISO/IEC 42010:2011 (80% )
• Risk and Threats - The Common Ground Between Security and Safety? (40% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (20% )
• Keep Clear Separation Between the Concerns that Each Architecture View Addresses (20% )
• Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document (20% )

External Links

Conformance Assessment vs ISO/IEC 42010:2011

It’s very hard when everyone seems to be claiming conformance with ISO/IEC 42010 to establish whether the claims are true. All too often we get ‘partly compliant with ’ which means what exactly? As a standard trying to get standardisation in the field of architecture description and trying to eliminate the variability and anarchy it isn’t much use to be partly compliant (any more than claiming to be partly pregnant). You either do or don’t conform. The hard work put in by those that try to conform to the standard is undermined by those that claim conformance but don’t actually conform.

I’m pleased to be able to say that TRAK has agreed to take part in a pilot against an official ‘conformance assessment instrument’ prototype that is being developed against ISO/IEC 42010:2011 which is soon to be jointly published by both the IEEE and ISO. The conformance instrument applies to Architecture Frameworks, Architecture Description Languages and Architecture Descriptions.

As ever I’m sure the assessment and feedback will benefit both sides in refining and sharpening up the documentation. These are early days and no doubt some ideas still need to be worked through, hence the pilot using the prototype conformance instrument.

I’m quietly confident with respect to TRAK itself (time will tell!) but more importantly it will be useful to have an independent assessment of any claim to conformity whereas the current situation allows any Tom, Dick or Harry to claim conformity with impunity and where no sanctions can be applied. I look forwards to this situation being changed.

Comments

Comment on this article

Related Articles

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

Sharing tags:

• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (57% )
• Risk and Threats - The Common Ground Between Security and Safety? (43% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (14% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (14% )
• TRAK Article Published by The Institution of Engineers (Singapore) (14% )

External Links

Page 1 of 4 pages  1 2 3 >  Last ›