[SystemSafety] Partly Off Topic: What Happens in October [No Classification]

[Barnes, Robert A (NNPPI)]

This message has been marked as No Classification by Barnes, Robert A (NNPPI)


This is quite a specific example and I'd argue that, if the security case rests on a single point of failure in non-assured software, something has gone horribly wrong in the design and development of this system!

Defence in depth has become an accepted principle in safety engineering, and it is just as valid in security.  There should be no single point or perimeter, the failure of which would lead to the system becoming insecure; this is the same that there should be no single point of failure in a system that leads to an unsafe condition.  Arguably, in your example, these are one and the same as an insecure system of this nature can't be safe, right?  So who has dropped the ball?

-Rob

-----Original Message-----
From: Peter Bernard Ladkin [mailto:ladkin at causalis.com]
Sent: 18 October 2016 11:47
To: Barnes, Robert A (NNPPI); The System Safety List
Subject: Re: [SystemSafety] Partly Off Topic: What Happens in October [No Classification]



On 2016-10-18 12:16 , Barnes, Robert A (NNPPI) wrote:
> Firstly, what are we attempting to achieve by patching systems?  .... 
> The reoccurring bone of contention with patching to address security 
> vulnerabilities is safety certification: changing the software changes 
> the system and recertification is therefore necessary.  However, there is always more than one way to skin a cat and patching is just one way of managing a known vulnerability.

So, suppose you have a trusted communication system administered through a despec-ed version of Mac OS. And somebody tells you they think it was compiled with the "go to fail" bug. So you don't actually know if the code is validating its trusted communication partners or not. You and by now a few hackers looking for a good time (let's hope that's all they are looking for). Presumably you could find out in a day or so. Some hacker will likely be quicker.

Say the service is distributing session keys for, say, train control. (Germany will be doing this
centrally.)

I guess you could stop all long-distance trains running in the country until you've figured out whether you're vulnerable, and until you've fixed it and revalidated the system. There'll be lots of unhappy bunnies. (Did I say I once shared a carriage with the German Defence Minister?)

I'd be very tempted to patch, and to do so without first finding out whether I'm vulnerable. What would you suggest I do instead?

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany MoreInCommon Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de






The following attachments and classifications have been attached:
The data contained in, or attached to, this e-mail, may contain confidential information. If you have received it in error you should notify the sender immediately by reply e-mail, delete the message from your system and contact +44 (0) 3301235850 (Security Operations Centre) if you need assistance. Please do not copy it for any purpose, or disclose its contents to any other person.

An e-mail response to this address may be subject to interception or monitoring for operational reasons or for lawful business practices.

(c) 2016 Rolls-Royce plc

Registered office: 62 Buckingham Gate, London SW1E 6AT Company number: 1003142. Registered in England.