[SystemSafety] UK principles for security of driverless cars [No Classification]

Wed Aug 9 02:12:47 CEST 2017

My experience is that if you give a principles document to an engineer for
whom it is not their ‘bread and butter’ it will be used to prop open the
door. To go from principles to application in any discipline requires
expertise.

There’s also a simple solution that I think everyone is studiously
overlooking, and that’s to legislate that you can’t connect a car’s
critical systems to the internet. Everyone acts as if the
interconnectedness of everything is a lay down mazare, but the reality is
it’s a social choice like anything else, and there’s nothing that says that
you [have] to trade off security/safety for the convenience of the Tesla
corporation (or any other).

The other perspective is that once you have an exploitable remote attack
for one car, you have it for [all] the cars running that software, that you
can reach. That was the take home of the Chrysler/Jeep hack for me. Again
we tend to fall into the trap of thinking about these problems as just one
instance. But we actually need to scale up the severity to cover the
scenario, of what happens if all the cars released by company X are hacked
and (for example) suddenly start indiscriminately accelerating, braking and
reversing? Botnet jihad anyone?

https://criticaluncertainties.com/2015/07/25/more-internet-of-everything-hijinks/#more-9787

On 9 August 2017 at 9:12:49 am, Driscoll, Kevin R (
kevin.driscoll at honeywell.com) wrote:

> What we should be worried about is someone remotely abusing …

At the recent “Black Hat”, another “slew of Tesla attacks
<http://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/>
” was revealed as well as details of last year’s.  Of course, both last
year’s and this year’s vulnerabilities are claimed to have been patched.
Next year, …

We should do better than the “pile of bandages” approach to safety and
security.  An in-vehicle network designed for safety and security would
have stopped all the external automobile attacks I know of, which “leap
frog” from a broken non-critical system to critical functions via the
vehicle’s network.

> Views?
Typical “do everything”, without regards to cost or feasibility.  An
example of the latter:

*Principle 5.1 *The security of the system does not rely on single points
of failure, security by obscuration or anything which cannot be readily
changed, should it be compromised.

So, everything has to be readily changeable, which requires a change
mechanism that then becomes the single-point-of-failure.  Replace
“competing standards” with “single points of failure” in the comic
xkcd.com/927.  Look at all the attacks where the vector was the “flashing
mechanism” used to implement this principle.

In general, it is not clear that “defence in depth” is more cost-effective
than fewer and better defences.  Without such evidence, all of Principle 5
is argument from ignorance or assumption of infinite size, weight, power,
and cost budgets.

What disk on a vehicle needs “full disk encryption” vs just file encryption
for some files??

</troll mode>

*From:* systemsafety [mailto:
systemsafety-bounces at lists.techfak.uni-bielefeld.de] *On Behalf Of *Barnes,
Robert A (NNPPI)
*Sent:* Tuesday, August 08, 2017 12:06
*To:* martyn at thomas-associates.co.uk;
systemsafety at lists.techfak.uni-bielefeld.de
*Subject:* Re: [SystemSafety] UK principles for security of driverless cars
[No Classification]

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

Hi Martyn

The interplay between safety and security isn’t apparent in the
principles.  My experience of discussing security with safety engineers
(and engineers in safety critical work) is that it’s concerned with
authorisation and confidentiality, and is something separate to safety ie.
“Outside of the sphere of things I have to be worried about right now.”  I
am concerned that, when discussing vehicle security, we are in danger of
falling into the same trap.  When considering vehicle security, many would
think of locks, alarms and immobilisers – these are all solved problems.
What we should be worried about is someone remotely abusing the
internet-connected entertainment system to interfere with the safe
operation of the vehicle, and that doesn’t come across in the principles.

Regards,

-Rob

The following attachments and classifications have been attached:

*From:* systemsafety [
mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de
<systemsafety-bounces at lists.techfak.uni-bielefeld.de>] *On Behalf Of *Martyn
Thomas
*Sent:* 08 August 2017 16:36
*To:* systemsafety at lists.techfak.uni-bielefeld.de
*Subject:* [SystemSafety] UK principles for security of driverless cars

https://www.gov.uk/government/publications/principles-of-cyber-security-for-connected-and-automated-vehicles/the-key-principles-of-vehicle-cyber-security-for-connected-and-automated-vehicles
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gov.uk%2Fgovernment%2Fpublications%2Fprinciples-of-cyber-security-for-connected-and-automated-vehicles%2Fthe-key-principles-of-vehicle-cyber-security-for-connected-and-automated-vehicles&data=02%7C01%7Ckevin.driscoll%40honeywell.com%7C011b79677d0640121ef308d4de7f971e%7C96ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C636378086974951926&sdata=nSw53dXLTpUmHriLq6hQ6EcidWBtrl4AY48EkEnVQmI%3D&reserved=0>

Views?

Martyn

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) 2017 Rolls-Royce plc

Registered office: 62 Buckingham Gate, London SW1E 6AT Company number:
1003142. Registered in England.
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170808/2cf17a62/attachment.html>