start	end	text
0	5180	Thank you so much. And I just love this village. You know, I have been coming to this village,
5180	11860	I think it is three years in a row. And I do miss DEF CON a lot. And some of you know my sister,
11860	18280	Karen Elazari, I often go to DEF CON with her and we definitely miss that experience. But I am
18280	24740	very excited to be here with you today. And today I'm also joined with a really good colleague of
24740	32820	mine, Anait, she is a spectacular engineer from the IoTG business unit with us. And we're going
32820	38560	to be talking with you today on this evolving landscape of baseline standards and regulation.
38560	42760	So first of all, let me check again. Can you all hear us great, Sam, Tim?
43460	44800	Yep, we can.
44900	52680	Wonderful. Well, as Sam shared, we are both from Intel. I work in the government's relation team
52680	57980	at Intel within the legal department. I work with governments around the world and policymakers
58520	63060	on issues of security policy. And I also lecture at the UC Berkeley School of Information,
63060	70200	where I teach in the Master in Cybersecurity program. And as many of you know, I'm also Israeli.
70320	75960	And usually when I come to this village, I start with a direct question. So let me do it again.
76140	81620	By now, most of you should be familiar with this face. And I hope you know him. This is Kevin
81620	87900	Finster. He's a researcher. And like many of you in the audience, he is also focused on embedded
87900	95940	systems. And specifically, he has a love and passion towards drones. And he has conducted
95940	103340	research on DJI, one of their drone systems, and he found the vulnerability that, according to him,
103340	108780	leaked personal information. And he wanted to report that vulnerability to DJI and, you know,
108780	116180	do the right thing and engage in disclosure. And at the time, DJI just launched their bug bounty
116180	122900	program with this media announcement, inviting the community, inviting the ecosystem to report
122900	131440	vulnerabilities to them. And, you know, it was not really clear what was the scope, according to the
131440	137460	reports. There wasn't really a bug bounty policy or contract. And there was some confusion between
137460	144040	the parties on this issue of the scope, according to the reports. So Kevin contacted DJI and asked
144040	151220	them, is this vulnerability that I found is in scope? And they, in fact, according to the reports,
151220	157620	suggested it is in scope. Not only that, they said that they would like to pay him $30,000
157620	164820	for that vulnerability. So for those of you engaged in bug hunting, just empirically speaking,
165380	172380	that's a pretty high bounty. And then the plot thickened. So there are two sides to this story,
172380	178620	and I encourage you to check out the links in the bottom. But Kevin felt that during the negotiation
179420	184960	on issues of disclosure, there were some issues that were unclear, again, because we didn't have
184960	190560	that scope and website. And then the plot thickened. And then in the draft letter mentioning
190560	196180	the Computer Fraud and Abuse Act, which is the main anti-hacking law here in the United States,
196180	202260	together with the DMCA, was mentioned, according to the reports in that letter. And Kevin ended up
202260	209420	walking away from this approved bug bounty of $30,000 and sharing on Twitter his version of
209420	217980	the story. And, you know, he did order a Tesla. He ended up canceling that order of a Tesla.
217980	224380	And it's just a story highlighting some of the nuance between laws and bug bounties and
224380	229520	vulnerability disclosure programs in this evolving landscape of anti-hacking laws.
229520	234400	And it's a story that I shared a lot during the last few years. And I'm actually happy
234400	240700	to report that we have seen, maybe also because Kevin went and shared this story,
240940	245740	a lot of progress in this area. We have seen a lot of safe harbor adoptions and a lot of
245740	252220	collaborations between companies and researchers. And even recently, it was announced this week,
252220	258380	and maybe you have seen the draft CISA binding operative directive from CISA, which is the main
258380	264100	federal cybersecurity authority that actually has also safe harbor language in it as well.
264100	268620	So all of this is very exciting. And for me personally, because I did spend a lot of time
268620	274540	on these issues between law and technology, and specifically this landscape for the last
274540	279320	years in my prior work at Berkeley, before I joined Intel, promoting this framework for
279320	284660	collaboration, it really is nice to see the growing adoption of safe harbor.
285440	291020	One of my key takeaways from this kind of evolving interaction between law and technology
291660	301120	is that laws are often basically evolving slower than technology. So we know that laws are slowly
301120	306480	being amended. It's not like innovation that is rapidly being developed. And laws often have
306480	314400	concepts like authorization or reasonable security or principles that are adapted with time. The
314400	319520	reason I bring this example is that if you even consider the CFAA, again, this main anti-hacking
319520	326760	law that I mentioned, and I'm sure many speakers are speaking about this law throughout DEF CON,
326760	333820	it is a law from 1986, before the internet as we know it today. And much has changed,
333820	339520	including hacking and security testing. And this year, the Supreme Court is going to actually take
339520	345540	one of the first court cases on this issue of authorization. And we will see how that will
345540	351940	evolve. But it just shows kind of how the laws are adapting to technology but are often behind.
351940	356360	And I think this is one of the main takeaways that for you in the audience today from our talk
356360	361760	is we're going to look at this landscape from both a policy and both from a technical perspective,
361760	367460	and we're going to see how things are fitting together. So I shared a little bit about my
367460	375300	background. Towards this week at DEF CON, a lot has been talked about in terms of disclosed I.O.
375300	380240	and bug bounty. You can check out my prior work in this area. But I'm very passionate about this
380240	387520	issue of collaboration between researchers and hackers and companies. And while I am a lawyer
387520	392780	and my background is legal, I'm not your lawyer. And today I'm going to be talking about my own
392780	397460	personal opinion and I'm not going to be providing any legal advice. So I know this is a little bit
397460	404340	of fine print. You would probably expect that from me, right? But it is exciting. And, you know,
404340	408360	if I need to complement kind of the prior discussion, I am also very excited to share
408360	414760	that we at Intel, which I've recently joined, we do have a safe harbor in a bug bounty program,
414760	418780	and we encourage you to not just engage with us, and we're going to talk a little bit about that,
418780	423600	but also know that we have that language in our bug bounty. And with that, I spoke a lot about
423600	430020	collaboration. I spoke about why this is important as we think about technology and laws and how they
430020	436080	go together. So I want to invite my fearless collaborator, Anait, to tell us a little bit
436080	443280	what it is in the evolving attack landscape and particularly the IoT ecosystem that is
443280	449520	sparking all this conversation around IoT proposed regulations and policies. Anait, please take it
449520	456680	away. Thanks, Amit. Indeed, it's a great collaboration. So hi, folks. Very glad to be
456680	464200	here. And as Amit said, I work directly on product definition side. So today we are talking about
464200	469960	security and regulation policies, right? And being on the receiving side of the regulatory
469960	475580	guidelines inside Intel, I spent time understanding and assessing the technical
476120	481880	implication. So first, I would like to start looking at the concern that triggers this rising
481880	492560	regulatory effort. And one of the key IoT security issue is the expanded attack surface. And that's
492560	499060	due to the increased number of the endpoint devices. So we all see this futurescape that predict
499060	505580	billions of devices with trillions of sensors. This large number of IoT devices that being
505580	513300	brought into the business triggers the growth of attack. Another issue is the sophistication
513300	520460	and evolving of the intent. It is clear that the attack target is not limited to the assets of IoT
520460	528500	device only. IoT device exposure opens a plethora of opportunity across the edge to cloud and
528500	536720	exposes a lot of valuable assets. So let's analyze the genealogy of the IoT attacks.
540020	548800	So what you see here is typical IoT solution that spans edge to cloud. So IoT device control
548800	555260	other devices in the system and itself, they being controlled by others in the edge to cloud
555260	562060	solution. This duality exposes enormous challenges for the security community and adds new dimension
562060	569180	to the system cybersecurity controls. Attacks that originate on the very left side at the edge
569180	576000	easily can propagate throughout the entire pipeline and single device can jeopardize the
576000	585420	entire solution. One notorious example of this type of scenario is a casino fish tank attack.
586190	593820	I don't know how many of you are aware of that story. But just a quick recap.
597510	602710	So using a trivial vulnerability in a smart thermometer in fish tank,
602710	609170	hackers gained access to casino network. They retrieved data about high paying customers and
609170	615990	then extracted that data through the thermostat and to the cloud and a result of it, 10 gigabyte
615990	622930	of data ended up in Finland. This looks like a Hollywood ready story, perfect for ocean trilogy
622930	629930	sequel. But from our perspective, this just proves the point that the simple device, in this case,
629930	637450	the thermometer, can break down the very tough protected end-to-end solution.
638290	643330	With that many new devices already deployed and even more on the way,
643330	648430	it is important to consider the unique challenges in IoT space.
648970	655970	And first, let's look at the technical side of it. So IoT business world is different from
655970	662510	traditional well-established and structured PC environment, cloud environment. There are
662510	668650	several factors that contribute to the technical and business challenges in our world.
669510	676310	It's a diversity of distinct market segment and the business model. So very range of the,
676310	683210	very wide range of the use cases that we are dealing with. IoT usages need to meet
683210	691410	stringent power performance and form factor requirements. Another challenge is the complex
691410	698810	ecosystem. There are many entities involved in defining finished and customer usable product.
698890	705130	Another distinction is the wide range of the software and firmware, which includes OS,
705130	709310	hypervisors, bootloaders, right? Of course, application and all the workloads that run
709310	716770	on top of it. Heterogeneity of the installed base in that end-to-end solution is also a pretty
716770	727270	unique factor. IoT is a mix of the green and brown field devices. And on top of it comes the icing.
727470	733610	IoT needs to be supported over extended lifetime, which is much longer than traditional PC
734550	740710	service. All these challenges become contributing factors to vulnerability of IoT devices and
740710	747630	introducing security risk. Those are the concerns that actually triggered and got reflected in the
747630	753770	policy arena. And here I would like to ask Amit, please share your insights from the regulatory
753770	761470	guideline perspective. Thank you so much, Anet. And you're exactly right. When it comes to the
761470	766670	evolving policy and regulatory sphere, the complexities that we're seeing in terms of
766670	773310	the various business model and the technical verticals also influence what are some of the
773310	779650	principles that the policymakers are considering as they're coming to proposed best practices,
779650	787490	reports, standard development, and laws and regulations and requirements in this area.
787490	792270	One of the interesting things is this idea of having the risk-based approach. This is, by the
792270	798730	way, an underlying principle for all security policy. But particularly in IoT, it's important.
798730	806290	Why? Because we have that horizontal but yet very versatile environment of devices, right?
806290	813010	Everything from the low-cost business model of the dog collar, if you will, to the sensitive
813010	819910	devices being deployed in critical infrastructure, election system, medical devices, and the like.
819910	826550	So with that diversity of technical systems, business models, economic consideration,
826910	833730	considering the risk of the device, not just in terms of which vertical and sector it goes into,
833730	839610	but what is the environment, what is the unique attack surface the device is being deployed in
839610	846050	from various kind of standpoints? That's one of the ideas when you think about the proposed
846050	852510	regulations, that the requirements should apply based on a risk-based approach. And you as
852510	857710	researchers should expect a lot more standards and thinking. This is already an established
857710	865690	principle in the security community and also in IoT, for example, 62443 IEC, but you should expect
865690	871370	more and more thinking and principles and standards around in this area. What more? Definitely the
871370	877750	regulatory environment should consider how to support innovations. A lot of these problems
877750	883330	are going to be solved by technology and we need to incentivize the development of innovation
883330	889010	and consider the fact that proposed regulations might hinder innovation if they're not framed
889010	895350	correctly. Interoperability. So this is a key issue. We need to think about how the IoT devices
895350	902070	are working together. How can we foster the secure deployment that is interoperable for IoT devices
902070	908930	and also how IoT devices are connecting edge to cloud with OT environments, with other environments.
908930	914610	All of that is putting interoperability in the kind of front. And here this idea of leveraging
914610	923310	international standards that are scalable, that are developed globally at forums like CTA, ISO, IEC,
923310	930130	JTC1, Etsy and the like, that is also very critical because as you know, technology knows no
930130	936730	boundaries. The deployment of IoT is obviously a global phenomenon, but the supply chain
936730	942110	of technology is global in its nature. So we want to avoid fragmented regulation or some kind of
942110	947810	requirements that are really localized because that's not scalable when you think about manufacturers
947810	953670	that are, and the supply chain that are globally, that are global in their nature. Another key
953670	960350	principle that is not unique just by the way for IoT but is really important for IoT is this idea
960350	966190	of design neutrality. That laws and regulations, because they usually adapt, they usually are
966190	975530	amended very slowly, they always walk slower than technology, should not bake into the legislative
975530	982290	language a specific design or a specific requirement that might become outdated or even
982290	988470	terms, for example, like passwords that might change with time or a unique technical definition.
988470	993980	Instead, we should leverage these international standards and principle-based approaches.
994950	999950	And with all of that, I think a lot of regulators around the world and policymakers are recognizing
999950	1005950	the need to consider IoT as part of the broader ecosystem and enable private-public partnerships.
1005950	1012490	So I spoke a lot about the principles, but let's dive in. Let's look at a few examples of what is
1012490	1017650	really kind of cutting edge in terms of proposed regulation in IoT around the world. Now, this is
1017650	1023930	just an example. I'm going to walk you through more domains, but this is super interesting. It's
1023930	1030070	coming from the UK. Some of you may have heard about this in the past. I believe it's since 2018,
1030070	1036150	the UK, with their leadership, have put together an IoT security code of practice with 13
1036150	1042530	requirements. They've taken that effort a step farther, and now they're considering a law,
1042670	1047710	a regulation. This is, I believe, the third consultation already they are publishing
1048350	1055710	for this regulation. And by the way, now they're also considering to encompass PCs and laptops
1055710	1060210	as part of their regulation. They're really looking at three core requirements that are
1060210	1067730	proposed. The first one is around this issue of not having default password and having unique
1067730	1073790	authentication. This concept is one that we have seen in other regulations around the world.
1073790	1080590	If you look at the prior consultations, they say explicitly how they were motivated by the Mirai
1080590	1085710	attack. So you see the connection between the attack surface, the attack, and then the
1085710	1091430	regulators are considering action. The second requirement is around an issue which is very
1091430	1098250	close to heart to this community, having the public point of contact as part of a vulnerability
1098250	1105810	disclosure policy or program to allow researchers like you to submit vulnerabilities to the
1105810	1111570	manufacturer and have the manufacturer address the vulnerabilities. The third point which is
1111570	1117050	proposed is around this issue of support of security updates. By the way, they're also
1117050	1122870	referencing a standard, a technical standard, they have been developing as part of a broader consensus
1122870	1130270	at Etsy in Europe which really talks about consumer IoT requirements in more detail.
1130390	1135510	But it just kind of shows to you the connection between the standards and the proposed regulation.
1135510	1141790	So if we look at the broader landscape, we do have a lot of things happening in this sphere.
1141790	1148470	Everything from state laws, actually in Oregon and California we have laws already in effect
1148470	1155470	from January 2020 on connected devices, looking at this issue of reasonable security for connected
1155470	1161270	devices and they have some language there as well on the issue of authentication means and unique
1161270	1167850	authentication. We also have proposed federal laws. So this is very interesting. In the United States
1167850	1174610	there has been a number of proposed federal laws for all the United States on this issue of IoT
1174610	1181010	security. One of them is the IoT Cybersecurity Improvement Act that has been proposed for a while,
1181010	1188390	looking at leveraging federal procurement of IoT devices with requirements for all devices going
1188390	1194730	into federal procurement as a way to foster security of devices in all domains. We have also
1194730	1202850	seen a recent COVID white paper from the Cyberspace Solarium Commission proposing that we should have
1202850	1210150	all the market IoT federal U.S. law, so certainly an emerging area. We also have best practices and
1210150	1214770	standards. Okay, so this particular area is of particular interest and we're going to
1214770	1221170	dive in into the requirements or at least the consensus around what are some kind of the
1221170	1227330	foundational capabilities of IoT devices. This is an effort to bring all of industry together,
1227330	1232210	both at the international level, so that's at ISO, I'm an editor of one of the standards there,
1232210	1240270	but both in the U.S. with efforts like NISTOR 8259, that by the way is also referenced on the left in
1240270	1244410	the COVID white paper of the Cyberspace Solarium Commission, so you see the interaction between
1244410	1250470	the efforts. What's of particular interest for this community is that these are really technical
1250470	1257830	documents, they are horizontal, they reflect the consensus of all of industry, and they might shape
1257830	1264350	the future of both research and market demand in this area. We have also seen, based on kind
1264350	1272050	of these efforts of overall horizontal kind of trends, sector-specific requirements. So
1272850	1280570	for example, NIST has created and worked together on building consensus around NISTOR 8259,
1280570	1285770	which is always central to all the market. Now they've also released a draft on GitHub,
1285910	1292810	a federal profile of these requirements, that is in particular for the federal government
1293450	1299930	sector, so what goes under FISMA to federal agencies for that particular sector. In addition,
1299930	1304910	of course, this is not just in the U.S., I've showed the example from the U.K., we have seen
1304910	1311190	around the world attention to these issues with governments like Australia and the U.K. proposing
1311190	1316590	code of practices for IoT. Australia, in their recent announcement of what they're going to do
1316590	1321990	in terms of cybersecurity policy, they have a segment on IoT there. Of course, in Europe, a big
1321990	1329130	conversation around attestation, certification, and INISA is definitely also thinking about IoT.
1329390	1334690	So this is a global phenomenon, and we have seen leadership also from countries like Japan
1335570	1340830	proposing risk-based frameworks for IoT, so definitely of interest for regulators and
1340830	1345530	policymakers around the world. So finally, I talked about international standards and their
1345530	1352090	importance, how they've been developed in this area. We have seen two interesting also, I would
1352090	1357590	say, trends that go together with IoT. One of them is supply chain prosperity. This is, of course,
1357750	1364530	a big theme in the area of security policy, but in particular, it's connected with IoT. So those
1364530	1371990	of you who are long-term DEF CON attendees, or besides Las Vegas attendees, or just otherwise
1371990	1377950	might have seen talks from Alan Friedman on the initiative called the SBOM, the Software Bill of
1377950	1383150	Materials. So this is this idea that you should have transparency into the ingredients of the
1383150	1388990	software, and that transparency into the ingredients can support the other capabilities like updates
1388990	1394690	and the like. In this area, we also are getting to have some solutions around compute life cycle
1394690	1399630	assurance. Another trend that we have seen is the coordinate vulnerability disclosure trend that
1399630	1406210	goes together with IoT. So by that, I mean regulators and policymakers are also recognizing
1406210	1412410	the need to leverage the ecosystem, the need to have that collaboration to address the issues,
1412410	1418590	and they are coupling together with proposed reports and regulations and best practices,
1418590	1423810	this idea of having a process to receive vulnerabilities from the external community,
1423810	1429630	and you have seen the example from the UK, and to handle the vulnerabilities internally. So
1429630	1436450	bottom line, a lot of evolving kind of proposed, a lot of evolving kind of initiatives with
1436450	1442750	relationships between them, some are horizontal, some are sector-specific, and a bleed towards
1442750	1449650	other areas of security policy. Now we're going to drill down into this NISTR, which is this
1449650	1457190	consensus-driven best practice. This is not a regulation or a requirement per se, but it's a
1457190	1462890	consensus effort that is of interest for this community. You can see here on the left the C2
1462890	1467130	effort by the Council to Secure the Digital Economy, and all the different trade associations
1467130	1473270	really spanning the entire technology sector that have come together to define this consensus.
1473270	1478290	Anaita, I would like to invite you to present to us with more detail the technical elements that
1478290	1487370	are explored in the NISTR. Thanks, Amit. So yeah, you heard a lot about NISTR at the magic 8259
1487370	1494770	number, right? Let's take a closer look at what it is, what is the motivation and objective. As this
1494770	1501190	effort very well exemplifies what's happening in regulatory momentum. So what is this about?
1501710	1508950	8259 targets manufacturers. Specifically, the subject of this recommendation is framed around
1508950	1515710	the finished IoT devices. It provides the recommendation on cyber security activities
1515710	1523330	and capabilities to address customers' cyber security needs. So NISTR publication proposes
1523330	1531330	to normalize the manufacturer-customer relationship by leveraging the laws, regulations, and guidelines.
1531330	1539490	Let me set the expectations right. So 8259 is intended to address a very broad range of IoT
1539490	1546550	devices, from tiny little doorknobs to very complex critical infrastructure class of devices.
1546550	1553610	So expect to see what I would call it lowest common denominator. However, this is setting the
1553610	1561450	trend, right? It's also important to note that all other parts of the IoT ecosystem, other than IoT
1561450	1569270	device itself, are outside of scope of this NISTR recommendation. So overall, this is the first step
1569270	1576450	towards the making the IoT security more measurable. It is expected that eventually more
1576450	1582610	guidelines will be developed to address that out-of-scope problems, as well as more specific
1582610	1588030	market segment profiles and the risk-based recommendation will evolve from this one.
1588030	1593310	And we do see it happening already in the federal space, as Amit mentioned earlier.
1593310	1602890	So NIST emphasizes the message that IoT security shall start early on. So let's look at their
1602890	1610150	recommended actions. Again, remember, this is all about manufacturers. It is proposed that
1610150	1616990	IoT device manufacturers need to perform this action and provide the services to their customers
1616990	1624410	who would plan that cybersecurity for the devices within their system and environment.
1624410	1632370	So NISTR 8259 identifies six specific recommended actions, pre-market and post-market.
1632370	1638910	The first two activities assume that manufacturers have to have the full disclosure on device usages
1638910	1644590	and the security goals. This might be quite challenging, actually, as there are many cases
1644590	1651810	that we know when customers and manufacturers don't have that good collaboration. As a result,
1651810	1656470	manufacturers cannot expect what will happen with the device in the field.
1656690	1662330	Activity number three is the anchor point for the core baseline capability.
1662330	1669670	These capabilities are defined by NISTR 8259a and supposed to address what customers would
1669670	1676510	need to achieve their goals and fulfill their requirement. This is the most technically loaded
1676510	1685190	proposal in this recommendation. Activity number four addresses the support. So manufacturers
1685190	1691850	should consider all the resources required to support development and continued support of
1691850	1700430	the IoT device. That includes security code practices, vulnerability disclosures,
1700430	1707570	vulnerability responses, and floor remediation. Post-market, there are activities five and six,
1707570	1713690	and those are related to customer communication. Although I would call that really post-market,
1713690	1719670	as planning on how to address these activities needs to be baked in at very early stage of the
1719670	1725050	design of the product. There are several potential considerations listed in the publication for
1725050	1732330	this stage. Some of them are the lifespan expectation, the software update, device
1732330	1739130	retirement, and end of life. The main takeaway here, so NIST attempts to frame the security
1739130	1747170	actions around the different stages of the device lifecycle, bringing manufacturers to customers.
1747500	1754090	It calls out that pre-market development stage core capabilities needs to be addressed.
1754090	1762110	So now let's see what are those core capabilities and drill down here. This baseline represents
1762110	1768670	the industry-wide collaboration effort that Amit mentioned earlier, as a result of which
1768670	1775490	definition of common capabilities were produced. And the common is the key word here. This is not
1775490	1781670	exhaustive lips. Remember the lost denominator? This is starting point that set the direction.
1781670	1788690	Therefore, in each implementing organization, you may find the superset
1788690	1795630	capabilities that better fit their needs. There are six basic capabilities outlined.
1795710	1802210	First one is device identification, covers both logical and physical identification.
1802210	1809170	Second is device configuration that can be performed by authorized entities only.
1809170	1816520	Data protection addresses the protection of data from authorized access and modification.
1816890	1825040	Logical access to interfaces is about restricting of logical access to local and network interfaces.
1825680	1832700	Software updates recommends that, again, the update needs to be done in supervised manner,
1832700	1841500	updated only by authorized entities. And last one here is the cyber security state awareness.
1841500	1847660	So this capability is about the ability of IoT device to report its own cyber security state
1847660	1854740	and make that information accessible to authorized entities. So this was just a quick run
1854740	1860160	through these capabilities. There are many nuances to this baseline. So I would recommend
1860160	1868720	reading through NISTers 82598 document directly. And at this point, let's change the gear and look
1868720	1876420	on what's left outside of out of the NIST scope. So we did talk about the complexity of the
1876420	1884140	ecosystem. So NIST simplified the ecosystem model just to two entities. And we at Intel realized
1884140	1890340	that truly deployable IoT solution require more complex relationship. When we think about Intel,
1890340	1897980	we think about Silicon, which would be very left of this picture. It is our partner ecosystem that
1897980	1906020	builds out the rest of the story. So the analogy that we like to use a lot is the orchestra playing
1906020	1912800	together. So each player has a critical role in delivering finished symphony to the audience.
1912800	1922080	And the value chain in case of IoT device goes from the ingredient to manufacturers, OEM, ODM,
1922080	1928960	then through the ISVs, cloud service providers, solution integrators, and then only get delivered
1928960	1936860	to the end users. So all these artists participate in the security baseline definition
1936860	1945540	and implementation. But there is also the life after the deployment, right? The device goes to
1945540	1953200	the circular stages of the updates. And again, manufacturers, they have to rely on the rest of
1953200	1962840	the ecosystem to deliver the updates. So what do we do? So we realized that it's not an Intel
1962840	1968580	universe, so we have to work with the broad ecosystem. And we established the partnership.
1968600	1975360	So IoT Solution Alliance is our partnership framework. It covers 6,000 solutions, includes
1975360	1982300	more than 500 members, and of course, we work across the globe throughout our global platform.
1982300	1988540	As Amit mentioned, this is very important from the regulatory perspective, the global interaction in
1988540	1996220	the policy space. So our member companies, they span the globe and offer local expertise in
1996220	2002960	market worldwide. This is the community that we're closely collaborating on security as well.
2002960	2010480	And for the security discussion, it's important to establish the common ground, attack surfaces
2010480	2017640	and threats is that the common ground that we use to build the collaboration. So let's take a look
2017640	2026420	to this table. The attack surface sums up all the penetration points, otherwise known as
2026420	2032440	attack vectors. So a summary of exploitable vulnerabilities at device level. So we are
2032440	2038260	looking now at the device level is presented in this table, where different threats on the right
2038260	2046180	side are correlated with respective attack surfaces and components on the left side.
2046180	2053340	Moving from bottom up, you see the hardware layer, right? And then above it is the firmware
2053340	2061220	optional hypervisor when virtual machine monitor and then the operating system. And finally,
2061220	2070560	this user space where the application or workloads will be running. The attacks in the top layers
2070560	2077980	have been prevalent and known for quite some time already. But attacks are more and more
2077980	2084400	moving down the stacks, exploiting vulnerabilities all the way to the firmware and the hardware
2085140	2093320	layers as well, which could potentially give even more interesting opportunities,
2093320	2100400	higher privileges on the devices as well as those attacks can go fairly undetected.
2100560	2108480	So let's take an example. So by tampering with the firmware, it might be possible to subvert
2108480	2116560	the entire boot, right? And boot the operating system, which would be attacker's choice, right?
2116560	2125180	The desired operating system. This table overall is an eye chart, but I think the main takeaway
2125180	2131600	here is that the attacks are not singular, right? It's a multi-dimensional problem and spans across
2131600	2139120	the entire stack of IoT device and requires the protection mechanism at each layer as well.
2139120	2145500	So having this framework allows us to systematically analyze the security solution
2145500	2153740	to mitigate the risk from the very early stage of our product design phase. And we work with
2153740	2161220	our customer based on this taxonomy. And we do provide, of course, solutions and innovate the
2161220	2169520	hardware-based security technology in our product to build the defense in depth from the bottom up
2169520	2179120	and withstand the attack propagation. But, Amit, it's not only about our own innovation and our
2179120	2186380	own technologies, right? So can you share your thoughts about how this evolving attack surfaces
2187040	2196180	can drive a greater collaboration with technologists? Yes, absolutely. And I think, Amit,
2196180	2202400	you're exactly right. I think you've seen throughout this presentation so much of the complexity that
2202400	2208480	is pretty unique for the IoT ecosystem. And this is the vertical business model, the versatile devices
2208480	2213880	from everything from the dog collar to the sensitive systems, the type of the attacks and
2213880	2220200	how the attack surface is evolving, and also the technical challenges, right? And Amit
2220880	2226980	definitely provided a very extensive overview of this. All of this suggests that this issue is not
2226980	2232220	just going to be solved through the innovations, through the security capabilities that we are
2232220	2237960	going to bake into hardware and software and firmware. Yes, that is a critical piece of the
2237960	2246640	discussion. Yes, incentivizing the innovation, the R&D, the research, the pipeline, all of that is
2246640	2252300	critical, but we are still going to need the collaboration. And by collaboration, I mean
2252860	2258360	companies working with researchers, enabling the ecosystem, right? Collaboration between the
2258360	2264340	different verticals in the supply chain. Also collaborations between policymakers and legislators
2264340	2270520	and regulators as they're thinking about these issues between the public and the private industry
2270520	2277780	and having your expertise, the expertise of the crowd in these arenas as well, engaging in
2277780	2284640	that dialogue. And I think we have seen tremendous developments in that area. I think the safe harbor
2284640	2290860	kind of discussion is one of them. We have seen also growing collaboration and a lot of thinking
2290860	2296680	that goes into researcher relations. I don't know if you've seen some of my peers from PSIRT and
2296680	2302120	from Intel Security at the Red Team Village or in this village talking about how we collaborate with
2302120	2307940	the ecosystem, how we are funding academic researchers in this area. All that is critical.
2307940	2312340	So as we are thinking about this kind of conversation, it's really critical to get
2312340	2320700	the dialogue going. And with that particular recommendation, I would like to invite you all
2320700	2327460	to ethically hack us. We do have a bug bounty. It's a public bug bounty. We offer rewards. You
2327460	2332420	can check it out. You can check out the scope. We also have a vulnerability disclosure program.
2332420	2337120	You can report vulnerabilities to us. The collaboration with the researcher community
2337120	2343640	is extremely important to us. And we work with the entire ecosystem to drive security first.
2343780	2349540	So security at Intel.com, please report your vulnerabilities. Please continue the great work
2349540	2356580	and research in the embedded system arena, especially this village is dear to heart for us.
2356580	2361620	And let's continue the conversation. And we would like to welcome your questions. I did
2361620	2367820	went through in a true Israeli fashion and a little bit of my style. My sister always tells
2367820	2373880	me to slow down. I went through a lot of examples when I was talking. And I will provide you the
2373880	2380060	links to all of these resources that I've talked about and Ana shared as well in the Discord chat.
2380180	2385300	So this is just a little bit of preview. Please join us in the Discord if you want to get all
2385300	2389720	the details and all the information about what we shared with you today. You can find it there as
2389720	2395660	well. And we'd like to continue the conversation with you. Ana, for me, this has been a great
2395660	2401680	collaboration. The former hacker that I collaborated with in a talk is my sister,
2401680	2406260	Karen. I hope to continue that collaboration. Maybe she is here with us in the audience.
2406260	2413640	Karen, I haven't forgotten you, of course. But this has been a really joyful dialogue for me.
2413640	2417680	Thank you so much. Anything to share from your perspective, Ana, before we wrap it up?
2417680	2425100	No, this is a great journey. And this is a great example of collaboration. Again, I am on the
2425100	2431200	technology side. I'm on the product side. Amit represents a more regulatory perspective.
2431200	2442480	And this is when these two... when the two worlds meet, we see absolutely new perspective, right?
2442480	2446480	So collaboration is the key. And thank you very much. We are looking to hear from you.