[SystemSafety] Cybersecurity for safety in IEC 61508-3

[paul cleary]

Interesting proposal Peter. My only concern is these reissued standards 61508), while at the leading edge, will only serve to subvert existing railway standards for Sw (50128). Is there any interface communication, or coworking group with Cenelec, to ensure, too novel approaches, will be incorporated in existing rail standards? 

Regards
Paul Cleary
Rail Assured Consulting 
Rail Assurance Consulting 

Sent from my iPad

> On 4 Jul 2019, at 23:57, Peter Bernard Ladkin <ladkin at causalis.com> 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