Re: [SystemSafety] [EC 61508 and cybersecurity

Date: Mon, 1 Jun 2015 13:18:12 +0200

The idea to mandate clean processes to get assurance (backbone of ARP/DO), even if existing in IEC61508 (somewhat discretely embedded) is not something obvious to process and manufacturing industries. It requires at least two items that don't exist and that these industries are not in a position to finance:

Bertrand Ricque

Program Manager

Optronics and Defence Division

Sights Program

Mob : +33 6 87 47 84 64

Tel : +33 1 58 11 96 82


-----Original Message-----
Sent: Monday, June 01, 2015 1:13 PM
To: The System Safety List
Subject: Re: [SystemSafety] [EC 61508 and cybersecurity


On 01/06/2015 11:03, Peter Bernard Ladkin wrote:

> ...


> IEC 62443 only concerns security in the process industries. At a

recent meeting of the German NC

> on E/E/PE functional safety, a representative from the NC concerned

with IEC 62443 said that

> everything necessary from ISO 27000 had been taken into account and

IEC 62443 was a successful

> enterprise. Having recently suffered through some heinously boring

presentations, involving

> subdivision and classification and boxes and arrows as far as the eye

could see, I .... um .....

> reserve judgement.

I have found a lengthy presentation of 62443 on the internet. It seems to be a mix of 27001 and architectural partitioning into "zones"

separated by firewalls. The presentation said "be very careful designing and implementing the firewalls".

Little engineering and nothing useful on assurance.

I can't see how I could use it to provide adequate confidence that I had controlled the security threats to a safety-critical system adequately.


> You can only find out about results of the IEC Working Group by being

in it, as far as I can tell.

> I've tried to find out and get two sentences in reply. They are a

different two sentences for each

> colleague I ask. I don't "AND" the replies.

A sensible engineering standardisation process would start with an public discussion between experts about the scope of the standard and the criteria for judging a good outcome. Once these were agreed, the development of the standard would also be public and interactive.

The current processes seem to have nothing to recommend them.


-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

Comment: GPGTools -









The System Safety Mailing List

systemsafety_at_xxxxxx #
" 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_xxxxxx Received on Mon Jun 01 2015 - 13:18:18 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST