[SystemSafety] Cybersecurity in IEC 61508

Peter Bernard Ladkin ladkin at causalis.com
Sun Feb 24 15:36:50 CET 2019


As many here know, I am on both of the IEC 61508 maintenance teams, who are revising IEC 61508:2010.
The call for maintenance went out in 2017 and the IEC received somewhat over 250 comments
recommending/requiring changes from the 30+ National Committees participating in IEC SC65A.

We have somewhat over 20 "task groups" working on particular parts of the document which National
Committee comments said need attention. We are aiming towards a CD ("Committee Draft") to send out
at the beginning, when the formal maintenance period is declared. (Declaring maintenance formally
gives a specific timetable of two years for the revised version. The committees have decided not to
call maintenance formally until we are pretty sure we have a draft revision addressing all of the
current NC comments.)

Working in standards is messy and often frustrating. And often beset by levels of expertise well
below that which one might imagine should be involved. But, however messed-up the process, it has
social consequences. Back some 7 years ago I was helping some lawyers dealing with a hugely
expensive industrial accident with intercontinental stakeholder involvement. The junior barrister on
the case had been through the standards, including IEC 61508, in a few days and, despite having no
formal engineering expertise, had a grasp of their requirements well exceeding that of most of my
students. In many countries, such standards are law, and these highly capable lawyers are arguing
them in tribunals and courts. (That leads to its own anomalies: certain editions of the EN 5012x
series have become German rail law, say EN 5012x Ed. n. Then comes a next edition (n+1), which of
course differs from Ed. n in certain important respects. And there is another law saying one has to
apply the state-of-the-art as defined in contemporary standards. The law thereby contradicts itself:
Ed. n is the law, but there is also a law which says you are to use Ed. (n+1). This really happens.)

One of the issues attracting a lot of current attention in the MTs (that is, a "task group" with 15
or so members) is cybersecurity. We've been here before. I am trying to figure out a modus operandi
which will lead to the best result (whatever that is).

Cybersecurity is addressed in just a couple of places in the IEC 61508 series. Summarised and
discussed in https://rvs-bi.de/publications/books/RVS-Bk-17-01/Ch13-SecurityIn61508-61511.pdf There
are a number of NC comments to the effect that this is inadequate (I agree with this judgement).

There is general agreement that IEC 61508 is not the place to describe details of cybersecurity
analyses and how they are to be performed. Currently, the IEC 64223 series (Cybersecurity for IACS)
is referenced. There is a Technical Report giving some guidance for IACS safety+security due to be
published "any day now", IEC TR 63069, which I have commented on here recently. Many specific
industry sectors have "adapted" safety guidance originating with IEC 61508, and some are now doing
the safety+cybersecurity thing.

However, the cybersecurity task group in the IEC 61508 maintenance teams has a quandary. There are
two incompatible proposals for how to accommodate cybersecurity concerns. Consensus is required, but
seems far away.

One proposal is mine. I suggest:

* During Hazard and Risk Analysis (H&RA Part 1 subclause 7.4), a cybersecurity risk analysis *shall*
(i.e., mandatorily) take place (current wording says "should", i.e., highly recommended)

* During requirements formulation (Part 1 subclause 7.5), cybersecurity requirements addressing the
vulnerabilities shall be formulated. And fulfilled.

* All this is to be documented.

Another proposal is:

* to take all mention of cybersecurity out of H&RA, and out of requirements, etc. Completely out.

A general rationale given for this is that cybersecurity is like electrical safety and other
specific sources of hazard and risk. Electrical safety is not mentioned explicitly in IEC 61508; so
why mention cybersecurity? Both are covered in their own theme-specific standards.

Now, I have my answer as to why cybersecurity is not like electrical safety. But my point here is to
give the essence of the two proposals.

Expert members of this list (and others) likely have a good idea which proposal they might favor and
why. But there is not open discussion of this issue, let alone any form of "community resolution".
One can certainly understand and support confidentiality when intellectual property is being
discussed, but there is no intellectual property associated with any of the requirements concerning
hazard and risk analysis, including cybersecurity-risk, in IEC 61508. (Indeed, I am not aware of any
intellectual property associated with any of the parts of IEC 61508. If there is some, please
educate me!)

I have my advisors. Advisors are an acceptable part of IEC proceedings; company colleagues and other
collaborators with specific expertise. I have a couple (one on this list; one not). There are others
interested - I was just contacted by a researcher needing to work on IEC TR 63069 but who couldn't
(amongst other things, because it has not been published yet!). And of course there are others on
this list who are also on the IEC MTs, indeed in the cybersecurity task group.

Cybersecurity is very important, and it is essential to get it right in IEC 61508 Ed. 3 (whatever
"right" turns out to be). I would like to invite anyone here who is expert in cybersecurity and
safety, and motivated to work on and advise on these matters over the next couple of years, even
though not in the MT, to get in touch with me.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190224/f6fd6fb8/attachment.sig>


More information about the systemsafety mailing list