Secure by Default with Microsoft: “Without IoT security people will be reluctant to innovate.”

Listen on Your Platform of Choice

image
image
image

#beyondthenow IoT Security Podcast

SERIES 2

EPISODE 3

In our second #beyondthenow podcast episode with Microsoft, we take a deep dive into IoT security with Eustace Asanghanwa (Principal Program Manager for Security, Azure IoT, Microsoft). Eustace and David explore IoT security challenges, what we mean by a secure by default approach, and the benefits of protection profiles. They also discuss Microsoft Azure's PSA Certified Level 1 certification, how it is helping to facilitate better collaboration with the ecosystem, and why we need to see more cohesion between different security certification schemes.

Listen to a Sneak Peek

“When we have a world that is built to be secure by default, we are not only trying to prevent malicious activity in that world, we are really trying to provide an environment that empowers innovators to be able to innovate without fear of their efforts being undercut.”
Eustace Asanghanwa
Principal Program Manager for Security, Azure IoT, Microsoft

HIGHLIGHTS

Key talking points in this episode:

  • Introductions to Eustace and Microsoft. [01:24]: “I'm the principal program manager for security on the Microsoft Azure IoT engineering team. And there my role is really focused on security, especially on the client-side, making sure that security is designed in from the get-go, building systems that are secured by design. I know these are buzz words, but when you really put it into practice, it means a lot. It means working on the platform itself, but working in collaboration with the rest of the ecosystem. I've been with Microsoft for about five years now and before joining Microsoft, I spent 20 years in the semiconductor industry in different roles, but all of it around security. From design applications to business development, and that exposure gave me an opening to see what security really means in the industry. From a technology point of view, from a commercial point of view. For example, how do people make decisions about building insecurity in their systems? Working at Microsoft and still keeping that connection with the industry that is where we can work together in order to make sure that systems are designed to be secured from the get-go.”
  • The Azure RTOS is PSA Certified Level 1 and how this addresses the ‘trilemma’ of IoT security. [03:56]: “We are very excited that the AzureRTOS is PSA certified. It's a very big deal. I guess one way to really share what that means is to see what problem that is solving. So when I think of IoT in my mind, I think of this trilemma of things that you have to balance. So one is being able to scale the platform across different hardware. The other one is being able to address hardware with different compute resources. For example, when we talk about compute resources, I'm thinking rich hardware, in terms of processing power and memory and all the components that go into that compute, as opposed to constraint hardware. The other pillar is the availability of resources. When it comes to the problem of scale, for example, it is easy to build a software development kit (SDK) that would work with just any hardware or any compute resource out there. By the time you end up achieving an SDK that does just that, the SDK ends up being very big and it may not fit hardware that is constrained in resources. And that gives the first challenge. Then you have other platforms like the AzureRTOS that target hardware that cannot run this rich operating system or are constraints in resources. So, when you use a platform like an RTOS platform, what that means is that the SDK that has been built to scale across hardware is no longer a viable solution. What that leaves people building on RTOS with is, either go in and scale down the SDK, or go in and try to build their own systems from scratch. And when they do that they end up with their own implementation. What they lose from that is security because, at the end of the day, when they do it by themselves, the resources that goes into building a secured system only comes from one source and they don't benefit from having an ecosystem collaborate on a platform or on a set of resources. So PSA certified to us, it really means recognizing the platforms that focus on constraint systems and building on it, rather than trying to build your own system by yourself or trying to scale down an already bloated SDK in order to fit constraint systems. So working with PSA certified really helped us to work with the larger community on constraint systems.”
  • PSA Certified is also helping to facilitate collaboration between the AzureRTOS and the ecosystem. [06:56]: “A big benefit of working with the larger community is security because it allows us an ability to then collaborate on security and make sure that systems are secured from the get-go. So on a platform like AzureRTOS, the team has done an incredible job in integrating with individual hybrid components. They know what it takes to do that and also do it securely in such a way that they take advantage of all this hardware security as offered by the hardware platforms- the MCUs and all the processors- they know how to do that. They have done a good job in that, but at the same time, they recognize the fact that if you work collaboratively on a joint project, in an open ecosystem, you heightened the value of security because you get to benefit from the oversights of everybody collaborating on that platform. So PSA Certified is important to us because of that and is a nod that we are moving in the right direction and being recognized for that."
  • People value IoT security but they don’t always know what it means. [09:41]: “I think it's clear that many people, they know the word security and they know that they value it, but when you go deeper into it, it means a lot of different things. But we are all going into a connected world where our fates are joined together, whether we like it or not. And security is one of those things that is end to end, and it's as strong as the weakest link. People have heard this. But the truth of it is that in IoT, we are all one ecosystem because the world is connected and we have to be secured from every angle and any vulnerability at any point, whether it is the devices themselves but also related to devices is the processes that the devices go through.”
  • Securing the IoT will encourage new innovations [10:44]: "The supply chain or the operation of the devices, or the retirement of devices, many aspects go into security. And each of those has a lot of importance to make sure that we have a secured ecosystem or a secured IoT. I believe everybody and every organization doesn’t understand what can go bad if there is a security incident or a security event. The piece that I think is also important, that may not come to the forefront, is the fact that without security people will be reluctant to innovate. You want to innovate when you know that your innovations are going to pay off and they are not going to be subverted. By securing IoT, you are actually helping people to innovate, which is the essence of IoT: bringing innovations in technology to build a better world. "
  • The autonomy of IoT devices is removing the ‘human companion’ and the IoT security protection that provides. [12:01]: "Now, when it comes down to devices themselves, like a specific device, we always think of devices as talking to a network or some endpoint, like a cloud. Devices used to exist in companion with humans. So, you have like your laptop, you have a cell phone or a printer. There was always a human companion to a device and that human companion provided some level of security to that device. So a laptop, for example, the way you secure it, you consider that laptop being in possession of somebody who also adds to the security profile of the laptop, by making sure that that laptop is only in their possession and not in the possession of some malicious person. So that profile has always been there in our history of computing. Now moving into IoT, we have a lot more devices being autonomous, making intelligent decisions, being on their own. They don't have any human companions anymore. And what that means is if a malicious actor comes across that device, they may be able to do something bad. They may be able to attack the device and escalate the attack to get into a network, for example. What that means is that the security profile of the device needs to be raised in such a way that the device is not only a companion to a human but the endpoint in itself. So, we use words like trust anchor inside of the device, meaning that you can verify every transaction coming from the device. If you have the notion of having some kind of a trust anchor inside of the device that brings in the concepts of having a root of trust (RoT) inside the device being able to establish a trusted connection in the device. Having the root of trust allows a device to be tamper-resistant, to resist, not just a network's ability to subvert the device, but also a physical ability to subvert the device. So when it comes down to device security, there are many layers at which you can look at it: from the device itself to the root of trust, all the way out to what security at the device level means for the whole IoT to foster innovation."
  • What is a ‘secure by default’ approach to security? [16:11]: "Secure by default is recognizing the fact that it is important to think of security upfront rather than try to add security at the end. The general notion is this, if somebody or an organization wants to build a product, I’ll use the connected mousetrap here, they focus on the functionality of the mousetrap, knowing that security is something that they're going to deal with and usually defer it to the end. They want to get a functional product first before they add security to it. And when they do it like that, they miss many opportunities where they could've incorporated the security into the product. Security ends up being disjointed additions into the product and exploiters are very savvy at exploiting those dis-joints. So it is important that when building security, you have to build the solution to be secured from the get-go."
  • A Secure by default approach enables a threat modeling mindset. [17:08]: "When we are thinking of it this way it allows you to open your mind to ‘what are the possible areas where security can be exploited in this product?’ When you start thinking of what could go wrong, you have a threat modeling mindset, what you realize is that even if you do everything the right way, in terms of software engineering and hardware engineering, maybe by the time the hardware gets to you there have been some opportunities to exploit security. So to be secure by default, you have to think of the entire life cycle of every component that goes into that solution. So that means the supply chain, all the contributions that you're building into the product, how you operate the product, and also how you retire it- you have to think of it end to end. So retirement is a big deal."
  • When you design-in security you need to consider the product’s entire lifecycle. [18:52]: "Thinking of it end to end means building countermeasures in order to make sure that every aspect of security is addressed, from the supply and manufacturing chain to onboarding, to operation, to transfer of ownership to retirement. When you think of it this way, it influences how you actually build a product itself, the kinds of software platforms or the kinds of hardware platforms that you choose, and the way you collaborate with the rest of the ecosystem. Because what you realize is that in the ecosystem, there are many contributors of value to this. It is not just the chip makers, the hardware security module (HSM) makers, or the device manufacturers (OEMs). You have public key infrastructure (PKI) providers, you have other value providers like update services, all of those have to be thought through and make sure that the entire solution is working cohesively. So secure by default is this level of thinking beyond the immediate product that you as an engineer have in front of you, but thinking how that product exists in the larger ecosystem of the IoT and securing that."
  • People are willing to invest in IoT security because they understand the value of the IoT and digital transformation. [22:10]: "The good news is that IoT is a new area that many people are seeing the value of. There are some new technologies or new paradigms where people scratch their heads to see, where is this going? What is the value of this? Fortunately, IoT is one of those where companies directly see the value in it. They see how it adds value to their systems, to their operations, or their organizations. And they see the value of security and they're willing to work towards enhancing the security of IoT. And in this sense, like any other technology or any other up-and-coming new area, we learn as we go."
  • Securely deploying the IoT requires an ecosystem approach. [23:00]: " With security a lot of times people focus on their unique areas, their specific pillars. For the IoT device, for example, you have companies that focus on the root of trust and the root of trust is absolutely important to build either a standardized or proprietary interface. But they deliver the root of trust and they focus just on the root of trust for the device and they traditionally don't think beyond that. Again, another value is how do you distribute trust in the ecosystem? Thinking in terms of identity and identity device and identity management, one of the big technologies in this area is the public key infrastructure (PKI), and the certificates that go with it. For the providers of those services, they tend to think only of that specific value. I am in the business of operating a PKI or delivering certificates. With OEM it’s the same thing. An OEM is like ‘I have a device that has a software platform installed in it. The software is running. It is up to a system integrator to then configure the software to work how they need it, configure it and put whatever password they want’. So the system integrator has to customize it in the way that they want it to connect. Somebody has to put all of that together."
  • It's unrealistic to expect system integrators to become experts in all areas of IoT development and deployment. [24:53]: "And that has been and continues to be the role of system integrators. And it becomes a challenge for them because to actually put all of these technologies together and also ensure that these technologies are working together seamlessly and in a way that it is secured, it demands that they become experts in each of these pillars. They have to be experts on how a HSM works. They have to be experts on how PKIs work, they have to be experts in device engineering- device engineering is not a simple thing. It's one thing to take a product and connect it to a cloud. But when it comes to scaling that out and also building in the reliability that is required for whatever industry that you work in, you find out that device engineering becomes complex very easily. And that is an area of expertise for OEMs. So we expect the system integrators to deal with all of this, which means they have to become experts in all of this. When they're already dealing with the complexity of bringing billions of devices with cloud solutions to work together. If they have their way all they want to think of is that I want to connect to a device. It is secured and they don't have to worry about all the other things that has to happen in order to bring that together."
  • As an ecosystem, we need to work together on the solutions to reduce the burden on system integrators. [26:29]: "One of the areas that we are learning and we are going into is recognizing the value of the ecosystem of providers (technology providers, services providers) working together to make sure that the system integrator is getting devices that already have pre integrations. It is not enough to say that ‘hey I have a HSM, which if you just use this SDK will work on any cloud that you want’. That is not enough, how can you work together with the PKI providers and OEMs and the services providers to make sure that all of this is working together- because these are the domain experts that have the knowledge in those areas? How can they get the device to work together and then present the final solution to a system integrator? System integrators are willing to pay for customized devices that they just receive, and it works. And they know that it has been built with the highest thought towards security inside of them."
  • Microsoft Azure’s Blueprint approach to IoT security. [27:39]: "The efforts that we've been working on with ecosystem partners is this blueprint approach to IoT security. One of them is the zero-touch provisioning blueprint approach, working with the domain experts like the OEMs, the HSM providers, and the PKI providers for certificates. Which involves all the services that are required to make sure that the devices that are built are customized. So that when the system integrator receives the device, you have high confidence that all the technologies going into it, have been properly composed, securely composed, and the device is ready to connect. All they have to do is power the device, turn it on, and a device autonomously knows how to onboard and then get into their systems. Recently we also announced a blueprint for enclave devices and enclave has to do with confidential computing, which is solving another area of security that has to do with protecting privacy and also protecting safety, especially in terms of safe remote operation. What we see now is that these intelligent devices are making more and more decisions and making common and control decisions at the edge and we want to make sure that the environment where the compute is happening is protected confidentially. One of the big and upcoming areas is autonomous control of systems and subsystems in vehicles, like driverless vehicles. So you wouldn't want any of those environments to be tampered with when a vehicle is moving. That is an example just to bring out the kind of safety we're talking about here and absolutely the importance of it."
  • Confidential Compute and the edge. [31:47]: "The confidential computing part of it is making sure that for companies that have sensitive intellectual property, they are reluctant to move to the edge, but this is where the technology itself is of its highest value. If it's being operated at the edge, that is where the first and foremost proposition of confidential computing brings value, to protect that IP. But the way we approach confidential computing means that you give safe isolations to perform executions. And these isolations are isolations from even the operating system itself. There are hardware isolations that are isolated from everything else inside of the device. It gives the highest assurance that there is no visibility into that environment, giving a guarantee that there is nothing that is going to go in and tamper with the activities of that environment. So that brings in the safety aspect of it."
  • Protection profiles help us to answer the question ‘Is this device secured?’ [33:21]: "Protection profiles bring a lot of value. And we learned this again through experience. So if you think of the very early days of IoT, we're talking maybe six, seven, eight years ago, it was more machine to machine and things like that. But if you think of it six years ago, it was cloud service providers, solution builders would bring their devices, they do a connection and everything connects. The solution builders get their devices from OEMs to build the devices and say “my device can connect, you know, to this endpoint or this cloud”. And sometimes they even take the step to put in the requirements of connecting to specific clouds, like an SDK, for example. So by the time the solution builder is buying the device, it is already capable of connecting and talking to specific clouds, depending on how they put together the devices. Now over and over, one question keeps coming up from the solution builders. And the question is, ‘is the device secured?’ And that is a question they're asking to the device providers, which are largely OEMs and ODMs. Typically the answer would be yes, of course it is secured. But then when you dig deeper into it, what does that mean? What is secure? And the justification usually comes in saying, ‘yeah, I implemented TLS, which is transport layered security, meaning that the communication is secured from end to end, or it has a TPM, which is a kind of trusted platform module secured chip to provide a trust anchor’. But at the same time, it says nothing about whether the TLS is implemented in such a way that it cannot be subverted or whether the root of trust is actually present inside of the device. You realize that to claim that a device is secured, some foundational things must be in place. I just mentioned secured communication. I mentioned having a root of trust. In order to answer, ‘is this device secured?’ it takes a long checklist of things that must be in place foundationally, like a baseline, in order to even make that claim."
  • Protection profiles create a baseline of requirements for specific devices to be secured. [36:20]: "When the system integrators ask whether the device is secured, they haven't really spent time understanding what this long list is. Part of it is probably because they just want to focus on building the application that they want to build, or they may not have the knowledge to do that. OEMs on the other side, they do understand what this list is, but unfortunately, to have all the checkmarks it means putting a lot of resources in. The OEMs together with the HSMs (hardware security modules), the root of trust providers, have the deepest knowledge in these areas, but they are not going through that because there is no way for them to monetize all this effort. Devices traditionally have been valued by the CPU speed or how much RAM, or how much hard drive, but nothing about security. There is no way to measure this, to show the added value of the engineering that goes into security. So there hasn't been a way to communicate device security. So we actually worked with members of industry, big names, to create a protection profile for IoT devices, for intelligent edge devices. We call this the edge compute node protection profile using the common criteria framework. A protection profile is a way of defining a list, a baseline for what it means for a device to be secured. It gives a standard that if an OEM says that this device is secured and is secured according to this protection profile, which is backed by measurements from this lab, and also operating under the auspices of this certification body, it gives confidence to this system integrator that this means something. So protection profiles are that means of communicating. And also for the OEMs to be able to say that we did invest engineering into the security of this device so we can command some margins to compensate us for that engineering."
  • Multiple certifications help us target security at different levels of granularity. [39:36]: "Multiple certifications are really important because they target security at different levels of granularity. Security has to compose from the smallest granularity all the way up to the biggest levels. And I'll give some examples here. There are many proprietary root of trust devices from the semiconductor providers that can go through a certification. And one of the well-known certifications in the industry is the FIPs Certification. I believe it’s recognized by many countries, but it originated, and I believe is still being driven, from the US. And people may not know the technical details behind FIPs, but they have a sense of what it means to say that a device is FIPs certified at this level. People have grown to understand what that means, even without understanding the technical details that goes behind it. At FIPs they have this concept of a cryptographic module- it is limited within a certain bound of a compute device. Now, when you're thinking of IoT, you're thinking of what those bounds of compute might be: a root of trust or a processor, but an IoT device is a composition of that root of trust, the processor, the operating system running in that device. And that is just the baseline. In addition to that, being able to defend the services that the device is working with, and also the verticals that a device works in."
  • We expect to see a more cohesive composition between IoT security certification schemes that target different functionalities and markets. [41:27]: "Take something like updates, to do a secure update in a device, there is an aspect of being able to make sure that the device receives the update, verifies the content that is going to be updated inside of the device and verifies it before it applies it, which takes cryptographic measurements to do. But updates do not exist on an island. When you think of it from an application point of view, it exists in conjunction with an update service, which does not exist in a device- that exists in a cloud somewhere. When you want to apply an update it is a service at the other end that orchestrates all of that. And being able to attest the device, and then also provide a trust framework that says that the device that has gone through this secured update is also working together with the cloud in such way you can have an overall trust in the entire update service- that is a very important portion of that. Again, talking about certifications, you may have a certification that deals with the root of trust, FIPs, for example, you may have a certification that deal with the different services: attestation, updates, and many things like that. Or certifications that deal with the composition of the components inside of the device itself. So, when have like an industrial PC (IPC), to say a device is certified according to this protection profile, it is giving some notion of the device security- but it doesn't end there. If that device is operating in the medical industry in the US, you might want to say that this device is also HIPAA certified- which is one of the regulations regulating patient content in medical devices in the US. Or if you're in the industrial space, which is something that is coming up a lot and many people are asking questions about, they want to know whether the device is IEC62443 certified. It would be good to be able to capture that in a certification scheme that formally captures all of that. Each of these certifications- they work together. In my opinion, they should work together in composition where they are built in such a way that this composition can happen, and this composition continues to mature. There are loose obligation of islands today- but moving forward, maybe two or three years down the line, I think we will be seeing better compositions in these certifications. But it is absolutely important to have each of these journalized certifications to bring in that higher level of resolution in what measurements are you applying and at what level of the device. You need different expertise and you need these different certifications to certify each of those."
  • Eustace’s predictions for the IoT in 5 years’ time. [46:02]: "Right now it seems like many organizations still look at security as a cost line item in the proposition of the product. They have to decide whether to invest in this particular component of security or not. And they're looking at it only from a cost point of view. I'm thinking that in five years, that is going to go away, people will be more willing to invest in the value that the product provides. And that value is not just the application value, but the stability of that application and the security of that application. So what that means is that the solution builders are more willing to invest in services that provide security rather than the components that want to manage the security. And what that means to OEMs for example, instead of trying to see how they can build, sell, and forget, and hope that it doesn't come back for recall or anything like that. They should be thinking of devices as offering a service. So, they build a device, they sell, or they lease a device, and then they provide security because security has to be renewed continually. I'm thinking in five years, the tension of the cost of security, which is tied to the cost on the bill of materials is going to change into more of this service dynamic. Where everybody wins. Right now OEMs feel like they're in a position where they can build secure devices, but they are not rewarded for the engineering and the effort that they put into security. When we have this service industry going, it's more of a sharing model where they are participating in the sharing of the monetization that comes from the services and security is going to be truly uniform. So, it's not a new technology, it's just a maturity of thinking, a maturity of culture and I believe that is going to be ubiquitous in the next five years."
  • Blockchains might lower the cost of security infrastructure. [49:01]: "Now in terms of new areas of security, I think there are things to really watch out for. There's been a lot of buzz around blockchains and the buzz today is saying that, with blockchain, you get security, and you don't have to use a root of trust and things like that. I don't think that is how it's going to fall out. I think blockchains will bring a lot of value in security, but that is also going to work in conjunction with the use of a root of trust. It's just going to bring another way of managing ecosystems. So, some of the challenges that we have to deal with in supply chains today, like putting in building infrastructure in order to build a level of trust, blockchain might facilitate or might lower the cost of those kinds of infrastructure. But again, things like the root of trust, the components that go with building security, we still have to have that in place. So I'm thinking in five years, we're going to see blockchain become more and more part of the story in IoT security and also help in delivering higher needs of security inside of the IoT."
  • Eustace’s top piece of IoT security advice. [50:26]: "For any listener that has been listening up to this point, I really want to thank them so much because security can be a very dry topic to listen to at some point! But I really want to encourage them to recognize that security is a technology, but it is not really about the technology. It's about the value that technology provides. When we have a secured world, a world that is built to be secured by default, we are not only trying to prevent malicious activity in that world, we are really trying to provide the environment to empower innovators, to be able to innovate even more into the future, without fear of their efforts being undercut. If they have the confidence that IoT is secured, they are more encouraged to bring forth even more innovations at a higher rate than what the IoT has been delivering so far. The other thing I'd like to say is that to achieve security that does not mean that you must be an expert in cryptography, or be an expert in different security protocols. There are people who live and breathe that and they like to thrive in that area. Being able to think of this service-driven ecosystem, it really allows for us to share value for the people who can provide security. We share the value in order to sustain them as well, to constantly provide security and everybody can benefit from that entire network. You don't have to be an expert in security in order to benefit from security or encourage a secured world, just participating in the right processes and moving towards a service model will bring us there."

Related Links

Discover more about the IoT security challenges

Find out more about the value of third party certification

Share this page

The PSA Certified name, PSA Certified logos, PSA Functional API Certified logo featured on this website are registered trademarks or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights reserved. Other brands and names mentioned on this website may be the trademarks of their respective owners.

Copyright © 2021 Arm Limited (or its affiliates). All rights reserved.

Sign Up To Stay Up to Date With Our Latest Podcasts Episodes

Loading...