[SystemSafety] IEC 61508 and cybersecurity

[Peter Bernard Ladkin]

On 2019-09-19 16:52 , Andrew Banks wrote:
> While the article shows a reasonable understanding of things I note:
> 
>>> I have long advocated for peer review of standards documents at the final pre-publication stage by acknowledged senior scientists in the area.
> 
> Anyone (Note 1) can join their National Body mirror panel.  The National Body members get to comment and vote at DIS and FDIS. 

That manifestly does not suffice to ensure that valid technical criticism is (a) raised to the
authoring committee and (b) acted upon by that committee. I have multiple personal experiences of this.

Amongst other things, there are plenty of large to very-large companies involved, with special
interests and plenty of resources to pursue them. That's OK when they are fighting over the shape of
a plug. It is not OK when they are maintaining that their security departments are separate from
their safety departments so that cybersecurity must be clearly separated from other E/E/PE
dependability properties.

There is a lot of high-worth industrial politics which individuals cannot deal with (there aren't a
lot of Greta Thunbergs around). And then there is the cost of involvement. Travel costs for the IEC
61508 MT amount to about £6000 p.a. if one attends all meetings. On top of that, attending the
German electrotechnical software safety committee regularly was costing upwards of €1600 p.a. and
the meetings of the German NC €400-800 depending on whether I needed to overnight. And they all met
for 20-22 working days per year. That is about a person-month: 8% of one's working time. A decade
ago, senior engineers were being costed at about €15,000 per person-month for participation in
European projects. Put that all together, and participation can be priced at about €23,000 p.a. For
what will be nominally 4-5 years for Edition 3 of IEC 61508, but in fact the SW MT has been meeting
two years longer than that.

However, three independent individual referees at the conclusion of the standards-development
process can identify the more blatant biases. But again, as I noted, when the stakes are high, the
"independent referees" are also subject to special-interest capture (of inappropriate sort). A
referee costs €2000 a day, all up, for a face-to-face. Three of them cost €6000, in the multiyear
life of a standardisation project. (Well, if they find stuff and send it back, that goes up a bit.
But not much.) That is not a lot of money, in comparison with the resources the committee members
have put in. Company economists can do the arithmetic, just as I can. They won't want to be putting
tens-to-hundreds of thousands of <monetary units> into their special interests unless there is a
good chance they pass end-review.

There is a way of mitigating possibly inappropriate special-interest capture of reviewers, which is
to make the reviews publicly available.

> But to the nub of the article... I can understand IEC 61508 not wishing to become yet another security standard... there are plenty to choose from already.  In this, I think ISO 26262 got it right (Note 2), by addressing the interaction between safety and security, and emphasising that (cyber)security must be considered, but going no deeper.

I support that approach, but I would add that the standard should say where in forward development
and in maintenance cybersecurity be considered, and how, and what the products of that consideration
are. For example, (1) cybersecurity vulnerabilities should be considered in hazard analysis, and
requirements devised for mitigation of those hazards, as for all hazards. (2) It should be
documented which cybersecurity vulnerabilities were expressly considered, and what the (degree of)
protection against those vulnerabilities consists in, and this documentation shall be made expressly
available to the operators.

Both (1) and (2) are strenuously disputed in the MTs at present. They are also not present in any
applicable cybersecurity standard of which I am aware. (1) is actually present in IEC 61508-1:2010.
There is currently a move to take it out.

There is also a dispute as to the relation to/with IEC 62443. That is a cybersecurity standard, but
for IACS. As pointed out by a transport specialist at a safety conference I was attending, "I work
in rail. We can't put fences around our kit and patrol to keep people out." They have train control
commands going cross-country over the ether (ERTMS); network/signal cabling cross-country in the
open air, and key signalling processors sitting trackside where anybody can get to them, all
obviously vulnerable to physical MITM cyberattack. (Physical DoS, people cutting cables, is
relatively easily sensed by building a continuity wire into the cable.)

Currently, IEC 61508 refers to IEC 62443 as the only cybersecurity reference. Some of us think that
is woefully inadequate, even for IACS alone. For example, NIST SP 800 82 Revision 2 has an Appendix
C of threat sources and vulnerabilities which could well be used during hazard analysis according to
IEC 61508-1:2010 subclause 7.4. The NIST list is not complete. But no IEC standard as far as I am
aware includes such a list. The Mitre CWE list is not regarded as a standards-equivalent document.
And there is nothing pointing towards the US CERT-ICS CVE lists. As far as I know, there is no IEC
standard which says thou shalt refer to NIST SP 800 82 <latest revision> and CWE and CVE lists and I
am not sure at this point whether there could be, given IEC restrictions on normative references.

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/20190920/4519b5a1/attachment.sig>