[SystemSafety] Fwd: "Protected" Environments

Sun Nov 11 02:31:05 CET 2018

The first view might also be driven by the inherent vulnerability of legacy systems that are 20 to 30 years old and a belief that the only practical approach is the castle defence.  

Matthew Squair

MIEAust, CPEng
Mob: +61 488770655
Email; Mattsquair at gmail.com
Web: http://criticaluncertainties.com

> On 10 Nov 2018, at 10:14 pm, Peter Bernard Ladkin <ladkin at causalis.com> wrote:
> 
> From Bertrand. Somehow this didn't get distributed to the List.
> 
> 
> -------- Forwarded Message --------
> Subject:    RE: [SystemSafety] "Protected" Environments
> Date:    Fri, 9 Nov 2018 08:45:40 +0000
> From:    RICQUE Bertrand (SAFRAN ELECTRONICS & DEFENSE) <bertrand.ricque at safrangroup.com>
> To:    Peter Bernard Ladkin <ladkin at causalis.com>, The System Safety List
> <systemsafety at techfak.uni-bielefeld.de>
> 
> 
> 
> I will add some personal comments to Peter’s general introduction.
> 
>  
> 
> In addition to the terminology issue, the elaboration of IEC TR 63069 has highlighted fundamental
> conflicts in the approach to safety and security.
> 
>  
> 
> The concept of « security environment » is at the heart of this conflict.
> 
>  
> 
> In brief and schematically two positions are opposing themselves :
> 
> 1.       Security threats are potentially additional causes of dangerous system failures as any
> others and thus, have to be included in the H&RA and will consequently influence the results of the
> H&RA (might increase SIL/DAL/ASIL in the worst case, might influence the system requirements).
> 
> 2.       The above position is not acceptable because far too expensive and complex, and thus
> unacceptable for industry. Safety functions must be « protected » by a « security » environment, so
> that the safety requirements remain unchanged (or very little influenced). The paradigm is, citing a
> tenant of this position, that « It is fact, that to properly investigate functional safety, the
> system has to be considered free from security attacks and this target (freedom from attacks) needs
> to remain.”
> 
>  
> 
> The proponents of position 2 come mainly from machinery/manufacturing industries and somewhat from
> process industries. As it is common for them to be able to handle safety by the means of independent
> dedicated HW and SW, their position can be understood. The “system” for them is not the plant.
> 
>  
> 
> The proponents of position 1 argue that considering a car, a plant, a plane or plant “free from
> security attacks” is an insult to intelligence and H&RA state of the art.
> 
>  
> 
> The opposition between these two positions is now a hot topic in the frame of the preparation of
> edition 3 of IEC 61508.
> 
>  
> 
> RESTRICTED
> 
>  
> 
> Bertrand RICQUE
> 
> Program Manager | Optronics and Defence Division |  Customer Support
> 
> Safran Electronics & Defense
> 
>  
> 
> P +33 (0)1 58 11 96 82 �M +33 (0)6 87 47 84 64
> 
> bertrand.ricque at safrangroup.com
> 
> 102 Avenue de Paris
> 
> 91300 MASSY FRANCE
> 
> www.safran-electronics-defense.com
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> -----Message d'origine-----
> De : systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] De la part de Peter
> Bernard Ladkin
> Envoyé : vendredi 9 novembre 2018 06:45
> À : The System Safety List
> Objet : [SystemSafety] "Protected" Environments
> 
>  
> 
> Folks,
> 
>  
> 
> The IEC is about to publish guidance on safety+security in industrial automated control systems
> (IACS). The document is IEC TR 63069 and will be published in January 2019. It is supposed to be
> guidance in the use of IEC 61508 and IEC 62443 together in designing/evaluating IACS.
> 
>  
> 
> A number of us have been following the progress of this document for a few years. The final result
> is quite vague, largely because it contains lots of undefined terms and phrases, and its central
> guidance seems to many of us to be unattainable in the current state of the art.
> 
>  
> 
> There are other problems, for example it contains a table of "multiply-defined terms" in IEC 61508
> and the IEC 62443 series. There are twelve such terms. One may wonder why they are deemed "multiply
> defined", since some are defined in one document but not in the other (surely those should be
> "singly defined terms"?) In fact, the project Harbsafe in which I work has been through IEC 61508,
> IEC 62443 series (as it was in January 2017 - other parts have been published since), as well as
> Guide 51 (guidance in what must be in all standards which have safety aspects; namely adequate risk
> 
> analysis) and Draft Guide 120 (as it was; it has now been published: guidance in what must be in all
> standards which have cybersecurity aspects). There are in fact 68 multiply-defined terms.
> 
>  
> 
> This fact was fed in through the usual IEC procedures as comment on a draft of 63069. I believe it
> was filtered out.
> 
>  
> 
> That says a lot about the intellectual standard of this work.
> 
>  
> 
> The central premise/guidance is that it is for cybersecurity specialists to establish a "security
> environment" (a key term, not well defined) in the IACS, within which environment safety engineers
> can go about analysing and designing their safety functions under the assumption that cybersecurity
> is assured. Let me call this CP.
> 
>  
> 
> So, for example, you have your control computer sitting in building A and the controlled system in
> building B (often the case with turbines and generators and so on, so that when they self-destruct
> the damage is limited). The cables transmitting sensor information to the controller and control
> information to the equipment actuators run between the buildings, and there might be a repeater or
> two. Since a "security environment" is presumed to have been established, engineers designing the
> protocols and commissioning the equipment with which this communication is effected can assume
> everything they deal with is cybersecure. So, for example, there might be a need for CRC, but there
> is no need for message encryption under this assumption.
> 
>  
> 
> If there is no need for message encryption, then an employee with access can run a MITM attack
> from/through one of the repeaters.
> 
>  
> 
> Duuuh.
> 
>  
> 
> Unfortunately, this has consequences. Such thinking may well affect how cybersecurity is handled in
> the next edition of IEC 61508.
> 
>  
> 
> Hence my question. Does anyone know of an actual civilian safety-related system which is equipped
> with such an impenetrable "security environment"?
> 
>  
> 
> The reason for my question is as follows. Standards are supposed to reflect the state of the art. If
> there isn't such a system (actually, if there aren't lots of them), then this proposed architecture
> is pie-in-the-sky and accordingly shouldn't be reflected in a standards document.
> 
>  
> 
> PBL
> 
>  
> 
> Prof. Peter Bernard Ladkin, Bielefeld, Germany MoreInCommon Je suis Charlie
> 
> Tel+msg +49 (0)521 880 7319  www.rvs-bi.de <http://www.rvs-bi.de>
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des informations
> confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un
> caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit
> de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu.
> Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par
> erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique
> ce courriel ainsi que tous les documents qui y sont attachés."
> ******
> " This e-mail and any attached documents may contain confidential or proprietary information and may
> be subject to export control laws and regulations. If you are not the intended recipient, you are
> notified that any dissemination, copying of this e-mail and any attachments thereto or use of their
> contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is
> prohibited. If you have received this e-mail in error, please advise the sender immediately and
> delete this e-mail and all attached documents from your computer system."
> #
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181111/f34e3291/attachment.html>