Welcome. My name is Jonathan Williams and I'm in the product manager team within the IoT and wireless business unit at Twilio and I'm here to talk about the challenges around overcoming IoT security threats from the start. Now you may know Twilio for our fantastic communications APIs, bringing easy to use connectivity so SMS, voice, WhatsApp chats, etc. To apps and websites, enabling billions of customer interactions to take place every day. Well, just as we enable simple and easy connectivity for people and applications, what you might not know is that we also power connectivity for millions of devices across the Internet of Things, both with our super sim connectivity solution as well as our microvisor device builder platform. But enough about that. Today I really want to talk about the sobering reality when it comes to IoT devices and security across the Internet of Things, security has been overlooked. An amazing 1.51 billion IoT devices were breached in the first six months of 2021, and this itself was an increase from 639,000,000 breached in the same time period in 2020. So this is a growing problem and with the anticipated number of connected devices worldwide predicted to reach 50 billion by 2030, there is still a lot that needs to be done to ensure that these devices are protected from attacks and things includes ensuring the security of your connected devices and your data lives up to the promise you make to your customers. The impact of your devices being compromised is a big one and can often be ignored until it is too late. So I think we know that both us as device builders and now consumers are increasingly aware of the importance of device security. But it can be challenging to know which devices are secure by design and which just haven't been targeted yet. For many device builders, security can become an afterthought as you prioritize the features of the product or service itself when working towards a minimum viable product. Equally, security can sometimes be considered a necessary but unexciting piece of the product development. These hoops that you unfortunately have to jump through. It can also be hard and therefore expensive to retrofit security into an existing product properly. And maybe these are some of the reasons why we sometimes see insecure products released to market. But it is worth remembering that the risk profile of a security incident is high and the impact can be extremely severe. If the worst was to happen and a breach or hack occurs, you may well end up suffering company damaging impacts. Really because of this high level of risk, these security of your data and of your device must be foundational and must be built in from the start. Security really does need to be considered as a necessary system component within your device or system architecture. Now, I thought it might be interesting to take a look at a few high promise incidents that have happened in the last few years. Now. I think these are interesting to look at as whilst they're not necessarily exactly IoT use cases, I think the lessons learned are directly applicable to what we need to think about when securing our IoT devices. So before Zoom became a household name, there were a series of security loopholes discovered within the Zoom client implementations. So across several platforms, Mac, Windows, et cetera, and within the AV industry, there was a lot of comment, news articles and concerns being raised around the general security of the Zoom implementation. This in turn was arguably starting to cause the reputational damage that can be so, so damaging for a growing company. In many ways, how Zoom responded to the security concerns was pretty damn impressive. By zoom pivoting to take security seriously and addressing the issues raised in a timely fashion, they did manage to turn the problem into an opportunity to excel, which is no mean feat. I can only imagine the stress and sleepless nights that occurred whilst these high profile software fixes were being worked on. And I'm sure many a Zoom executive would much rather have seen security as a core feature of the initial product rather than the afterthought that IoT effectively was. So, taking a look at another one, several years ago, the connected security cameras from Hicvision were compromised through a weak password implementation and a backdoor misuse of a cookie, which resulted in devices being compromised. The Department of Homeland Security characterized the vulnerability as remotely exploitable with a low level of skill to exploit, I. E. Anyone with a computer can reproduce this and remotely access another user's camera footage. Now, rather than this just being a security incident that was raised and publicized and fixed before it became an actual issue, as so many are here, hackers did start accessing camera footage and actual users were targeted after their device security was exploited. So their hypothetical worst case scenario of real users and their data being hacked became reality. And it's not just reputational damage that can happen, there can be a huge financial cost to a security incident as well. Only this year the well documented colonial pipeline cyber attack took place and ransomware impacted computerized equipment managing the Texas based pipeline so kind of a bit like a connected IoT style device if I squint a bit. But here the attackers stole nearly 100gb of data and threatened to release it on the Internet if a ransom was not paid. Having caused the shutdown of the pipeline for six days and compromised these billing system. The only way out of this situation, in the end has to pay that ransom and that cost them 75 bitcoin or at the time, $4.4 million. Now, these are just some of the many, many security incidents or CVE vulnerabilities that are exploited or design mistakes that affect products somewhere in the world every single day. And as someone responsible for a connected device, the risk of a security incident should be enough to keep you awake at night. The important thing here, though, is certainly not to throw stones at others. Those examples I used a moment ago, it really is to learn, appreciate and understand that similar things happen all the time. And to that extent, unless you are really conscious about security as a core Internet of your product development, this too could happen to you. So perhaps as an embedded software engineer or a device developer, a CEO or product manager responsible for a connected device, what must you think about and look for to make sure that your device is one of the secure ones? First, when it comes to security, you really must start by considering the threat model that you're actually connected about, I. E. What are you trying to protect and who are you trying to protect against? And this essentially boils down to, at one end of the scale, protecting against accidental misuse or a sloppy implementation that hick vision default password, for example, through bad actors and rogue employees, untrusted manufacturing partner access, the kind of thing iso 27,001 help protects against all the way through to the hypothetical government sponsored hacking where silicon chips will be decapped and power supply injection used to read flash contents. And obviously, the approach that you would consider necessary to protect against accidental misuse is somewhat different to that required to protect against statesponsored hacking. Now, the basics of IoT device security can consider somewhat covered by legislation or certification in standards. For example, the most obvious weak authentication, which in general means a poor or default password approach and must for obvious reasons be avoided, is increasingly being included in new IoT legislation around the world. So, for example in California or Australia and more recently in the United Kingdom, IoT device legislation is attempting to banish the weak or default password approach. But there are lots of devices out there that are still affected by this, and obviously this will still take time for everyone to adopt it and standards, be them specific security standards, for example ARMPSA or the multitude of others, or be it ISO implementation standards, ISO 27,001 for example. These can also help with some of the specific issues and people based risks putting in processes around which employees have access to which systems and the data within them now, many of these are essentially hoops that you need to jump through, but it could be said that if you can't jump through the hoop, then you probably aren't ready to release your product to market, specifically in terms of the device itself. And as an example of these things that you need to think about, Microsoft laid out one approach in their white paper, the seven properties of highly secure devices. And here Microsoft identifies and discusses seven properties that they think must be shared by all highly secure network connected devices. And these are a hardware based route of trust that you have a small trusted computing base, defense, in depth compartmentalization of code, certificate based authentication, renewable security and built in failure reporting. And this does form a great basis for considering what your device needs to do in order to be secure. It's important to note that Microsoft uses a custom silicon part to support these seven properties, but these can be achieved in a variety of ways, and I think I agree with them that these should all be considered necessary for IoT devices today. But I think there's more to think about as well. So has well as the above seven properties, I think there are some other things that we should consider necessary for a secure device implementation, and this includes things like secure boot and secure factory provisioning. As manufacturing secure products at scale requires a well designed production process that allows secure products to be built in insecure factories. And this protects customer IP and prevents gray market devices from ever existing. So whatever you're thinking your threat model is, whether it's accidental misuse, rogue employees at the factory, or the manufacturing partner, or the government sponsored hacking I things, it's fair to say that it is vital that you control and manage the code that's running on your device. I mean, if you cannot trust that the device is running the code that you think it is, I. E. Your code, then pretty much you cannot trust anything about that device. So to this end, I think you must have a method of secure boot and secure factory provisioning. And this is a must have for you to be able to trust the device and the device code itself. As it's the combination of these features that ensure that you can guarantee that your device is running your code. I like to think if you can't manufacture it securely then it certainly isn't secure. A good example of this, or can be, is where the need to get something up and running quickly does not lead to a secure implementation. And an example of this is the many industrial use cases built on top of the Raspberry PI. And this does not support either secure, brute or a secure factory provisioning step. So it's absolutely great at what it does do in getting a use case up and running quickly, but kind of secure by design? Not really. What can we do about it? So the challenge can be that once you have committed to an approach, be it a hardware or software approach, then switching or changing your development can be seen as both a hard and b costly. The inertia and the sunk cost of development so far, combined with that pressure to get a product out of the door, often means that companies, engineering teams and devices tend to stick with a relatively insecure approach as they look to move to production. Maybe that's something we saw in some of those examples earlier. So I think it's important, or perhaps crucial to ask yourself, how important is it that we have a secured device implementation? Is the approach that we're taking properly secure, and are we happy with that level of risk that were taking security rise? What would the outcome be? What would happen if our devices were hacked or compromised? And probably crucially or most importantly, is the cost and risk of not having a secure approach and potentially having one of those security incidents really worth it? I would say don't be afraid to ask these questions, whatever stage of the development process you're at, and don't be afraid to come to the conclusion that security must matter. And these earlier you do this, ideally right at the start, the better it will be for you, your devices and your customers, and ultimately your overall business. And if it seems too hard, don't worry, switching to a secure architecture doesn't need to be as hard as it seems. And if you do want to take a look at our approach to a true end to end embedded security based on our Twilio microvisor, which is essentially a hypervisor for microcontrollers, providing a secure implementation at the edge all the way through to the cloud, or our supersim connectivity for enabling global cellular connectivity for IoT devices, then please do check us out@Twilio.com. Slash IoT so thank you very much for your time and I hope you enjoy, enjoyed that quick look at what it takes to consider IoT security from the start. Thank you very much.