36C3 - The sustainability of safety, security and privacy

prerol music

Herald: Our next speaker, he's a professor
of security engineering at Cambridge

University. He is the author of the book
Security Engineering. He has done a lot of

things already. He has been inventing semi
invasive attacks based on inducing photo

currence. He has done API attacks. He
has done a lot of stuff. If you read his

bio is it feels like he's involved in
almost everything we like related to

security. So please give a huge round and
a warm welcome to Ross Anderson and his

talk, The Sustainability of safety,
security and privacy.

applause

Ross Anderson: Thanks. Right. It's great
to be here, and I'm going to tell a story

that starts a few years ago and it's about
the regulation of safety. Just to set the

scene, you may recall that in February
this year there was this watch Enox's

Safe-Kid One suddenly got recalled. And
why? Well, it's unlikely that unencrypted

communications with the backhand server
allowing an authenticated access and

translated into layman language that meant
that hackers could track and call your

kids, changed the device ID and do
arbitrary bad things. So this was

immediately recalled by the European Union
using powers that it had under the Radio

Equipment Directive. And this was a bit of
a wake up call for industry, because up

until then, people active in the so-called
Internet of Things didn't have any idea

that, you know, if they produced an unsafe
device, then they could suddenly be

ordered to take it off the market. Anyway,
back in 2015, the European Union's

research department asked Eireann Leverett,
Richard Clayton and me to examine what I

would see implied from the regulation of
safety, because the European institutions

regulate all sorts of things, from toys to
railway signals and from cars through

drugs to aircraft. And if you start having
software and everything, does this mean

that all these dozens of agencies suddenly
start to have software safety experts and

software security experts? So what does
this mean in institutional terms? We

produced a report for them in 2016, which
the commission sat on for a year. A

version of the report came out in 2017 and
later that year the full report. And the

gist of our report was once you get
software everywhere, safety and security

become entangled. And in fact, when you
think about it, the two are the same in

pretty well all the languages spoken by EU
citizens. speaks other languages.

It's only English that distinguishes
between the two. And with

Britain leaving the EU, of course you will
have languages in which safety and

security become the same. Throughout
Brussels and throughout the continent. But

anyway, how are we going to update safety
regulation in order to cope? This was the

problem that Brussels was trying to get
its head around. So one of the things that

we had been looking at over the past 15,
20 years is the economics of information

security, because often a big complex
systems fail because the incentives are

wrong. If Alice guards the system and Bob
pairs the cost of failure, you can expect

trouble. And many of these ideas go across
the safety as well. Now, it's already well

known that markets do safety in some
industries, such as aviation, way better

than others, such as medicine. And cars
were dreadful for many years for the first

80 years of the car industry. People
didn't bother with things like seatbelts,

and it was only until Ralph Nader's book,
Unsafe at Any Speed, led the Americans to

set up the National Highways,
Transportation and Safety Administration

and various court cases brought this
forcefully to public attention that car

safety started to become a thing. Now in
the EU, we've got a whole series of broad

frameworks and specific directives and
detail rules and thus overall 20 EU

agencies plus the UNECE in play here. So
how can we navigate this? Well, what we

were asked to do was to look at three
specific verticals and study them in some

detail so that the lessons from them could
be then taken to the other verticals in

which the EU operates. And, cars were one
of those. And some of you may remember the

carshark pepper in 2011. Four guys from
San Diego and the University of Washington

figured out how to hack a vehicle and
control it remotely. And I used to have a

lovely little video of this that the
researchers gave me. But my Mac got

upgraded to Catalina last week and it
doesn't play anymore. So, verschlimmbessern?

Man sagt auf Deutsch? Oder?
Yeah.

applause

Okay. We'll get it going sooner or later.
Anyway, this was largely ignored because

one little video didn't make the biscuit.
But in 2015, there suddenly came to the

attention of the industry because Charlie
Miller and Chris Valasek, two guys who had

been in the NSA is hacking team hacks a
cheap Cherokee using Chryslers Uconnect.

And this meant that they could go down
through all the Chrysler vehicles in

America and look at them one by one and
ask, where are you? And then when they

found the vehicle that was somewhere
interesting, they could go in and do

things to it. And what they found was that
to hack a vehicle, suddenly you just

needed the vehicle's IP address. And so
they got a journalist into a vehicle and

they got into slow down and had trucks
behind them hooting away, and eventually

they ran the vehicle off the road. And
when the TV footage of this got out,

suddenly, people cared. It made the front
pages of the press in the USA, and

Chrysler had to recall 1.4 million
vehicles for a software fix, which meant

actually reflashing the firmware of the
devices. And it cost them billions and

billions of dollars. So all of a sudden,
this is something to which people paid

attention. Some of you may know this chap
here, at least by sight. This is Martin

Winterkorn, who used to run Volkswagen.
And when it turned out that he had hacked

millions and millions of Volkswagen
vehicles by putting in evil software that

defeated emissions controls. That's what
happened to Volkswagen stock price. Oh,

and he lost his job and got prosecuted. So
this is an important point about vehicles

and in fact, about many things in the
Internet of things for Internet of

targets, whatever you want to call it. The
thread model isn't just external, it is

internal as well. There are bad people all
the way up and down the supply chain. Even

at the OEM. So that's the state of play in
cars. And we investigated that and wrote a

bit about it. Now, here's medicine. This
was the second thing that we looked at.

These are some pictures of the scene in
the intensive care unit in Swansea

Hospital. So after your car gets hacked
and you go off the road, this is where you

end up. And just as a car has got about 50
computers in it, you're now going to see

that there's quite a few computers at your
bedside. How many CPUs can you see? You

see, there's quite a few, about a
comparable number to the number of CPUs in

your car. Only here the systems
integration is done by the nurse, not by

the engineers at Volkswagen or Mercedes.
And does this cause safety problems? Oh,

sure. Here are pictures of the user
interface of infusion pumps taken from

Swansea's intensive care unit. And as you
can see, they're all different. This is a

little bit like if you suddenly had to
drive a car from the 1930s an old

Lanchester, for example, and then you find
that the accelerator is between the brake

and the clutch, right? Honestly, there
used to be such cars. You can still find

them in antique car fairs or a Model T
Ford, for example, for the accelerator is

actually a lever on the dashboard and one
of the pedals is as a gear change. And yet

you're asking nurses to operate a variety
of different pieces of equipment and look,

for example, at the Bodyguard 545. The one
on the top to increase the doors. Right,

this is the morphine that is being dripped
into your vein once you've had your car

crash, to increase the dose you have to
press 2 and to decrease that, you have to

press 0. Under the Bodyguard 545 at the
bottom right, to increase the dose you

press 5 and to decrease it, you press 0.
And this leads to accidents, to fatal

accidents, a significant number of them.
Okay. So you might say, well, why not have

standards? Well, we have standards. We've
got standards which say that liter should

always be a capital L, so it is not
confused with a one. And then you see that

and the Bodyguard on the bottom right.
MILLILITERS is a capital L in green. Okay.

Well done, Mr. Bodyguard. The problem is,
if you look up two lines, you see 500

milliliters is in small letters. So
there's a standard problem. There's an

enforcement problem and there's extra
inanities because each of these vendors

will say, well, everybody else should
standardize on my kit. And there are also

various other market failures. So the
expert who's been investigating this is my

friend Harold Thimbleby, who's a professor
of computer science at Swansea. And his

research shows that hospitals safety,
usability failures kill about 2000 people

every year in the UK, which is about the
same as road accidents. And safety

usability, in other words, gets ignored
because the incentives are wrong. In

Britain and indeed in the European
institutions, people tend to follow the

FDA in America and that is captured by the
large medical device makers over there.

They only have two engineers. They're not
allowed to play with pumps, etc, etc, etc.

The curious thing here is that safety and
security come together. The safety of

medical devices may improve because as
soon as it becomes possible to hack a

medical device, then people suddenly take
care. So the first of this was when Kevin

Fu and researchers at the University of
Michigan showed that they could hack the

hospital, a symbolic infusion pump over
Wi-Fi. And this led the FDA to immediately

panic and blacklist the pump, recalling it
from service. But then said, Kevin, what

about the 200 other infusion pumps that
are unsafe because of the things on the

previous slide? Also, the FDA, we couldn't
possibly recall all those. Then two years

ago, there's an even bigger recall. It
turned out that 450 000 pacemakers made by

St. Jude could similarly be hacked over
Wi-Fi. And so the recall was ordered. And

this is quite serious, because if you've
got a heart pacemaker, right, it's

implanted surgically in the muscle next to
your shoulder blade. And to remove that

and replace it with a new one, which they
do every 10 years to change the battery,

you know, is a day care surgery procedure.
You have to go in there, get an

anesthetic. They have to have a
cardiologist ready in case you have a

heart attack. It's a big deal, right? It
costs maybe 3000 pounds in the UK. And so

3000 pounds times 450 000 pacemakers.
Multiply it by two for American health

care costs and you're talking real money.
So what should Europe do about this? Well,

thankfully, the European institutions have
been getting off their butts on this and

the medical device directors have been
revised. And from next year, medical

devices will have post-market
surveillance, risk management plan,

ergonomic design. And here's perhaps the
driver for software engineering for

devices that incorporate software. The
software shall be developed in accordance

with the state of the art, taking into
account the principles of development,

life cycle risk management, including
information, security, verification and

validation. So there at least we have a
foothold and it continues. Devices shall

be designed and manufactured in such a way
as to protect as far as possible against

unauthorized access that could hamper the
device from functioning as intended. Now

it's still not perfect. There's various
things that the manufacturers can do to

wriggle. But it's still a huge
improvement. The third thing that we

looked at was energy, electricity
substations and electro technical

equipments in general, there have been one
or two talks at this conference on that.

Basically, the problem is that you've got
a 40 year life cycle for these devices.

Protocols such as Smart Bus and DNP3 don't
support authentication. And the fact that

everything has gone to IP networks means
that as with the Chrysler Jeeps. Anybody

who knows your IP address can read from
and with an actuator's IP address, you can

activate it. So the only practical fix
there is to re-perimeterise and the

entrepreneurs who noticed this 10 to 15
years ago and set up companies like Beldon

have now made lots and lots of money.
Companies like BP now have thousands of

such firewalls which isolate their
chemical and other plants from the

internet. So one way in which you can deal
with this is having one component that

connects you to the network, you replace
it every five years. That's one way of

doing, if you'd like sustainable security
for your oil refinery. But this is a lot

harder for cars, which have got multiple
RF interfaces. A modern car has maybe 10

interfaces in all those there is the
internal phone. There's the short range radio

link for remote key entry. Those things.
There are links to the devices that

monitor your tire pressure. There's all
sorts of other things and every single one

of these has been exploited at least once.
And there are particular difficulties in

the auto industry because of the
fragmented responsibility in the supply

chain between the OEM, the tier ones and
the specialists who produce all the

various bits and pieces that get glued
together. Anyway, so the broad questions

that arise from this include who will
investigate incidents and to whom will

they be reported? Right? How do we embed
responsible disclosure? How do we bring

safety engineers and security engineers
together? This is an enormous project

because security engineers and safety
engineers use different languages. We have

different university degree programs. We
go to different conferences. And the world

of safety is similarly fragmented between
the power people, the car people, the

naval people, the signal people and so on
and so forth. Some companies are beginning

to get this together. The first is Bosch,
which put together their safety,

engineering and security engineering
professions. But even once you have done

that in organizational terms, how do you
teach a security engineer to think safety

and vice versa? Then the problem that
bothered the European Union, are the

regulators all going to need security
engineers? Right. I mean, many of these

organizations in Brussels don't even have
an engineer on staff, right? They are

mostly full of lawyers and policy people.
And then, of course, for this audience,

how do you prevent abuse of lock-in, you
know, in America if you've got a chapter

from John Deere? And then if you don't
take it to a John Deere dealer every six

months or so, it stops working. Right. And
if you try and hack it so you can fix it

yourself, then John Deere will try to get
you prosecuted. We just don't want that

kind of stuff coming over the Atlantic
into Europe. So we ended up with a number

of recommendations. We thought that we
would get vendors to self-certify for the

CE mark that products could be patched if
need be. That turned out to be not viable.

We then came up with another idea that
things should be secure by default for the

update to the Ready Equipment Directive.
And that didn't get through the European

Parliament either. In fact, it was Mozilla
that lobbied against it. Eventually we got

something through which I'll discuss in a
minute. We talked about requiring a secure

development lifecycle with vulnerability
management because we've already got

standards for that. We talked about
creating an European security engineering

agency. So that would be people in
Brussels to support policymakers and the

reaction to that. A year and a half ago
was to arrange for ENISA to be allowed to

open an office in Brussels so that they
can hopefully build a capability. There

with some technical people who can support
policymakers. We recommended extending the

product liability directive to services.
There is enormous pushback on that.

Companies like Google and Facebook and so
on don't like the idea that they should be

as liable for mistakes made by Google
Maps, as for example, Garmin is liable for

mistakes made by the navigators. And then
there's the whole business of how do you

take the information that European
institutions already have on breaches and

vulnerabilities and report this not just
to ENISA, but the safety regulators and

users, because somehow you've got to
create a learning system. And this is

perhaps one of the big pieces of work to
be done. How do you take, I mean, once all

cars are sort of semi intelligent, once
everybody's got telemetry and once that

are, you know, gigabytes of data
everywhere, then whenever there's a car

crash, the data have to go to all sorts of
places, to the police, to the insurers, to

courts, and then, of course, up to the car
makers and regulators and component

suppliers and so on. How do you design the
system that will cause the right data to

get to the right place, which will still
respect people's privacy rights and all

the various other legal obligations? This
is a huge project and nobody has really

started to think yet about how it's going
to be done, right. At present, if you've

got a crash in a car like a Tesla, which
has got very good telemetry, you basically

have to take Tesla to court to get the
data because otherwise they won't hand it

over. Right. We need a better regime for
this. And that at present is a blank

slate. It's up to us, I suppose, to figure
out how such a system should be designed

and built, and it will take many years to
do it, right. If you want a safe system, a

system that learns this is what is going
to involve. But there's one thing that

struck us after we'd done this work, after
we delivered this to the European

Commission, that I'd gone to Brussels and
given a thought to dozens and dozens of

security guys. Richard Clayton and I went
to Schloss Dagstuhl for a weeklong seminar

on some other security topic. And we were
just chatting one evening and we said,

well, you know, what did we actually learn
from this whole exercise on

standardization and certification? Well,
it's basically this. That there's two

types of secure things that we currently
know how to make. The first is stuff like

your phone or your laptop, which is secure
because you patch it every month. Right.

But then you have to throw it away after
three years because Larry and Sergei don't

have enough money to maintain three
versions of Android. And then we've got

things like cars and medical devices where
we test them to death before release and

we don't connect them to the Internet, and
we almost never patch them unless Charlie

Miller and Chris Fellowship get to go at
your car that is. So what's gonna happen

to support costs? Now that we're starting
to patch cars and you have to patch cars

because they're online, I want some things
online, right? Anybody in the world can

attack us. If a vulnerability is
discovered, it can be scaled and something

that you can previously ignore suddenly
becomes something that you have to fix.

And if you, you have to pull all your cars
into a garage to patch them, that costs

real money. So you need to be able to
patch them over the air. So all of a

sudden cars become like computers or
phones. So what is this going to mean? So

this is the trilemma. If you've got a
standard safety life cycle, there's no

patching. You get safety and
sustainability, but you can't go online

because you'll get hacked. And if you get
the standard security lifecycle you're

patching, but that breaks the safety
certification, so that's a problem. And if

you get patching plus redoing safety
certification with current methods, then

the cost of maintaining your safety rating
can be sky high. So here's the big

problem. How do you get safety, security
and sustainability at the same time? Now

this brings us to another thing that a
number of people at this congress are

interested in: the right to repair. This
is the Centennial Light, right? It's been

running since 1901. Right. It's in
Livermore in California. It's kind of dim,

but you can go there and you can see it.
Still there. In 1924, the three firms have

dominated the light business. GE, Osram
and Philips agreed to reduce average bulb

lifetime some 2500 hours to 1000
hours. Why? In order to sell more of

them. And one of the things that's come
along with CPUs and communications and so

on with smart stuff to use, that horrible
word, is that firms are now using online

mechanisms, software and cryptographic
mechanisms in order to make it hard or

even illegal to fix products. And I
believe that there's a case against Apple

going on in France about this. Now, you
might not think it's something that

politicians will get upset about, that you
have to throw away your phone after three

years instead of after five years. But
here's something you really should worry

about. Vehicle life cycle economics,
because the lifetimes of cars in Europe

have about doubled in the last 40 years.
And the average age of a car in Britain,

which is scrapped, is now almost 15 years.
So what's going to happen once you've got,

you know, wonderful self-driving software
in all the cars. Well, a number of big car

companies, including in this country, were
taking the view two years ago that they

wanted people to scrap their cars after
six years and buy a new one. Hey, makes

business sense, doesn't it? If you're Mr.
Mercedes, your business model is if the

customer is rich, you sell him a three
year lease on a new car. And if the

customer is not quite so rich, you sell
him a three year lease on a Mercedes

approved used car. And if somebody drives a
seven year old Mercedes, that's thought

crime. You know, they should emigrate to
Africa or something. So this was the view

of the vehicle makers. But here's the rub.
The embedded CO2 costs of a car often

exceeds its lifetime fuel burn. My best
estimate for the embedded CO2 costs of an

E-class American is 35 tons. So go and
work out, you know, how many liters per

100 kilometers and how many kilometers
it's gonna run in 15 years. And you come

to the conclusion that if you get a six
year lifetime, then maybe you are

decreasing the range of the car from 300
000 kilometers to 100 000 kilometers. And

so you're approximately doubling the
overall CO2 emissions. Taking the whole

life cycle, not just the scope one, but
the scope two, and the scope three, the

embedded stuff as well. And then there are
other consequences. What about Africa,

where most vehicles are imported second
hand? If you go to Nairobi, all the cars

are between 10 and 20 years old, right?
They arrive in the docks in Mombasa when

they're already 10 years old and people
drive them for 10 years and then they end

up in Uganda or Chad or somewhere like
that. And they're repaired for as long as

they're repairable. What's going to happen
to road transport in Africa if all of a

sudden there's a software time bomb that
causes cars to self-destruct? Ten years

after we leave the showroom. And if there
isn't, what about safety? I don't know

what the rules are here, but in Britain I
have to get my car through a safety

examination every year, once it's more
than three years old. And it's entirely

foreseeable that within two or three years
the mechanic will want to check that the

software is up to date. So once the
software update is no longer available,

that's basically saying this car must now
be exported or scrapped. I couldn't resist

the temptation to put in a cartoon:
"My engine's making a weird noise."

"Can you take a look?"
"Sure. Just pop the hood. Oh, the hood

latch is also broken. Okay, just pull up
to that big pit and push the car in. We'll

go get a new one."
Right? This is if we start treating cars

the way we treat consumer electronics. So
what's a reasonable design lifetime? Well,

with cars, the way it is going is maybe 18
years, say 10 years from the sale of the

last products in a model range, domestic
appliances, 10 years because of spares

obligation plus store life, say 15.
Medical devices: If a pacemaker lives for

10 years, then maybe you need 20 years. Of
electricity substations, even more. So

from the point of view of engineers, the
question is, how can you see to it that

your software will be patchable for 20
years? So as we put it in the abstract, if

you are writing software now for a car
that will go on sale in 2023, what sort of

languages, what sort of tool change should
you use? What sort of crypto should you

use so that you're sure you'll still be
able to patch that software in 2043? And

that isn't just about the languages and
compilers and linkers and so on. That's

about the whole ecosystem. So what did the
EU do? Well, I'm pleased to say that at

the third attempt, the EU managed to get
some law through on this. Their active 771

this year on smart goods says that buyers
of goods with digital elements are

entitled to necessary updates for two
years or for a longer period of time if

this is a reasonable expectation of the
customer. This is what they managed to get

through the parliament. And what we would
expect is that this will mean at least 10

years for cars, ovens, fridges, air
conditioning and so on because of existing

provisions about physical spares. And
what's more, the trader has got the burden

of proof in the first couple of years if
there's disputes. So there is now the

legal framework there to create the demand
for long term patching of software. And

now it's kind of up to us. If the durable
goods were deciding today are still

working in 2039, then a whole bunch of
things are gonna have to change. Computer

science has always been about managing
complexity ever since the very first high

level languages and the history goes on
from there through types and objects and

tools like git and Jenkins and Coverity.
So here's a question for the computer

scientists here. What else is going to be
needed for sustainable computing? Once we

have software in just about everything. So
research topics to support 20 year

patching include a more stable and
powerful toolchain. We know how complex

this can be from crypto with looking at
history of the last 20 years of TLS. Cars

teach that it's difficult and expensive to
sustain all the different test

environments. You have a different models
of cars. Control systems teach for that

you can make small changes to the
architecture, which will then limit what

you have to patch. Android teaches how do
you go about motivating OEMs to patch

products that they no longer sell. In this
case, it's European law, but there's maybe

other things you can do too. What does it
mean for those of us who teach and

research in universities? Well, since
2016, I've been teaching safety and

security together in the same course the
first year undergraduates, because

presenting these ideas together in
lockstep will help people to think in more

unified terms about how it all holds
together. In research terms we've have

been starting to look at what we can do to
make the tool chain more sustainable. For

example, one of the problems that you have
if you maintain crypto software is that

every so often the compiler writes, okay,
so a little bit smarter and the compiler

figures out that these extra padding
instructions that you put in to make the

the loops of your crypto routines run in
constant time and to scrub the contents of

round keys once you are no longer in use,
are not doing any real work, and it

removes them. And all of a sudden from one
day to the next, you find that your crypto

has sprung a huge big timing leak and then
you have to rush to get somebody out of

bed to fix the tool chain. So one of the
things that we thought was that better

ways for programmers to communicate intent
might help. And so there's a paper by

Laurent Simon and David Chisnall and I
where we looked about zeroising sensitive

variables and doing constant time loops
with a plug in and VM. And that led to a

EuroS&P paper a year and a half ago: "What
you get is what you C", and there's a plug

in that you can download them and play
with. Macro scale sustainable security is

going to require a lot more. Despite the
problems in the area industry with the

737Max, the aerospace industry still has
got a better feedback loop of learning

from incidents and accidents. And we don't
have that yet in any of the fields like

cars and so on. It's going to be needed.
What can we use as a guide? Security

economics is one set of intellectual tools
that can be applied. We've known for

almost 20 years now that complex socio-
technical systems often fail because of

poor incentives. If Alice guards a system
and Bob pays the cost of failure, you can

expect trouble. And so security economics
researchers can explain platform security

problems, patching cycle liability games
and so on. And the same principles apply

to safety and will become even more
important as safety and security become

entangled. Also, we'll get even more data
and we'll be able to do more research and

get more insights from the data. So where
does this lead? Well, our papers Making

security sustainable, and the thing that
we did for the EU standardization and

certification of the Internet of Things
are on my web page together with other

relevant papers on topics around
sustainability from, you know, smart

metering to pushing back on wildlife
crime. And that's the first place to go if

you're interested in this stuff. And
there's also our blog. And if you're

interested in these kinds of issues at the
interface between technology and policy of

how incentives work and how they very
often fail when it comes to complex socio-

technical systems, then does the workshop
on the Economics of Information Security

in Brussels next June is the place where
academics interested in these topics tend

to meet up. So perhaps we'll see a few of
you there in June. And with that, there's

a book on security engineering which goes
over some of these things and there's a

third edition in the pipeline.

H: Thank you very much,
Ross Anderson, for the talk.

applause

We will start the Q&A session a little bit
differently than you used to, Ross has a

question to you. So he told me there will
be a third edition of his book and he is

not yet sure about the cover he wants to
have. So you are going to choose. And so

that the people on the stream also can
hear your choice, I would like you to make

a humming noise for the cover which you
like more. You will first see Bill's covers.

R: Cover 1, and cover 2.
H: So, who of you would like to prefer the

first cover?
applause Come on.

And the second choice. louder applause
OK. I think we have a clear favorite here

from the audience, so it would
be the second cover.

R: Thanks.
H: And we will look forward to see this

cover next year then. So if you now have
questions yourself, you can line up in

front of the microphones. You will find
eight distributed in the hall, three in

the middle, two on the sides. Signal Angel
has the first question from the Internet.

Person1: The first question is, is there a
reason why you didn't include aviation

into your research?
R: We were asked to choose three fields,

and the three fields I chose were the ones
in which we's worked more, most recently.

I did some work in avionics for that was
40 years ago, so I'm no longer current.

H: Alright, a question from microphone
number two, please.

Person2: Hi. Thanks for your talk. What
I'm wondering most about is where do you

believe the balance will fall in the fight
between privacy, the want of the

manufacturer to prove that it wasn't their
fault and the right to repair?

R: Well, this is an immensely complex
question and it's one that we'll be

fighting about for the next 20 years. But
all I can suggest is that we study the

problems in detail, that we collect the
data that we need to say coherent things

to policymakers and that we use the
intellectual tools that we have, such as

the economics of security in order to
inform these arguments. That's the best

way that we can fight these fights, you
know, by being clearheaded and by being

informed.
H: Thank you. A question from microphone

number four, please. Can you switch on the
microphone number four.

Person3: Oh, sorry. Hello. Thank you for
the talk. As a software engineer, arguably

I can cause much more damage than a single
medical professional simply because of the

multiplication of my work. Why is it that
there is still no conversation about

software engineers caring liability
insurance and being collaborative for the

work they do?
R: Well, that again is a complex question.

And there are some countries like Canada
where being a professional engineer gives

you a particular status. I think it's
cultural as much as anything else, because

our trade has always been freewheeling,
it's always been growing very quickly. And

throughout my lifetime it's been sucking
up a fair proportion of science graduates.

If you were to restrict software
engineering to people with degrees in

computer science, then we would have an
awful lot fewer people. I wouldn't be

here, for example, because my first
degree was in pure math.

H: All right, the question from microphone
number one, please.

Person4: Hi. Thank you for the talk. My
question is also about aviation, because

as I understand that a lot of the, all
retired aircraft and other equipment is

dumped into the so-called developing
countries. And with the modern technology

and the modern aircraft where the issue of
maintain or software or betting would

still be in question. But how do we see
that rolling out also for the so-called

third world countries? Because I am a
Pakistani journalist, but this worries me

a lot because we get so many devices
dumped into Pakistan after they're retired

and people just use them. I mean, it's a
country that can not even afford a license,

to operating system. So maybe you could
shed a light on that. Thank you.

R: Well, there are some positive things
that can be done. Development IT is

something in which we are engaged. You can
find the details of my Web site, but good

things don't necessarily have to involve
IT. One of my school friends became an

anesthetist and after he retired, he
devoted his energies to developing an

infusion pump for use in less developed
countries, which was very much cheaper

than the ones that we saw on the screen
there. And it's also safe, rugged,

reliable and designed for for use in
places like Pakistan and Africa and South

America. So the appropriate technology
doesn't always have to be the wiziest?,

right. And if you've got very bad roads,
as in India, in Africa, and relatively

cheap labor, then perhaps autonomous
cars should not be a priority.

Person4: Thank you.
H: All right. We have another question

from the Internet, the Signal Angel, please?
Person5: Why force updates by law?

Wouldn't it be better to prohibit the
important things from accessing the

Internet by law?
R: Well, politics is the art of the

possible. And you can only realistically
talk about a certain number of things at

any one time in any political culture or
the so-called Overton Window. Now, if

you talked about banning technology,
banning cars that are connected to the

Internet as a minister, you will be
immediately shouted out of office as being

a Luddite, right. So it's just not
possible to go down that path. What is

possible is to go down the path of saying,
look, if you've got a company that imports

lots of dangerous toys that harm kids or
dangerous CCTV cameras are recruited into

a botnet, and if you don't meet European
regulations, we'll put the containers on

the boat back to China. That's just
something that can be solved politically.

And given the weakness of the car industry
after the emission standard scandal, it

was possible for Brussels to push through
something that the car industry really

didn't like. So, again, and even then that
was the third attempt to do something

about it. So, again, it's what you can
practically achieve in real world politics

H: All right. We have more questions.
Microphone number four, please.

Person6: Hi, I'm automotive cyber security
analyst and embedded software engineer.

Most the part of the ISO 21434 Automotive
Cyber Security Standard, are you aware of

the standard that's coming
out next year? Hopefully.

R: I've not done any significant work with
it. Friends in the motor industry have

talked about it, but it's not something
we've engaged with in a detail.

Person6: So I guess my point is not so
much a question, but a little bit of a

pushback but a lot of the things you
talked about are being worked on and are

being considered over the years updating
is going to be mandated. Just 30, a 30, 40

year lifecycle of the vehicle is being
considered by engineers. Why not? Nobody I

know talks about a six year lifecycle that
you know, that that's back in the 80s,

maybe when we talked about planned
obsolescence. But that's just not a thing.

So I'm not really sure where that language
is coming from, to be honest with you.

R: Well, I've been to close motor industry
conferences where senior executives have

been talking about just that in terms of
autonomous vehicles. So, yeah, it's

something that we've disabused them of.
H: All right. So time is unfortunately up,

but I think Ross will be available after
to talk as well for questions so you can

meet him here on the side. Please give a
huge round of applause for Ross Anderson.

applause

R: Thanks. And thank you
for choosing the cover.

36c3 postrol music

Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!