[00:00.000 --> 00:05.180]  Thank you so much. And I just love this village. You know, I have been coming to this village,
[00:05.180 --> 00:11.860]  I think it is three years in a row. And I do miss DEF CON a lot. And some of you know my sister,
[00:11.860 --> 00:18.280]  Karen Elazari, I often go to DEF CON with her and we definitely miss that experience. But I am
[00:18.280 --> 00:24.740]  very excited to be here with you today. And today I'm also joined with a really good colleague of
[00:24.740 --> 00:32.820]  mine, Anait, she is a spectacular engineer from the IoTG business unit with us. And we're going
[00:32.820 --> 00:38.560]  to be talking with you today on this evolving landscape of baseline standards and regulation.
[00:38.560 --> 00:42.760]  So first of all, let me check again. Can you all hear us great, Sam, Tim?
[00:43.460 --> 00:44.800]  Yep, we can.
[00:44.900 --> 00:52.680]  Wonderful. Well, as Sam shared, we are both from Intel. I work in the government's relation team
[00:52.680 --> 00:57.980]  at Intel within the legal department. I work with governments around the world and policymakers
[00:58.520 --> 01:03.060]  on issues of security policy. And I also lecture at the UC Berkeley School of Information,
[01:03.060 --> 01:10.200]  where I teach in the Master in Cybersecurity program. And as many of you know, I'm also Israeli.
[01:10.320 --> 01:15.960]  And usually when I come to this village, I start with a direct question. So let me do it again.
[01:16.140 --> 01:21.620]  By now, most of you should be familiar with this face. And I hope you know him. This is Kevin
[01:21.620 --> 01:27.900]  Finster. He's a researcher. And like many of you in the audience, he is also focused on embedded
[01:27.900 --> 01:35.940]  systems. And specifically, he has a love and passion towards drones. And he has conducted
[01:35.940 --> 01:43.340]  research on DJI, one of their drone systems, and he found the vulnerability that, according to him,
[01:43.340 --> 01:48.780]  leaked personal information. And he wanted to report that vulnerability to DJI and, you know,
[01:48.780 --> 01:56.180]  do the right thing and engage in disclosure. And at the time, DJI just launched their bug bounty
[01:56.180 --> 02:02.900]  program with this media announcement, inviting the community, inviting the ecosystem to report
[02:02.900 --> 02:11.440]  vulnerabilities to them. And, you know, it was not really clear what was the scope, according to the
[02:11.440 --> 02:17.460]  reports. There wasn't really a bug bounty policy or contract. And there was some confusion between
[02:17.460 --> 02:24.040]  the parties on this issue of the scope, according to the reports. So Kevin contacted DJI and asked
[02:24.040 --> 02:31.220]  them, is this vulnerability that I found is in scope? And they, in fact, according to the reports,
[02:31.220 --> 02:37.620]  suggested it is in scope. Not only that, they said that they would like to pay him $30,000
[02:37.620 --> 02:44.820]  for that vulnerability. So for those of you engaged in bug hunting, just empirically speaking,
[02:45.380 --> 02:52.380]  that's a pretty high bounty. And then the plot thickened. So there are two sides to this story,
[02:52.380 --> 02:58.620]  and I encourage you to check out the links in the bottom. But Kevin felt that during the negotiation
[02:59.420 --> 03:04.960]  on issues of disclosure, there were some issues that were unclear, again, because we didn't have
[03:04.960 --> 03:10.560]  that scope and website. And then the plot thickened. And then in the draft letter mentioning
[03:10.560 --> 03:16.180]  the Computer Fraud and Abuse Act, which is the main anti-hacking law here in the United States,
[03:16.180 --> 03:22.260]  together with the DMCA, was mentioned, according to the reports in that letter. And Kevin ended up
[03:22.260 --> 03:29.420]  walking away from this approved bug bounty of $30,000 and sharing on Twitter his version of
[03:29.420 --> 03:37.980]  the story. And, you know, he did order a Tesla. He ended up canceling that order of a Tesla.
[03:37.980 --> 03:44.380]  And it's just a story highlighting some of the nuance between laws and bug bounties and
[03:44.380 --> 03:49.520]  vulnerability disclosure programs in this evolving landscape of anti-hacking laws.
[03:49.520 --> 03:54.400]  And it's a story that I shared a lot during the last few years. And I'm actually happy
[03:54.400 --> 04:00.700]  to report that we have seen, maybe also because Kevin went and shared this story,
[04:00.940 --> 04:05.740]  a lot of progress in this area. We have seen a lot of safe harbor adoptions and a lot of
[04:05.740 --> 04:12.220]  collaborations between companies and researchers. And even recently, it was announced this week,
[04:12.220 --> 04:18.380]  and maybe you have seen the draft CISA binding operative directive from CISA, which is the main
[04:18.380 --> 04:24.100]  federal cybersecurity authority that actually has also safe harbor language in it as well.
[04:24.100 --> 04:28.620]  So all of this is very exciting. And for me personally, because I did spend a lot of time
[04:28.620 --> 04:34.540]  on these issues between law and technology, and specifically this landscape for the last
[04:34.540 --> 04:39.320]  years in my prior work at Berkeley, before I joined Intel, promoting this framework for
[04:39.320 --> 04:44.660]  collaboration, it really is nice to see the growing adoption of safe harbor.
[04:45.440 --> 04:51.020]  One of my key takeaways from this kind of evolving interaction between law and technology
[04:51.660 --> 05:01.120]  is that laws are often basically evolving slower than technology. So we know that laws are slowly
[05:01.120 --> 05:06.480]  being amended. It's not like innovation that is rapidly being developed. And laws often have
[05:06.480 --> 05:14.400]  concepts like authorization or reasonable security or principles that are adapted with time. The
[05:14.400 --> 05:19.520]  reason I bring this example is that if you even consider the CFAA, again, this main anti-hacking
[05:19.520 --> 05:26.760]  law that I mentioned, and I'm sure many speakers are speaking about this law throughout DEF CON,
[05:26.760 --> 05:33.820]  it is a law from 1986, before the internet as we know it today. And much has changed,
[05:33.820 --> 05:39.520]  including hacking and security testing. And this year, the Supreme Court is going to actually take
[05:39.520 --> 05:45.540]  one of the first court cases on this issue of authorization. And we will see how that will
[05:45.540 --> 05:51.940]  evolve. But it just shows kind of how the laws are adapting to technology but are often behind.
[05:51.940 --> 05:56.360]  And I think this is one of the main takeaways that for you in the audience today from our talk
[05:56.360 --> 06:01.760]  is we're going to look at this landscape from both a policy and both from a technical perspective,
[06:01.760 --> 06:07.460]  and we're going to see how things are fitting together. So I shared a little bit about my
[06:07.460 --> 06:15.300]  background. Towards this week at DEF CON, a lot has been talked about in terms of disclosed I.O.
[06:15.300 --> 06:20.240]  and bug bounty. You can check out my prior work in this area. But I'm very passionate about this
[06:20.240 --> 06:27.520]  issue of collaboration between researchers and hackers and companies. And while I am a lawyer
[06:27.520 --> 06:32.780]  and my background is legal, I'm not your lawyer. And today I'm going to be talking about my own
[06:32.780 --> 06:37.460]  personal opinion and I'm not going to be providing any legal advice. So I know this is a little bit
[06:37.460 --> 06:44.340]  of fine print. You would probably expect that from me, right? But it is exciting. And, you know,
[06:44.340 --> 06:48.360]  if I need to complement kind of the prior discussion, I am also very excited to share
[06:48.360 --> 06:54.760]  that we at Intel, which I've recently joined, we do have a safe harbor in a bug bounty program,
[06:54.760 --> 06:58.780]  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:03.600]  but also know that we have that language in our bug bounty. And with that, I spoke a lot about
[07:03.600 --> 07:10.020]  collaboration. I spoke about why this is important as we think about technology and laws and how they
[07:10.020 --> 07:16.080]  go together. So I want to invite my fearless collaborator, Anait, to tell us a little bit
[07:16.080 --> 07:23.280]  what it is in the evolving attack landscape and particularly the IoT ecosystem that is
[07:23.280 --> 07:29.520]  sparking all this conversation around IoT proposed regulations and policies. Anait, please take it
[07:29.520 --> 07:36.680]  away. Thanks, Amit. Indeed, it's a great collaboration. So hi, folks. Very glad to be
[07:36.680 --> 07:44.200]  here. And as Amit said, I work directly on product definition side. So today we are talking about
[07:44.200 --> 07:49.960]  security and regulation policies, right? And being on the receiving side of the regulatory
[07:49.960 --> 07:55.580]  guidelines inside Intel, I spent time understanding and assessing the technical
[07:56.120 --> 08:01.880]  implication. So first, I would like to start looking at the concern that triggers this rising
[08:01.880 --> 08:12.560]  regulatory effort. And one of the key IoT security issue is the expanded attack surface. And that's
[08:12.560 --> 08:19.060]  due to the increased number of the endpoint devices. So we all see this futurescape that predict
[08:19.060 --> 08:25.580]  billions of devices with trillions of sensors. This large number of IoT devices that being
[08:25.580 --> 08:33.300]  brought into the business triggers the growth of attack. Another issue is the sophistication
[08:33.300 --> 08:40.460]  and evolving of the intent. It is clear that the attack target is not limited to the assets of IoT
[08:40.460 --> 08:48.500]  device only. IoT device exposure opens a plethora of opportunity across the edge to cloud and
[08:48.500 --> 08:56.720]  exposes a lot of valuable assets. So let's analyze the genealogy of the IoT attacks.
[09:00.020 --> 09:08.800]  So what you see here is typical IoT solution that spans edge to cloud. So IoT device control
[09:08.800 --> 09:15.260]  other devices in the system and itself, they being controlled by others in the edge to cloud
[09:15.260 --> 09:22.060]  solution. This duality exposes enormous challenges for the security community and adds new dimension
[09:22.060 --> 09:29.180]  to the system cybersecurity controls. Attacks that originate on the very left side at the edge
[09:29.180 --> 09:36.000]  easily can propagate throughout the entire pipeline and single device can jeopardize the
[09:36.000 --> 09:45.420]  entire solution. One notorious example of this type of scenario is a casino fish tank attack.
[09:46.190 --> 09:53.820]  I don't know how many of you are aware of that story. But just a quick recap.
[09:57.510 --> 10:02.710]  So using a trivial vulnerability in a smart thermometer in fish tank,
[10:02.710 --> 10:09.170]  hackers gained access to casino network. They retrieved data about high paying customers and
[10:09.170 --> 10:15.990]  then extracted that data through the thermostat and to the cloud and a result of it, 10 gigabyte
[10:15.990 --> 10:22.930]  of data ended up in Finland. This looks like a Hollywood ready story, perfect for ocean trilogy
[10:22.930 --> 10:29.930]  sequel. But from our perspective, this just proves the point that the simple device, in this case,
[10:29.930 --> 10:37.450]  the thermometer, can break down the very tough protected end-to-end solution.
[10:38.290 --> 10:43.330]  With that many new devices already deployed and even more on the way,
[10:43.330 --> 10:48.430]  it is important to consider the unique challenges in IoT space.
[10:48.970 --> 10:55.970]  And first, let's look at the technical side of it. So IoT business world is different from
[10:55.970 --> 11:02.510]  traditional well-established and structured PC environment, cloud environment. There are
[11:02.510 --> 11:08.650]  several factors that contribute to the technical and business challenges in our world.
[11:09.510 --> 11:16.310]  It's a diversity of distinct market segment and the business model. So very range of the,
[11:16.310 --> 11:23.210]  very wide range of the use cases that we are dealing with. IoT usages need to meet
[11:23.210 --> 11:31.410]  stringent power performance and form factor requirements. Another challenge is the complex
[11:31.410 --> 11:38.810]  ecosystem. There are many entities involved in defining finished and customer usable product.
[11:38.890 --> 11:45.130]  Another distinction is the wide range of the software and firmware, which includes OS,
[11:45.130 --> 11:49.310]  hypervisors, bootloaders, right? Of course, application and all the workloads that run
[11:49.310 --> 11:56.770]  on top of it. Heterogeneity of the installed base in that end-to-end solution is also a pretty
[11:56.770 --> 12:07.270]  unique factor. IoT is a mix of the green and brown field devices. And on top of it comes the icing.
[12:07.470 --> 12:13.610]  IoT needs to be supported over extended lifetime, which is much longer than traditional PC
[12:14.550 --> 12:20.710]  service. All these challenges become contributing factors to vulnerability of IoT devices and
[12:20.710 --> 12:27.630]  introducing security risk. Those are the concerns that actually triggered and got reflected in the
[12:27.630 --> 12:33.770]  policy arena. And here I would like to ask Amit, please share your insights from the regulatory
[12:33.770 --> 12:41.470]  guideline perspective. Thank you so much, Anet. And you're exactly right. When it comes to the
[12:41.470 --> 12:46.670]  evolving policy and regulatory sphere, the complexities that we're seeing in terms of
[12:46.670 --> 12:53.310]  the various business model and the technical verticals also influence what are some of the
[12:53.310 --> 12:59.650]  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:12.270]  One of the interesting things is this idea of having the risk-based approach. This is, by the
[13:12.270 --> 13:18.730]  way, an underlying principle for all security policy. But particularly in IoT, it's important.
[13:18.730 --> 13:26.290]  Why? Because we have that horizontal but yet very versatile environment of devices, right?
[13:26.290 --> 13:33.010]  Everything from the low-cost business model of the dog collar, if you will, to the sensitive
[13:33.010 --> 13:39.910]  devices being deployed in critical infrastructure, election system, medical devices, and the like.
[13:39.910 --> 13:46.550]  So with that diversity of technical systems, business models, economic consideration,
[13:46.910 --> 13:53.730]  considering the risk of the device, not just in terms of which vertical and sector it goes into,
[13:53.730 --> 13:59.610]  but what is the environment, what is the unique attack surface the device is being deployed in
[13:59.610 --> 14:06.050]  from various kind of standpoints? That's one of the ideas when you think about the proposed
[14:06.050 --> 14:12.510]  regulations, that the requirements should apply based on a risk-based approach. And you as
[14:12.510 --> 14:17.710]  researchers should expect a lot more standards and thinking. This is already an established
[14:17.710 --> 14:25.690]  principle in the security community and also in IoT, for example, 62443 IEC, but you should expect
[14:25.690 --> 14:31.370]  more and more thinking and principles and standards around in this area. What more? Definitely the
[14:31.370 --> 14:37.750]  regulatory environment should consider how to support innovations. A lot of these problems
[14:37.750 --> 14:43.330]  are going to be solved by technology and we need to incentivize the development of innovation
[14:43.330 --> 14:49.010]  and consider the fact that proposed regulations might hinder innovation if they're not framed
[14:49.010 --> 14:55.350]  correctly. Interoperability. So this is a key issue. We need to think about how the IoT devices
[14:55.350 --> 15:02.070]  are working together. How can we foster the secure deployment that is interoperable for IoT devices
[15:02.070 --> 15:08.930]  and also how IoT devices are connecting edge to cloud with OT environments, with other environments.
[15:08.930 --> 15:14.610]  All of that is putting interoperability in the kind of front. And here this idea of leveraging
[15:14.610 --> 15:23.310]  international standards that are scalable, that are developed globally at forums like CTA, ISO, IEC,
[15:23.310 --> 15:30.130]  JTC1, Etsy and the like, that is also very critical because as you know, technology knows no
[15:30.130 --> 15:36.730]  boundaries. The deployment of IoT is obviously a global phenomenon, but the supply chain
[15:36.730 --> 15:42.110]  of technology is global in its nature. So we want to avoid fragmented regulation or some kind of
[15:42.110 --> 15:47.810]  requirements that are really localized because that's not scalable when you think about manufacturers
[15:47.810 --> 15:53.670]  that are, and the supply chain that are globally, that are global in their nature. Another key
[15:53.670 --> 16:00.350]  principle that is not unique just by the way for IoT but is really important for IoT is this idea
[16:00.350 --> 16:06.190]  of design neutrality. That laws and regulations, because they usually adapt, they usually are
[16:06.190 --> 16:15.530]  amended very slowly, they always walk slower than technology, should not bake into the legislative
[16:15.530 --> 16:22.290]  language a specific design or a specific requirement that might become outdated or even
[16:22.290 --> 16:28.470]  terms, 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:39.950]  And with all of that, I think a lot of regulators around the world and policymakers are recognizing
[16:39.950 --> 16:45.950]  the need to consider IoT as part of the broader ecosystem and enable private-public partnerships.
[16:45.950 --> 16:52.490]  So I spoke a lot about the principles, but let's dive in. Let's look at a few examples of what is
[16:52.490 --> 16:57.650]  really kind of cutting edge in terms of proposed regulation in IoT around the world. Now, this is
[16:57.650 --> 17:03.930]  just an example. I'm going to walk you through more domains, but this is super interesting. It's
[17:03.930 --> 17:10.070]  coming from the UK. Some of you may have heard about this in the past. I believe it's since 2018,
[17:10.070 --> 17:16.150]  the UK, with their leadership, have put together an IoT security code of practice with 13
[17:16.150 --> 17:22.530]  requirements. They've taken that effort a step farther, and now they're considering a law,
[17:22.670 --> 17:27.710]  a regulation. This is, I believe, the third consultation already they are publishing
[17:28.350 --> 17:35.710]  for this regulation. And by the way, now they're also considering to encompass PCs and laptops
[17:35.710 --> 17:40.210]  as part of their regulation. They're really looking at three core requirements that are
[17:40.210 --> 17:47.730]  proposed. The first one is around this issue of not having default password and having unique
[17:47.730 --> 17:53.790]  authentication. This concept is one that we have seen in other regulations around the world.
[17:53.790 --> 18:00.590]  If you look at the prior consultations, they say explicitly how they were motivated by the Mirai
[18:00.590 --> 18:05.710]  attack. So you see the connection between the attack surface, the attack, and then the
[18:05.710 --> 18:11.430]  regulators are considering action. The second requirement is around an issue which is very
[18:11.430 --> 18:18.250]  close to heart to this community, having the public point of contact as part of a vulnerability
[18:18.250 --> 18:25.810]  disclosure policy or program to allow researchers like you to submit vulnerabilities to the
[18:25.810 --> 18:31.570]  manufacturer and have the manufacturer address the vulnerabilities. The third point which is
[18:31.570 --> 18:37.050]  proposed is around this issue of support of security updates. By the way, they're also
[18:37.050 --> 18:42.870]  referencing a standard, a technical standard, they have been developing as part of a broader consensus
[18:42.870 --> 18:50.270]  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:08.470]  Everything from state laws, actually in Oregon and California we have laws already in effect
[19:08.470 --> 19:15.470]  from January 2020 on connected devices, looking at this issue of reasonable security for connected
[19:15.470 --> 19:21.270]  devices and they have some language there as well on the issue of authentication means and unique
[19:21.270 --> 19:27.850]  authentication. We also have proposed federal laws. So this is very interesting. In the United States
[19:27.850 --> 19:34.610]  there has been a number of proposed federal laws for all the United States on this issue of IoT
[19:34.610 --> 19:41.010]  security. One of them is the IoT Cybersecurity Improvement Act that has been proposed for a while,
[19:41.010 --> 19:48.390]  looking at leveraging federal procurement of IoT devices with requirements for all devices going
[19:48.390 --> 19:54.730]  into federal procurement as a way to foster security of devices in all domains. We have also
[19:54.730 --> 20:02.850]  seen a recent COVID white paper from the Cyberspace Solarium Commission proposing that we should have
[20:02.850 --> 20:10.150]  all the market IoT federal U.S. law, so certainly an emerging area. We also have best practices and
[20:10.150 --> 20:14.770]  standards. Okay, so this particular area is of particular interest and we're going to
[20:14.770 --> 20:21.170]  dive in into the requirements or at least the consensus around what are some kind of the
[20:21.170 --> 20:27.330]  foundational capabilities of IoT devices. This is an effort to bring all of industry together,
[20:27.330 --> 20:32.210]  both at the international level, so that's at ISO, I'm an editor of one of the standards there,
[20:32.210 --> 20:40.270]  but both in the U.S. with efforts like NISTOR 8259, that by the way is also referenced on the left in
[20:40.270 --> 20:44.410]  the COVID white paper of the Cyberspace Solarium Commission, so you see the interaction between
[20:44.410 --> 20:50.470]  the efforts. What's of particular interest for this community is that these are really technical
[20:50.470 --> 20:57.830]  documents, they are horizontal, they reflect the consensus of all of industry, and they might shape
[20:57.830 --> 21:04.350]  the future of both research and market demand in this area. We have also seen, based on kind
[21:04.350 --> 21:12.050]  of these efforts of overall horizontal kind of trends, sector-specific requirements. So
[21:12.850 --> 21:20.570]  for example, NIST has created and worked together on building consensus around NISTOR 8259,
[21:20.570 --> 21:25.770]  which is always central to all the market. Now they've also released a draft on GitHub,
[21:25.910 --> 21:32.810]  a federal profile of these requirements, that is in particular for the federal government
[21:33.450 --> 21:39.930]  sector, so what goes under FISMA to federal agencies for that particular sector. In addition,
[21:39.930 --> 21:44.910]  of course, this is not just in the U.S., I've showed the example from the U.K., we have seen
[21:44.910 --> 21:51.190]  around the world attention to these issues with governments like Australia and the U.K. proposing
[21:51.190 --> 21:56.590]  code of practices for IoT. Australia, in their recent announcement of what they're going to do
[21:56.590 --> 22:01.990]  in terms of cybersecurity policy, they have a segment on IoT there. Of course, in Europe, a big
[22:01.990 --> 22:09.130]  conversation around attestation, certification, and INISA is definitely also thinking about IoT.
[22:09.390 --> 22:14.690]  So this is a global phenomenon, and we have seen leadership also from countries like Japan
[22:15.570 --> 22:20.830]  proposing risk-based frameworks for IoT, so definitely of interest for regulators and
[22:20.830 --> 22:25.530]  policymakers around the world. So finally, I talked about international standards and their
[22:25.530 --> 22:32.090]  importance, how they've been developed in this area. We have seen two interesting also, I would
[22:32.090 --> 22:37.590]  say, trends that go together with IoT. One of them is supply chain prosperity. This is, of course,
[22:37.750 --> 22:44.530]  a big theme in the area of security policy, but in particular, it's connected with IoT. So those
[22:44.530 --> 22:51.990]  of you who are long-term DEF CON attendees, or besides Las Vegas attendees, or just otherwise
[22:51.990 --> 22:57.950]  might have seen talks from Alan Friedman on the initiative called the SBOM, the Software Bill of
[22:57.950 --> 23:03.150]  Materials. So this is this idea that you should have transparency into the ingredients of the
[23:03.150 --> 23:08.990]  software, and that transparency into the ingredients can support the other capabilities like updates
[23:08.990 --> 23:14.690]  and the like. In this area, we also are getting to have some solutions around compute life cycle
[23:14.690 --> 23:19.630]  assurance. Another trend that we have seen is the coordinate vulnerability disclosure trend that
[23:19.630 --> 23:26.210]  goes together with IoT. So by that, I mean regulators and policymakers are also recognizing
[23:26.210 --> 23:32.410]  the need to leverage the ecosystem, the need to have that collaboration to address the issues,
[23:32.410 --> 23:38.590]  and they are coupling together with proposed reports and regulations and best practices,
[23:38.590 --> 23:43.810]  this idea of having a process to receive vulnerabilities from the external community,
[23:43.810 --> 23:49.630]  and you have seen the example from the UK, and to handle the vulnerabilities internally. So
[23:49.630 --> 23:56.450]  bottom line, a lot of evolving kind of proposed, a lot of evolving kind of initiatives with
[23:56.450 --> 24:02.750]  relationships between them, some are horizontal, some are sector-specific, and a bleed towards
[24:02.750 --> 24:09.650]  other areas of security policy. Now we're going to drill down into this NISTR, which is this
[24:09.650 --> 24:17.190]  consensus-driven best practice. This is not a regulation or a requirement per se, but it's a
[24:17.190 --> 24:22.890]  consensus effort that is of interest for this community. You can see here on the left the C2
[24:22.890 --> 24:27.130]  effort by the Council to Secure the Digital Economy, and all the different trade associations
[24:27.130 --> 24:33.270]  really spanning the entire technology sector that have come together to define this consensus.
[24:33.270 --> 24:38.290]  Anaita, I would like to invite you to present to us with more detail the technical elements that
[24:38.290 --> 24:47.370]  are explored in the NISTR. Thanks, Amit. So yeah, you heard a lot about NISTR at the magic 8259
[24:47.370 --> 24:54.770]  number, right? Let's take a closer look at what it is, what is the motivation and objective. As this
[24:54.770 --> 25:01.190]  effort very well exemplifies what's happening in regulatory momentum. So what is this about?
[25:01.710 --> 25:08.950]  8259 targets manufacturers. Specifically, the subject of this recommendation is framed around
[25:08.950 --> 25:15.710]  the finished IoT devices. It provides the recommendation on cyber security activities
[25:15.710 --> 25:23.330]  and capabilities to address customers' cyber security needs. So NISTR publication proposes
[25:23.330 --> 25:31.330]  to normalize the manufacturer-customer relationship by leveraging the laws, regulations, and guidelines.
[25:31.330 --> 25:39.490]  Let me set the expectations right. So 8259 is intended to address a very broad range of IoT
[25:39.490 --> 25:46.550]  devices, from tiny little doorknobs to very complex critical infrastructure class of devices.
[25:46.550 --> 25:53.610]  So expect to see what I would call it lowest common denominator. However, this is setting the
[25:53.610 --> 26:01.450]  trend, right? It's also important to note that all other parts of the IoT ecosystem, other than IoT
[26:01.450 --> 26:09.270]  device itself, are outside of scope of this NISTR recommendation. So overall, this is the first step
[26:09.270 --> 26:16.450]  towards the making the IoT security more measurable. It is expected that eventually more
[26:16.450 --> 26:22.610]  guidelines will be developed to address that out-of-scope problems, as well as more specific
[26:22.610 --> 26:28.030]  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:42.890]  So NIST emphasizes the message that IoT security shall start early on. So let's look at their
[26:42.890 --> 26:50.150]  recommended actions. Again, remember, this is all about manufacturers. It is proposed that
[26:50.150 --> 26:56.990]  IoT device manufacturers need to perform this action and provide the services to their customers
[26:56.990 --> 27:04.410]  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:18.910]  The first two activities assume that manufacturers have to have the full disclosure on device usages
[27:18.910 --> 27:24.590]  and the security goals. This might be quite challenging, actually, as there are many cases
[27:24.590 --> 27:31.810]  that we know when customers and manufacturers don't have that good collaboration. As a result,
[27:31.810 --> 27:36.470]  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:49.670]  These capabilities are defined by NISTR 8259a and supposed to address what customers would
[27:49.670 --> 27:56.510]  need to achieve their goals and fulfill their requirement. This is the most technically loaded
[27:56.510 --> 28:05.190]  proposal in this recommendation. Activity number four addresses the support. So manufacturers
[28:05.190 --> 28:11.850]  should consider all the resources required to support development and continued support of
[28:11.850 --> 28:20.430]  the IoT device. That includes security code practices, vulnerability disclosures,
[28:20.430 --> 28:27.570]  vulnerability responses, and floor remediation. Post-market, there are activities five and six,
[28:27.570 --> 28:33.690]  and those are related to customer communication. Although I would call that really post-market,
[28:33.690 --> 28:39.670]  as planning on how to address these activities needs to be baked in at very early stage of the
[28:39.670 --> 28:45.050]  design of the product. There are several potential considerations listed in the publication for
[28:45.050 --> 28:52.330]  this stage. Some of them are the lifespan expectation, the software update, device
[28:52.330 --> 28:59.130]  retirement, and end of life. The main takeaway here, so NIST attempts to frame the security
[28:59.130 --> 29:07.170]  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:22.110]  So now let's see what are those core capabilities and drill down here. This baseline represents
[29:22.110 --> 29:28.670]  the industry-wide collaboration effort that Amit mentioned earlier, as a result of which
[29:28.670 --> 29:35.490]  definition of common capabilities were produced. And the common is the key word here. This is not
[29:35.490 --> 29:41.670]  exhaustive lips. Remember the lost denominator? This is starting point that set the direction.
[29:41.670 --> 29:48.690]  Therefore, in each implementing organization, you may find the superset
[29:48.690 --> 29:55.630]  capabilities that better fit their needs. 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:32.700]  Software updates recommends that, again, the update needs to be done in supervised manner,
[30:32.700 --> 30:41.500]  updated only by authorized entities. And last one here is the cyber security state awareness.
[30:41.500 --> 30:47.660]  So this capability is about the ability of IoT device to report its own cyber security state
[30:47.660 --> 30:54.740]  and make that information accessible to authorized entities. So this was just a quick run
[30:54.740 --> 31:00.160]  through these capabilities. There are many nuances to this baseline. So I would recommend
[31:00.160 --> 31:08.720]  reading through NISTers 82598 document directly. And at this point, let's change the gear and look
[31:08.720 --> 31:16.420]  on what's left outside of out of the NIST scope. So we did talk about the complexity of the
[31:16.420 --> 31:24.140]  ecosystem. So NIST simplified the ecosystem model just to two entities. And we at Intel realized
[31:24.140 --> 31:30.340]  that truly deployable IoT solution require more complex relationship. When we think about Intel,
[31:30.340 --> 31:37.980]  we think about Silicon, which would be very left of this picture. It is our partner ecosystem that
[31:37.980 --> 31:46.020]  builds out the rest of the story. So the analogy that we like to use a lot is the orchestra playing
[31:46.020 --> 31:52.800]  together. So each player has a critical role in delivering finished symphony to the audience.
[31:52.800 --> 32:02.080]  And the value chain in case of IoT device goes from the ingredient to manufacturers, OEM, ODM,
[32:02.080 --> 32:08.960]  then through the ISVs, cloud service providers, solution integrators, and then only get delivered
[32:08.960 --> 32:16.860]  to the end users. So all these artists participate in the security baseline definition
[32:16.860 --> 32:25.540]  and implementation. But there is also the life after the deployment, right? The device goes to
[32:25.540 --> 32:33.200]  the circular stages of the updates. And again, manufacturers, they have to rely on the rest of
[32:33.200 --> 32:42.840]  the ecosystem to deliver the updates. So what do we do? So we realized that it's not an Intel
[32:42.840 --> 32:48.580]  universe, so we have to work with the broad ecosystem. And we established the partnership.
[32:48.600 --> 32:55.360]  So IoT Solution Alliance is our partnership framework. It covers 6,000 solutions, includes
[32:55.360 --> 33:02.300]  more than 500 members, and of course, we work across the globe throughout our global platform.
[33:02.300 --> 33:08.540]  As Amit mentioned, this is very important from the regulatory perspective, the global interaction in
[33:08.540 --> 33:16.220]  the policy space. So our member companies, they span the globe and offer local expertise in
[33:16.220 --> 33:22.960]  market worldwide. This is the community that we're closely collaborating on security as well.
[33:22.960 --> 33:30.480]  And for the security discussion, it's important to establish the common ground, attack surfaces
[33:30.480 --> 33:37.640]  and threats is that the common ground that we use to build the collaboration. So let's take a look
[33:37.640 --> 33:46.420]  to this table. The attack surface sums up all the penetration points, otherwise known as
[33:46.420 --> 33:52.440]  attack vectors. So a summary of exploitable vulnerabilities at device level. So we are
[33:52.440 --> 33:58.260]  looking now at the device level is presented in this table, where different threats on the right
[33:58.260 --> 34:06.180]  side are correlated with respective attack surfaces and components on the left side.
[34:06.180 --> 34:13.340]  Moving from bottom up, you see the hardware layer, right? And then above it is the firmware
[34:13.340 --> 34:21.220]  optional hypervisor when virtual machine monitor and then the operating system. And finally,
[34:21.220 --> 34:30.560]  this user space where the application or workloads will be running. The attacks in the top layers
[34:30.560 --> 34:37.980]  have been prevalent and known for quite some time already. But attacks are more and more
[34:37.980 --> 34:44.400]  moving down the stacks, exploiting vulnerabilities all the way to the firmware and the hardware
[34:45.140 --> 34:53.320]  layers as well, which could potentially give even more interesting opportunities,
[34:53.320 --> 35:00.400]  higher privileges on the devices as well as those attacks can go fairly undetected.
[35:00.560 --> 35:08.480]  So let's take an example. So by tampering with the firmware, it might be possible to subvert
[35:08.480 --> 35:16.560]  the entire boot, right? And boot the operating system, which would be attacker's choice, right?
[35:16.560 --> 35:25.180]  The desired operating system. This table overall is an eye chart, but I think the main takeaway
[35:25.180 --> 35:31.600]  here is that the attacks are not singular, right? It's a multi-dimensional problem and spans across
[35:31.600 --> 35:39.120]  the entire stack of IoT device and requires the protection mechanism at each layer as well.
[35:39.120 --> 35:45.500]  So having this framework allows us to systematically analyze the security solution
[35:45.500 --> 35:53.740]  to mitigate the risk from the very early stage of our product design phase. And we work with
[35:53.740 --> 36:01.220]  our customer based on this taxonomy. And we do provide, of course, solutions and innovate the
[36:01.220 --> 36:09.520]  hardware-based security technology in our product to build the defense in depth from the bottom up
[36:09.520 --> 36:19.120]  and withstand the attack propagation. But, Amit, it's not only about our own innovation and our
[36:19.120 --> 36:26.380]  own technologies, right? So can you share your thoughts about how this evolving attack surfaces
[36:27.040 --> 36:36.180]  can drive a greater collaboration with technologists? Yes, absolutely. And I think, Amit,
[36:36.180 --> 36:42.400]  you're exactly right. I think you've seen throughout this presentation so much of the complexity that
[36:42.400 --> 36:48.480]  is pretty unique for the IoT ecosystem. And this is the vertical business model, the versatile devices
[36:48.480 --> 36:53.880]  from everything from the dog collar to the sensitive systems, the type of the attacks and
[36:53.880 --> 37:00.200]  how the attack surface is evolving, and also the technical challenges, right? And Amit
[37:00.880 --> 37:06.980]  definitely provided a very extensive overview of this. All of this suggests that this issue is not
[37:06.980 --> 37:12.220]  just going to be solved through the innovations, through the security capabilities that we are
[37:12.220 --> 37:17.960]  going to bake into hardware and software and firmware. Yes, that is a critical piece of the
[37:17.960 --> 37:26.640]  discussion. Yes, incentivizing the innovation, the R&D, the research, the pipeline, all of that is
[37:26.640 --> 37:32.300]  critical, but we are still going to need the collaboration. And by collaboration, I mean
[37:32.860 --> 37:38.360]  companies working with researchers, enabling the ecosystem, right? Collaboration between the
[37:38.360 --> 37:44.340]  different verticals in the supply chain. Also collaborations between policymakers and legislators
[37:44.340 --> 37:50.520]  and regulators as they're thinking about these issues between the public and the private industry
[37:50.520 --> 37:57.780]  and having your expertise, the expertise of the crowd in these arenas as well, engaging in
[37:57.780 --> 38:04.640]  that dialogue. And I think we have seen tremendous developments in that area. I think the safe harbor
[38:04.640 --> 38:10.860]  kind of discussion is one of them. We have seen also growing collaboration and a lot of thinking
[38:10.860 --> 38:16.680]  that goes into researcher relations. I don't know if you've seen some of my peers from PSIRT and
[38:16.680 --> 38:22.120]  from Intel Security at the Red Team Village or in this village talking about how we collaborate with
[38:22.120 --> 38:27.940]  the ecosystem, how we are funding academic researchers in this area. All that is critical.
[38:27.940 --> 38:32.340]  So as we are thinking about this kind of conversation, it's really critical to get
[38:32.340 --> 38:40.700]  the dialogue going. And with that particular recommendation, I would like to invite you all
[38:40.700 --> 38:47.460]  to ethically hack us. We do have a bug bounty. It's a public bug bounty. We offer rewards. You
[38:47.460 --> 38:52.420]  can check it out. You can check out the scope. We also have a vulnerability disclosure program.
[38:52.420 --> 38:57.120]  You can report vulnerabilities to us. The collaboration with the researcher community
[38:57.120 --> 39:03.640]  is extremely important to us. And we work with the entire ecosystem to drive security first.
[39:03.780 --> 39:09.540]  So security at Intel.com, please report your vulnerabilities. Please continue the great work
[39:09.540 --> 39:16.580]  and research in the embedded system arena, especially this village is dear to heart for us.
[39:16.580 --> 39:21.620]  And let's continue the conversation. And we would like to welcome your questions. I did
[39:21.620 --> 39:27.820]  went through in a true Israeli fashion and a little bit of my style. My sister always tells
[39:27.820 --> 39:33.880]  me to slow down. I went through a lot of examples when I was talking. And I will provide you the
[39:33.880 --> 39:40.060]  links to all of these resources that I've talked about and Ana shared as well in the Discord chat.
[39:40.180 --> 39:45.300]  So this is just a little bit of preview. Please join us in the Discord if you want to get all
[39:45.300 --> 39:49.720]  the details and all the information about what we shared with you today. You can find it there as
[39:49.720 --> 39:55.660]  well. And we'd like to continue the conversation with you. Ana, for me, this has been a great
[39:55.660 --> 40:01.680]  collaboration. The former hacker that I collaborated with in a talk is my sister,
[40:01.680 --> 40:06.260]  Karen. I hope to continue that collaboration. Maybe she is here with us in the audience.
[40:06.260 --> 40:13.640]  Karen, I haven't forgotten you, of course. But this has been a really joyful dialogue for me.
[40:13.640 --> 40:17.680]  Thank you so much. Anything to share from your perspective, Ana, before we wrap it up?
[40:17.680 --> 40:25.100]  No, this is a great journey. And this is a great example of collaboration. Again, I am on the
[40:25.100 --> 40:31.200]  technology side. I'm on the product side. 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:46.480]  So collaboration is the key. And thank you very much. We are looking to hear from you.