 Hi everybody! Hope you're enjoying your Hacker summer camp for this year. We are so excited to be here again with you in the IoT DEF CON village. We are going to be talking about the journey of establishing IoT trustworthiness and IoT security foundation. So we're going to be covering some of the key highlights what has changed in the IoT security policy and regulatory landscape, the technical standard and baseline landscape. Then we're going to tie it up to this broader conversation about the concept of IoT trustworthiness and how it connects to some of the developments with respect to AI trustworthiness, how that concept is fitting in into the conversation. We're going to bring both technical engineering policy perspectives to the table tying it all together. As I mentioned, my name is Amita. I'm director of Global Cybersecurity Policy at Intel's cooperation in our government defense group. I'm also lectured UC Berkeley School of Information Master in Cybersecurity and Information Program. I'm joined today by with two great friends, technical experts, wonderful experts from a network and edge group, Anne Tarcanian. She's a security principal engineer in our CTO IoT office and Ria Travru who is the AI ethics league architect in our group as well. I'm so excited to be here and I would like to kick us off by inviting Anne to tell us a little bit about what is changing the landscape, why IoT security continues to be top of mind both with headlines and both in the policy circles. Anne, take it away. Glad to be part of IoT Village again. Here we have experts who are very keen in IoT technology and it will be no brainer that Internet of Things receive increased attention from industry policy makers, consumers and the media. This interest ignited by technology advancement. The advancement does hitting the production reality or in other words the trade-off between the desired outcome of using technologies versus the risk associated with that. IoT came with the promise to change the user experience from focusing on situational awareness to behavior performance or helping to support defined user intent. It becomes smarter and smarter and now with expansion of AI machine learning technologies at IoT, IoT device is in charge of decisions too. We see that Internet of Things evolve. It is no longer about things themselves. It's about overall business. Those things are designed to support. It's about the data processing pipeline and that explains that increased interest of attackers on IoT devices. Yes, you know very well that there is no lack of IoT security headlights. As you remember, Mirai botnet was the first wave of high visibility DDoS attack that turned IoT devices to a network of bots. Today it is still valid exploitation. Moreover, the DDoS evolved and the DDoS attack sometimes can be deployed as a destruction from even more nefarious activities. So ransomware and DDoS deployed in combination where DDoS used as a smoke screen with volumetric saturating network bandwidth to close up the connection for legit users. In addition, security researchers steadily uncovering severe vulnerabilities in firmware. Among recent examples are IP cameras with UDP technology and GE universal replay family of protection and control devices. And finally, the most prominent colonial pipeline attack. Yes, IoT, it was not bridge, however, that affected the OT usage as well. So to ensure the safety of the pipeline, the company proactively disconnected certain systems that monitor and control the physical pipeline function. So that would not be compromised. As a result, we know what happened, right? So definitely these security vulnerabilities attacks are one of the factors that contribute to increased attention to internet optics. Now let's look at a broader picture on why IoT is in the center of the gravity. First and foremost, IoT is about diversity. Diversified markets, plethora of usages, complex supply chain of solution, it's all about IoT. Intersection of IT and OT comes with pros and cons. It brings the best and worst of both worlds. And as we can see on the example of colonial pipeline, the attack on the IT resulted in the shutdown of the OT. And finally, most interesting as we mentioned at the beginning, IoT matured and it attracts the cutting edge technologies for the smart functionality. AI and machine learning bring and opened up new opportunities. And at the same time, they raised the distinct concerns. New adversarial attack called deep slot developed by scientists at the University of Maryland was very interesting. It can force machine learning system to slow down, to crawl, taxing the computer devices and possibly causing the critical failure in the applications. So this will result in the loss of efficacy for up to 45% but attackers doesn't even have exact information about the target AI model. This brings a new dimension to the problem of IoT risk. As you can see, IoT is morphing, it's maturing, growing, evolving and there is still a lot of security challenges that needs to be addressed in this space. Now, let's switch gears and look at what's happening at policy side. Amit, please walk us through evolving policy landscape. Thank you, Annette. So let's talk a little bit about what has changed in the policy landscape. Obviously, IoT security continues to be tough of mind for policymakers, but we also have seen how related developments in other landscapes like the supply chain security landscape and across the board, conversations in security policy are impacting our kind of trending towards specific new developments on IoT security. So, of course, as many of you might be aware, we already have state legislation on connected device security in California and Oregon in effect. We also have a federal law that has passed the IoT Cyber Security Improvement Act passed on December. The focus there is federal procurement, so security requirements for federal contractors supplying IoT devices. These are both technical requirements on device and non-technical requirements processes. We're going to walk you through this. This will build on the NISTER 8259 series and implementation is now underway to define these requirements and guidelines. We also have their new guidelines to be developed on the area of coordinate mobility disclosures, including on certain aspects related to federal contractors. Again, all of this in development and implementation. This is, of course, interacting with the development, the major development in the landscape, the executive order issued by the Biden administration, comprehensive, robust offer effort with respect to software secure development practices, supply chain security, insert reporting, and other issues as well. We are going to be seeing new requirements there on the area of secure development. There are additional requirements for critical software. NISTER has already defined that concept and issued kind of their first view on how this might look. There is a lot of work under section four on what would be the different requirements that are going to be issued. There is an element of the SBOM, the software bill of materials, which is, of course, a key concept in the IoT security conversation, the policy conversation as well. NTA is already issued their first view on minimal elements of the SBOM, and this is going to be incorporated in section four. NISTER is going to provide us with more insights on that as part of that implementation. Of course, there is a big focus multiple sections on not just the importance of zero trust architecture across the board, but also how incident reporting and cornered vulnerability disclosure practices are going in hand with software development security practices. This is the continued focus on combining both processes, assurance practices, but also the focus on how vulnerabilities are getting remediated and what are the processes around that. We see that in the executive order really clearly, and that trend will continue. What else? Looking at the kind of major trends in the landscape, this is not exhaustive, but of course in Europe and in the UK. The UK have continued with their leadership on the proposed regulation for security requirements for consumer products. They've issued the results of their consultation on April. I encourage you to check that out. They're still focusing on key free requirements there. This is interacting with their work and the European's work to develop it at CEN 3.0.3.6.4.5, which is a standard for IoT security consumer baseline capabilities that is referred to in this proposed regulation. We also know that IoT security is going to be a big focus in Europe. It's a pillar of the cybersecurity strategy there of Anissa and the commission. We are already seeing as part of the radio equipment directive, security and privacy requirements, implementation in the standard bodies, the technical standards work there, how IoT security standards in particular might be leveraged, 3.0.3.6.4.5, 6.0.2.4.3. Of course, these are ongoing conversations, but we are seeing that already there. We are expecting a new horizontal potential proposed regulation for product security requirements, and maybe is even a voluntary certification scheme as part of that strategy. That's on the European side, among others, some of the key developments. Of course, this is going hand-in-hand with the technical standard conversation. Our efforts to come together as a community and develop a baseline understanding of the security capabilities for IoT from a technical perspective, a horizontal standard that would build upon the work in the vertical standards. The work there is still ongoing. Of course, the NISTA 859 series of documents, which is really important, and it is going to walk us through a little bit of the technical background there. The work there continues. Specifically, we are now focusing, NISTA is focusing on building upon 859A and building that federal profile, the baseline capabilities for the federal sector as part of the implementation of the IoT Cybersecurity Improvement Act. The work continues on establishing our international standards, our harmonized standards to avoid fragmentation on technical security baseline capabilities. I'm one of the co-editors. This is happening at ISOIC at SE 27. We are benefiting from the perspectives of multiple standards and efforts that are coming together there, including, of course, from the European perspective at SE 35645, and of course, the work done by NISTA 859 and CTA 288. The role of vertical standards is still under rise. We all understand that this is a very complex ecosystem, and therefore, there is going to be a role for technical standards on security that are really targeted and tailored for the needs of a particular sector, so for OT, of course, 624 for free, for the consumer sector, FEO 365, and we are seeing basically how the horizontal standards are leveraging the vertical standards to work together in a flexible manner. Finally, the IoT security policy landscape continues to interact with other landscape that are developing quickly. We have the supply chain security conversation. I already mentioned one development in that domain, which is the executive order. Of course, there are many others. This would be continued focus area for policymakers around the world. There is a focus there on software provenance, software assurance, and the concept of the S-bomb, right? Software available materials is elevated as part of the executive order. There is continued focus on vulnerability disclosure practices. It can not a new concept in IoT security regulation, but we are seeing all of that coming together. Of course, the conversation around confidence measure. Not just what are the requirements or what are the potential capabilities you should expect in IoT devices, but how this is being communicated or measured. That's the conversation about certifications, declaration of conformity and labeling, which is on the rise. Specifically, one element of the executive order is a pilot program on IoT security consumer labeling that is going to be led by the FTC. Again, very interesting executive order. I encourage you all to check it out. There is a section there on IoT in particular. Of course, this policy conversation ties in with a broader concept of data protection, machine learning, and AI-transforminess that is continuing to be evolved. We have, of course, a new proposed regulation in Europe, the EU AI proposal for how they're going to approach AI regulation. You're going to hear a little bit more about from Ria about the concept of AI-transforminess. This is just a little bit of a mapping, an eye chart on how everything is coming together. You're seeing on the left the developments on both the legislation side, the passing of the IoT Cyber Security Improvement Act, how it connects to the implementation work done by NIST, including the federal profile. You're seeing the contribution from the standard domain that the consensus-driven processes by the council to secure the digital economy, the C2 effort, how it fits into development at both A259, but both are work at ISOIEC to establish that horizontal international standards. And, of course, on the right, some of the developments in Europe and how they, with the implementation of the red directive, the red directive, we're going to see even more focus on technical standards coming from IoT and how they are contributing and connecting to a work at ISOIEC. Just as a reminder, we've been talking a lot about this concept, NIST8259. I encourage you also to check out the presentations from many presentations by NIST on this topic. This has been a wide industry consensus effort to develop that baseline understanding of the IoT security capabilities. It benefited from the work of the council to secure the digital economy to establish that consensus on the technical side with a wide participation from all the trade associations and other groups you're seeing on the left. And that technical baseline, it's a 100-page document, check it out, has now matured into a CTA-led technical standard that is providing more insight on how to implement this for engineers that is also contributing to the development of ISOIEC 2742. I'm also excited to announce here something that was recently published to call your attention to this document. It's a consensus around IoT security policy principles. Again, work by the council to secure the digital economy, building on their consensus on the technical side and basically pulling together a number of policy principles that can help inform policymakers as they go about how to potentially design a regulation for IoT security, very wide consensus with international participation. It's a six-seven-page document. You can check it out. It talks a little bit about the policy principles like design neutrality, flexible adoption of technical standards and the like, and translates these concepts to the policy domain. With that, I would like to invite Anne to walk us a little bit through the NIST documentation. It's a code 8259, cybersecurity activities for IoT device manufacturer. As you can see here, the target is a manufacturer. It's about the steps that manufacturers should be performing when they introduce their device to the market. NIST emphasizes here the message the IoT security shall start early on. It frames the security actions around the IoT device lifecycle, bridging the manufacturer and customers. The proposed framework is very important. NIST identifies six specific recommended action, cramp market and post market. This is reflecting the principle of security by design. It requires manufacturers to analyze the customer's expected use cases, their needs and goals, and also create that communication channel with the customer. You could see here SDL, vulnerability response, software update, device retirement, highlighted, and those are important functions that need to be baked in early on in the product development. Cyber security core baseline is the technical core of 8259 and it is prescribed that both manufacturers have to provide to customers to fulfill their requirements. So now let's look closer to that core baseline capability recommendation. NIST proposed six device capabilities as IoT device security baseline. The first one is device identification. This refers to creating a capability during device manufacturing process so that IoT device can be uniquely identified to both logicals, such as digital certificate or physical, such as unique device number identifiers. Unique device identification allows device to be authenticated, managed, and are necessary to restrict their access to authorized entities only. Next is device configuration. The ability to change the configuration of device software after it's been deployed allows device manufacturers, integrators, and users to upgrade security retroactively and customize functionality for deploy environment. For most devices, certain parameters will need to be changed or updated once device has been installed in the field. Moreover, security flows are often discovered after the device reached the end customers. Next capability is data protection. To work properly, IoT device must be able to send, receive, and store data. It is vital for device to protect this data and have the robust mechanism for identifying and restricting access to authorized users only. As we mentioned, IoT is about data processing and the amount of data that IoT device stores and transmits makes them target for the hackers and that drives the necessity for strong crypto protection to ensure the data integrity and confidentiality. Next capability is logical access to interfaces. NIST recommends that IoT device have the ability to provide access only to authorized entities and should themselves only be able to interface with trusted networks. This is supposed to limit the possible access point and reduce the number of attack vectors available for the hackers. Next category is software updates and there is no doubt that this is a fundamental requirement. It describes ability for the manufacturers or integrated to remotely or locally update the IoT device system after it's been deployed. Updates are essential to provide device operation and functionality and fix the firmware software vulnerabilities as it gets discovered. And the last capability here is the cybersecurity state of awareness and this refers to device ability to recognize and communicate its own cybersecurity status to authorized entities. The thread indicator should be robust enough to prevent it from being altered or sending false messages to the back end servers. For device manufacturers and operators it's important to have that process to determine if device are operational, functional as a specific and flag any possible compromised device. Let's see how NIST 8259 portfolio expanded. This picture outlines the evolution of NIST activities that extended the range of full guidance for IoT cybersecurity. Of course the primary goal here was addressing IoT device security and privacy controls for federal systems. We reviewed 8259, 8259A and A and B are the complementary pair, providing the balance of technical and non-technical requirements and giving more comprehensive guidance for manufacturers and executing the six activities called out earlier in 8259. The new 8259C is quite interesting. It describes the methodology that can be usable by any organization as a do-it-yourself toolkit. It's based on core baseline provided in NIST 8259A and B and explains how to integrate the baselines with vertical or application specific requirements and develop profiles suitable for specific device usage. This can be used for customer vertical segment requirements, industry standards or regulatory guidance. NIST 8259D shows the result of applying this methodology in federal government customer space. It's supposed to address the requirement of SP800213 that provides the guidance for federal agencies who plan to integrate IoT devices into their systems and infrastructure. It answered the question what are the abilities and actions that federal agency will expect from the IoT device as it's manufactured and third parties respectively. This framework leverages the SP8503 security and privacy control and newly created updated catalog of cyber security capabilities. Again, you can see on this picture the main idea here is to connect customers and the manufacturers to the side of this guidelines. The expanded this portfolio don't only demonstrate how to address the IoT baseline requirements for the federal vertical segment, but I think it's also very interesting to see the tools that they provide to the rest of the industry that can be leveraged for their specific usages. As I made a demonstration, there is no lack of initiative to address IoT security. However, how to bring the balance in every evolving world of IoT? How to establish the confidence in the IoT device and the results that the device is producing? Industry was pondering about the question of trustworthiness in the equilibrium between expectations and risk. Let's understand what is the trustworthiness. Here is the definition of trustworthiness as it was defined by industrial internet consortium. As you can see, trustworthiness closely ties to the confidence. So, trustworthiness is a confidence that IoT system will operate in conformance with the requirements results from assurance that several characteristics of the systems are compliant with this requirement despite environmental disturbance, human errors, system faults and attacks. On May 14, NIST published an essay on IoT device confidence. The purpose of the essay is to start a conversation about what it means to have confidence in IoT devices used by individuals or organization and the various ways of gaining the confidence. There are six roles outlined in the ecosystem of IoT transport. First is the customers of the category of the products. Next is the advocacy group that would watch out for the customer interest. Then we have manufacturers who produce the products. Regulators are mandating requirements for a particular market or category of the product and enforce them. Next would be the SDON industrial consortia that develops specification and requirements for the category of the product and establish consensus or industry standards for that category. The last one is a very important body is the conformity assessment body that measures the conformity of the product to select the standard or regulation and provides certification indicating a level of conformity which in essence means the measuring the conformity or in this case the measuring the security of the device. The size and diversity of the IoT device marketplace demonstrates the need for a variety of confidence mechanisms depending on the type of IoT device, use cases and the risk-involving operation. Specific confidence mechanism will be the best choice for a distinct situation bringing together communities of interest around particular device types and market segments and identifying the best confidence mechanism will need to be worked through a variety of forms. On the right side you can see the picture that outlines the relationship in that ecosystem of trust. Talking about the measuring the conformity, the question how it's going to be structured. So this is proposing to leverage the trustworthiness of the cyber physical system framework. As you can see it basically bridging the stakeholder perspective with the result the notion of trustworthiness. So it includes the aspects as you can see on the picture and those are high-level grouping of cross-cutting concerns. Concerns are the interest in the system relevant to one or several stakeholders. Here you can see functional, business-human, timing, data, life-cycle concerns. Facets are a view on the responsibility in the system engineering process. They contain well-defined activities, artifacts, or output for addressing those concerns. Here there are three facets identified. The first one is conceptualization facet that captures activity related to that high-level goal, functional requirements and organization. Next is the realization facet that captures the activity surrounding the detailed engineering design, production, implementation, and operation of this system. And assurance facet deals with obtaining the confidence that device built in the realization facet satisfies the model developed in the conceptualization facet. The activities include evaluation of the claims, argumentation, and evidence as required to address the important requirements of design, policy, law, and regulation. So the core of this of course is trustworthiness concern. And let's take a closer look to those trustworthiness concerns. Priority trustworthiness relies on five closely connected concerns or attributes. Safety, security, privacy, reliability, resiliency. Those attributes defined by several SDRs, the standard bodies such as ISO, IEC, JTC, SC41, NIST, as well as the industrial internet consortium. Let's take a closer look. So security as we all know is the condition of the system being protected for unintended or under rise access change or destruction. Safety is an acceptable risk or physical injury. A damage can be caused by the system to the health of the people, either directly or indirectly. Relability is the ability to perform its required function under state of condition for specific period of time. Resiliency is the ability to withstand abnormal conditions and reconstitute to operational capabilities after the casualties. Privacy is the right of individual or group to control or influence the information related to them, how it will be collected, processed, stored, and how it's going to be disclosed. So if you look at these concerns, we can see that security is in the center of this picture because it has a dual role. So it represents the concerns, right, or attributes of the trustworthiness and it provides the underpinning for the rest of the attributes. Security failure in the device has the potential to undermine all other trustworthiness concerns of the device. So we are with the trustworthiness with building that both trustworthiness, they are entering a new field where security of course needs to be formalized, needs to be measured, but also this additional aspect of the reliability, safety, and resilience, right, it needs to be also comprehended. So far we have been looking through IoT device lens, through the security policy, baseline definition, trustworthiness of the device, right, but let's switch here now and look from the workload perspective and specifically bring the AI machine learning flavors to IoT device. So I'm inviting Ria to share her tools from AI ML trustworthiness side. And now I'm going to dive into the implications of IoT trust readiness for AI systems. So as we've elaborated throughout this presentation, we're seeing a lot of the critical trustworthiness elements applied for the IoT ecosystems. Now let's look into the applicability of these elements for AI pipelines both during the development and the deployment phases and why this is critical. Now what we've done is outlined the key characteristics outlined by NIST and their trust in AI publication on trustworthiness elements for AI systems. I'm going to call out these on a high level and some interesting considerations to share with the audience. From a core security standpoint, we're seeing security, privacy, reliability, and resiliency as the critical elements here. So as part of the incorporation in an AI pipeline, we may assume the incorporation of monitoring mechanisms in order to ensure the reliability, the resiliency of the system end to end considering the overall holistic pipeline, its inputs, outputs, and the processes made by the AI system. In addition to this, we may also consider some automated mitigation mechanisms that we can instill as part of this where we have some thresholds that we're putting into place based on robust definitions of these elements that are then used to govern the design. And during the runtime of the system, the processing mechanisms are similar of AI. Now similarly on this note, we're also seeing the core elements including explainability, safety, objectivity, accountability, and similar. So here this is also considering the idea of value alignment and alignment to the expectations of the users of the system where we are designing with our users in mind. This includes instilling abilities to visualize or interpret different components of the AI pipeline as part of the explainability or transparency component, accountability in terms of being able to provide documentation, logging, and similar capabilities. So users are aware of where data is being generated, are able to leverage provenance types of capabilities to keep track of how their data is being used, et cetera, and some additional implications. Now on the last component, accuracy is a very interesting point to consider in the context of trustworthiness. Performance metrics such as accuracy are used in the design and the development of AI systems very carefully because these performance metrics need to align with the outcomes of the system and the user expectations. This is how we would go ahead through the different suite of metrics that are available for a particular use case in a particular data modality and pick the metric that we're looking for. In the trustworthiness context, this is especially relevant because we are designing the selection of performance metrics or the creation of new metrics in order to reflect these other vectors as well. Incorporating trustworthiness is a key output of the pipeline and not just considering about the accuracy or the overall performance of the system, but also these separate capabilities. So for example, this may include preferences of models that are more explainable, transparent, and reliable over models that have higher accuracy given that they adhere to these trustworthiness elements or guidelines and are sustainable for longer term considerations. In addition to this, it's also interesting to consider the differentiation of machine learning pipeline assets and data. So what really differentiates AI assets compared to general data protections and security and trustworthiness considerations for data in IoT ecosystems? Now AI is adding a layer of complexity to this. One of the ideas for answering this question in terms of what's the difference between a machine learning model asset that can include data exploration, data preprocessing, AI model, parameter selection, hyperparameters, performance metrics, etc. What differentiates the security, privacy, reliability, explainability, all the trustworthiness elements lens of these assets compared to general data elements considered as part of the IoT ecosystem? Well, there are some interesting considerations in terms of the added complexity. AI is a consumer and producer of data, and it's constantly interacting with its environment. So I wanted to focus on the component of characterizing the behavior of data and how it can be different from a traditional data element that we're considering in the IoT ecosystem. So with AI systems and in particular continual learning, the particular interesting implications we're seeing for IoT ecosystems with that AI flavor includes concept and data drift, where we're considering the target variables that we want to predict changing over time for concept drift. And similarly, the very features that we're leveraging for making predictions where the AI system is leveraging also changing over time in terms of data drift. Now even more kind of going further based off of that, we're also considering catastrophic for getting as part of this interesting added complexity that AI is offering, where AI models sometimes have the tendency to abruptly forget information that they previously learned upon learning new information. Now this is generally fixable or accountable for in typical machine learning development and deployment environments, but if we start to consider this in the place of IoT ecosystems such as telemetry applications and similar, when you're starting to evaluate and pick or select different AI models based on their adherence to these trustworthiness elements, it's also critical to see how the environment is infecting our AI models. And with concerns such as catastrophic for getting and concept and data drift, we're starting to see that these will be key implications that are adding in to the concerns and adherence of trustworthiness elements. If we have a model that we consider to be reliable based on a definition provided by IoT trustworthiness, but in the context of catastrophic forgetting is quickly losing quality of outputs and degrading and performance due to these mechanisms. This is something that we should incorporate as a quality or a behavior of data and AI system. Now in addition to this, again going back on that note of characterizing the behavior of data, generically we also have different types of data uncertainties that the system will be able to account for. Now some of the questions as part of this may include, you know, what are the mechanisms that again adhere to trustworthiness but also do not degrade the performance of the system at large that can account for these types of uncertainties. And these may include systematic and random data uncertainties, alloteric uncertainty, which is now being used in the subset of spaces in AI in order to represent natural stochastic uncertainty associated with data, and epistemic uncertainty, which is uncertainty that can be considered as a scientific uncertainty in the model of the process due to factors such as limited data and knowledge. So being able to account for these different types of data as part of the design of our systems, whether that be, you know, telemetry applications or similar is key. Finally, in terms of dependable logic and composite systems, we're starting to see AI systems influencing each other going back to my point on AI consuming and producing data on a regular basis and evolving its representations over time. So here when we start to see different AI systems depending on each other, we're again starting to see some definitions of IoT trustworthiness and similar getting impacted and being changed in relation to this. So if we have, for example, multiple agents, let's say reinforcement learning algorithms working in parallel and being able to feed data from each other and learn from each other, if one algorithm fails, then how would the other behave and what are substitutes that we can provide for the data that it's expecting, the actuation capabilities and priorities that we're giving these etc. So the prioritization definition of these trustworthiness elements in relation to AI algorithms deployed on edge devices in the cloud, raise a lot of interesting implications and open research and development questions that I've addressed here. Now I'm going to hand it back to Amit to understand more about the lessons learned from this presentation. Okay, so we have given you a lot of information, but all these reports, these developments we'll be talking about, you can find more information online. And let's focus on some of the key lessons from this journey. So first of all, our policy landscape continues to evolve. We have seen developments there. The IoT security policy landscape is definitely informed by developments in the supply chain conversations and the executive order is one example. We have also seen the rise and focus on measurable security practices or proposals around regulations or other policy vehicles for IoT. And specifically, the increased focus on labeling and certification, that is a key component of what's happening in the landscape. And we have also seen how IoT trustworthiness, the broader concept of trustworthiness is impacting IoT security and how the AI trustworthiness conversation is fitting together with the IoT security conversation. In that regard, there have been, of course, some notable policy developments in the area of IoT trustworthiness. One of them is the proposal for the EU AI regulation that is already released. Finally, we have seen the standard conversation. The framework, the conversation continues to evolve. NISTAR continuing their work on A259, specifically being in their federal profile. The community coming together in the technical standards at ISOIEC but also CTA 288, many developments there that will continue and inform the policy conversations. And of course, this reminds us security comes first and I'm very passionate to be working at security in Intel because part of our efforts here on IoT security is building that technology foundation to support the capabilities right from the hardware app is our collaboration with our industry peers in the standard bodies to develop our understanding around IoT security from the technical perspective. It's our collaboration with the ecosystem, with the IoT partner alliance that Anait mentioned as well. And of course, is our work with the community, our working with the community as part of our core availability disclosure practices and the like because we know collaboration with the community is a big pillar of security and IoT security specifically as well. Disengagement continues to be a key priority for us. We are really focusing on developing those partnerships. And for me, personally, the partnership with this community, the security research community continues to be top of mind. We do so through our vulnerability disclosure program, for our back bounties, for assurance practices and the work we do with the entire ecosystem on core vulnerability disclosure. And we encourage you to partner with us, check out our Intel bug bounty, check out our efforts in the space, check out our vulnerability disclosure program, and come work with us to find potential vulnerabilities. So big takeaway, collaboration, the lens continues to evolve, the complexity is under rise. I'm excited to be collaborating here today with Ria and Anait. And I think our collaboration, both with our industry partners, both as we build the technology foundations on security from the bottom up, both with policymakers as they go about considering how to regulate IoT security and both with this community, the security research community to work together to secure the ecosystem continues. I leave you with that message. We are very much excited to be collaborating with the IoT Village at DEFCON. And please keep the conversation going with us, check us out on Twitter, and have a wonderful rest of Hacker Summer Camp.