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.

Things that You Think That Are Going to be Simple Never Are

This is a bit of a tale, and not an unusual one at that. It concerns the development of a stencil for the Omni Group’s OmniGraffle drawing application which is available for both Mac and iPad. I’m a long time user of OmniGraffle Pro (at least 8 years) as well the the Mac (still have my original Mac Iici working) and OmniGraffle is just an easy to use and intuitive means of producing good drawings. All of the stuff in the defining TRAK documentation is produced using it.

Anyway, thought it might be an idea to have a stencil of the stereotypes and relationships to be able to knock up a quick TRAK architecture view when I felt it merited it (rather than firing up a bigger modelling tool such as Sparx Enterprise Architect). It’s all about horses for courses.

The OmniGraffle Stencil for TRAK Implements the TRAK Definition

The Beginning - Fumblings

Not knowing anything about developing a stencil I simply created the blocks needed for the TRAK views and added a set of connectors for the relationships having labelled them. Then I discovered on loading the stencil that OmniGraffle presents the bare connectors separately from the labels for those connectors so there were many connectors in the stencil all seemingly the same. Started again. This time I just had 2 connectors and a text label for each relationship. This cut down the noise but I discovered that on the iPad version it wasn’t easy to use these as it didn’t seem to allow you to drag the label onto the connector and for the 2 to remain locked together as it would do on the desktop version. Started again. This next version had separate connectors, each with it’s own label but this time I grouped the label with the line and this indeed stopped the stencil from displaying them separately.

Sharing

Now I felt I was starting to get the hang of it. The obvious choice was to lodge this onto Sourceforge with all the other TRAK stuff so I created a new project (trakomnigraffle) and then discovered the front end of Sourceforge had changed so much I no longer knew where to go to do what in setting it up. This looks to be a consequence of security and an earlier attack on Sourceforge this year. Then I remembered GraffleTopia. This is a site that holds stencils and templates for OmniGraffle. Even better it’s moved on apace such that when looking for a stencil in OmniGraffle, including the iPad, it will display results from GraffleTopia for download/installation. Sounds good so I duly submitted the stencil. It appeared last Friday on the 12th August so very pleased. The ability to see how many downloads is nice. Sure enough I found it does appear within the desktop and iPad versions and you can download it from the iPad version. For whatever reason it throws an error in OmniGraffle Pro when you select it for downloading. I then had to spend time submitting a bug report.

I know that OmniGraffle supports user data in terms of a set of keys and data values. It seemed therefore sensible to implement the attributes for the various elements in the TRAK metamodel. This would allow more information to be captured and it looked likely to offer a path through which a XML export could be produced with these which would allow a sensible conversion or import via XMI into a UML modelling tool. I then updated the stencil so that each object has the right set of attributes. Great - making progress! I then update the Sourceforge site and go to the GraffleTopia site to upload the new version only to find that it doesn’t support the workflow involved with an update -

Update: Have now found the link to edit and resubmit new versions of the stencil so can only assume it was stupidity and/or blindness on my part. The good news is that GraffleTopia and Sourceforge are in sync!

More Ideas, More Problems

Having all these attributes as user data is good. Trouble is I then thought it’d be nice to be able to copy the attributes and perhaps the values from one object to another. No problems - this is a job for AppleScript (a venerable but very useful scripting technology that operates across the Mac platform and has done so for many many years) which could automate this. Luckily I have a decent debugger but even so it wasn’t going well owing partly to ignorance or forgetting things on my part not having used it for a while. I had to call on support from the ‘Support Ninjas’ at OmniGraffle and each time I’ve managed to move it forwards. I’ve now got to the stage where I can populate a set of shapes with a set of TRAK attributes. Even better it recognises if there is a key with data that exists and asks whether it should continue and wipe this data out for that key or just skip this item. You can see it’s getting ever more complicated which I suppose is the penalty for user-friendliness. Unfortunately it hit a problem when testing for a key name that doesn’t exist. After another response from the OmniGraffle Support Ninjas it seems there is a bug with the AppleScript object in OmniGraffle which causes it to return an undefined object and causes a runtime error. I have been directed to a workaround but it’s going to take a while to get my head around this.

Then it occurred to me that it’d make sense to have the type shown on the object to be determined from a key labelled ‘stereotype’ within each object. This way I wouldn’t be dependent on someone spelling the type correctly. I found that you can then display the value using the string <%UserData stereotype%> which then means by setting the value of this user data key it’s easy to change the type displayed to the user. I knew that only the Pro version supports the editing of these user data keys but had been assured by the OmniGraffle Support Ninjas that whilst the iPad and plain OmniGraffle applications couldn’t edit them they wouldn’t strip them out. But could they understand them?

Yes and no it seems. OmniGraffle behaves as OmniGraffle Pro does in that you can see the type names in the stencil and on the drawing canvas. OmniGraffle for iPad however doesn’t parse the user data whilst displaying the stencil and the result was 30-odd objects having no visible type only the <%UserData stereotype%> string. Not good!  Of course for the iPad you don’t have a mouse only fingers and therefore you can’t hover a finger and therefore I had no tool-tip text to save the day. The iPad application does, however, parse the user data and display the object type when you drop it onto the drawing canvas.The desktop versions display a tool-tip for the type or the relationship name making it easy to pick the right thing. Up until this point you’re just guessing. Sent another support request to the OmniGraffle Support Ninjas pointing out this inconsistency. In doing so I discovered that OmniGraffle doesn’t, for whatever reason, display the tool-tip text on mouse-over an object. Added this to the support request.

Update: iPad version failing to parse/display user data whilst object is in the stencil is now a confirmed bug. OmniGraffle not displaying note content as a tool-tip on mouse-over has been raised for debate within the OmniGraffle development team.

What to do in the meantime? I didn’t want to have to produce a second template just for the iPad. Equally I wanted to make use of the stereotype key to keep things consistent. In the end I added a workaround of changing ‘Name’ on each object to things like ‘a system’, ‘an architecture task’ so that there was again visibility of the object type.

The net result shown in the iPad is:

OmniGraffle Stencil for TRAK Available for Use on an iPad

Where Are We Then?

OmniGraffle Stencil for TRAK Provides Objects With Which to Construct TRAK Architecture Description Views

The OmniGraffle Stencil for TRAK provides:

• a set of graphic objects corresponding to the TRAK metamodel stereotypes
  • each graphic object has the TRAK attributes (editable in OmniGraffle Pro)
• a set of connectors corresponding to the TRAK metamodel relationships
• a drawing identification / version box
• available for Mac and iPad platforms
• downloadable within the OmniGraffle application itself - but see below
• available on GraffleTopia

The latest version of this is always on the Sourceforge trakomnigraffle project site. The GraffleTopia version is at version 1 still.

When I solve the problems with AppleScript there will then be an easy means to:

• copy and pasted an object’s attributes (with no value)
• copy and paste and object’s attributes and their values

Of course any drawing application has limitations when it comes to architecture description since it’s hard to keep it consistent and to enforce or check things like correct relationships being made. It is, however, a useful step and a useful addition to the family of implementations of TRAK and with more work should provide a migration path into a dedicated modelling tool. It has it’s place. As with TRAK it has just to be good enough or adequate - we’re not aiming for perfection!

It has, however, taken a lot, lot longer than I’d originally thought.

Comments

Comment on this article

Related Articles

• Trapped in an Unfulfilled Relationship? Perhaps Wise Not to Rush for a Tool Just Yet

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (13% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (7% )
• Conformance Assessment vs ISO/IEC 42010:2011 (7% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (7% )
• TRAK Article Published by The Institution of Engineers (Singapore) (7% )

External Links

• OmniGraffle (desktop)
• OmniGraffle for iPad
• OmniGraffle Stencil for TRAK - project home. http://trakomnigraffle.sourceforge.net
• TRAK stencil on GraffleTopia
• TRAK

TRAK is in the Wild - Now an Open Source Enterprise Architecture Framework

TRAK has been released, thanks to the foresight of London Underground Ltd., under an open source license.

Releasing TRAK under open source is important because

• it is a standard to facilitate the exchange of architecture models
• it recognises that there are many who could contribute expertise if allowed to do so - any with the need or energy/motivation can participate
• it provides a feasible maintenance and support system - one where TRAK has the wherewithall to heal itself
• it keeps the cost of using the standard to a minimum - since architecture is a form of communication we shouldn’t tax it!
• it represents pragmatism in terms of releasing early, not waiting for perfection and in collaborating for the common good

The UK Department for Transport are the sponsor of TRAK as part of a wider systems engineering initiative.

The release of TRAK has been split into 4 products.

The first 2 parts form the logical definition of TRAK.

• the TRAK metamodel. This specifies the allowable object types and relationships that can be used. In essence it provides the language that an architect can use through the set of nouns and verbs. It includes a simplified metamodel for easy reference. It also includes a detailed comparison against MODAF 1.2 in order to set an initial baseline. One of the reasons for release using the GNU Free Documentation License (GFDL) is that the History section is preserved together with attribution to those who help develop TRAK. The metamodel is at trakmetamodel.sourceforge.net
• the TRAK architecture viewpoint definitions. TRAK adopts ISO 42010 / IEEE 1471 practice by having a viewpoint for each architectural view that specifies the concerns addressed, the allowable objects (from the metamodel), the suggested presentation format and the consistency rules. It includes a comparison against MODAF 1.2 view set. It is released as open source under the GFDL at trakviewpoints.sourceforge.net

The second 2 parts are implementations against the logical definition.

• the MDG Technology for TRAK. This is a Sparx Systems Enterprise Architect (EA) file that contains the architectural model used to create both the MDG plugin that implements TRAK in Enterprise Architect and the UML profile for TRAK which is used by Enterprise Architect and any other UML modelling tool. It represents the implementation of both the TRAK metamodel and the TRAK viewpoint definition as far as is possible. It contains the EA plugin and the source EA project file. It is released under the GNU Public License version3 (GPL v3) at mdgfortrak.sourceforge.net
• the UML profile for TRAK. This provides the set of objects and relationships defined within the TRAK Metamodel in a way that any decent UML modelling tool can use. It is released under the GPL v3 at trakumlprofile.sourceforge.net

Not saying it’s perfect - we know it isn’t. It’s good enough for practical purposes and we have a list of things that need looking at. What I hope is, being open source, that anyone needing to apply it in a particular situation and finding it lacking can then get involved to solve the problem. Application and usability are all important - more so than any theoretical underpinning. The framework is not a system - this only arises when you add tools, people, organisations and therefore you always have to address visibility, navigation, affordance etc - in short the user interface for the whole thing. We hope in this way that TRAK will be user-centric and problem-led rather than specification-centric.

If you do want to get involved there are forums set up at the TRAK Viewpoints and TRAK Metamodel sites.

Comments

Comment on this article

Related Articles

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (19% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (13% )
• Conformance Assessment vs ISO/IEC 42010:2011 (6% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (6% )
• TRAK Article Published by The Institution of Engineers (Singapore) (6% )

External Links