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!