 Thank you so much. And I just love this village, you know, have been coming to this village. I think it is three years in a row. And I do miss deaf con a lot. And some of you know, my sister Karen, I often go to deaf con with her. And we definitely miss that experience, but I am very excited to be here with you today. And today I'm also joined with a really good colleague of mine. She's a spectacular engineer from the business unit with us. And we're going to be talking with you today on this evolving landscape of baseline standards and regulation. So first of all, let me check again. Can you all hear us great Sam team? Yep, we can. Wonderful. Well, as Sam shared, we are both from Intel. I work in the government's relation team at Intel within the legal department. I work with governments around the world and policymakers on issues of security policy. And I also lecture at the UC Berkeley School of Information where I teach in the master in cybersecurity program. And as many of you, as many of you know, I'm also Israeli. And usually when I come to this village, I start with a direct question. So let me do it again. By now, most of you should be familiar with this face. And I hope you know him. This is Kevin Finster. He's a researcher and like many of you in the audience is also focused on embedded systems. And specifically, he has a love and passion towards drones. And he has conducted research on DJI. One of their drone systems and he found the vulnerability that according to him leaked personal information and he wanted to report that vulnerability to DJI and, you know, do the right thing and engage in disclosure. 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. And, you know, it was not really clear what was the scope according to the reports. There wasn't really a bug bounty policy or contract and there was some confusion between the parties on this issue of the scope according to the reports. So Kevin contacted DJI and asked them, is this vulnerability that I found is in scope and they in fact, according to the reports, suggested it is in scope, not only that they said that they would like to pay him $30,000 for that vulnerability. So for those of you engaged in bug hunting, just empirically speaking academically that's a pretty high bounty. And then the plot, they can't. So there are two sides to this story and I encourage you to check out the links in the bottom. But Kevin felt that doing the negotiation on issues of disclosure. There were some issues that were unclear again because we didn't have that scope and website and then the plot thickened 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 ICA was mentioned according to the reports in that letter. And Kevin ended up walking away from this approved bug bounty of $30,000 and sharing on Twitter, his version of the story. And you know, he did order a Tesla. He ended up canceling that order over Tesla. And it's just a story highlighting some of the nuance between laws and bug bounties and vulnerability disclosure programs and this evolving landscape of anti hacking laws. And it's a story that I shared a lot during the last three years and I'm, I'm actually happy to report that we have seen maybe also because Kevin went and share this story. A lot of progress in this era we have seen a lot of safe harbor adoptions and a lot of collaborations between companies and researchers and even recently. We 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. So all of this is very exciting 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 firework at Berkeley before I joined Intel promoting this framework for collaboration. It really is nice to see the growing adoption of safe harbor. But one of my key takeaways from this kind of evolving interaction between line technology is that laws are often basically evolving slower than technology. So we know that laws are slowly being the amendment. It's not like innovation that is rapidly being developed and laws often have concepts like authorization or reasonable security or principles that are adopted with time. The reason I bring this example is that if you even consider the CFA again this main anti hacking law that I mentioned that I'm sure many speakers are speaking about this law throughout DEF CON. It is a law from 1986 before the internet as we knew it today, and many much has changed including hacking and security testing. And this year, the Supreme Court is going to actually take one of the first core cases on this issue of authorization. And we will see how that will evolve, but it just shows kind of how the laws are adapting to technology but are often behind. 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 feeding together. So I shared a little bit about my background towards this week at DEF CON a lot has been talked about in terms of this closed IO and bug bounty. You can check out my prior work in this area, but I'm very passionate about this issue of collaboration between researchers and hackers and companies. And while I am a lawyer and my background is legal, I'm not your lawyer and today I'm going to be talking about my own personal opinion and I'm not going to be providing any legal advice. So I know this is a little bit of fine print. You would probably expect that from me right. But it is exciting and, you know, if I need to compliment kind of the prior discussion I am also very excited to share the lead 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, but also know that we have that language in our bug bounty. And with that, I spoke a lot about collaboration I spoke about why this is important as we think about technology and laws and how they go together. So I want to invite my fearless collaborator and eight 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 and please take it away. Thanks, Amit. Indeed, it's a great collaboration. So hi folks, very glad to be here. And as Amit said, I work directly on product definition side. So today we are talking about security and regulation policies right and being on the receiving side of the regulatory guidelines inside Intel I spent time understanding and assessing the technical implication. So first, I would like to start looking at the concern that triggers this rising regulatory efforts. And one of the key IOT security issue is the expanded attack surface. And that's due to the increased number of the endpoint devices. So we all see this future scape that predict billions of devices with trillions of sensors. This large number of IOT devices that being bought into the business triggers the growth of attack. Another issue is the sophistication and evolving of the intent. It is clear that the attack target is not limited to the assets of IOT device only. IOT device exposure opens plethora of opportunity across the edge to cloud and exposes a lot of valuable assets. So let's analyze the genealogy of the IOT attacks. So what you see here is typical IOT solution that spans edge to cloud. So IOT device control other devices in the system and itself they being controlled by others in the edge to cloud solution. This duality exposes enormous challenges for the security community and adds new dimension to the system cybersecurity controls. Attacks that originate on a very left side of the edge easily can propagate throughout the entire pipeline and single device can jeopardize the entire solution. One notorious example of this type of scenario is Casino fish tank attack. I don't know how many of you are aware of that story, but just a quick recap. So using a trivial vulnerability in a smart thermometer in fish tank, hackers gained access to Casino network. They retrieved data about high paying customers and then extracted that data through the thermostat and to the cloud and a result of a 10 gigabyte of data ended up in Finland. This looks like a Hollywood ready story perfect for ocean trilogy sequel. But from our perspective, this just proves the point that the simple device in this case it was the thermometer can break down the very tough protected end to end solution. With that many new devices already deployed and even more on the way it is important to consider the unique challenges in IOT space. And first, let's look at the technical side of it. So IOT business world is different from traditional well established and structured PC environment cloud environment. There are several factors that contribute to the technical and business challenges in our world. There it's a diversity of distinct market segment and the business model so very range of the very wide range of the use cases that we are dealing with. The usages need to meet stringent power performance and form factor requirements. Another challenge is the complex ecosystem. There are many entities involved in defining finished and customer usable product. Another distinction is the wide range of the software and firmware, which includes OS, hyperbases, boot loaders, right, of course application and all the workloads that run on top of it. Heterogeneity of the installed base is in that end to end solution also pretty unique factor. IOT is a mix of the green and brown field devices and on top of it comes the icing. IOT needs to be supported over extended lifetime, which is much longer than traditional PC service. All these challenges become contributing factor to vulnerability of IOT devices and introducing security risk. Those are the concern that actually triggered and got reflected in the policy arena. And here I would like to ask Amit, please share your insights from the regulatory guideline perspective. Thank you so much, Anit. And you're exactly right. When it comes to the evolving policy and regulatory sphere, the complexities that we are 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 are coming to proposed best practices, reports, standard development and laws and regulations and requirements in this area. So one of the interesting things is this idea of having the risk based approach. This is by the way an underlying principle for all security policy, but particularly in IOT it's important. Why? Because we have that horizontal, but yet very versatile environment of devices, right? 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. 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. That's one of the ideas when you think about the proposed regulations that the requirements should apply based on a risk based approach. So you as researchers should expect a lot more standards and thinking 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. More definitely the regulatory environment should consider how to support innovations. 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. Interoperability. So this is a key issue. We need to think about how the IOT devices are working together. 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. All of that is putting interoperability in the kind of front 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. The deployment of IOT is a global, obviously a global phenomenon, but the supply chain of technology is global in its nature. 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 globally in their nature. So that key principle that is not unique just by the way for IOT but is really important for IOT is this idea of design neutrality. That laws and regulations because they usually adapt, they usually are amended very slowly. So IOT's 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, for example, like passwords that might change with time or unique technical definition. Instead, we should leverage these international standards and principle based approaches. And with all of that, I think a lot of regulators around the world and policy makers are recognizing the need to consider IOT as part of the broader ecosystem and enable private public partnerships. So I spoke a lot about the principles, but let's dive in. 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. Now, this is just as an example. I'm going to walk you through more domains, but this is super interesting. It's coming from the UK. Some of you may have heard about this in the past. I believe it says 2018, the UK with their leadership have put together IOT code of security code of practice with 13 requirements. They've taken that effort a step farther. And now they're considering a law, a regulation. This is, I believe, the third consultation already they are publishing for this regulation. And by the way, now it's also, they're also considering to encompass species and laptops as part of their regulation. They're really looking at three core requirements that are proposed. The first one is around this issue of not having default password and having unique authentication. This concept is one that we have seen in other regulations around the world. And if you look at the prior consultations, they say explicitly how they were motivated by the MIRAE attack. So you see the connection between the attack surface, the attack, and then the regulators are considering action. 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 vulnerability disclosure policy or program to allow researchers like you to submit vulnerabilities to the manufacturer and have the manufacturer address the vulnerabilities. The third point which is proposed is around this issue of support of security updates. In a way, they're also referencing the standard, the technical standard that has been developing as part of a broader consensus at Etsy in Europe, which really talks about consular IoT requirements in more detail. But it just kind of shows to you the connection between the standards and the proposed regulation. So if we look at the broader landscape, we do have a lot of things happening in the sphere. I think from state laws, actually from 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. We also have proposed federal laws. So this is very interesting. In the United States, there has been a number of proposed federal laws for all the United States on this issue of IoT security. 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. We have also seen a recent COVID white paper from the cyber space Solarium Commission proposing that we should have all the market IoT federal US law. So certainly an emerging area. You also have best practices and standards. 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. This is an effort to bring all of industry together, both at the international level so that's an ISO. I'm an editor of one of the standards there. But both in the US with efforts like NISTAR 8259 that by the way is also referenced on the left in the COVID white paper of the cyber space Solarium Commission. So you see the interaction between the efforts. What's of particular interest for this community is that these are really technical document 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. We have also seen based on kind of these efforts of overall horizontal kind of trends sector specific requirements. So, for, for example, NIST has created and work together on building consensus around NISTAR 8259 which is always entered to all the market. 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. In addition, of course, this is not just in the US. I've showed the example from the UK. We have seen around the world. Attention to these issues with governments like Australia and the UK proposing code of practices for IOT Australia in their recent announcement of what they're going to do in terms of cybersecurity policy. They have a statement on IOT there. Europe, a big conversation around attestation, certification, and NIST is definitely also thinking about IOT. So this is a global phenomena 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. So finally, I talked about international standards and their importance, how they've been developed in this area. We have seen two interesting also, I would say trends that go together with IOT. One of them is supply chain prosperity. This is of course a big theme in the area of security policy, but in particular it's connected with IOT. So those of you who are long term deaf con attendees or besides Las Vegas attendees or just otherwise might have seen talks from the London Fridman on the initiative called the S bomb, the software bill of materials. 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. In this area, we also had to have some solutions around compute life cycle assurance. Another trend that we have seen is the coordinate vulnerability disclosure trend that goes together with IOT. So by that I mean regulators and policymakers are also recognizing the need to leverage the ecosystem. We need to have that collaboration to address the issues, and they're coupling together with proposed reports and regulations and best practices. 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. 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. Now we're going to drill down into this minister, which is this consensus driven best practice. This is not a regulation or requirement per se, but it's a consensus effort that is of interest for this community. You can see here on the left the C2 effort by the console to secure the digital economy and all the different trade associations really spending the entire technology sector that have come together to define this consensus. And I would like to invite you to present to us with more detail the technical elements that are explored in the NISTAR. Thanks, Amit. So yeah, you heard a lot about NISTAR at the magic 8259 number, right? Let's take a closer look what it is. What is the motivation and objective as this effort very well exemplifies what's happening in regulatory momentum. So what is this about? 8259 targets manufacturers, specifically the subject of this recommendation is framed around the finished IoT devices. It provides the recommendation on cybersecurity activities and capabilities to address customers' cybersecurity needs. So NIST publication proposes to normalize the manufacturer-customer relationship by leveraging the laws, regulations and guidelines. Let me set the expectations right. So 8259 is intended to address a very broad range of IoT devices from tiny little doorknob to very complex critical infrastructure class of devices. So expect to see what I would call it lost common denominator. However, this is setting the trend, right? 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 NISTAR recommendation. So overall, this is the first step towards the making the IoT security more measurable. 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. And we do see it happening already in the federal space as I mentioned earlier. So NIST emphasizes the message that IoT security shall start early on. So let's look at their recommended actions. Again, remember, this is all about manufacturers. 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. So NISTAR 8259 identifies six specific recommendation action, pre-market and post-market. The first two activities assume that manufacturers have to have the full disclosure on device usages and the security goals. This might be quite challenging actually as there are many cases that we know when customers and manufacturers don't have that good color variation. As a result, manufacturers cannot expect what will happen with the device in the field. Activity number three is the anchor point for the core baseline capability. These capabilities are defined by NISTAR 8259A and supposed to address what customers would need to achieve their goal that fulfill their requirement. This is the most technically loaded proposal in this recommendations. Activity number four addresses the support. So manufacturers should consider all the resources required to support development and continued support of the IoT device. That includes security, secure code practices, vulnerability disclosures, vulnerability responses and floor remediation. Post-market there are activities five and six and those are related to customer communication. 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. There are several potential considerations listed in the publication for this stage. Some of them are the lifespan expectation, the software update, device retirement and end of life. The main takeaway here is NISTAR attempts to frame the security actions around the different stages of the device lifecycle, bringing manufacturers to customers. Specifically, it calls out that prem market development stage core capabilities needs to be addressed. So now let's see what are those core capabilities and drill down here. This baseline represents the industry wide collaboration effort that I mentioned earlier. As a result of each definition of common capabilities were produced and the common is the keyword here. This is not exhaustive lips. Remember the lost denominator. This is starting point that set the direction. Therefore, each implementing organization in each implementing organization, you may find the superset capabilities that better fit their needs. There are six basic capabilities outlined. The first one is device identification covers both logical and physical identification. Second is device configuration that can be performed by authorized entities only. Data protection addresses the protection of data from onto access and modification. Logical access to interfaces is about restricting of logical access to local and network interfaces. Software updates recommends that again, the updates needs to be done in supervised manner, updated only by authorized entities. And last one here is the cybersecurity state awareness. So this capability is about the ability of IoT device to report its own cybersecurity state and make that information accessible to authorized entities. So this was just a quick run through of this capabilities. There are many nuances to this baseline. So I would recommend reading through NISTERS 8259A document directly. And at this point, let's change the gear and look on what's left outside of the NIS SCOPE. So we did talk about the complexity of the ecosystem. So NIS simplified the ecosystem model just to two entities. And we at Intel realized that truly deployable IoT solution require more complex relationship. When we think about Intel, we think about silicon, which would be very left of this picture. It is our partner ecosystem that builds out the rest of the story. So the analogy that we like to use a lot is the orchestra playing together. So each player has a critical role in delivering finished symphony to the audience. And the value chain, in case of IoT device, goes from the ingredient to manufacturers, OEM or DM, then through the ISVs, cloud service providers, solution integrators, and then only get delivered to the end users. So all these artists participate in the security baseline definition implementation. But there is also the life after the deployment, right? The device goes to the circular stages of the updates. And again, manufacturers, they have to rely on the rest of the ecosystem to deliver the updates. So what do we do? So we realized that it's not an Intel universe, so we have to work with the broad ecosystem. And we established the partnership. So IoT Solution Alliance is our partnership framework. It covers 6,000 solutions, includes more than 500 members. And of course, we work across the globe throughout our global platform. As Amit mentioned, this is very important from the regulatory perspective, the global interaction in the policy space. So our member companies, they span the globe and offer local expertise in market worldwide. This is the community that we closely collaborating on security as well. 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. So let's take a look to this table. The attack surface sums up all the penetration points, otherwise known as attack vectors. So a summary of exploitable vulnerabilities at device level. 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. Moving from bottom up, you see the hardware layer, right? And then above it is the firmware optional hypervisor with virtual machine monitor and then the operating system. And finally, this user space where the application or workloads will be running. The attacks in the top layers have been prevalent and known for quite some time already, 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, even with higher privileges on the devices as well as those attacks can go fairly undetected. So let's take an example. So by tampering at the firmware, it might be possible to subvert the entire boot and boot the operating system, which would be attacker's choice, right? The desired operating system. This table overall is I-Chart, but I think the main takeaway here is that the attacks are not singular, right? 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. 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. And we work with our customer based on this taxonomy 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. But I mean, it's not only about our own innovation and our own technologies, right? So can you share your thoughts about how these evolving attack surfaces, right, can drive a greater collaboration with technologists? Yes, absolutely. And I think, Annie, you're exactly right. I think you've seen throughout this presentation so much of the complexity that is pretty unique for the IoT ecosystem and this is the vertical business model, the versatile devices from everything from the dock collar to the sensitive systems, the type of the attacks and how the attack surface is evolving and also the technical challenges, right? And Annie definitely provided a very extensive overview of this. 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. Yes, that is a critical piece of the discussion. 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. And by collaboration, I mean companies working with researchers, enabling the ecosystem, right? Collaboration between the different verticals in the supply chain. Also collaborations between policymakers and legislators and regulators as they are 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. And I think we have seen tremendous developments in that area. I think the Safe Harbor kind of discussion is one of them. We have seen also growing collaboration and a lot of thinking that goes into researcher relations. I don't know if you've seen some of my peers from PISERT 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. All that is critical. So as we are thinking about this conversation, it's really critical to get the dialogue going. And in that particular kind of, with that particular recommendation, I would like to invite you all to ethically hack us. We do have a bug bounty. It's a public bug bounty. We offer rewards. You can check it out. You can check out the scope. We also have a vulnerability disclosure program. You can report vulnerabilities to us. The collaboration with the researcher community is extremely important to us. And we work with the entire ecosystem to drive security first. So security at Intel.com, please report your vulnerabilities. Please continue the great work in researching the embedded system arena, especially this village is dear to heart for us. And let's continue the conversation and we would like to welcome your questions. I did went through, through Israeli fashion and a little bit of my style. My sister always tells me to slow down. I went through a lot of examples when I was talking and I will provide you the links to all of these resource that I've talked about. And Anna shared as well in the discord chat. So this is just a little bit of preview. 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. You can find it there as well. And we'd like to continue the conversation with you on it for me. This has been a great collaboration. The former hacker that I collaborated with in a talk is my sister Karen. I hope to continue that collaboration. Maybe she's here with us in the audience. Karen, I haven't forgotten you, of course, but this has been a really joyful dialogue for me. Thank you so much. Anything to share from your perspective on it before we wrap it up. No, this is a great journey. And this is a great example of collaboration. Again, I am on the technology side. I'm on the product side. Amit represents a more regulatory perspective. And this is when the two words hit with absolutely new perspective. So collaboration is the key. And thank you very much. We are looking to hear from you.