1 00:00:00,000 --> 00:00:01,560 Thank you so much. 2 00:00:01,560 --> 00:00:03,300 And I just love this village. 3 00:00:03,300 --> 00:00:08,040 You know, I have been coming to this village, I think it is three years in a row. 4 00:00:08,040 --> 00:00:09,860 And I do miss DEF CON a lot. 5 00:00:09,860 --> 00: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. 6 00:00:17,500 --> 00:00:21,100 But I am very excited to be here with you today. 7 00:00:21,240 --> 00: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. 8 00:00:32,460 --> 00:00:38,560 And we're going to be talking with you today on this evolving landscape of baseline standards and regulation. 9 00:00:38,560 --> 00:00:40,080 So first of all, let me check again. 10 00:00:40,080 --> 00:00:42,760 Can you all hear us great, Sam, Tim? 11 00:00:43,460 --> 00:00:44,800 Yep, we can. 12 00:00:44,900 --> 00:00:45,900 Wonderful. 13 00:00:46,440 --> 00:00:49,980 Well, as Sam shared, we are both from Intel. 14 00:00:50,000 --> 00:00:55,580 I work in the government's relation team at Intel within the legal department. 15 00:00:55,580 --> 00:01:00,300 I work with governments around the world and policymakers on issues of security policy. 16 00:01:00,300 --> 00:01:05,820 And I also lecture at the UC Berkeley School of Information, where I teach in the Master in Cybersecurity program. 17 00:01:06,440 --> 00:01:10,200 And as many of you know, I'm also Israeli. 18 00:01:10,320 --> 00:01:14,100 And usually when I come to this village, I start with a direct question. 19 00:01:14,320 --> 00:01:15,960 So let me do it again. 20 00:01:16,140 --> 00:01:19,720 By now, most of you should be familiar with this face. 21 00:01:19,760 --> 00:01:21,000 And I hope you know him. 22 00:01:21,000 --> 00:01:22,740 This is Kevin Finster. 23 00:01:22,740 --> 00:01:23,980 He's a researcher. 24 00:01:23,980 --> 00:01:29,260 And like many of you in the audience, he is also focused on embedded systems. 25 00:01:29,260 --> 00:01:34,640 And specifically, he has a love and passion towards drones. 26 00:01:34,640 --> 00: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. 27 00:01:44,820 --> 00:01:53,220 And he wanted to report that vulnerability to DJI and, you know, do the right thing and engage in disclosure. 28 00:01:53,220 --> 00: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. 29 00:02:05,740 --> 00:02:12,380 And, you know, it was not really clear what was the scope, according to the reports. 30 00:02:12,380 --> 00:02:16,040 There wasn't really a bug bounty policy or contract. 31 00:02:16,040 --> 00:02:21,280 And there was some confusion between the parties on this issue of the scope, according to the reports. 32 00:02:21,280 --> 00:02:28,100 So Kevin contacted DJI and asked them, is this vulnerability that I found is in scope? 33 00:02:28,100 --> 00:02:32,980 And they, in fact, according to the reports, suggested it is in scope. 34 00:02:32,980 --> 00:02:39,500 Not only that, they said that they would like to pay him $30,000 for that vulnerability. 35 00:02:39,500 --> 00:02:47,380 So for those of you engaged in bug hunting, just empirically speaking, that's a pretty high bounty. 36 00:02:47,520 --> 00:02:49,860 And then the plot thickened. 37 00:02:49,880 --> 00:02:55,140 So there are two sides to this story, and I encourage you to check out the links in the bottom. 38 00:02:55,460 --> 00: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. 39 00:03:07,220 --> 00:03:08,780 And then the plot thickened. 40 00:03:08,780 --> 00: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. 41 00:03:20,920 --> 00: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. 42 00:03:30,980 --> 00:03:34,320 And, you know, he did order a Tesla. 43 00:03:34,340 --> 00:03:37,980 He ended up canceling that order of a Tesla. 44 00:03:37,980 --> 00: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. 45 00:03:49,520 --> 00:03:53,260 And it's a story that I shared a lot during the last few years. 46 00:03:53,260 --> 00: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. 47 00:04:02,300 --> 00:04:08,880 We have seen a lot of safe harbor adoptions and a lot of collaborations between companies and researchers. 48 00:04:08,880 --> 00: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. 49 00:04:24,100 --> 00:04:25,720 So all of this is very exciting. 50 00:04:25,720 --> 00: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. 51 00:04:45,440 --> 00: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. 52 00:04:58,680 --> 00:05:02,160 So we know that laws are slowly being amended. 53 00:05:02,160 --> 00:05:05,440 It's not like innovation that is rapidly being developed. 54 00:05:05,440 --> 00:05:14,320 And laws often have concepts like authorization or reasonable security or principles that are adapted with time. 55 00:05:14,320 --> 00: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. 56 00:05:32,140 --> 00:05:36,180 And much has changed, including hacking and security testing. 57 00:05:36,180 --> 00: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. 58 00:05:43,860 --> 00:05:46,340 And we will see how that will evolve. 59 00:05:46,340 --> 00:05:51,940 But it just shows kind of how the laws are adapting to technology but are often behind. 60 00:05:51,940 --> 00: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. 61 00:06:05,640 --> 00:06:08,480 So I shared a little bit about my background. 62 00:06:09,040 --> 00:06:15,300 Towards this week at DEF CON, a lot has been talked about in terms of disclosed I.O. 63 00:06:15,300 --> 00:06:16,320 and bug bounty. 64 00:06:16,320 --> 00:06:18,680 You can check out my prior work in this area. 65 00:06:18,680 --> 00:06:25,420 But I'm very passionate about this issue of collaboration between researchers and hackers and companies. 66 00:06:26,000 --> 00:06:30,700 And while I am a lawyer and my background is legal, I'm not your lawyer. 67 00:06:30,700 --> 00: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. 68 00:06:36,340 --> 00:06:38,700 So I know this is a little bit of fine print. 69 00:06:38,800 --> 00:06:41,700 You would probably expect that from me, right? 70 00:06:41,900 --> 00:06:43,680 But it is exciting. 71 00:06:43,680 --> 00: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, 72 00:06:58,780 --> 00:07:01,780 but also know that we have that language in our bug bounty. 73 00:07:01,980 --> 00:07:04,480 And with that, I spoke a lot about collaboration. 74 00:07:04,480 --> 00:07:10,840 I spoke about why this is important as we think about technology and laws and how they go together. 75 00:07:10,840 --> 00: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. 76 00:07:28,360 --> 00:07:30,420 Anait, please take it away. 77 00:07:31,540 --> 00:07:32,720 Thanks, Amit. 78 00:07:32,720 --> 00:07:34,540 Indeed, it's a great collaboration. 79 00:07:34,540 --> 00:07:35,660 So hi, folks. 80 00:07:35,660 --> 00:07:37,440 Very glad to be here. 81 00:07:37,440 --> 00:07:42,560 And as Amit said, I work directly on product definition side. 82 00:07:42,560 --> 00:07:47,180 So today we are talking about security and regulation policies, right? 83 00:07:47,180 --> 00:07:57,240 And being on the receiving side of the regulatory guidelines inside Intel, I spent time understanding and assessing the technical implication. 84 00:07:57,240 --> 00:08:03,760 So first, I would like to start looking at the concern that triggers this rising regulatory effort. 85 00:08:03,800 --> 00:08:11,060 And one of the key IoT security issue is the expanded attack surface. 86 00:08:11,240 --> 00:08:15,620 And that's due to the increased number of the endpoint devices. 87 00:08:15,620 --> 00:08:22,380 So we all see this futurescape that predict billions of devices with trillions of sensors. 88 00:08:22,380 --> 00:08:30,020 This large number of IoT devices that being brought into the business triggers the growth of attack. 89 00:08:30,160 --> 00:08:36,020 Another issue is the sophistication and evolving of the intent. 90 00:08:36,020 --> 00:08:42,420 It is clear that the attack target is not limited to the assets of IoT device only. 91 00:08:42,420 --> 00:08:51,780 IoT device exposure opens a plethora of opportunity across the edge to cloud and exposes a lot of valuable assets. 92 00:08:51,780 --> 00:08:56,720 So let's analyze the genealogy of the IoT attacks. 93 00:09:00,020 --> 00:09:06,940 So what you see here is typical IoT solution that spans edge to cloud. 94 00:09:06,940 --> 00: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. 95 00:09:16,400 --> 00:09:25,060 This duality exposes enormous challenges for the security community and adds new dimension to the system cybersecurity controls. 96 00:09:25,600 --> 00: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. 97 00:09:38,100 --> 00:09:45,420 One notorious example of this type of scenario is a casino fish tank attack. 98 00:09:46,190 --> 00:09:50,060 I don't know how many of you are aware of that story. 99 00:09:50,900 --> 00:09:53,820 But just a quick recap. 100 00:09:57,510 --> 00:10:05,830 So using a trivial vulnerability in a smart thermometer in fish tank, hackers gained access to casino network. 101 00:10:05,830 --> 00: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. 102 00:10:18,130 --> 00:10:24,030 This looks like a Hollywood ready story, perfect for ocean trilogy sequel. 103 00:10:24,030 --> 00: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. 104 00:10:38,290 --> 00: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. 105 00:10:48,970 --> 00:10:52,850 And first, let's look at the technical side of it. 106 00:10:52,850 --> 00:11:01,950 So IoT business world is different from traditional well-established and structured PC environment, cloud environment. 107 00:11:01,950 --> 00:11:08,650 There are several factors that contribute to the technical and business challenges in our world. 108 00:11:09,510 --> 00:11:14,690 It's a diversity of distinct market segment and the business model. 109 00:11:14,690 --> 00:11:20,810 So very range of the, very wide range of the use cases that we are dealing with. 110 00:11:20,810 --> 00:11:28,310 IoT usages need to meet stringent power performance and form factor requirements. 111 00:11:28,310 --> 00:11:32,410 Another challenge is the complex ecosystem. 112 00:11:32,410 --> 00:11:38,810 There are many entities involved in defining finished and customer usable product. 113 00:11:38,890 --> 00:11:47,030 Another distinction is the wide range of the software and firmware, which includes OS, hypervisors, bootloaders, right? 114 00:11:47,030 --> 00:11:50,750 Of course, application and all the workloads that run on top of it. 115 00:11:51,450 --> 00:11:58,490 Heterogeneity of the installed base in that end-to-end solution is also a pretty unique factor. 116 00:11:58,550 --> 00:12:04,890 IoT is a mix of the green and brown field devices. 117 00:12:04,930 --> 00:12:07,270 And on top of it comes the icing. 118 00:12:07,470 --> 00:12:15,590 IoT needs to be supported over extended lifetime, which is much longer than traditional PC service. 119 00:12:15,590 --> 00:12:22,870 All these challenges become contributing factors to vulnerability of IoT devices and introducing security risk. 120 00:12:22,870 --> 00:12:29,230 Those are the concerns that actually triggered and got reflected in the policy arena. 121 00:12:29,230 --> 00:12:35,870 And here I would like to ask Amit, please share your insights from the regulatory guideline perspective. 122 00:12:36,450 --> 00:12:38,190 Thank you so much, Anet. 123 00:12:38,190 --> 00:12:39,810 And you're exactly right. 124 00:12:39,810 --> 00: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, 125 00:12:59,650 --> 00:13:07,490 reports, standard development, and laws and regulations and requirements in this area. 126 00:13:07,490 --> 00:13:11,630 One of the interesting things is this idea of having the risk-based approach. 127 00:13:11,630 --> 00:13:15,850 This is, by the way, an underlying principle for all security policy. 128 00:13:15,850 --> 00:13:18,730 But particularly in IoT, it's important. 129 00:13:18,730 --> 00:13:19,490 Why? 130 00:13:19,490 --> 00:13:26,290 Because we have that horizontal but yet very versatile environment of devices, right? 131 00:13:26,290 --> 00: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. 132 00:13:39,910 --> 00: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? 133 00:14:02,530 --> 00: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. 134 00:14:12,030 --> 00:14:16,630 And you as researchers should expect a lot more standards and thinking. 135 00:14:16,630 --> 00: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. 136 00:14:29,790 --> 00:14:30,690 What more? 137 00:14:30,690 --> 00:14:36,330 Definitely the regulatory environment should consider how to support innovations. 138 00:14:36,330 --> 00: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. 139 00:14:50,670 --> 00:14:51,870 Interoperability. 140 00:14:51,970 --> 00:14:53,330 So this is a key issue. 141 00:14:53,330 --> 00:14:56,990 We need to think about how the IoT devices are working together. 142 00:14:56,990 --> 00: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. 143 00:15:08,930 --> 00:15:12,570 All of that is putting interoperability in the kind of front. 144 00:15:12,570 --> 00: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. 145 00:15:31,390 --> 00:15:38,850 The deployment of IoT is obviously a global phenomenon, but the supply chain of technology is global in its nature. 146 00:15:38,850 --> 00: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. 147 00:15:52,830 --> 00: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. 148 00:16:02,110 --> 00: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, 149 00:16:23,230 --> 00:16:28,470 for example, like passwords that might change with time or a unique technical definition. 150 00:16:28,470 --> 00:16:33,980 Instead, we should leverage these international standards and principle-based approaches. 151 00:16:34,950 --> 00: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. 152 00:16:45,950 --> 00:16:49,990 So I spoke a lot about the principles, but let's dive in. 153 00:16:49,990 --> 00: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. 154 00:16:57,250 --> 00:16:58,870 Now, this is just an example. 155 00:16:58,870 --> 00:17:03,790 I'm going to walk you through more domains, but this is super interesting. 156 00:17:03,790 --> 00:17:05,510 It's coming from the UK. 157 00:17:05,510 --> 00:17:08,090 Some of you may have heard about this in the past. 158 00:17:08,090 --> 00: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. 159 00:17:17,010 --> 00:17:23,630 They've taken that effort a step farther, and now they're considering a law, a regulation. 160 00:17:23,630 --> 00:17:30,310 This is, I believe, the third consultation already they are publishing for this regulation. 161 00:17:30,310 --> 00:17:37,750 And by the way, now they're also considering to encompass PCs and laptops as part of their regulation. 162 00:17:37,750 --> 00:17:41,310 They're really looking at three core requirements that are proposed. 163 00:17:41,310 --> 00:17:49,010 The first one is around this issue of not having default password and having unique authentication. 164 00:17:49,170 --> 00:17:53,790 This concept is one that we have seen in other regulations around the world. 165 00:17:53,790 --> 00:18:01,910 If you look at the prior consultations, they say explicitly how they were motivated by the Mirai attack. 166 00:18:01,910 --> 00:18:08,030 So you see the connection between the attack surface, the attack, and then the regulators are considering action. 167 00:18:08,030 --> 00: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. 168 00:18:30,430 --> 00:18:35,770 The third point which is proposed is around this issue of support of security updates. 169 00:18:35,830 --> 00: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. 170 00:18:50,390 --> 00:18:55,510 But it just kind of shows to you the connection between the standards and the proposed regulation. 171 00:18:55,510 --> 00:19:01,790 So if we look at the broader landscape, we do have a lot of things happening in this sphere. 172 00:19:01,790 --> 00: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. 173 00:19:22,410 --> 00:19:24,830 We also have proposed federal laws. 174 00:19:24,830 --> 00:19:26,610 So this is very interesting. 175 00:19:26,690 --> 00: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. 176 00:19:35,370 --> 00: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. 177 00:19:53,950 --> 00: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. 178 00:20:05,550 --> 00:20:08,410 law, so certainly an emerging area. 179 00:20:08,410 --> 00:20:11,130 We also have best practices and standards. 180 00:20:11,130 --> 00: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. 181 00:20:24,350 --> 00: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. 182 00:20:33,890 --> 00: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. 183 00:20:46,270 --> 00: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. 184 00:21:01,590 --> 00:21:12,010 We have also seen, based on kind of these efforts of overall horizontal kind of trends, sector-specific requirements. 185 00:21:12,010 --> 00: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. 186 00:21:22,390 --> 00: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. 187 00:21:39,070 --> 00: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. 188 00:21:50,810 --> 00:21:53,210 proposing code of practices for IoT. 189 00:21:53,210 --> 00: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. 190 00:22:00,530 --> 00:22:09,130 Of course, in Europe, a big conversation around attestation, certification, and INISA is definitely also thinking about IoT. 191 00:22:09,390 --> 00: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. 192 00:22:22,970 --> 00:22:28,470 So finally, I talked about international standards and their importance, how they've been developed in this area. 193 00:22:28,470 --> 00:22:34,830 We have seen two interesting also, I would say, trends that go together with IoT. 194 00:22:34,830 --> 00:22:36,910 One of them is supply chain prosperity. 195 00:22:36,910 --> 00:22:44,030 This is, of course, a big theme in the area of security policy, but in particular, it's connected with IoT. 196 00:22:44,050 --> 00: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. 197 00:22:59,030 --> 00: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. 198 00:23:10,410 --> 00:23:15,810 In this area, we also are getting to have some solutions around compute life cycle assurance. 199 00:23:15,810 --> 00:23:21,370 Another trend that we have seen is the coordinate vulnerability disclosure trend that goes together with IoT. 200 00:23:21,370 --> 00: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, 201 00:23:38,590 --> 00: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. 202 00:23:49,330 --> 00: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. 203 00:24:05,870 --> 00:24:12,010 Now we're going to drill down into this NISTR, which is this consensus-driven best practice. 204 00:24:12,010 --> 00: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. 205 00:24:20,410 --> 00: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. 206 00:24:33,270 --> 00: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. 207 00:24:40,790 --> 00:24:41,730 Thanks, Amit. 208 00:24:41,730 --> 00:24:48,370 So yeah, you heard a lot about NISTR at the magic 8259 number, right? 209 00:24:48,370 --> 00:24:54,030 Let's take a closer look at what it is, what is the motivation and objective. 210 00:24:54,250 --> 00:24:59,370 As this effort very well exemplifies what's happening in regulatory momentum. 211 00:24:59,370 --> 00:25:01,190 So what is this about? 212 00:25:01,710 --> 00:25:04,370 8259 targets manufacturers. 213 00:25:04,370 --> 00:25:11,550 Specifically, the subject of this recommendation is framed around the finished IoT devices. 214 00:25:11,550 --> 00:25:21,270 It provides the recommendation on cyber security activities and capabilities to address customers' cyber security needs. 215 00:25:21,270 --> 00:25:31,330 So NISTR publication proposes to normalize the manufacturer-customer relationship by leveraging the laws, regulations, and guidelines. 216 00:25:31,330 --> 00:25:34,150 Let me set the expectations right. 217 00:25:34,150 --> 00: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. 218 00:25:46,550 --> 00:25:51,510 So expect to see what I would call it lowest common denominator. 219 00:25:51,510 --> 00:25:55,050 However, this is setting the trend, right? 220 00:25:55,050 --> 00: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. 221 00:26:07,210 --> 00:26:13,990 So overall, this is the first step towards the making the IoT security more measurable. 222 00:26:13,990 --> 00: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. 223 00:26:28,030 --> 00:26:33,310 And we do see it happening already in the federal space, as Amit mentioned earlier. 224 00:26:33,310 --> 00:26:41,130 So NIST emphasizes the message that IoT security shall start early on. 225 00:26:41,130 --> 00:26:45,170 So let's look at their recommended actions. 226 00:26:45,170 --> 00:26:48,450 Again, remember, this is all about manufacturers. 227 00:26:48,450 --> 00: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. 228 00:27:04,410 --> 00:27:12,370 So NISTR 8259 identifies six specific recommended actions, pre-market and post-market. 229 00:27:12,370 --> 00:27:20,690 The first two activities assume that manufacturers have to have the full disclosure on device usages and the security goals. 230 00:27:20,690 --> 00: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. 231 00:27:31,130 --> 00:27:36,470 As a result, manufacturers cannot expect what will happen with the device in the field. 232 00:27:36,690 --> 00:27:42,330 Activity number three is the anchor point for the core baseline capability. 233 00:27:42,330 --> 00: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. 234 00:27:54,530 --> 00:28:00,710 This is the most technically loaded proposal in this recommendation. 235 00:28:00,790 --> 00:28:04,390 Activity number four addresses the support. 236 00:28:04,390 --> 00:28:13,490 So manufacturers should consider all the resources required to support development and continued support of the IoT device. 237 00:28:13,490 --> 00:28:23,910 That includes security code practices, vulnerability disclosures, vulnerability responses, and floor remediation. 238 00:28:24,230 --> 00:28:30,350 Post-market, there are activities five and six, and those are related to customer communication. 239 00:28:30,350 --> 00: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. 240 00:28:41,310 --> 00:28:45,830 There are several potential considerations listed in the publication for this stage. 241 00:28:45,830 --> 00:28:54,950 Some of them are the lifespan expectation, the software update, device retirement, and end of life. 242 00:28:54,970 --> 00: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. 243 00:29:07,500 --> 00:29:14,090 It calls out that pre-market development stage core capabilities needs to be addressed. 244 00:29:14,090 --> 00:29:20,230 So now let's see what are those core capabilities and drill down here. 245 00:29:20,390 --> 00: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. 246 00:29:32,910 --> 00:29:34,830 And the common is the key word here. 247 00:29:34,830 --> 00:29:36,610 This is not exhaustive lips. 248 00:29:36,610 --> 00:29:39,150 Remember the lost denominator? 249 00:29:39,150 --> 00:29:41,670 This is starting point that set the direction. 250 00:29:41,670 --> 00:29:52,250 Therefore, in each implementing organization, you may find the superset capabilities that better fit their needs. 251 00:29:52,250 --> 00:29:55,630 There are six basic capabilities outlined. 252 00:29:55,710 --> 00:30:02,210 First one is device identification, covers both logical and physical identification. 253 00:30:02,210 --> 00:30:09,170 Second is device configuration that can be performed by authorized entities only. 254 00:30:09,170 --> 00:30:16,520 Data protection addresses the protection of data from authorized access and modification. 255 00:30:16,890 --> 00:30:25,040 Logical access to interfaces is about restricting of logical access to local and network interfaces. 256 00:30:25,680 --> 00:30:36,500 Software updates recommends that, again, the update needs to be done in supervised manner, updated only by authorized entities. 257 00:30:36,820 --> 00:30:41,500 And last one here is the cyber security state awareness. 258 00:30:41,500 --> 00: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. 259 00:30:53,100 --> 00:30:56,740 So this was just a quick run through these capabilities. 260 00:30:56,740 --> 00:30:59,300 There are many nuances to this baseline. 261 00:30:59,300 --> 00:31:05,400 So I would recommend reading through NISTers 82598 document directly. 262 00:31:05,700 --> 00: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. 263 00:31:13,340 --> 00:31:17,460 So we did talk about the complexity of the ecosystem. 264 00:31:17,460 --> 00:31:22,080 So NIST simplified the ecosystem model just to two entities. 265 00:31:22,080 --> 00:31:28,700 And we at Intel realized that truly deployable IoT solution require more complex relationship. 266 00:31:28,700 --> 00:31:35,260 When we think about Intel, we think about Silicon, which would be very left of this picture. 267 00:31:35,260 --> 00:31:41,080 It is our partner ecosystem that builds out the rest of the story. 268 00:31:41,080 --> 00:31:46,920 So the analogy that we like to use a lot is the orchestra playing together. 269 00:31:46,920 --> 00:31:52,800 So each player has a critical role in delivering finished symphony to the audience. 270 00:31:52,800 --> 00: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. 271 00:32:10,480 --> 00:32:18,600 So all these artists participate in the security baseline definition and implementation. 272 00:32:18,880 --> 00:32:23,580 But there is also the life after the deployment, right? 273 00:32:23,580 --> 00:32:29,280 The device goes to the circular stages of the updates. 274 00:32:29,280 --> 00:32:36,340 And again, manufacturers, they have to rely on the rest of the ecosystem to deliver the updates. 275 00:32:36,340 --> 00:32:38,200 So what do we do? 276 00:32:38,880 --> 00:32:45,860 So we realized that it's not an Intel universe, so we have to work with the broad ecosystem. 277 00:32:45,860 --> 00:32:48,580 And we established the partnership. 278 00:32:48,600 --> 00:32:52,560 So IoT Solution Alliance is our partnership framework. 279 00:32:52,560 --> 00: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. 280 00:33:02,300 --> 00:33:10,020 As Amit mentioned, this is very important from the regulatory perspective, the global interaction in the policy space. 281 00:33:10,020 --> 00:33:18,040 So our member companies, they span the globe and offer local expertise in market worldwide. 282 00:33:18,100 --> 00:33:22,960 This is the community that we're closely collaborating on security as well. 283 00:33:22,960 --> 00: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. 284 00:33:36,440 --> 00:33:40,500 So let's take a look to this table. 285 00:33:41,100 --> 00:33:47,660 The attack surface sums up all the penetration points, otherwise known as attack vectors. 286 00:33:47,660 --> 00:33:51,940 So a summary of exploitable vulnerabilities at device level. 287 00:33:51,940 --> 00: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. 288 00:34:06,180 --> 00:34:11,000 Moving from bottom up, you see the hardware layer, right? 289 00:34:11,000 --> 00:34:20,520 And then above it is the firmware optional hypervisor when virtual machine monitor and then the operating system. 290 00:34:20,520 --> 00:34:28,240 And finally, this user space where the application or workloads will be running. 291 00:34:28,680 --> 00:34:35,440 The attacks in the top layers have been prevalent and known for quite some time already. 292 00:34:35,440 --> 00: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. 293 00:35:00,560 --> 00:35:03,060 So let's take an example. 294 00:35:03,060 --> 00:35:10,480 So by tampering with the firmware, it might be possible to subvert the entire boot, right? 295 00:35:10,480 --> 00:35:16,560 And boot the operating system, which would be attacker's choice, right? 296 00:35:16,560 --> 00:35:19,200 The desired operating system. 297 00:35:19,860 --> 00: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? 298 00:35:28,440 --> 00: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. 299 00:35:39,120 --> 00: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. 300 00:35:52,300 --> 00:35:56,740 And we work with our customer based on this taxonomy. 301 00:35:56,740 --> 00: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. 302 00:36:14,160 --> 00:36:20,700 But, Amit, it's not only about our own innovation and our own technologies, right? 303 00:36:20,700 --> 00:36:33,460 So can you share your thoughts about how this evolving attack surfaces can drive a greater collaboration with technologists? 304 00:36:33,760 --> 00:36:35,220 Yes, absolutely. 305 00:36:35,240 --> 00:36:37,220 And I think, Amit, you're exactly right. 306 00:36:37,220 --> 00:36:45,400 I think you've seen throughout this presentation so much of the complexity that is pretty unique for the IoT ecosystem. 307 00:36:45,400 --> 00: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? 308 00:36:59,240 --> 00:37:03,700 And Amit definitely provided a very extensive overview of this. 309 00:37:03,700 --> 00: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. 310 00:37:15,480 --> 00:37:19,040 Yes, that is a critical piece of the discussion. 311 00:37:19,040 --> 00: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. 312 00:37:30,140 --> 00:37:37,300 And by collaboration, I mean companies working with researchers, enabling the ecosystem, right? 313 00:37:37,320 --> 00:37:40,860 Collaboration between the different verticals in the supply chain. 314 00:37:40,860 --> 00: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. 315 00:37:58,620 --> 00:38:03,380 And I think we have seen tremendous developments in that area. 316 00:38:03,380 --> 00:38:07,180 I think the safe harbor kind of discussion is one of them. 317 00:38:07,180 --> 00:38:13,320 We have seen also growing collaboration and a lot of thinking that goes into researcher relations. 318 00:38:13,320 --> 00: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. 319 00:38:26,280 --> 00:38:27,940 All that is critical. 320 00:38:27,940 --> 00:38:34,000 So as we are thinking about this kind of conversation, it's really critical to get the dialogue going. 321 00:38:34,200 --> 00:38:42,420 And with that particular recommendation, I would like to invite you all to ethically hack us. 322 00:38:42,420 --> 00:38:44,180 We do have a bug bounty. 323 00:38:44,180 --> 00:38:45,580 It's a public bug bounty. 324 00:38:45,580 --> 00:38:47,400 We offer rewards. 325 00:38:47,400 --> 00:38:48,560 You can check it out. 326 00:38:48,560 --> 00:38:50,140 You can check out the scope. 327 00:38:50,140 --> 00:38:52,420 We also have a vulnerability disclosure program. 328 00:38:52,420 --> 00:38:54,620 You can report vulnerabilities to us. 329 00:38:54,620 --> 00:38:59,540 The collaboration with the researcher community is extremely important to us. 330 00:38:59,540 --> 00:39:03,640 And we work with the entire ecosystem to drive security first. 331 00:39:03,780 --> 00:39:08,040 So security at Intel.com, please report your vulnerabilities. 332 00:39:08,040 --> 00:39:16,580 Please continue the great work and research in the embedded system arena, especially this village is dear to heart for us. 333 00:39:16,580 --> 00:39:18,560 And let's continue the conversation. 334 00:39:18,560 --> 00:39:21,100 And we would like to welcome your questions. 335 00:39:21,100 --> 00:39:26,440 I did went through in a true Israeli fashion and a little bit of my style. 336 00:39:26,520 --> 00:39:29,200 My sister always tells me to slow down. 337 00:39:29,200 --> 00:39:32,420 I went through a lot of examples when I was talking. 338 00:39:32,420 --> 00: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. 339 00:39:40,180 --> 00:39:42,700 So this is just a little bit of preview. 340 00:39:42,940 --> 00: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. 341 00:39:48,680 --> 00:39:50,440 You can find it there as well. 342 00:39:50,460 --> 00:39:53,800 And we'd like to continue the conversation with you. 343 00:39:53,800 --> 00:39:56,820 Ana, for me, this has been a great collaboration. 344 00:39:57,660 --> 00:40:01,980 The former hacker that I collaborated with in a talk is my sister, Karen. 345 00:40:01,980 --> 00:40:03,960 I hope to continue that collaboration. 346 00:40:04,080 --> 00:40:06,260 Maybe she is here with us in the audience. 347 00:40:06,260 --> 00:40:09,800 Karen, I haven't forgotten you, of course. 348 00:40:09,820 --> 00:40:13,640 But this has been a really joyful dialogue for me. 349 00:40:13,640 --> 00:40:14,580 Thank you so much. 350 00:40:14,580 --> 00:40:17,680 Anything to share from your perspective, Ana, before we wrap it up? 351 00:40:17,680 --> 00:40:20,160 No, this is a great journey. 352 00:40:20,160 --> 00:40:23,240 And this is a great example of collaboration. 353 00:40:23,240 --> 00:40:26,300 Again, I am on the technology side. 354 00:40:26,300 --> 00:40:27,960 I'm on the product side. 355 00:40:27,960 --> 00:40:31,200 Amit represents a more regulatory perspective. 356 00:40:31,200 --> 00:40:42,480 And this is when these two... when the two worlds meet, we see absolutely new perspective, right? 357 00:40:42,480 --> 00:40:44,120 So collaboration is the key. 358 00:40:44,120 --> 00:40:45,080 And thank you very much. 359 00:40:45,080 --> 00:40:46,480 We are looking to hear from you.