How Risk Executives Are Managing New Firmware Threats

A very warm welcome to our audience worldwide. My name is Rick Garrett, and I'm honored to serve as your master of ceremonies for today's CyNet Connect event. Firmware, firmware, firmware. It's in every computer, every cell phone, every router. It's in your doorbell. It's everywhere. And questions about who developed it and how safe it is and how it works is the topic of today's CyNet Connect event. Connect event. To kick us off, it is my honor to introduce the chairman and founder of CyNet, Mr. Robert Rodriguez.

Robert?

Where is everywhere? Um, during the session, we will discuss the apparent collision between new firmware oriented attack vectors and traditional cybersecurity tools, roles, and boundaries. And I'd like to start with David introducing yourself, and we'll go down the row. David Han, please.

Thanks, Robert. Glad to be here. I'm David Han. I'm the CISO for CDK Global. We're an automotive SaaS company. Been doing CISO work for many, many years, so glad to be part of this panel.

Thank you, Yuri.

Thank you, Robert, and pleasure to meet my fellow panelists here. Yuri Beligin, I'm CEO, founder of a company, Eclipsim, protecting hardware infrastructure and hardware supply chain. Prior to founding Eclipsim, I spent 11 years at Intel Corporation in various roles, building security technologies, finding vulnerabilities in hardware and firmware that Intel builds and researching threats. Glad to be here.

Thank you, Gary. Thank you. Steve Oran.

Thank you, Robert. I'm glad to be here. Steve Oran. I'm the federal CTO for Intel Corporation, where I drive all of our engagements around technology with the federal government, and I have a 26-year background in cybersecurity and security-related research and startups.

And thank you for bringing that knowledge for today's session. Over to you, Matthew.

Hi, Matthew Rosenquist. I'm CISO of Eclipse, cybersecurity strategist, and also a former employee of Intel where I managed security operations center, and I also managed the security roadmap and strategy for the security of Intel's core CPUs. So 30 years in the industry. Pleasure to be here today.

Well, I'll tell you what, we've got an all-star panel of subject matter experts. So thank you, Matthew. And over to my friend Malcolm.

Hey, thanks, Robert. Malcolm Harkins. I'm Chief Security and Trust Officer with an early-stage cybersecurity company called Epiphany Systems. Prior to that, I spent time at Silence as Chief Security and Trust Officer. And prior to that, I spent my life at Intel straight out of graduate school, and I was worldwide Chief Security and Privacy Officer for quite a while.

So, Malcolm, I've known you the longest here. Well, David Hahn and then you, I think. Why don't we start off with you and give an overview of where you were, firmware was, and where it is today and where you see it headed in the future?

Yeah. You know, as I mentioned, I spent a couple of decades at Intel, so I grew up at the foundation of computing, right, where sand turns to silicon and then everything above computing that we've seen grow and evolve for decades rests on, on silicon. And when I tripped my way into security 20 years ago, actually this month, after 9/11 and Code Red and NIMDA, when Andy Grove was still running Intel, and like his book, Only the Paranoid Survive, he impressed upon us that we needed to think about everything that could occur that could create catastrophic-level issues, not only for Intel, but more broadly across the ecosystem. And so for me, from, from those early days, from a business background and then finding my way into security while I was managing operationally the issues on the IT side of things for years before I started taking over product security, I always worried about that foundation. I always worried about the programming that, that could alter the structural integrity of everything above it. And, and I've seen for years, and, and I'll be pretty blunt, I think the compute industry by and large during most of that time period ignored it. They thought it was an esoteric risk that only very, very unique individuals might go play around with and do something nefarious. But we started seeing 15, 16 years ago researchers start going into this space and, and we started focusing on it. But it's always been a significant worry for me for quite a long time.

And so you mentioned— I'm staying with you, Malcolm— programming and frameworks. Is it more serious because the attacker is more sophisticated today? Is that what you would say?

I think it's more serious for a couple things, a couple reasons why. One, what I'd say the ignorance with respect to things below the operating system, broadly speaking, that many in the industry have just ignored it. That creates a ripe capability for threat actors and threat agents to go look into a space that by and large was ignored. You know, so if you go back 15, 16 years ago, yeah, I think it required unique skills, but nation-state actors were dabbling in that space even back then. IT organizations, for the most part, have not addressed this issue. And as we talked in the opening item from Rick, I mean, firmware's in everything from, you know, my thermostat in my house to my smart TV to a printer. Let alone the PCs, servers, anything that computes has firmware in it. And so because of that ignorance in that area, we didn't get in front of that risk curve. And by and large, many are still discounting the implications of it today. And those that do, I think, are going to suffer potentially grave harm as we go forward.

You know, you bring up a really important point because it's so pervasive, but anything foundational in life you really need to pay attention to. And I want to go to Matthew and ask you, what is the relevance of firmware to cybersecurity risk?

Well, it's huge. But again, as Malcolm said, it's been ignored. It's kind of been that redheaded stepchild. And if we think about any computer as kind of a stack, right, where you've got hardware at the very, very bottom, the hardware has to communicate communicate with everything. And that's where that firmware sits, right above that. And above that, you might have virtualized memory managers, operating systems, applications, data, all that other stuff. And where firmware sits, it's in a unique position because it can see everything going on above that stack, but things above really can't see what's going on in the firmware. So although it's tough to hack, Once you're there, you have an unprecedented level of visibility and potential control over the system. And it's simply not sexy, though. The industry is always focused on vulnerabilities in operating systems or application or data hacks, right? That's where our mindset has been. And we've largely ignored the importance. And when attackers get in, they get 3 benefits. They get the benefit of that control and visibility and what's going on in the system.

Right?

The second thing is they get to hide. They get to be very stealthy because, again, that, you know, anti-malware software doesn't really get to see what's going on in the firmware. So if you're hiding there, you're not going to get seen. And that leads to the third aspect is persistence. Attackers want to attack something and stay on the system, even when you turn it off, even when you reboot it, even when you blow away the operating system and reinstall. Everything, you can remain persistent. That's why attackers are moving there. It's not easy, but as the tools and everything get developed, it becomes easier for everybody to go in there. And we're seeing more research, we're seeing more vulnerabilities, we're seeing more tools. This is really important, and it can no longer be that area that we ignore. We just can't afford it.

And Matthew, in, in terms of geopolitics and you know, we've moved from globalization to populism to nationalism. You see what's happening in the South China Sea and Taiwan, China, et cetera. Do you believe that this is a greater opportunity seen by nation states for attacks? And if we even went to a further escalation of physical and cyber warfare?

Absolutely. Again, you know, our world is turning digital. Everything, all the data, the controls and whatnot are moving to digital systems or are reliant on digital systems. So this is a strategic maneuver point for nation states for pushing policy, reinforcing, controlling internal or external entities, you know, placing pressure. And, you know, as Malcolm had indicated, it's in everything. Every compute device, every piece of hardware needs to have firmware in it. Therefore, if you can go in and you can control it and you can stay persistent, right, and cannot be evicted very easily, that's a perfect target for nation states. But it doesn't end with the nation state. Once a nation state has those vulnerabilities, develops those exploits, creates those tools, there's a trickle-down effect. The moment they use those exploits, right, it gets out into the wild. And now you see cybercriminals pick up those things, tear it apart, and use pieces of it. So it isn't only relegated to nation-state hackers. Once an attack, an exploit is in the wild, it's fair game for everybody to use. So we're going to see this type of exploitation cascade down to many different types of threat agents.

Steve, I want to kind of touch on what Matthew addressed as ignoring firmware and, you know, the VCs. And I'll make a a recollection of a comment by General Alexander, probably about 2011, 2012. We were at West Point for a workshop. He was then director of NSA, and he said the app was the Achilles heel, hence kind of the attention that people were giving back then. From your perspective, how do you see this evolving?

Well, I think as you mentioned, everyone looked at what, what was right in front of them, the weakest link in the chain, the easy attack point, which has been application-level security and data. And that's what you hear a lot of the news about. What Matt and Malcolm have been really hinting at is there's this underlying problem, which is again the firmware, which hasn't been in the purview of the public. It's not the easy thing to go after, but it is the thing once you go there, the attacks can be pervasive and can be very stealthy. And so I think— I don't think General Alexander was wrong. We, at the time in 2010 and 2011, we weren't focusing. We had just, you know, the industry hadn't done a good job yet on true data security end-to-end, on looking at applications. A lot of the technologies had been developed, they hadn't been deployed. I think we're in the same kind of case here where the IT organizations are lagging behind the threat actors. And so once again, we have something that's been a vulnerability for a very long time, has not gotten the focus, from the IT and from the best practices and controls. But that being said, I don't want it to all be doom and gloom here. It's not that, okay, we have to start from scratch and we have nothing to secure the firmware. There are technologies that have been available for many years. As Malcolm mentioned, oftentimes it's really nation-states, governments, and maybe financial services that really focused on some of these critical infrastructure, critical firmware security controls and capabilities. But they are there and the best practices do exist. They just have to be deployed. You have to recognize that you need it and build it into your security posture. And so I think that's been a big disconnect. Now, while there's lots more to be done, even the basic hygiene around firmware security, getting visibility into it, using the right tools and techniques, doing verification of the BIOS and the firmware upon boot and on regular checks, Those kind of best practices are well known. They just haven't been well adopted. And I think that's one of the key inflection points that we should be talking about here is about getting that to be de rigueur inside IT organizations, just like doing patching, just like deploying firewalls and other security controls throughout the enterprise. Firmware security needs to be on that same par and that same level.

I do believe what General Alexander said back then is even more true today with the digital transformation. Journey and shift left and all that comes with it. I want to stay with you for a moment, Steve. What can the hardware do to help with firmware security?

It's a very good question, Robert, and I think many of us on the call here have spent time at Intel or at other hardware organizations understand that at the end of the day, the thing that's immutable is the hardware. So if you wanted to start to build your trust, you start in hardware. And there's a concept called hardware roots of trust. And basically it's being able to leverage features or capabilities in the hardware to be able to measure and validate the firmware and ultimately to the operating system or hypervisor that loads on top of it, even into then the application space. So step 1 is verifying what you have, and it can be as complex as a multi-chain hardware root of trust on a PC or server. It can be as simple in a smartphone of having the firmware be signed and verified upon load. So there are techniques that are already available in hardware across the ecosystem that allow you to verify what you have. And that's baseline. That's just knowing that I started secure. And then from there, what you want to look at is being able to get that attestation, be able to verify that and then communicate that information to policy, to orchestrators, to your risk environment, to your threat feeds so that you can keep track of that security across the lifespan of a given device. And across the enterprise. And that's where tools and technology working together with hardware need to come and be deployed. The challenge, and Malcolm sort of hinted at, and even in the beginning, is that there's just so many different types of devices out there. And while these technologies exist in PCs and servers and in cell phones and tablets and some of the more high-end embedded devices, there isn't a whole lot of security, you know, for the hardware in smart thermostats as there needs to be. Or in other kinds of IoT devices. And so part of it is an industry shift to really get firmware security and hardware security that enables it deployed at en masse to these low-end or really pervasive IoT devices.

David, to you as a practitioner, you're on the front lines. Your job has increasingly become more challenging for numerous reasons. From your perspective, how do you address this risk?

Yeah, Rob, so, you know, when I first started hearing about it, you know, and especially, you know, talking to Yuri, you know, gives me so much insight into this. You know, I went through those stages of grief, right? So first thing is just kind of like, ah, this is crazy, this is that, you know, and then you start getting into denial, like, oh, it won't affect me, like, I'm immune to this thing. And then you start going into deflection, oh, it's the supply chain problem, it's all the vendors, it's their problem. So you try to deflect because there's only so much I can handle as a CISO and it just keeps increasing. I got cloud issue, I got mobile issues, all these things that we're doing and yet this is another one. So it just almost becomes, I mean, just helpless that you feel. So after you kind of get over that, it's like, okay, I gotta wake up now. I gotta deal with these issues. Then you start kind of figuring out where can I, align this with what I do have from a functional standpoint? Okay, so my vulnerability team, can they handle this as part of the scanning? Well, the tools, do they have the right tools to be able to even identify? So I start going through that in terms of, you know, the piece. Okay, so the desktop team, you know, everything that was just mentioned in terms of practices, are they doing it? Can they do it? I'm trying to get them to a gold image and, you know, trying to get them to get some fundamental pieces in place. So it is very frustrating because it is clearly a problem, it is there, and yet for us to kind of move and change the company to better practices as we're trying to figure this out. So that becomes a hard part. So definitely it's a community, right? I need help from vendors, I need from security vendors giving me better tools, right, for visibility to be able to do patching. And then certainly the ecosystem, right? I mean, anybody who's creating any kind of an IoT device has to have this thing built into it. So there's no way that as a practitioner, I can literally tackle this, certainly not on my own. But what I try to do is in terms of instilling the awareness of it. So in terms of where will I be exposed? I probably have less exposure. Again, that's not a denial piece, right? Versus I'm thinking of my fellow CISO friends who have hospitals, right? I mean, these are life and death type of environments that they're in and the number of devices that they have there. Because any kind of a breach could impact lives. And those are the things that certainly concern me. But yeah, at this point I don't have a good answer to tell you, but I'm looking forward to seeing more solutions because of just the awareness of this so that there could be other startups or even bigger companies to start coming up with ways to handle it. And then certainly those who will create these devices, those who actually use the firmware, do a better job. Okay, come on, we all are impacted by this. So spend some investments into it. So let's improve the whole supply chain so that we're all benefiting.

Dave, so I'm going to stay with you again. As a buyer, do you feel that this is a nice-to-have or must-have, need-to-have bucket? Because as a, as a buyer or an investor, an entrepreneur, you have to be in that must, need-to-have bucket to move the needle.

Yeah. Yeah, absolutely. So that's a hard piece, right? So, you know, to your point, there's so many things that I need to get, invest with, and it's really hard to explain that to management, board, because like, why every time David's always asking for more and more and more? Why is that? Why does it always continue? So here's the challenge that I think that we as an industry, we have to have things much more integrated, right? So, you know, again, the typical vulnerability scanning tools that I have, those have been around for years. There's several good ones. You know, why can't this be incorporated to it? You know, discovery tools, right? In terms of Azure discovering assets, We should be able to catalog the firmware just as easily as we're doing operating systems and Linux. And, you know, so it all needs to be added into the ecosystem versus we do it for the core, most key computing, Windows, and then, oh yeah, firmware, we just ignore it.

Right.

So it's gotta be incorporated into it. And so, yeah, I'm willing to invest money into tools that we already have and how we can integrate that because yeah, no one's going to give me, you know, 10 more new resources and a couple of million dollars just on you know, the notion of me scaring them, right? So we have to do a better job of really explaining how this is all part of an architecture, it's part of a design, and we got to build it into the ecosystem, and then we got to make sure that this all works together. So that's the only way, because I mean, whether it's firmware or any other risk, that's the only way that I'm going to survive, is to be able to integrate these things together.

Thank you, David. Yuriy, I wanted to get your advice. This new breed of attacks targeting network devices seems to have surprise both network security and configuration and management teams. What do you suggest that you have seen and what you think to help teams get educated on network device attacks that focus on firmware as the initial target? Jury, you're on mute.

Well, there are two buttons, of course. Thank you, Robert. So, um, so we— it was a great discussion, and, uh, you know, we moved from, um, uh, you know, Malcolm and, uh, and Matthew, uh, mentioning that this problem has been ignored, and it has been. There, there There are many reasons why it has, you know, we saw nation-state actors exploiting firmware, and maybe that was not for everyone to defend. And now what David said is, how do I actually operationalize that? How do I integrate into my existing tools and frameworks that I've already been using to defend against all sorts of threats, all sorts of vulnerabilities? Because there's so many of these vulnerabilities that security teams are dealing daily right now, thousands of these. How do you prioritize that? Network devices is part of that, and network devices is important because network devices are front, you know, gateways into the infrastructure, into the environment. And that's why we're seeing now that almost every ransomware operator has been exploiting firmware in network devices, anything from Cisco and F5, BIG-IP, and Fortinet, and Pulse Secure, and all of these. So, but these are only part of the problem. I think a good approach was taken by CISA with their recent binding operational directive a few days ago, where they essentially said that, you know, instead of dealing with all those thousands of vulnerabilities and risks, we will help you prioritize the ones that are actively being exploited by threat actors. They're actively being taken advantage of. You can be breached because of these. And they published about 291 vulnerabilities. And so based on the knowledge about which vulnerabilities, which risks are being exploited, you can build, you know, priorities in your security program. You can build security controls that are tailored to mitigating those risks. And some of these are in you know, in application level and OS level and Windows, Apple devices, and so on and so forth. 50 of these are in firmware. Most of these are in networking appliances today. Some of these in endpoints and in mobile devices, but most of these are in networking appliances. So that's where you probably as a security team, as a security practitioner, need to spend first focus on.

Thank you. Thank you, Yuri. Malcolm, every day we think about risk and prioritization of our life, whether it's jaywalking or a yellow light. What's your perspective on organizations that are drowning with OS risks and vulnerabilities? How should they evaluate this relative to what is biting them today and how do they prioritize it on the totem pole?

Yeah, you know, it's the challenge I think we all have is this noise-to-signal ratio, right? Whether it be in the day-to-day SOC with the alerts or just the threat intelligence and everything being vulnerable. And Yuri mentioned the CISA publication. I think it was useful. I think it highlights for people where active exploitation of vulnerabilities are, which will help them. But, you know, you can't just say, "I'm drowning here, so therefore I have to ignore it." When I get to the point where I am unable to prioritize things, I look at it from what I call extinction events. What will cause my organization to cease operating? What will cause the maximum impact to the organization, my customers, my shareholders? I think when you start doing that, you can start looking at the noise of vulnerabilities and figure out which ones have the highest propensity to create the biggest impact. I think when you do that, you will likely find that firmware-related risks in some aspects of your environment are those category killers that would cause substantial issues for your organization and thus its mission and its stakeholders and customers. So, you know, for me, you can't just ignore it. You just have to get frank a different lens on looking at risk and get out of looking at the things that are just annoyances and look at those things that really are going to create a substantial level of material or significant harm.

Yeah, totally agree on that. Matthew Rosenquist, in the case of firmware vulnerabilities and toeholds, it seems like the bad guys are weaponizing firmware faster. Than the defenders are addressing it— TrickBot, TrickBoot, NetWalker, etc. To prevent that bad day, what would you advise other information security executives to do and to catch up on firmware challenges and fixes?

Well, kind of to build on what Yuri had said, we have to be able to prioritize, and that starts with understanding that risk. And a good risk practitioner won't be concerned whether a vulnerability or a risk is in an application or an operating system. They have to look at all of the risks. And if you're purposely ignoring vulnerabilities or exploitations in firmware, you're doing yourself a disservice. And if you don't have that risk picture, you can't prioritize. You know, and as Malcolm said, you know, extinction-level events, ELIs, you know, you have to think about that. Ultimately, when you're doing a risk assessment, you have to look at what is the likelihood that any vulnerability, whether it's in operating systems or firmware, what's the likelihood it's going to happen and what's the damage it's going to cause? And in firmware, it's a little bit different. Your operating system and applications, they're updated every week, in some cases many times a day. Firmware isn't. That IoT device that you're going to buy may sit in your factory or your home for many years and never get updated. So the attackers have that advantage. They can go after legacy equipment and firmware vulnerabilities that probably aren't ever going to be patched unless people have that as part of their risk assessment. So we have to take a proactive approach. I managed Intel stock, right? I had those millions of alerts coming in every day. Sucks and it is a very reactive, just have to put out every fire. We have to get out of that mode, right? Every CISO knows that. We have to be more proactive in understanding what are the risks coming. And if you're not looking, if firmware isn't part of that picture that you're evaluating, all you're gonna be doing is chasing the attacker because the attacker always maintains the initiative. And you know, when we see the reports come out, you know, from CISA and say, hey, these are the vulnerabilities that are being exploited. If that's what you're waiting for, you're already too late because when you see that vulnerability, chances are, especially given the rate of attack and how fast the attackers evolve, you know, you're behind the curve. So we have to get ahead. We have to do better risk assessments. It has to incorporate those risks for firmware. That feeds into a prioritization which melds and mixes in with the operating system and application vulnerabilities and the people vulnerabilities. It's all part of that picture and we have to act thinking smart, thinking ahead.

Steve, I want to go a little deeper on what Matthew touched on and let's specifically speak about version 3 of NIST 800-53. It had about 16 specific firmware references or requirements. The new version 5 has about 160, basically a tenfold increase. To what extent does that make it easier or harder, both organizationally and functionally, to champion and build controls at this sub-OS and sub-app level? And let me add White House Executive Order 14028. What are your thoughts?

So there's a couple of ways to look at this, Robert, and I want to build upon what Matt and Malcolm and the others have been talking about. One thing to be clear, whether it's the CISA report or a set of requirements coming out of NIST on the 853, if you're just doing checklist security, you're going to be behind the 8-ball every time. You're not going to be securing your systems because, like Matt said, if you're only doing the 50 that are currently being exploited, that means they're currently attacking you and you're already exposed. You're not even thinking about what's coming next. And so when the next 50 come out from CISA, you're still behind. So the way I like to look at it, whether it be the, the, the new executive order, and I think one of the key things when you peel back that executive order, um, in the NIST publication that came out about a month afterwards, they defined what was critical software. And for the first time it was written down, firmware is part of critical software. So in the past, a lot of times it was sort of where the software sit, the type of mission it supported, the operating system environment. Firmware was front and center this time as one of the key aspects of critical software. So the question you ask is really straightforward. What do we do about it? And what it comes down to, I think, is 4 key things, 4 key best practices upon which all these controls and the, the risk assessments can be applied. Step 1 is you got to know what you have, whether it be the, the process part about the inventory or being able to validate the firmware that's on the systems today, make sure that it's good. Step 2, just like you patch your operating systems and your applications, you need to patch your firmware when it is available. Matt made a very good point. Many firmware packages and systems don't get the regular updates that your applications and OS do, but they do get updates. The problem is oftentimes organizations aren't even looking at, how do I update, or what's the process for updating my firmware, or, oh, that's scary and hard, I'm going to push that out. So step 2 is patch your firmware with the same due diligence that you patch everything else. Step 3 is continuous monitoring. You've got to be able to monitor, and that means having the right visibility into the firmware to be able to know if there's a vulnerability. Are you— do you have that firmware?

Is it—

are you exposed? Is there a new patch available? Has someone changed the firmware? If you're not watching it, you can't secure it. And then the last one really addresses the big problem of the diversity of devices. Picking on the factory as an example, you may have devices and systems and IoT that is in there that has no patch, has been there for 10 years, and there's likely not going to be a patch. And that's where enclaving or segregation and microsegmentation can help you as well. So if you can't patch that device because it's too legacy or there's no support for it or they haven't figured out how to do patching, You can isolate it away from the rest of the network. You know, think about OT/IT barriers and put strong controls on who and what can access those systems to help mitigate the risk that they pose. These are best practices. And if you look at the NIST controls and the new 100+ that they put in there, when you boil them down, they come into those 4 key categories of what we need to do to better protect ourselves from the firmware risk.

That's a fantastic recommendation, Steve. I want to stay with you before I go to Yuri for a moment. I find this a really fascinating conversation. I'm frankly learning quite a bit in a very short period. I can't help but think that this is really going to get explosive at some point, if not already. I mean, thinking about the, you know, the 16 specific Wormer references and requirements and then moving forward in a year or two on a bell curve. Do you have a thought of where we are in terms of severity?

So it's a very interesting question, and I would look at it from two aspects. The severity of the threat, the things you can do with firmware is well known. And so we're already there. We've seen permanent denial of service. We've seen very persistent malware take advantage of firmware, both on PC servers as well as into IoT devices. There's a great example from a number of years ago. There was a set of hacker talks at DEF CON and Black Hat, And if you looked at all of the IoT devices that were targeted in that particular conference year, 100% of them at the end of their exploitation and their research, the last step was swap out firmware, do bad thing. Every one of them. And so that theme, that maturity curve in the hacker space is here today. So we are already there at the extreme side. Where I see we're still early in the crossing the chasm bell curve is in the IT adoption of the controls and the processes to secure that firmware. So that, I think we still have a long way to go to get even over the first hump of early adopters. We've got financial services, we've got certain key industries like government that are focusing finally on firmware, but we're still a ways off before we hit the upper portions of that bell curve.

Steve, when I think of Black Hat, I think of the folks there trying to outdo the other and, you know, having, you know, money spit out of an ATM machine or taking control of a Jeep. So this is the area where they have the most fun and excitement, right?

Absolutely. And whether it's seismometers that are deployed into the ocean, tsunami systems, to smart light switches, to now that you can do hack the satellite, you know, Maritime Hacks, they're doing the research on the embedded systems, on the compute systems that are driving boats and planes and satellite systems. The research is there. So we're seeing that threat, that maturity on the research side and on the threat actor, like everyone has been saying. What we haven't seen the maturity is on the IT operations side.

Yuri, your thoughts on NIST and the executive orders and our discussion here with Steve and Matthew.

Thank you, Robert. You know, I like what Steve said earlier, that this is ultimately a supply chain problem, and supply chain is a complicated problem. We have, you know, service providers, our suppliers, that we need to somehow manage risk from them. We consume a lot of software packages, a lot of open source, when we build our products. And part of that supply chain problem is all the hardware infrastructure that we acquire. All of those, you know, devices from IoT to large IT servers to networking switches. Enterprise-grade networking switch can be built in 16 countries. And, you know, a server may have up to 100 components running their own operating systems and firmware. So that we need to deal with that as a supply chain problem. And We, when we invest in controls at a higher level of stack only, whether it's a, you know, security controls at the OS level or maybe confidential computing or full disk encryption, if a hard drive that you are getting in a device has a modified firmware compromised to, you know, by a threat actor or maybe in the supply chain as a you know, as part of tampering with that device, then full disk encryption is not effective. If your BIOS UEFI firmware has been tampered with, then OS-level security controls are not effective. If your CPU has been, or chipset has been tampered with, or infected, running infected firmware, then the confidential computing solutions are not effective. And so this goes into fundamental layers of our supply chain and our hardware infrastructure that needs to be taken care of. And the 4 recommendations that Steve summarized are amazing. We just need to deal with that problem just like we're dealing with the risks, uh, with other parts of our technology and the technological supply chain. We need to have visibility, we need to patch, we need to prioritize risks that we patch, and we need to continuously monitor, continuously monitor for any sort of, uh, you know actors, malicious actors that have been tampering with the network, tampering with the networking, IoT devices and servers.

So I hear a lot of words today and I want to ask you, Yuri, envision a pyramid. What is the uber word? Is it supply chain risk management? Is it OT, operating systems, IT? What is the word? And then everything else falls underneath it, if you can.

It's firmware. Because it's everywhere, it's ubiquitous, it's in every device and in every supply chain for those devices.

Well, it's at the top of the totem pole then. David, do you agree?

Well, you know, Yuri lives with this much more than I do. What I see as the practitioner, as you say, is the supply chain problem, right? Because to me, I see that in just about everything. And guess what? All of us during this pandemic, we are learning a little bit about when the supply chain doesn't work, you know, and we can't get our doggy treats for our dog and it's something's behind. And my Amazon Next Day is now taking me 2 weeks. Like, oh my gosh, we can't do, you know, handle that. You know, so we are so dependent now, right? In the supply chain world. And there's just nothing, you know, that's gonna change overnight. And so that's the part that makes me definitely concerned about whether we can literally get the IT community to recognize the supply chain issue here and really start to act on it. So I think unfortunately, you know, it's going to have to take a few more really bad things to occur, right? You know, the Colonial Pipeline, right? You know, those are the type of things where it impacts people. And that's an unfortunate way that our security industry continues to operate, that we have to wait for those types of terrible things to happen and for it to begin to respond and make changes to it. But yeah, the supply chain piece to me is the hardest and firmware is definitely a part of that, but it just goes into all the risk that I see because I don't have teams that could do the research, right? To do more detailed analysis on any kind of software, let alone firmware. And so because I can't do that, I'm relying on others, I'm relying on vendors, I'm relying on the community. And, you know, the supply chain, you know, part of that. So we got to get to a better approach to that and, you know, keep working together because otherwise, yeah, we're just going to get hit and it's just going to be just random. So again, I hate to paint the bleak news, but that's the way that I'm starting to feel, which is like, I can't control this. Now I'm going to take a lot of the practice that Steve just talked about because I got to go to my IT team and say, hey guys, some simple things you could do. Why aren't we doing those? So those are the things that I will take back in terms of being able to, you know, utilize. To get through it. But yeah, this is definitely a big, to me, supply chain issue, and it's a big industry issue.

So let's stay in the same arena here. You're talking about the problem, but what recommendations do you give to the security team, and what do they think about IT ops vendor management to address these firmware risks? And any specifics?

You know, I look at in terms of, you know, the process, the framework that going through that one, this can be managed within there, right? So meaning I don't want to get into flood with my teams because then they kind of lose, you know, any sense of confidence that we can tackle it. So we have to be much more diligent, even more, right, from a monitoring, detection, and containment strategy, which is still effective, right? So that, yeah, if we happen to have some firmware that become a problem, we got to then look for those, right? So don't assume that that firmware is not an issue. In fact, we should do the reverse. We should always assume that it's a problem. Until we can prove otherwise. So I think this is always a chance to reaffirm with your teams of what their mission is, and that this is just yet another weakness that we have and another thing that we have to overcome. But for the most part, what I try to do is keep giving them as much tools, capabilities, but at the same time, stay diligent, stay to your core, and execute against those things, and we'll have a better chance. Now, how long can I keep doing that? That always becomes an issue in terms of the people get tired. So yeah, we do need automation, we do need better tools, better things like that. So I definitely want to put a shout out to Eclisium and what they're doing. We need more companies like that that really bringing this forthright and ability to actually recognize it and then do something about it. A lot of great things that can be done. So come on startups, all you founders out there, bring some solutions in and and we'll help you out.

And let's include the investors, the VCs in this equation as well. And Malcolm, I want to go to you on the same point. But David, do you see— what kind of growth do you see in this space with solution providers? Do you think they're listening, paying attention?

Was that to me or to Malcolm?

Yeah, to you.

And then I'm going to go to Malcolm.

Same topic.

I work a lot with VCs and really URI is the only company that, you that I've met and I've known you a few years, that's really tackling this. So it's not coming up often enough. And so certainly, you know, VCs are looking for where they see the sexy problems and where they see that they're gonna be able to get. And so, and I think it has to start with the founders, you know, people who are passionate about it. And then once they, you know, get their ideas out there, then the VCs will kind of come together with it. So I think it's up to all of us to really raise that. And then really even the VCs help them understand this that this is an opportunity, you know, from a business standpoint, an opportunity to fill gaps that currently is very few companies out there doing anything about it. So, yeah, hey, a good opportunity for them to jump in. And, you know, along the way, if there's a few founders out there listening with ideas, you know, I'm sure you would be more than glad to share his thoughts and then really get other companies to, you know, provide other solutions as well.

As I listen to the complexities and seriousness of the matter, I wonder if the reason why we have 4 out of 5 panelists, all former intel, that actually understand the nuances and depth of the problem. Malcolm, would you address that? And also on the totem pole, what is the uber word? The top of the pyramid here.

Yeah, you know, and you're right. And I think part of it, you know, for myself, and Matthew and Steve and Yuri, again, we grew up at that foundation of computing. So by nature of just where we grew up, we had exposure to it. So I think that heightened our sensitivity to it earlier than others. But the thing that, going back to the prioritization and some of the other items, if I put on my CISO hat and I pretend that I'm in any other organization, you know, accepting risk and acceptable risk are two different things. One's a business process, but it's not a control. And I think people sometimes confuse that. And, you know, we were in a dialogue back several weeks ago talking about macro-level enterprise risk with a bunch of organizations, and there was a financial institution that said their enterprise business risk, their number one board risk was fraud. And while that made sense on the one hand, I asked them about a ransomware attack at the heart of their trading platform that would cause them to be dead in the water and basically bypass all the above the operating system control issues. The way to do that would be through a firmware-level attack. And I'm like, you can't tell me that your board doesn't care about that. You haven't explained it to them in a way that gets them to understand why that's a relevant risk and why action should be taken to manage and mitigate it. And so, you know, for me, the relevant word or set of words is we've got to do a better job at architecting our choices. And recognizing we have a choice to make here in doing something about this. And if we don't, you know, that choice will make us at some point and we'll be on our knees suffering from an issue. And so will our shareholders and customers. So, you know, again, the choice is up to us. And the key word for me is choice. And you have to make one because if you don't make a choice, the choice makes you.

And I think I hear you saying a robust, secure, trusted, safe, redundant, resilient architecture, right?

From the, from the firmware all the way up to the user experience.

Absolutely. Matthew, your thoughts on the discussion? And it sounds like if we don't address this soon, immediately, it could undermine the trust in digital technology Absolutely right.

This is another relevant risk that unfortunately we've ignored as an industry. We've ignored because we've had squeakier wheels that we had to go oil. But as history has shown, wherever there is in the digital world an area that we have not paid the appropriate attention to, to secure and to manage the risks, The attackers go there, right? I mean, that's what they do. And they're very, very good at it. They're very adaptive. So if we don't start getting ahead of this, you know, as Malcolm said, it's going to put us on our knees. And we can ring the bell and say, "Hey, everybody wake up, wake up." But if, you know, the CISOs out there and the boards out there aren't paying attention and aren't taking it seriously, and we don't have the data and the communication to be able to share the concerns and integrate it into our risk assessments so that we know where our optimal level of risk is, where our target is, there's no way we're going to address it. So, you know, as Steve said, you know, he's got 4 great points and I'm all for them. You know, I'd like to add a few more from the CISO perspective. One, make sure firmware is part of your risk assessment process. If it's not, if you're only looking at vulnerabilities in operating systems and a few other— incorporate it in. And as part of that, also understand who's attacking you, right? If you're an organization where you really have to worry about nation-states, firmware should be very, very high on your list, right? The likelihood that they're gonna use that against you is pretty good. So understand that so you can define your goals and targets. The second thing is vote. Vote with your dollar signs, right? With your money, your paychecks, or your spending. We should, as every CISO in an organization, we should be expecting and demanding from hardware and from product vendors and IoT vendors, right? What and how do you secure your firmware? Do you patch it? Do you have the ability to? Right? Make it a purchase criteria because our industry moves with money. And if the customers start demanding it, now you've got a competitive situation where the vendors and the suppliers will jump in. And that's really how we change that supply chain environment is through money and spending. So let's use our wallets to, to vote. So that would be the second thing. And the third, is we know these are coming. May not be today, may not be tomorrow, but eventually your organization is gonna feel the pain. So make sure your internal processes, your response capabilities are in tune. So, you know, as part of either your annual, you know, tests or your crisis response. And part of that is if you've got IoT devices that are compromised, consider regular patching may not work. You may have to scrap those and have a plan for that in your environment.

So be prepared.

So I'm going to stay with you, Matthew, and because it really is all— it doesn't matter what investors invest in, what entrepreneurs build, it's what the buyer prioritizes. They drive the markets, increase the valuations, exit opportunities, etc. When you talk to the risk executives and CISOs, Do you have a sense of how important this is and is it a priority or what's your sense on that?

You know, we've got a saying in cybersecurity, you know, security isn't relevant until it fails. And many of the security professionals in the trenches, again, they're so busy putting out the daily firefights, they're not feeling that pain yet. But when they do, then it becomes a priority. So a lot of the discussions when I talk to fellow CISOs or to, you know, boards or to investor groups is to get that forward-looking insight to say this is coming and you can either be victimized by it horribly because you're surprised or you can start to position and maneuver yourself to where you're not going to be surprised or you can absorb this or you can effectively respond to it. And it really becomes that business choice, that choice that Malcolm was talking about, right? Where do you want to choose? Where do you want to be? Well, given that—

is one of the few. I wonder if other entrepreneurs or VCs think it's maybe too early. And I don't know. I'm just wondering about that. Have you thought about that?

Well, the perspective is either it's too early. Or something bad just happened and now I'm too late. So, where do you want to be on that spectrum? Do you want to be in early or do you want to be, you know, standing in the fire pit? You know, it's, again, it comes down to choice.

I believe it drives change to your point. It's Mothers Against Drunk Driving, Susan B. Komen. It's when pain is significant enough, it's when it drives change. And before I go to Steve, on the totem pole, the pyramid, what is the uber word or phrase?

It's risk management. This is all risk management, right? It just has to be— firmware has to be incorporated in. Most organizations have a risk process to assess that risk. Unfortunately, again, firmware has been outside that boundary for many organizations. Pull it in, right? It's a real risk that we have to understand.

Thank you. Steve, uber word or phrase, but, and then I want to ask you, are there device types specifically where the firmware presents a more substantial cyber risk to an organization?

So let's start with the word, and I, you know, I'm building off of what everyone else has said. Some people are thinking about being, you know, risk management. Is it supply chain security? I think the right way to think about it, it's about accurate risk management. And I think the key word there is accurate. Everyone's doing some form of risk calculus in their organization. The challenge is they oftentimes do not have accurate information flowing into that risk calculation, whether it be the firmware, whether it be the right processes, rogue IT. We find this across the enterprise and across the entire environment. So the key thing isn't that I have a risk calculus and risk management. You need to have that. It's not that I don't have visibility into my firmware or I'm beating up my vendors. It's about connecting the dots and making sure you have accurate information that flows in so you're making accurate decisions about the risk calculus. And firmware is one of those black holes today that we need to get that visibility into. So I think my top word is accurate risk management would be the way I would couch it. From an IoT perspective and really from a device perspective, This has been a challenge. I mean, whether you look at the NIST efforts around supply chain security or you look at, you know, 853 or other industries trying to figure out, do I say this piece of software is most critical, this system, or is it the thing that it does, or is it a combination of both? And I think what we found is that there isn't a good answer where if I go one way or the other. If you say the firmware is absolutely the most crucial, but the firmware is just controlling the lights, that turn them on and off, and it's not keeping the MRI machines on, then that firmware isn't the most important. The MRI machines are most important. So you can't just say it's the firmware. And if you say it's just the MRI machines, but you don't do the power generators in the basement, well, then you're, you're missing the boat there as well. And so it's really a combination of understanding the risk of a particular set of devices for the impact into the environment. It goes back to what Malcolm said, likelihood, and impact of a given device and the software running on it. That will be different based on each organization. The firmware that's running a laptop or embedded operating system in an airplane, it could be the exact same software stack that's running in a simulator at a training station. Same exact hardware, same exact software, very different impacts if that goes wrong. It's really about understanding your environment and having that be part of the risk calculus. So I wouldn't say there's IoT devices that are more critical than others, but there's places where those IoT devices sit and what they operate on make them more critical or not. And I think that's been our challenge is that we're looking— the industry in general tries to look for, give me a quick answer, give me a checklist. If I do XYZW, I'm done. And I think that's why if you look at the EO, buried in the bottom of Section 9 or something, it has— says zero trust plan. And again, zero trust is the buzzword for sure. But if you think about the approach of what does it really mean to do zero trust, and I'm not talking about the technologies or the process, it's all about not implicitly trusting things, but making a determination in real time and continuously updating that determination. That's the learning we should all have here. The risk calculus that Malcolm and Matthew and David were talking about isn't a one and done. The real way to solve this is to have a continuous risk calculation that applies the right policy at the right time. Because the lifespan of an IoT device or of a PC or server can change, or what you're doing with it can change. And so it's having accurate information for the moment so you can make the right determination.

In order to achieve that, you must know your environment. You must understand it. It's like the saying, Sun Tzu, I think it's, "Know thy enemy like you know thyself." Yuriy, from the customer perspective, Where do you see is working well? What isn't working well? When you think about the task of securing the firmware, should it begin with individual teams, as a CISO-level initiative, or in regulations and standards? Where do we begin?

Thanks, Robert. You know, I think going back to what Steve said about the prioritizing the risk, how organizations look at it, you know, the permanent security or supply chain security. It really comes down to, again, the criticality of the assets and impacts of the compromise of those assets. And for some organizations, the compromise of, you know, their thousands of new laptops that they purchase is critical. For other organizations, compromise of networking appliances, unpatched networking devices, that, you know, by ransomware is critical. So they, they choose to patch those devices and firmware on those devices as a result. So it comes, it comes down to really criticality of the, of the part of the infrastructure that they care about and the impacts of that infrastructure or compromise of that infrastructure.

What trends have you seen in the last 2 years or so in terms of the importance of what we're talking about and people actually taking action?

Writing checks, we talked about earlier. That actually hugely improved. I can say I'm happy. I've been sounding this alarm, you know, like the panelists here for a number of years when we saw, you know, folks that, you know, really brick infrastructure starting from nation-states years ago. But in the last couple years or even 18 months, things changed significantly. Out of roughly 44, there are 3 vectors that ransomware folks are exploiting right now: RDP, you know, using spear phishing, and then the networking appliances, all those load balancers and VPN appliances like like Pulse and Citrix and Fortinet. Out of the vulnerabilities, roughly 44 that ransomware folks are exploiting, 28 of them are now in those networking appliances, primarily in the firmware of those. So that has changed dramatically from zero 18 months ago to, you know, 28, 64% of all vulnerabilities used by ransomware. We also see the other limiting factor for us as an industry, as defenders, to manage security risk at the firmware level has been the perception that these are really complex attacks to do. They're absolutely not. They are— an exploit against a 20-year-old or 10-year-old firmware vulnerability takes one line. There is no rocket science there. We've seen, you know, Chinese actors weaponized BeckeriDK firmware exploitation framework that has been in public for 5 years. They weaponized it, probably took 2 weeks to do that, and they haven't been detected for 3 years. 2 weeks worth of effort to not being detected for 3 years. That's a huge ROI. We've seen same thing with the TrickBot operators first. They literally just, they took the same exact exploitation technique that the nation, the Russian nation-state actors have been using with their Logjacks framework. They adopted it and now they're exploiting UEFI firmware. It's simple. It's incredibly simple. So I think that So that's what has really changed in the last 2 years, year and a half.

Well, we're over a minute, but I want to thank all of you. And Yuri, congratulations on being a visionary and futurist. I'd like everyone just to have a closing comment, observation, recommendation. We'll start with Malcolm.

Start now. If you don't, it's too late.

Great. David?

Listen to Yuri.

Steve? Build the best practices to deal with what you have now.

Matthew?

You have to think ahead. This is part of that risk profile.

Well, I tell you what, I've done a lot of these sessions over, well, a year and a half, over a year and a half. This one was fascinating. I learned a lot, gentlemen. So thank you for your time, and I look forward to seeing all of you in person. Take care, everybody.

Thank you, everyone. Thank you, Rob.

Thanks.

Thank you.