[SystemSafety] Fwd: "Protected" Environments

[Peter Bernard Ladkin]

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."
#

-------------- 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/20181110/76f859bb/attachment.sig>