Firmware Supply Chain Risks
In this episode, host Paul Roberts chats with Binarly.io CEO & Founder Alex Matrosov about supply chain risks via firmware.
EPISODE TRANSCRIPT
PAUL ROBERTS
So here we are back at another episode of ConversingLabs. This is ReversingLabs podcast where we talk about all things supply chain security, threat intelligence, threat analysis, malware analysis and I'm really happy to have in the studio Alex Matrasov of the firm, Binarly. Alex, welcome.
ALEX MATROSOV
Hello everyone, Alex Matrosov here and thank you Paul for inviting me for this podcast.
PAUL ROBERTS
We're really excited to have you on there. We have a lot to talk about you- Binarly does some really interesting research. You and I ran into each other recently at LabsCon, this great conference that happened down in Phoenix that SentinelOne sponsored ReversingLabs sponsored it too, Binarly sponsored it three. Tell us a little bit for folks who might not be familiar with the company.
ALEX MATROSOV
Let me start from my background and then I come to the company. Actually I can talk about the supply chain attack, comes down to the firmware and hardware and basically I started my career as a reverse engineer in early 2000s. I've been focused on reverse engineering advanced threats like root kits, boot kits. And of course, it's nature that comes down to some firmware stuff because basically, natural evolution of that hiker from the perspective of getting the persistence. Of course, it comes to the firmware and hardware because it's where you can persist and no security solutions can see you right? And I work it for Intel Corporation when actually I've been one of the senior security researchers focused on offensive security research for the firmware and silicon level treads and then actually I move my career more to GPU direction. I work a few years at Nvidia and build the offensive security research team there. I became a chief offensive security researcher which has actually give me a lot of background through the different type of attack surfaces. Start from the automotive, choose robotics and IoT automation with machine learning and of course GPUs and data center. And looking in the industry in general, I see all these repeatable failures are happening, like we have all these attacks repeating again and again, same type of vulnerabilities. And it's how with my cofounder Claudiu Teodorescu, we decided to start Binarly, seeing all these repeatable threats, like some sort of solution, and we don't see anything exist in the industry so far. And it's how Binarly initially being founded and what actually Binarly does is that's a question you just asked, right? And Binarly, it's very interesting company because what we try to do, we try to focus on supply chain threats, but from the different perspective a lot of people talking from the supply chain perspective on the source code level, on actual infrastructure level and others we focus down to the firmware and hardware where we actually providing deep code inspection. But not on the source code level. On actual binary level. Exactly what comes to the customers, to the devices as an updates or actual updates which has already been deployed. And we try to detect malicious activity. We try to found known vulnerabilities and also unknown ones. We call them known unknowns when the bug classes are really known for our platform. But we try to figure it out if something new can appears and that's very interesting problem to solve because if you think about like you have firmware update coming from the vendor but how you can trust this firmware update when you deploy into the power grid where you have like 5000 H computing nodes and basically if something goes wrong, what you will do, you basically deploy all this update on all these knots and then basically you can just disrupt the energy for a city. Right, right.
PAUL ROBERTS
The horse has left the barn as the saying goes.
ALEX MATROSOV
Exactly.
PAUL ROBERTS
So I guess let's define some terms before we go too deep down into the discussion. When we're talking about firmware, what are we really talking about as opposed to just the software that runs on applications or laptops that companies are used to thinking about in the context of security?
ALEX MATROSOV
I think that's a very good question and I would say we need to clarify what the firmware does but also of course depends on of the device. It can be a different purpose of the firmware and different type of the firmware as well. But let's start from the simple one, what the firmware is. Firmware, it is a software of course, and there's a middle layer between the hardware and your operating system which is provide some initialization of the hardware to actually boot your operating system effectively and efficiently for the usage of the hardware resources. But if you think about the modern laptops, of course you have many layers of the boot process and the whole operating system on X 86 laptops or servers, it is actually a real time operating system. The firmware is like over 6 million lines of code. I mean it's bigger than modern anthos kernel, right? So basically it's a very comprehensive layer of the software which has been historically overlooked from security solutions and it's not because it's not happening, it's more because we don't know about that. Right.
PAUL ROBERTS
I think most people think of firmware, they think of a really small software image that it's fairly basic in its functionality and hardened. So when you say wow, 6 million lines of code that sounds like a big attack surface to me. Firmware, when we talk about it, what types of functions or role does it play in the function of the device, whatever that is, whether it's a router.
ALEX MATROSOV
Even your airpods like have multiple firmwares, right? So you're using an airpod and this is very interesting because you have multiple sensor across this device. You have the firmware which is responsible for communicating with your laptop, phone like responsible for actual wireless communication over the bluetooth. Yeah, exactly. You have actual audio device in this embedded in your airpod here. Every year you have a separate device and this device has another firmware which is actually responsible for sound quality and others and for the microphone and actually this comes to the conclusion when we have the device which looks pretty simple but it's actually have a very comprehensive firmware inside and another thing like a trackpad, right? So this is also the device which every laptop has, right? And a lot of people don't think about. But this device has also the firmware. And this firmware can be tricked because in many cases I've been seeing trackpads' firmwares are not signed. So it's easy to modify easy to actually deploy on the trackpad and if you think about usually users workflow as example with financial systems and others it's like pretty predictable because we have same interface where the transaction should make and others. If you program this trackpad maliciously, it can actually create some harm. But unfortunately, not many firmwares consider it to be secure. We're thinking about some main ones but what about other ones which also can be used maliciously and basically I would say the firmware it is some piece of software which is provide in many cases inability to device- to program the device and their workflows and trackpad is a simple device, right? Probably it doesn't have like the whole operating system or probably a real time operating system and bent on its firmware but yeah, let's maybe like focus on some details, go down to the security level.
PAUL ROBERTS
So when we think about the larger software world, obviously there are tens of thousands, even more companies that produce and publish software. In the firmware space, is it that is it as diverse? Are there that many companies producing firmware is basically each hardware company making its own firmware? Or is it more consolidated where you have a few big companies that are making the firmware?
ALEX MATROSOV
That's a great question and this actually comes to the whole supply chain problem we have in the industry because nobody can produce modern laptop just themselves you have too many different devices embedded on your laptop: SSD drive, CPU, wireless baseband and many others even trackpad we just..
PAUL ROBERTS
Specialized pieces, right?
ALEX MATROSOV
Exactly all these pieces comes from the third party and sometimes even this third party is not responsible for developing the firmware. They have the contractors or some other third parties which is actually produce the firmer for themselves and for them. And that actually creates a very comprehensive and very complicated picture of the supply chain for modern device. And also let's just take the system firmware which is UFI firmware powering the laptops and servers. Basically we have intel reference code or AMD reference code. Then we have some public layer called EDK Two. Then we have middle layer between device manufacture and actual package of the firmware. It is called IBB. Independent BIOS developers like American, Megatrends, Insight or Phoenix which is producing this package to actually shortcut the time of the product delivery to the market. Because it helps to kind of like more generalize the platform code from what actual device provide unique features, right? And manufacturers like Dell, Lenovo, HP and others, they focused mainly to create the open device features and try to basically power their open device with unique capabilities in the firmware. This goes to the question how many original code developed by device vendors and to be honest it's not many lines of the code written by them. In general, like based on our statistics, it comes to 5-8% of the whole firmware package developed by device manufacturers. But think about it's actually 92 or even more percent of the code base comes from the third part.
PAUL ROBERTS
And may be more or less standard between different types of devices.
ALEX MATROSOV
Absolutely.
PAUL ROBERTS
So when we're thinking about Binarly obviously is focused on securing and identifying threats within firmware when we think about the threat landscape for firmware, the types of threats and attacks that might be targeted at firmware, what are we talking about pretty similar to other types of applications or is it really different?
ALEX MATROSOV
It's actually different and different by many reasons. Basically, from the attacker perspective, it should be much more comprehensive technical skills to actually develop such threats. But also of course, compared to modern operating system level mitigations, I would say the cost of such attack will be lower. To bind all this chain of the exploits need to be used for bypass modern Windows Eleven security features or modern hardware right? And I mean that's exactly what's happening and more and more different threat actors start looking into the firmware direction even the attacks are not new and I would say the state sponsored threat actors been using the firmware goes to early 2000s and also let's talk about recent discoveries like a moon bounds. Right. So moon bounds is a threat which has been based on Chinese firmware implant kit which has been basically been developed back to 2014, 2012 and actual industry endpoint solutions discovered this threat in 2022. Right, so basically like I mean...
PAUL ROBERTS
Ten years?
ALEX MATROSOV
Yeah, exactly. So it's pretty good level of persistent I would say if the tiger can get one month of persistent it's very huge timeline, about like ten years it's impossible. Right.
PAUL ROBERTS
So ten years you kind of own the company at that point.
ALEX MATROSOV
Exactly, yeah.
PAUL ROBERTS
And how are these attacks leveraged? If a typical attack on an endpoint higher up in the stack starts with maybe social engineering and account compromise and privilege escalation when we're talking about firmware attacks is the firmware just a later stage in a traditional attack or do the attacks actually target the firmware from the get-go?
ALEX MATROSOV
Of course it depends on the threat actors but basically it of course connects supply chain problems when doing the transition of the device. Some third party can have an access to this device and do something and basically this action can perform enabling some malicious firmware or deploying some malicious firmware on the device. This is more comprehensive attack because you need a physical access, right? But if we talk about the remote attack vectors, it's actually pretty much part of some exploit chain. And of course to deploy the modern malware you need to kind of push the user to run something on their host machine or they need to kind of like browse a remote code execution and then basically it comes with a payload. From the firmware perspective, you need some driver to communicate with some physical memory space to actually deploy the firmware on X 86 systems or exploit vulnerabilities on the firmware side. But also actual complexity of current IT infrastructure comes from modern devices. It helps to the attacker because if you think about Windows Management instrumentation, let's say you have 5000 users in your network, how you can deploy the firmware update to all of them simultaneously. You basically can't go visit flash drive to all of them and kind of like deploy an update. You need some solution for that. And of course in this case like Windows Management instrumentation and others deploying tools like SolarWinds as well. By the way, it helps IT people in the large companies to actually support their infrastructure, but at the same time it's open new doors for the attacker. For example, you can remotely disable secure boot on many devices. You can remotely deploy the firmware update and do other things. So basically that can reduce the needs of the driver where it actually comes down with some of the automation. And in 2019 on Offensive Con conference, I've been demonstrating some sort of attack vectors when we can call some firmware functionality from Visual basic script. That's pretty scary, right? Yeah.
PAUL ROBERTS
You mentioned how organizations are doing firmware management which is often just using traditional IT management platforms and tools like WMI or SolarWinds Orion. How aware are organizations of the threat or risks that firmware poses? Is it sort of like well, this is running below the operating system so we don't really need to worry about it? Or are they aware of these threats and trying to do something about it?
ALEX MATROSOV
First of all, it really depends on the type of maturity of organization. But if you ask probably like most of the thesis about their top five of the problems, the firmware is not in top five. But if you're talking about the critical infrastructure or some other very sensitive to the firmware threats companies it will be of course like at least in top ten and last year executive order and actual assessment report from DHS and CISA, it helps to push forward in awareness about the firmware threats in general. And I'm really happy about that it's happening because when the argument you're getting like, oh, the threats, it's not exist because we don't see it, or basically we don't have much threats being discovered publicly. But then your company reporting 100 plus vulnerabilities yearly, that's kind of like scary, right? Huge attack surface and nobody actually looking on that. That means it gives an attacker an advantage and it's why also Binarly team stand forward to actually help to fix such supply chain problems.
PAUL ROBERTS
I know that there was like earlier, I think it was over the summer, there were some or maybe it was even last year, there were some stories written that maybe the Conti Ransomware group was developing exploits for firmware as a way to advance their attacks. Have we seen this? Have we seen either cybercriminal or APT actors actively looking to exploit firmware vulnerabilities?
ALEX MATROSOV
From the perspective of the threats we currently seeing in the wild it's mainly on state sponsored actors but also we see the shift of the cyber criminal thing when I mentioned it. Like the cost of the attack on operating system level it's actually increasing significantly and then they need to figure it out something else and then basically it goes down to the firmware because it gives them technical advantage to perform an attack with more cheaper way if possible. Talking about the Conti and other I think it's been Conti, TrickBot, and most recent Black Lotus, but all of them actually contain a lot of information about how they wanted to use but nobody has these samples. I mean TrickBot probably it's been the closest one. They've been collecting information about your firmware security, about your configuration and machine and others. Most likely they've been performing some of the attacks. About the Conti, we don't have the public samples available, but I'm pretty much sure they did something and related to Black Lotus, that's most recent one which has been come from Register article by some Kaspersky researcher. But unfortunately we don't have any evidence about these samples are available or it is a real malware. So also we didn't find the Dark web, any sort of information related to this advertisement which has been mentioned on this article. What is also kind of weird for me it's been no evidence screenshots or something like which will show original source of information, right? Yeah, we'll see. But I like the name Black Lotus, but basically so far I didn't see any data points which can confirm the stress and actually exist.
PAUL ROBERTS
When we talk about ways to secure firmware from sort of hardened firmware or hardened organizations so they're less vulnerable to attacks on firmware that might be used. Visibility strikes me as, like, one of the things first, which is, like, you talk about three different types of firmware just in my airpods, and then you think at the scale of an enterprise, right, all the different IT devices with IP addresses that they've got deployed and all the different types of firmware that might be on them. So what do organizations need to do from a visibility standpoint just to understand what firmware is even in their environment so that they can kind of triage and prioritize it?
ALEX MATROSOV
Yeah, that's actually a very good question and it comes to classification of different type of devices, right? We have a network appliances which has a firmware and actually that hacks on such devices. It's happening in the wild with already known vulnerabilities from the CISA directory and other ones. It is IoT devices, right? Or our home routers and others how frequently they will get updated I think pretty rare and not because users don't want update even if you enable like automatic updates delivery the vendors unfortunately most of the vendors not frequently releasing and updates and these devices has actually contained the whole Linux kernel and also a lot of dependencies and basically BC Wake monthly it's a lot of vulnerabilities on this core, components get fixed, but basically it's not deployed in the field. What if like I have a vulnerable DNS library on my router and it can be exploited remotely, right? Basically. I mean, it's definitely need more regulations and we see that coming and it's more actual certification for IoT devices, even for the home routers. But it will take a lot of time and effort and also what we can do to fix these problems and how we can help ourselves. I mean, that's a very complicated question. Because if you go to the Best Buy and if you pick just a random router, I'm pretty much sure I can get the remote code execution of this device. Because first of all, it will be not the recent firmware and if it's not enabled and now to update and you could just power up on this device, it will be some sort of definitely like the list of known vulnerabilities there and actually in this case SBOM, software bill of materials, and all these dependency graph activities going on right now, which is very comprehensive on operating system layer, but it's not less comprehensive on the firmware layer. Where we need to get more attention too, because everybody talking like, oh, we need to actually create all these dependency graphs for operating system layer components. But what about the firmwares? What about the firmware when the firmware contains the whole Linux image inside? Of course it's not because Linux is part of the firmware, it's more about like this firmware package contained Linux image which is delivered as the same firmware update and it's updating the same timelines, right? So in my opinion, SBOM actually will benefit industry a lot but we also need to understand SBOM it's a dependency graph it's dependency graph between the libraries but basically what if the library is the most recent version but still contain the vulnerabilities? So it doesn't help you to check this vulnerabilities, it's help you to crucify what is inside. And another problem with SBOMs, the SBOMs can be provided by the vendor but you need to also validate SBOM if it's SBOM actually source of truth and maybe the vendor just forget an update SBOM and basically updates the software include new dependencies but it can be surprising.
PAUL ROBERTS
And a lot of the even the federal guidance you're still having vendors self attest to the security of their wares. So just like you're trusting that when they send you that software update that it's not got a back door in it you're also just kind of trusting that that SBOM they send you is comprehensive and complete and isn't missing something, right? So it's still falling to trust and as we know that leaves you vulnerable. So talk about what Binarly does with companies when you get invited in, what kinds of companies do you work with, what types of problems bring them to your doorstep and say we need your help.
ALEX MATROSOV
So we're working with different type of companies and it goes through like a device manufacturers, large enterprise companies such as Critical Infrastructure and let's talk about the device manufacturers and one of the problems we help them to solve is actually scope what their own product lines are impacted from the vulnerability standpoint because in many cases when you have like 100 product lines and every product line have a separate repository for the firmware, it's hard to scope. And unfortunately the source code level tools doesn't help because it can be modified code of the same component which is vulnerable and then the same rule will be actually failing but on the Binarly level, which is actually source of truth you can see if this vulnerable trigger is exist and potentially can be exploitable and we help them to scope vulnerable product lines and understand the risk and impact from the perspective to remediate as soon as possible for their customers. On the other side for enterprise infrastructure, let's say you need to understand your devices are not vulnerable for known vulnerabilities. Also don't contain any malicious code and what is very important for the industry we have a lot of discussion about the integrity checking and integrity monitoring of the device. But if you think about like the integrity doesn't answer the most important question what happened in your infrastructure? It doesn't provide you understanding about the risk and impact, right? And if you basically, unfortunately facing some firmware or device level related incident and your incident response team just sees this alert with integrity filing, they just don't know what to do. Or like, a security operation center will be just stuck on that because they not understand what the next steps should be because of course they can disconnect the device. But what if the similar type of the devices in your network also impacted? Of course you can disconnect all of them but how you can understand the impact on your company infrastructure and that comes to very important value we are providing. We actually answer the most important question what's the impact and what the next steps? How these threats looks like we basically can classify the malicious activity in your firmware and not only failing the integrity answers and other things. But most importantly we save the time for incident response teams and the time for incident response team. It's most important asset because even few hours waste of the time, it can cost much more financially and it can impact the company infrastructure much more.
PAUL ROBERTS
Okay, so I can imagine security teams, like, their head kind of exploding because they've got their handful now, dealing with remote workforce, dealing with their legacy IT infrastructure. Dealing with cloud infrastructure. And now Alex is coming along and saying, you're not even looking at the firmware, and you really should be because that's a risk, too, that you're really not accounting for.
ALEX MATROSOV
You're absolutely right. But from other side you also think about how many firmware reverse engineers you have on your team. Zero. Basically even they want to help, they basically don't have a skill for that.
PAUL ROBERTS
Right? So thinking in terms of like crawling, walking, running, like progress, where can they start to start to bring this under the umbrella, under the security umbrella of their existing IT security operations. How would you triage this? Sort it from a priority perspective.
ALEX MATROSOV
Probably priority number one will be understand your assets, what the devices you are of in your infrastructure. Because sometimes let's say you have a lot of different development teams and just like a few developers bring new router from Best Buy, connect a few new workstation for let's say prototyping environment with new product or feature, right? And then you're not aware about this device, but this device connect to your infrastructure, it's connect to internet and actually exposed. Right? So I mean the asset management probably will be the first and important to understand the second asset management from the firmware perspective, what the portions are. And third one, it will be actual vulnerability management. When you need to scope which devices are vulnerable, what the risk are they are exposing. And even if you have a most recent firmware, it doesn't guarantee you to have the zero risk or zero known vulnerabilities left there. Think about like we presented our research at Black Hat in beginning of August and then we figured out in the first week of September actually 50% of vulnerabilities we are presented, it's not fixed but it's been coordinated disclosure with the vendors, it's been basically everything being agreed on and then we figure it out. Enterprise devices are not fixed. That's kind of like scary, right?
PAUL ROBERTS
And why is that Alex? Is that just a culture issue within the industry, within the sort of firmware part of the industry? Just lower level of awareness or urgency about fixing vulnerabilities? Or is it more complicated or complex to fix these firmware issues and to fix just an application issue?
ALEX MATROSOV
In general, it actually comes to a few different directions. Of course, if it is design issues, it's hard to fix, right? Probably they will be staying forever there. If it is, let's say by the vendor, if vendor thinks the risk are not that high they can basically postpone the fix from other side. Also it can be like some of the devices have been fixed, some of them not. That means they probably have a struggle of scoping these impactful parties or the devices in their own product lines. And I think it's why we developed this open source approach called Firmware Hunt to actually scope and detect such problems and give a tool to the industry.
PAUL ROBERTS
Talk about that, if you could.
ALEX MATROSOV
Yeah, of course. So we Binarly developed the Firmware Hunt. It is an approach for detecting known vulnerabilities and think is like we've been understand for detecting known vulnerabilities and unknown vulnerabilities. It's two separate problems which need to be solved separately and need different type of tools. And we developed the semantic based approach to scan and find the vulnerabilities because we also understand that for example, YARA rules doesn't effectively works for such problems because they've been created for detecting an IoCs and some sort of like properties of malicious activity into the Binarly files or let's say any sort of files, but they are not being suitable for detecting vulnerabilities. Because if you think about the vulnerability trigger, it can be not just one single function, it can be different functions, need to have different type of properties and then it comes down to single vulnerability. And if you're creating the YARA rule for that, it will be pretty long, YARA rule. Secondly, it will be quite a park, nobody will be understand it and for your customers it will be just a black box. And we've been thinking how we can actually create something which will be having more context, more easy to develop, easy to support and it will be more given more transparency about actual detection. So that's how original idea with the Firmware Hunt came up.
PAUL ROBERTS
And is that an open source tool?
ALEX MATROSOV
It's an open source tool. You can find our community scanner which is also based on Binarly analysis frameworks which is also open sourced in our GitHub. Yeah, so we can probably provide the link. Another tool we developed, it's called UFI Explorer. It actually gives security teams an ability to reverse engineer the firmware inside the prop plugin but at the same time it's actually create the semantic annotations context on the firmware about UEFI and reconstruct a lot of important structures. To actually give you a lot of advantage in terms of, like, you don't need to do it manually and you saving the time and actually can react on such threats much more effectively in some points. You even don't need to be an expert in unified to really give you a lot of context, which is actually human readable, like human readable from the reverse engineer perspective.
PAUL ROBERTS
So, final question, at LabsCon you presented sort of a follow up to some research that you presented at Black Hat on vulnerabilities in WMI Windows Management Infrastructure and talk about that and talk about some of the ways that companies first of all talk about that, talk about what the research you're doing now and what problems you're looking at now and just how companies need to be aware of some of the ways that these vulnerabilities might be used against them.
ALEX MATROSOV
So we give two talks. My co founder and CTO have been talking about Windows management instrumentation and how basically it can blind the modern SIEM and EDR solution in the field. So basically we just try to raise an awareness what type of traps it basically can came and use already existing mechanism to actually be more stealthy and bypass modern security solutions. But also from other side we provide a very comprehensive research on the firmware and it's been about 60% of our Black Hat research. But also we presented at seven new vulnerabilities, high impact vulnerabilities related to one of the IBV's source code, not source code... Packages. So basically what happened, this is kind of like if you attack the court which is related to this third party component, you attack all the devices which is rely on this component. And in this case like the attack vulnerabilities we found it's been focused on inside software which is powered a lot of devices like servers and others, but it doesn't mean they're caught it's worse than like other side BB. It's not I think working closely with these guys, we managed like a less than 90 days disclosure timeline and they really care about security. I mean for its first time ever, I can say the disclosure for the firmware threat I have less than six months. So usually it goes like very long timeline to disclose. I have the disclosures which has been like a 14 month. Like in 2020 we are presented... 2021, we presented with Alex Tigerskin and Adam Zabozky, some vulnerability we found in intereference and this has been a long disclosure, I can probably tell you exact timeline, but it's been very long disclosure. But finally we've been patching this vulnerability, at least on the vendor side, but also because it is related to some sort of reference, got a lot of devices in the field being impacted and we still see some unpatched devices with such vulnerabilities. Same comes to any sort of IBV independent BIOS developer code because on one side the vendor patched, but deployed systems need to be patched too, right in the field.
PAUL ROBERTS
Okay, so your final advice for companies? It just sounds like there are a couple of problems here. There's a problem on the sort of getting vendors to be more responsive and patch in a timely manner. Also an awareness problem on the customer on the end user side to make sure that first of all, they're looking for vulnerable firmware within their organization, second of all, that they're applying patches when they finally become available, right?
ALEX MATROSOV
My probably advice will be trust, but we reply because basically even the most recent version, it doesn't guarantee you your device is secure and basically we blindly trust everything which comes signed from the vendor side. We just apply to our devices but also sometimes even the vendors who produce a device or developing the firmware they don't have an access to some of the components in the source code, they have just the binaries and then basically they don't have enough information to trust exactly. It's provide a lot of risk and we definitely need to pay much more attention to phishing attacks, vectors and threads which is coming from below operating system layer and it's been historically overlooked but because we just have too many problems on operating system an application layer but now it's time we need to refine that.
PAUL ROBERTS
We're getting a lot of guidance from the federal government on supply chain security, SDLC, secure development lifecycle, SBOM and stuff. Do they need to talk more specifically now and give more specific guidance around this firmware problem than they have? What are your thoughts?
ALEX MATROSOV
I think we're talking a lot. Yeah, like, firmware is mentioned it and as an example, firmware is considered as a critical piece of software, but we definitely need to classify more the firmware regulations and basically comes down to the firmware explanation how we can apply SBOM to the firmer, even it is a software, but sometimes it's misunderstood. Or basically, if firmware been not discussed. For some of the people...
PAUL ROBERTS
That's part of the hardware. Right.
ALEX MATROSOV
Yeah, it's just not important. Right, but it is important and it is a root of trust for, it's foundational for zero trust. If you think how you can trust something which is on your up level stack if you don't trust your middle layer or hardware right, we have a lot of problems in the industry to fix that's interesting times when probably at some point we get much more secure devices and old malware will be gone. But probably it isn't a topic because devices get more and more... Complexity is an enemy of security and I mean complexity just growing at all the layers of our software stacks include the firmware and unfortunately it doesn't give us benefit of make this code more secure because we can make one library secure but we actually deploy ten more new ones.
PAUL ROBERTS
Final question, I mean do you think we were talking before we came on just about some of the hacks against chip silicon vendors going back a couple of years Nvidia and so on... Do you think we're going to start to see more in the wild attacks targeting firmware as we go, you know, into 2023 and beyond? Is this going to be something that we start to see more of?
ALEX MATROSOV
That's actually very important and interesting topic. First of all, you're absolutely right. If you think about for the last two years we have attacks on Gigabyte, Intel, Nvidia, Samsung, Acer and Lenovo. So basically this not like accidentally happening. It looks like it's really precise focus for the hackers to actually breach such companies. And in this sense, it actually can create very clearly supply chain problems because if the attacker already have an access to infrastructure like where the source code stores or to development machine so most likely he can potentially have access to the build server. Right. So it can be something which can be deployed on the devices later on. So it's pretty scary and also the time of reaction of such attacks, it's also scary as well because most of the vendors just not ready. So if you think about the Taiwanese vendors, which is like developing a firmware for third party manufacturing device for device manufacturers so basically in most of the cases they don't have security teams, it's just a bunch of the developers and some business unit for managing the discussion with the device vendor. That's pretty much it. I remember the time when I've been talking a few years ago sometime with this vendor and asked what kind of procedures you guys doing for the security? Oh, we have an antivirus solution, we scan every single firmware resistant antivirus solution. But guys, it's not suitable for such threat. It just will be not detected. Yes, but it all give us green. Right...
PAUL ROBERTS
But I mean, Taiwanese silicon manufacturer, I mean who would want to target them? Right?
ALEX MATROSOV
Because they're exactly right. It scares me a lot because you're absolutely right, it's like a pretty sweet target. And also think about...
PAUL ROBERTS
With some interested parties, the list of interested parties is yeah, sure.
ALEX MATROSOV
I would say now come back to our supply chain discussion. That's exactly the threat, that's exactly the impact which actually can tell like at some point every produced device can be compromised because somebody who's been involved in production process has been compromised. Right.
PAUL ROBERTS
Alex, is there anything I should have asked you that I didn't?
ALEX MATROSOV
I think we pretty much discussed everything. I don't know, it's just flows. I've been a bit of chaos in my mind stream which I put on your podcast but hopefully it's kind of like a connected thoughts and you enjoyed the discussion.
PAUL ROBERTS
Very much now it was a great conversation and we should definitely have you back. I have a feeling that this is a topic that's going to be getting a lot more attention in the months ahead. So maybe we can absolutely have you back on Conversinglabs.
ALEX MATROSOV
Absolutely.
PAUL ROBERTS
Alex Mattrasov of Binarly. Thank you so much for coming on, speaking to us on ConversingLabs and we will do this again, okay?
ALEX MATROSOV
Thank you very much Paul for having me, it's been a fun discussion and let's try to do it again in some future. And we think the supply chain security comes down to the firmware and hardware. Thank you very much.
PAUL ROBERTS
Our pleasure.
