[SystemSafety] Cybersecurity for safety in IEC 61508-3

Fri Jul 5 15:32:01 CEST 2019

Peter

For info, Adelard produced the following guidance for the Centre for the Protection of National Infrastructure (CPNI)

CPNI, Rail Code of Practice for Security-Informed Safety, A Good Practice Guide, Version 1.0, March 2019

While rail-oriented, the bulk of the guidance is generic (~30 pages of
clauses  inc supporting notes)
I think it should be relevant in a IEC 61508 context.
-but don't think it is publicly available yet

Peter Bishop

On 04/07/2019 17:56, Peter Bernard Ladkin wrote:
> Folks,
>
> IEC 61508-3, the software part of 61508, describes how safety-related software is to be developed,
> inspected, assessed (let me use the word "evaluated" for all these). Safety-related SW is SW which
> implements in part or in full a safety function.
>
> A safety function is a system function deemed to be necessary to reduce a specific risk of operating
> the system to an acceptable level; itself it gets a reliability criterion called a Safety Integrity
> Level (SIL) which indicates how reliable it needs to be in order to render the risk acceptable.
>
> The software has to exhibit a "systematic capability" (SC), which is a quality which renders it
> appropriate for implementing a safety function with a given SIL. SC 4 is for SIL 4, SC 3 for SIL 3,
> SC 2 for SIL 2 and SC 1 for SIL 1.
>
> It is appropriate to question some (or all) of these concepts, but I am not proposing to do that here.
>
> There are 40+pp of requirements on safety-related SW and its development in IEC 61508-3. And these
> requirementscurrently take no explicit account of possible cybersecurity vulnerabilities in the SW.
>
> Now, supposing SW exhibits SC 3, so is appropriate for implementing a safety function with SIL 3.
> And suppose it has a vulnerability. Exploitation of that vulnerability may render the SW no longer
> SC 3. So it is important not only that the SW be assessed to achiev SC 3, but that it be assessed to
> achieve *and maintain* SC 3 (in the face of its vulnerabilities).
>
> So to clauses of 61508-3 which relate to SW being evaluated to achieve SC 3 must be added a
> requirement to evaluate it to maintain SC 3 in face of its vulnerabilities (which usually would
> result in an attempt to mitigate the vulnerabilities).
>
> That is just one of the ways in which IEC 61508-3 might be modified to account appropriately for
> cyber(in)security properties.
>
> Just over a month ago, I went through the entire IEC 61508-3, identified clauses which needed
> modifying in the face of cyber(in)security phenomena, and modified them in a manner I thought was
> appropriate. The documentation of these modifications consists of a series of citations of
> subclauses: current version; proposed modified version; justification for modification.
>
> Changes are many (the document is some 15pp long); justifications are moderately repetitive.
>
> I would like to get some outside expert opinion on my proposal. I would be very grateful if people
> here who are familiar with IEC 61508-3 would consider it and offer an opinion (I have two so far:
> one says it could be condensed; the other suggests it is pointless and unnecessary). If you let me
> know that you are willing to offer your opinion, I will send you the document to review on the basis
> that you actually give me your opinion (no matter how short, long, acquiescent or caustic it may be).
>
> The only result I can guarantee from this process is that the next version of the proposal will be
> improved. It is then for my colleagues in the MT to decide what will go out in the CD to be assessed
> by the National Committees.
>
>
> Please drop me a note if you would be willing to read and offer comment.
>
> The compensation I can offer for your effort is this. I collect the commentaries together with
> attribution, and distribute the commentary to my colleagues on the MT and also publish it on the
> site ResearchGate.
>
> I did that with a query on attitudes to logic in computer science, some years ago, and published the
> assembled commentaries on my WWW site. It helped with the formulation of what is now an IEC project
> on the use of formal methods in dependable-SW development. I think ResearchGate is a more visible
> venue than my WWW pages.
>
> I am discovering that my most-read (for which read: most requested-full-text) papers are those which
> I would have wished. My comparison of ED-153 with IEC 61508, presented at the 2016 IET SSCS
> conference and distributed (unfortunately) only to the 160+ participants, of whom probably only a
> couple of dozen read it, has some 500+ reads on ResearchGate (IET take note!). People do look there
> for stuff they want to read. I am finding out much more about what my mathematician collaborator
> from 30+ years ago, Roger Maddux, is doing now than I ever did through looking at his WWW site. And
> so on. The site appears to do its job of encouraging readers and so that's where your assembled
> commentary will go. (I am also open to private comments and will treat them as such.)
>
> PBL
>
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> MoreInCommon
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319  www.rvs-bi.de
>
>
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-- 
Peter Bishop
Chief Scientist
Adelard LLP
24 Waterside, 44-48 Wharf Rd, London N1 7UX
http://www.adelard.com
Recep:  +44-(0)20-7832 5850
Direct: +44-(0)20-7832 5855

Registered office: 5th Floor, Ashford Commercial Quarter, 1 Dover Place,
Ashford, Kent TN23 1FB
Registered in England & Wales no. OC 304551. VAT no. 454 489808

This e-mail, and any attachments, is confidential and for the use of
the addressee only. If you are not the intended recipient, please
telephone 020 7832 5850. We do not accept legal responsibility for
this e-mail or any viruses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190705/4b01ec99/attachment.html>