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!