WEBVTT 00:00.000 --> 00:01.560 Thank you so much. 00:01.560 --> 00:03.300 And I just love this village. 00:03.300 --> 00:08.040 You know, I have been coming to this village, I think it is three years in a row. 00:08.040 --> 00:09.860 And I do miss DEF CON a lot. 00:09.860 --> 00:17.500 And some of you know my sister, Karen Elazari, I often go to DEF CON with her and we definitely miss that experience. 00:17.500 --> 00:21.100 But I am very excited to be here with you today. 00:21.240 --> 00:32.460 And today I'm also joined with a really good colleague of mine, Anait, she is a spectacular engineer from the IoTG business unit with us. 00:32.460 --> 00:38.560 And we're going to be talking with you today on this evolving landscape of baseline standards and regulation. 00:38.560 --> 00:40.080 So first of all, let me check again. 00:40.080 --> 00:42.760 Can you all hear us great, Sam, Tim? 00:43.460 --> 00:44.800 Yep, we can. 00:44.900 --> 00:45.900 Wonderful. 00:46.440 --> 00:49.980 Well, as Sam shared, we are both from Intel. 00:50.000 --> 00:55.580 I work in the government's relation team at Intel within the legal department. 00:55.580 --> 01:00.300 I work with governments around the world and policymakers on issues of security policy. 01:00.300 --> 01:05.820 And I also lecture at the UC Berkeley School of Information, where I teach in the Master in Cybersecurity program. 01:06.440 --> 01:10.200 And as many of you know, I'm also Israeli. 01:10.320 --> 01:14.100 And usually when I come to this village, I start with a direct question. 01:14.320 --> 01:15.960 So let me do it again. 01:16.140 --> 01:19.720 By now, most of you should be familiar with this face. 01:19.760 --> 01:21.000 And I hope you know him. 01:21.000 --> 01:22.740 This is Kevin Finster. 01:22.740 --> 01:23.980 He's a researcher. 01:23.980 --> 01:29.260 And like many of you in the audience, he is also focused on embedded systems. 01:29.260 --> 01:34.640 And specifically, he has a love and passion towards drones. 01:34.640 --> 01:44.820 And he has conducted research on DJI, one of their drone systems, and he found the vulnerability that, according to him, leaked personal information. 01:44.820 --> 01:53.220 And he wanted to report that vulnerability to DJI and, you know, do the right thing and engage in disclosure. 01:53.220 --> 02:04.920 And at the time, DJI just launched their bug bounty program with this media announcement, inviting the community, inviting the ecosystem to report vulnerabilities to them. 02:05.740 --> 02:12.380 And, you know, it was not really clear what was the scope, according to the reports. 02:12.380 --> 02:16.040 There wasn't really a bug bounty policy or contract. 02:16.040 --> 02:21.280 And there was some confusion between the parties on this issue of the scope, according to the reports. 02:21.280 --> 02:28.100 So Kevin contacted DJI and asked them, is this vulnerability that I found is in scope? 02:28.100 --> 02:32.980 And they, in fact, according to the reports, suggested it is in scope. 02:32.980 --> 02:39.500 Not only that, they said that they would like to pay him $30,000 for that vulnerability. 02:39.500 --> 02:47.380 So for those of you engaged in bug hunting, just empirically speaking, that's a pretty high bounty. 02:47.520 --> 02:49.860 And then the plot thickened. 02:49.880 --> 02:55.140 So there are two sides to this story, and I encourage you to check out the links in the bottom. 02:55.460 --> 03:07.200 But Kevin felt that during the negotiation on issues of disclosure, there were some issues that were unclear, again, because we didn't have that scope and website. 03:07.220 --> 03:08.780 And then the plot thickened. 03:08.780 --> 03:20.860 And then in the draft letter mentioning the Computer Fraud and Abuse Act, which is the main anti-hacking law here in the United States, together with the DMCA, was mentioned, according to the reports in that letter. 03:20.920 --> 03:30.640 And Kevin ended up walking away from this approved bug bounty of $30,000 and sharing on Twitter his version of the story. 03:30.980 --> 03:34.320 And, you know, he did order a Tesla. 03:34.340 --> 03:37.980 He ended up canceling that order of a Tesla. 03:37.980 --> 03:49.520 And it's just a story highlighting some of the nuance between laws and bug bounties and vulnerability disclosure programs in this evolving landscape of anti-hacking laws. 03:49.520 --> 03:53.260 And it's a story that I shared a lot during the last few years. 03:53.260 --> 04:02.300 And I'm actually happy to report that we have seen, maybe also because Kevin went and shared this story, a lot of progress in this area. 04:02.300 --> 04:08.880 We have seen a lot of safe harbor adoptions and a lot of collaborations between companies and researchers. 04:08.880 --> 04:24.100 And even recently, it was announced this week, and maybe you have seen the draft CISA binding operative directive from CISA, which is the main federal cybersecurity authority that actually has also safe harbor language in it as well. 04:24.100 --> 04:25.720 So all of this is very exciting. 04:25.720 --> 04:44.660 And for me personally, because I did spend a lot of time on these issues between law and technology, and specifically this landscape for the last years in my prior work at Berkeley, before I joined Intel, promoting this framework for collaboration, it really is nice to see the growing adoption of safe harbor. 04:45.440 --> 04:58.680 One of my key takeaways from this kind of evolving interaction between law and technology is that laws are often basically evolving slower than technology. 04:58.680 --> 05:02.160 So we know that laws are slowly being amended. 05:02.160 --> 05:05.440 It's not like innovation that is rapidly being developed. 05:05.440 --> 05:14.320 And laws often have concepts like authorization or reasonable security or principles that are adapted with time. 05:14.320 --> 05:32.080 The reason I bring this example is that if you even consider the CFAA, again, this main anti-hacking law that I mentioned, and I'm sure many speakers are speaking about this law throughout DEF CON, it is a law from 1986, before the internet as we know it today. 05:32.140 --> 05:36.180 And much has changed, including hacking and security testing. 05:36.180 --> 05:43.520 And this year, the Supreme Court is going to actually take one of the first court cases on this issue of authorization. 05:43.860 --> 05:46.340 And we will see how that will evolve. 05:46.340 --> 05:51.940 But it just shows kind of how the laws are adapting to technology but are often behind. 05:51.940 --> 06:05.440 And I think this is one of the main takeaways that for you in the audience today from our talk is we're going to look at this landscape from both a policy and both from a technical perspective, and we're going to see how things are fitting together. 06:05.640 --> 06:08.480 So I shared a little bit about my background. 06:09.040 --> 06:15.300 Towards this week at DEF CON, a lot has been talked about in terms of disclosed I.O. 06:15.300 --> 06:16.320 and bug bounty. 06:16.320 --> 06:18.680 You can check out my prior work in this area. 06:18.680 --> 06:25.420 But I'm very passionate about this issue of collaboration between researchers and hackers and companies. 06:26.000 --> 06:30.700 And while I am a lawyer and my background is legal, I'm not your lawyer. 06:30.700 --> 06:36.320 And today I'm going to be talking about my own personal opinion and I'm not going to be providing any legal advice. 06:36.340 --> 06:38.700 So I know this is a little bit of fine print. 06:38.800 --> 06:41.700 You would probably expect that from me, right? 06:41.900 --> 06:43.680 But it is exciting. 06:43.680 --> 06:58.780 And, you know, if I need to complement kind of the prior discussion, I am also very excited to share that we at Intel, which I've recently joined, we do have a safe harbor in a bug bounty program, and we encourage you to not just engage with us, and we're going to talk a little bit about that, 06:58.780 --> 07:01.780 but also know that we have that language in our bug bounty. 07:01.980 --> 07:04.480 And with that, I spoke a lot about collaboration. 07:04.480 --> 07:10.840 I spoke about why this is important as we think about technology and laws and how they go together. 07:10.840 --> 07:28.360 So I want to invite my fearless collaborator, Anait, to tell us a little bit what it is in the evolving attack landscape and particularly the IoT ecosystem that is sparking all this conversation around IoT proposed regulations and policies. 07:28.360 --> 07:30.420 Anait, please take it away. 07:31.540 --> 07:32.720 Thanks, Amit. 07:32.720 --> 07:34.540 Indeed, it's a great collaboration. 07:34.540 --> 07:35.660 So hi, folks. 07:35.660 --> 07:37.440 Very glad to be here. 07:37.440 --> 07:42.560 And as Amit said, I work directly on product definition side. 07:42.560 --> 07:47.180 So today we are talking about security and regulation policies, right? 07:47.180 --> 07:57.240 And being on the receiving side of the regulatory guidelines inside Intel, I spent time understanding and assessing the technical implication. 07:57.240 --> 08:03.760 So first, I would like to start looking at the concern that triggers this rising regulatory effort. 08:03.800 --> 08:11.060 And one of the key IoT security issue is the expanded attack surface. 08:11.240 --> 08:15.620 And that's due to the increased number of the endpoint devices. 08:15.620 --> 08:22.380 So we all see this futurescape that predict billions of devices with trillions of sensors. 08:22.380 --> 08:30.020 This large number of IoT devices that being brought into the business triggers the growth of attack. 08:30.160 --> 08:36.020 Another issue is the sophistication and evolving of the intent. 08:36.020 --> 08:42.420 It is clear that the attack target is not limited to the assets of IoT device only. 08:42.420 --> 08:51.780 IoT device exposure opens a plethora of opportunity across the edge to cloud and exposes a lot of valuable assets. 08:51.780 --> 08:56.720 So let's analyze the genealogy of the IoT attacks. 09:00.020 --> 09:06.940 So what you see here is typical IoT solution that spans edge to cloud. 09:06.940 --> 09:16.400 So IoT device control other devices in the system and itself, they being controlled by others in the edge to cloud solution. 09:16.400 --> 09:25.060 This duality exposes enormous challenges for the security community and adds new dimension to the system cybersecurity controls. 09:25.600 --> 09:37.980 Attacks that originate on the very left side at the edge easily can propagate throughout the entire pipeline and single device can jeopardize the entire solution. 09:38.100 --> 09:45.420 One notorious example of this type of scenario is a casino fish tank attack. 09:46.190 --> 09:50.060 I don't know how many of you are aware of that story. 09:50.900 --> 09:53.820 But just a quick recap. 09:57.510 --> 10:05.830 So using a trivial vulnerability in a smart thermometer in fish tank, hackers gained access to casino network. 10:05.830 --> 10:18.130 They retrieved data about high paying customers and then extracted that data through the thermostat and to the cloud and a result of it, 10 gigabyte of data ended up in Finland. 10:18.130 --> 10:24.030 This looks like a Hollywood ready story, perfect for ocean trilogy sequel. 10:24.030 --> 10:37.450 But from our perspective, this just proves the point that the simple device, in this case, the thermometer, can break down the very tough protected end-to-end solution. 10:38.290 --> 10:48.430 With that many new devices already deployed and even more on the way, it is important to consider the unique challenges in IoT space. 10:48.970 --> 10:52.850 And first, let's look at the technical side of it. 10:52.850 --> 11:01.950 So IoT business world is different from traditional well-established and structured PC environment, cloud environment. 11:01.950 --> 11:08.650 There are several factors that contribute to the technical and business challenges in our world. 11:09.510 --> 11:14.690 It's a diversity of distinct market segment and the business model. 11:14.690 --> 11:20.810 So very range of the, very wide range of the use cases that we are dealing with. 11:20.810 --> 11:28.310 IoT usages need to meet stringent power performance and form factor requirements. 11:28.310 --> 11:32.410 Another challenge is the complex ecosystem. 11:32.410 --> 11:38.810 There are many entities involved in defining finished and customer usable product. 11:38.890 --> 11:47.030 Another distinction is the wide range of the software and firmware, which includes OS, hypervisors, bootloaders, right? 11:47.030 --> 11:50.750 Of course, application and all the workloads that run on top of it. 11:51.450 --> 11:58.490 Heterogeneity of the installed base in that end-to-end solution is also a pretty unique factor. 11:58.550 --> 12:04.890 IoT is a mix of the green and brown field devices. 12:04.930 --> 12:07.270 And on top of it comes the icing. 12:07.470 --> 12:15.590 IoT needs to be supported over extended lifetime, which is much longer than traditional PC service. 12:15.590 --> 12:22.870 All these challenges become contributing factors to vulnerability of IoT devices and introducing security risk. 12:22.870 --> 12:29.230 Those are the concerns that actually triggered and got reflected in the policy arena. 12:29.230 --> 12:35.870 And here I would like to ask Amit, please share your insights from the regulatory guideline perspective. 12:36.450 --> 12:38.190 Thank you so much, Anet. 12:38.190 --> 12:39.810 And you're exactly right. 12:39.810 --> 12:59.650 When it comes to the evolving policy and regulatory sphere, the complexities that we're seeing in terms of the various business model and the technical verticals also influence what are some of the principles that the policymakers are considering as they're coming to proposed best practices, 12:59.650 --> 13:07.490 reports, standard development, and laws and regulations and requirements in this area. 13:07.490 --> 13:11.630 One of the interesting things is this idea of having the risk-based approach. 13:11.630 --> 13:15.850 This is, by the way, an underlying principle for all security policy. 13:15.850 --> 13:18.730 But particularly in IoT, it's important. 13:18.730 --> 13:19.490 Why? 13:19.490 --> 13:26.290 Because we have that horizontal but yet very versatile environment of devices, right? 13:26.290 --> 13:39.910 Everything from the low-cost business model of the dog collar, if you will, to the sensitive devices being deployed in critical infrastructure, election system, medical devices, and the like. 13:39.910 --> 14:02.530 So with that diversity of technical systems, business models, economic consideration, considering the risk of the device, not just in terms of which vertical and sector it goes into, but what is the environment, what is the unique attack surface the device is being deployed in from various kind of standpoints? 14:02.530 --> 14:12.030 That's one of the ideas when you think about the proposed regulations, that the requirements should apply based on a risk-based approach. 14:12.030 --> 14:16.630 And you as researchers should expect a lot more standards and thinking. 14:16.630 --> 14:29.790 This is already an established principle in the security community and also in IoT, for example, 62443 IEC, but you should expect more and more thinking and principles and standards around in this area. 14:29.790 --> 14:30.690 What more? 14:30.690 --> 14:36.330 Definitely the regulatory environment should consider how to support innovations. 14:36.330 --> 14:50.130 A lot of these problems are going to be solved by technology and we need to incentivize the development of innovation and consider the fact that proposed regulations might hinder innovation if they're not framed correctly. 14:50.670 --> 14:51.870 Interoperability. 14:51.970 --> 14:53.330 So this is a key issue. 14:53.330 --> 14:56.990 We need to think about how the IoT devices are working together. 14:56.990 --> 15:08.930 How can we foster the secure deployment that is interoperable for IoT devices and also how IoT devices are connecting edge to cloud with OT environments, with other environments. 15:08.930 --> 15:12.570 All of that is putting interoperability in the kind of front. 15:12.570 --> 15:31.310 And here this idea of leveraging international standards that are scalable, that are developed globally at forums like CTA, ISO, IEC, JTC1, Etsy and the like, that is also very critical because as you know, technology knows no boundaries. 15:31.390 --> 15:38.850 The deployment of IoT is obviously a global phenomenon, but the supply chain of technology is global in its nature. 15:38.850 --> 15:52.830 So we want to avoid fragmented regulation or some kind of requirements that are really localized because that's not scalable when you think about manufacturers that are, and the supply chain that are globally, that are global in their nature. 15:52.830 --> 16:02.110 Another key principle that is not unique just by the way for IoT but is really important for IoT is this idea of design neutrality. 16:02.110 --> 16:23.230 That laws and regulations, because they usually adapt, they usually are amended very slowly, they always walk slower than technology, should not bake into the legislative language a specific design or a specific requirement that might become outdated or even terms, 16:23.230 --> 16:28.470 for example, like passwords that might change with time or a unique technical definition. 16:28.470 --> 16:33.980 Instead, we should leverage these international standards and principle-based approaches. 16:34.950 --> 16:45.950 And with all of that, I think a lot of regulators around the world and policymakers are recognizing the need to consider IoT as part of the broader ecosystem and enable private-public partnerships. 16:45.950 --> 16:49.990 So I spoke a lot about the principles, but let's dive in. 16:49.990 --> 16:57.250 Let's look at a few examples of what is really kind of cutting edge in terms of proposed regulation in IoT around the world. 16:57.250 --> 16:58.870 Now, this is just an example. 16:58.870 --> 17:03.790 I'm going to walk you through more domains, but this is super interesting. 17:03.790 --> 17:05.510 It's coming from the UK. 17:05.510 --> 17:08.090 Some of you may have heard about this in the past. 17:08.090 --> 17:17.010 I believe it's since 2018, the UK, with their leadership, have put together an IoT security code of practice with 13 requirements. 17:17.010 --> 17:23.630 They've taken that effort a step farther, and now they're considering a law, a regulation. 17:23.630 --> 17:30.310 This is, I believe, the third consultation already they are publishing for this regulation. 17:30.310 --> 17:37.750 And by the way, now they're also considering to encompass PCs and laptops as part of their regulation. 17:37.750 --> 17:41.310 They're really looking at three core requirements that are proposed. 17:41.310 --> 17:49.010 The first one is around this issue of not having default password and having unique authentication. 17:49.170 --> 17:53.790 This concept is one that we have seen in other regulations around the world. 17:53.790 --> 18:01.910 If you look at the prior consultations, they say explicitly how they were motivated by the Mirai attack. 18:01.910 --> 18:08.030 So you see the connection between the attack surface, the attack, and then the regulators are considering action. 18:08.030 --> 18:30.430 The second requirement is around an issue which is very close to heart to this community, having the public point of contact as part of a vulnerability disclosure policy or program to allow researchers like you to submit vulnerabilities to the manufacturer and have the manufacturer address the vulnerabilities. 18:30.430 --> 18:35.770 The third point which is proposed is around this issue of support of security updates. 18:35.830 --> 18:50.270 By the way, they're also referencing a standard, a technical standard, they have been developing as part of a broader consensus at Etsy in Europe which really talks about consumer IoT requirements in more detail. 18:50.390 --> 18:55.510 But it just kind of shows to you the connection between the standards and the proposed regulation. 18:55.510 --> 19:01.790 So if we look at the broader landscape, we do have a lot of things happening in this sphere. 19:01.790 --> 19:22.290 Everything from state laws, actually in Oregon and California we have laws already in effect from January 2020 on connected devices, looking at this issue of reasonable security for connected devices and they have some language there as well on the issue of authentication means and unique authentication. 19:22.410 --> 19:24.830 We also have proposed federal laws. 19:24.830 --> 19:26.610 So this is very interesting. 19:26.690 --> 19:35.370 In the United States there has been a number of proposed federal laws for all the United States on this issue of IoT security. 19:35.370 --> 19:53.950 One of them is the IoT Cybersecurity Improvement Act that has been proposed for a while, looking at leveraging federal procurement of IoT devices with requirements for all devices going into federal procurement as a way to foster security of devices in all domains. 19:53.950 --> 20:05.550 We have also seen a recent COVID white paper from the Cyberspace Solarium Commission proposing that we should have all the market IoT federal U.S. 20:05.550 --> 20:08.410 law, so certainly an emerging area. 20:08.410 --> 20:11.130 We also have best practices and standards. 20:11.130 --> 20:24.350 Okay, so this particular area is of particular interest and we're going to dive in into the requirements or at least the consensus around what are some kind of the foundational capabilities of IoT devices. 20:24.350 --> 20:33.890 This is an effort to bring all of industry together, both at the international level, so that's at ISO, I'm an editor of one of the standards there, but both in the U.S. 20:33.890 --> 20:46.150 with efforts like NISTOR 8259, that by the way is also referenced on the left in the COVID white paper of the Cyberspace Solarium Commission, so you see the interaction between the efforts. 20:46.270 --> 21:01.590 What's of particular interest for this community is that these are really technical documents, they are horizontal, they reflect the consensus of all of industry, and they might shape the future of both research and market demand in this area. 21:01.590 --> 21:12.010 We have also seen, based on kind of these efforts of overall horizontal kind of trends, sector-specific requirements. 21:12.010 --> 21:22.390 So for example, NIST has created and worked together on building consensus around NISTOR 8259, which is always central to all the market. 21:22.390 --> 21:38.990 Now they've also released a draft on GitHub, a federal profile of these requirements, that is in particular for the federal government sector, so what goes under FISMA to federal agencies for that particular sector. 21:39.070 --> 21:50.810 In addition, of course, this is not just in the U.S., I've showed the example from the U.K., we have seen around the world attention to these issues with governments like Australia and the U.K. 21:50.810 --> 21:53.210 proposing code of practices for IoT. 21:53.210 --> 22:00.530 Australia, in their recent announcement of what they're going to do in terms of cybersecurity policy, they have a segment on IoT there. 22:00.530 --> 22:09.130 Of course, in Europe, a big conversation around attestation, certification, and INISA is definitely also thinking about IoT. 22:09.390 --> 22:22.650 So this is a global phenomenon, and we have seen leadership also from countries like Japan proposing risk-based frameworks for IoT, so definitely of interest for regulators and policymakers around the world. 22:22.970 --> 22:28.470 So finally, I talked about international standards and their importance, how they've been developed in this area. 22:28.470 --> 22:34.830 We have seen two interesting also, I would say, trends that go together with IoT. 22:34.830 --> 22:36.910 One of them is supply chain prosperity. 22:36.910 --> 22:44.030 This is, of course, a big theme in the area of security policy, but in particular, it's connected with IoT. 22:44.050 --> 22:59.030 So those of you who are long-term DEF CON attendees, or besides Las Vegas attendees, or just otherwise might have seen talks from Alan Friedman on the initiative called the SBOM, the Software Bill of Materials. 22:59.030 --> 23:10.350 So this is this idea that you should have transparency into the ingredients of the software, and that transparency into the ingredients can support the other capabilities like updates and the like. 23:10.410 --> 23:15.810 In this area, we also are getting to have some solutions around compute life cycle assurance. 23:15.810 --> 23:21.370 Another trend that we have seen is the coordinate vulnerability disclosure trend that goes together with IoT. 23:21.370 --> 23:38.590 So by that, I mean regulators and policymakers are also recognizing the need to leverage the ecosystem, the need to have that collaboration to address the issues, and they are coupling together with proposed reports and regulations and best practices, 23:38.590 --> 23:49.290 this idea of having a process to receive vulnerabilities from the external community, and you have seen the example from the UK, and to handle the vulnerabilities internally. 23:49.330 --> 24:05.150 So bottom line, a lot of evolving kind of proposed, a lot of evolving kind of initiatives with relationships between them, some are horizontal, some are sector-specific, and a bleed towards other areas of security policy. 24:05.870 --> 24:12.010 Now we're going to drill down into this NISTR, which is this consensus-driven best practice. 24:12.010 --> 24:20.410 This is not a regulation or a requirement per se, but it's a consensus effort that is of interest for this community. 24:20.410 --> 24:33.270 You can see here on the left the C2 effort by the Council to Secure the Digital Economy, and all the different trade associations really spanning the entire technology sector that have come together to define this consensus. 24:33.270 --> 24:39.990 Anaita, I would like to invite you to present to us with more detail the technical elements that are explored in the NISTR. 24:40.790 --> 24:41.730 Thanks, Amit. 24:41.730 --> 24:48.370 So yeah, you heard a lot about NISTR at the magic 8259 number, right? 24:48.370 --> 24:54.030 Let's take a closer look at what it is, what is the motivation and objective. 24:54.250 --> 24:59.370 As this effort very well exemplifies what's happening in regulatory momentum. 24:59.370 --> 25:01.190 So what is this about? 25:01.710 --> 25:04.370 8259 targets manufacturers. 25:04.370 --> 25:11.550 Specifically, the subject of this recommendation is framed around the finished IoT devices. 25:11.550 --> 25:21.270 It provides the recommendation on cyber security activities and capabilities to address customers' cyber security needs. 25:21.270 --> 25:31.330 So NISTR publication proposes to normalize the manufacturer-customer relationship by leveraging the laws, regulations, and guidelines. 25:31.330 --> 25:34.150 Let me set the expectations right. 25:34.150 --> 25:46.550 So 8259 is intended to address a very broad range of IoT devices, from tiny little doorknobs to very complex critical infrastructure class of devices. 25:46.550 --> 25:51.510 So expect to see what I would call it lowest common denominator. 25:51.510 --> 25:55.050 However, this is setting the trend, right? 25:55.050 --> 26:07.130 It's also important to note that all other parts of the IoT ecosystem, other than IoT device itself, are outside of scope of this NISTR recommendation. 26:07.210 --> 26:13.990 So overall, this is the first step towards the making the IoT security more measurable. 26:13.990 --> 26:28.030 It is expected that eventually more guidelines will be developed to address that out-of-scope problems, as well as more specific market segment profiles and the risk-based recommendation will evolve from this one. 26:28.030 --> 26:33.310 And we do see it happening already in the federal space, as Amit mentioned earlier. 26:33.310 --> 26:41.130 So NIST emphasizes the message that IoT security shall start early on. 26:41.130 --> 26:45.170 So let's look at their recommended actions. 26:45.170 --> 26:48.450 Again, remember, this is all about manufacturers. 26:48.450 --> 27:04.410 It is proposed that IoT device manufacturers need to perform this action and provide the services to their customers who would plan that cybersecurity for the devices within their system and environment. 27:04.410 --> 27:12.370 So NISTR 8259 identifies six specific recommended actions, pre-market and post-market. 27:12.370 --> 27:20.690 The first two activities assume that manufacturers have to have the full disclosure on device usages and the security goals. 27:20.690 --> 27:31.130 This might be quite challenging, actually, as there are many cases that we know when customers and manufacturers don't have that good collaboration. 27:31.130 --> 27:36.470 As a result, manufacturers cannot expect what will happen with the device in the field. 27:36.690 --> 27:42.330 Activity number three is the anchor point for the core baseline capability. 27:42.330 --> 27:54.530 These capabilities are defined by NISTR 8259a and supposed to address what customers would need to achieve their goals and fulfill their requirement. 27:54.530 --> 28:00.710 This is the most technically loaded proposal in this recommendation. 28:00.790 --> 28:04.390 Activity number four addresses the support. 28:04.390 --> 28:13.490 So manufacturers should consider all the resources required to support development and continued support of the IoT device. 28:13.490 --> 28:23.910 That includes security code practices, vulnerability disclosures, vulnerability responses, and floor remediation. 28:24.230 --> 28:30.350 Post-market, there are activities five and six, and those are related to customer communication. 28:30.350 --> 28:41.310 Although I would call that really post-market, as planning on how to address these activities needs to be baked in at very early stage of the design of the product. 28:41.310 --> 28:45.830 There are several potential considerations listed in the publication for this stage. 28:45.830 --> 28:54.950 Some of them are the lifespan expectation, the software update, device retirement, and end of life. 28:54.970 --> 29:07.170 The main takeaway here, so NIST attempts to frame the security actions around the different stages of the device lifecycle, bringing manufacturers to customers. 29:07.500 --> 29:14.090 It calls out that pre-market development stage core capabilities needs to be addressed. 29:14.090 --> 29:20.230 So now let's see what are those core capabilities and drill down here. 29:20.390 --> 29:32.910 This baseline represents the industry-wide collaboration effort that Amit mentioned earlier, as a result of which definition of common capabilities were produced. 29:32.910 --> 29:34.830 And the common is the key word here. 29:34.830 --> 29:36.610 This is not exhaustive lips. 29:36.610 --> 29:39.150 Remember the lost denominator? 29:39.150 --> 29:41.670 This is starting point that set the direction. 29:41.670 --> 29:52.250 Therefore, in each implementing organization, you may find the superset capabilities that better fit their needs. 29:52.250 --> 29:55.630 There are six basic capabilities outlined. 29:55.710 --> 30:02.210 First one is device identification, covers both logical and physical identification. 30:02.210 --> 30:09.170 Second is device configuration that can be performed by authorized entities only. 30:09.170 --> 30:16.520 Data protection addresses the protection of data from authorized access and modification. 30:16.890 --> 30:25.040 Logical access to interfaces is about restricting of logical access to local and network interfaces. 30:25.680 --> 30:36.500 Software updates recommends that, again, the update needs to be done in supervised manner, updated only by authorized entities. 30:36.820 --> 30:41.500 And last one here is the cyber security state awareness. 30:41.500 --> 30:52.760 So this capability is about the ability of IoT device to report its own cyber security state and make that information accessible to authorized entities. 30:53.100 --> 30:56.740 So this was just a quick run through these capabilities. 30:56.740 --> 30:59.300 There are many nuances to this baseline. 30:59.300 --> 31:05.400 So I would recommend reading through NISTers 82598 document directly. 31:05.700 --> 31:12.940 And at this point, let's change the gear and look on what's left outside of out of the NIST scope. 31:13.340 --> 31:17.460 So we did talk about the complexity of the ecosystem. 31:17.460 --> 31:22.080 So NIST simplified the ecosystem model just to two entities. 31:22.080 --> 31:28.700 And we at Intel realized that truly deployable IoT solution require more complex relationship. 31:28.700 --> 31:35.260 When we think about Intel, we think about Silicon, which would be very left of this picture. 31:35.260 --> 31:41.080 It is our partner ecosystem that builds out the rest of the story. 31:41.080 --> 31:46.920 So the analogy that we like to use a lot is the orchestra playing together. 31:46.920 --> 31:52.800 So each player has a critical role in delivering finished symphony to the audience. 31:52.800 --> 32:10.480 And the value chain in case of IoT device goes from the ingredient to manufacturers, OEM, ODM, then through the ISVs, cloud service providers, solution integrators, and then only get delivered to the end users. 32:10.480 --> 32:18.600 So all these artists participate in the security baseline definition and implementation. 32:18.880 --> 32:23.580 But there is also the life after the deployment, right? 32:23.580 --> 32:29.280 The device goes to the circular stages of the updates. 32:29.280 --> 32:36.340 And again, manufacturers, they have to rely on the rest of the ecosystem to deliver the updates. 32:36.340 --> 32:38.200 So what do we do? 32:38.880 --> 32:45.860 So we realized that it's not an Intel universe, so we have to work with the broad ecosystem. 32:45.860 --> 32:48.580 And we established the partnership. 32:48.600 --> 32:52.560 So IoT Solution Alliance is our partnership framework. 32:52.560 --> 33:02.300 It covers 6,000 solutions, includes more than 500 members, and of course, we work across the globe throughout our global platform. 33:02.300 --> 33:10.020 As Amit mentioned, this is very important from the regulatory perspective, the global interaction in the policy space. 33:10.020 --> 33:18.040 So our member companies, they span the globe and offer local expertise in market worldwide. 33:18.100 --> 33:22.960 This is the community that we're closely collaborating on security as well. 33:22.960 --> 33:36.260 And for the security discussion, it's important to establish the common ground, attack surfaces and threats is that the common ground that we use to build the collaboration. 33:36.440 --> 33:40.500 So let's take a look to this table. 33:41.100 --> 33:47.660 The attack surface sums up all the penetration points, otherwise known as attack vectors. 33:47.660 --> 33:51.940 So a summary of exploitable vulnerabilities at device level. 33:51.940 --> 34:06.180 So we are looking now at the device level is presented in this table, where different threats on the right side are correlated with respective attack surfaces and components on the left side. 34:06.180 --> 34:11.000 Moving from bottom up, you see the hardware layer, right? 34:11.000 --> 34:20.520 And then above it is the firmware optional hypervisor when virtual machine monitor and then the operating system. 34:20.520 --> 34:28.240 And finally, this user space where the application or workloads will be running. 34:28.680 --> 34:35.440 The attacks in the top layers have been prevalent and known for quite some time already. 34:35.440 --> 35:00.400 But attacks are more and more moving down the stacks, exploiting vulnerabilities all the way to the firmware and the hardware layers as well, which could potentially give even more interesting opportunities, higher privileges on the devices as well as those attacks can go fairly undetected. 35:00.560 --> 35:03.060 So let's take an example. 35:03.060 --> 35:10.480 So by tampering with the firmware, it might be possible to subvert the entire boot, right? 35:10.480 --> 35:16.560 And boot the operating system, which would be attacker's choice, right? 35:16.560 --> 35:19.200 The desired operating system. 35:19.860 --> 35:28.440 This table overall is an eye chart, but I think the main takeaway here is that the attacks are not singular, right? 35:28.440 --> 35:39.120 It's a multi-dimensional problem and spans across the entire stack of IoT device and requires the protection mechanism at each layer as well. 35:39.120 --> 35:52.300 So having this framework allows us to systematically analyze the security solution to mitigate the risk from the very early stage of our product design phase. 35:52.300 --> 35:56.740 And we work with our customer based on this taxonomy. 35:56.740 --> 36:13.480 And we do provide, of course, solutions and innovate the hardware-based security technology in our product to build the defense in depth from the bottom up and withstand the attack propagation. 36:14.160 --> 36:20.700 But, Amit, it's not only about our own innovation and our own technologies, right? 36:20.700 --> 36:33.460 So can you share your thoughts about how this evolving attack surfaces can drive a greater collaboration with technologists? 36:33.760 --> 36:35.220 Yes, absolutely. 36:35.240 --> 36:37.220 And I think, Amit, you're exactly right. 36:37.220 --> 36:45.400 I think you've seen throughout this presentation so much of the complexity that is pretty unique for the IoT ecosystem. 36:45.400 --> 36:59.240 And this is the vertical business model, the versatile devices from everything from the dog collar to the sensitive systems, the type of the attacks and how the attack surface is evolving, and also the technical challenges, right? 36:59.240 --> 37:03.700 And Amit definitely provided a very extensive overview of this. 37:03.700 --> 37:15.480 All of this suggests that this issue is not just going to be solved through the innovations, through the security capabilities that we are going to bake into hardware and software and firmware. 37:15.480 --> 37:19.040 Yes, that is a critical piece of the discussion. 37:19.040 --> 37:30.120 Yes, incentivizing the innovation, the R&D, the research, the pipeline, all of that is critical, but we are still going to need the collaboration. 37:30.140 --> 37:37.300 And by collaboration, I mean companies working with researchers, enabling the ecosystem, right? 37:37.320 --> 37:40.860 Collaboration between the different verticals in the supply chain. 37:40.860 --> 37:58.620 Also collaborations between policymakers and legislators and regulators as they're thinking about these issues between the public and the private industry and having your expertise, the expertise of the crowd in these arenas as well, engaging in that dialogue. 37:58.620 --> 38:03.380 And I think we have seen tremendous developments in that area. 38:03.380 --> 38:07.180 I think the safe harbor kind of discussion is one of them. 38:07.180 --> 38:13.320 We have seen also growing collaboration and a lot of thinking that goes into researcher relations. 38:13.320 --> 38:26.280 I don't know if you've seen some of my peers from PSIRT and from Intel Security at the Red Team Village or in this village talking about how we collaborate with the ecosystem, how we are funding academic researchers in this area. 38:26.280 --> 38:27.940 All that is critical. 38:27.940 --> 38:34.000 So as we are thinking about this kind of conversation, it's really critical to get the dialogue going. 38:34.200 --> 38:42.420 And with that particular recommendation, I would like to invite you all to ethically hack us. 38:42.420 --> 38:44.180 We do have a bug bounty. 38:44.180 --> 38:45.580 It's a public bug bounty. 38:45.580 --> 38:47.400 We offer rewards. 38:47.400 --> 38:48.560 You can check it out. 38:48.560 --> 38:50.140 You can check out the scope. 38:50.140 --> 38:52.420 We also have a vulnerability disclosure program. 38:52.420 --> 38:54.620 You can report vulnerabilities to us. 38:54.620 --> 38:59.540 The collaboration with the researcher community is extremely important to us. 38:59.540 --> 39:03.640 And we work with the entire ecosystem to drive security first. 39:03.780 --> 39:08.040 So security at Intel.com, please report your vulnerabilities. 39:08.040 --> 39:16.580 Please continue the great work and research in the embedded system arena, especially this village is dear to heart for us. 39:16.580 --> 39:18.560 And let's continue the conversation. 39:18.560 --> 39:21.100 And we would like to welcome your questions. 39:21.100 --> 39:26.440 I did went through in a true Israeli fashion and a little bit of my style. 39:26.520 --> 39:29.200 My sister always tells me to slow down. 39:29.200 --> 39:32.420 I went through a lot of examples when I was talking. 39:32.420 --> 39:40.060 And I will provide you the links to all of these resources that I've talked about and Ana shared as well in the Discord chat. 39:40.180 --> 39:42.700 So this is just a little bit of preview. 39:42.940 --> 39:48.680 Please join us in the Discord if you want to get all the details and all the information about what we shared with you today. 39:48.680 --> 39:50.440 You can find it there as well. 39:50.460 --> 39:53.800 And we'd like to continue the conversation with you. 39:53.800 --> 39:56.820 Ana, for me, this has been a great collaboration. 39:57.660 --> 40:01.980 The former hacker that I collaborated with in a talk is my sister, Karen. 40:01.980 --> 40:03.960 I hope to continue that collaboration. 40:04.080 --> 40:06.260 Maybe she is here with us in the audience. 40:06.260 --> 40:09.800 Karen, I haven't forgotten you, of course. 40:09.820 --> 40:13.640 But this has been a really joyful dialogue for me. 40:13.640 --> 40:14.580 Thank you so much. 40:14.580 --> 40:17.680 Anything to share from your perspective, Ana, before we wrap it up? 40:17.680 --> 40:20.160 No, this is a great journey. 40:20.160 --> 40:23.240 And this is a great example of collaboration. 40:23.240 --> 40:26.300 Again, I am on the technology side. 40:26.300 --> 40:27.960 I'm on the product side. 40:27.960 --> 40:31.200 Amit represents a more regulatory perspective. 40:31.200 --> 40:42.480 And this is when these two... when the two worlds meet, we see absolutely new perspective, right? 40:42.480 --> 40:44.120 So collaboration is the key. 40:44.120 --> 40:45.080 And thank you very much. 40:45.080 --> 40:46.480 We are looking to hear from you.