Bill of materials: devil's in the software details
Supply chain attacks are notoriously difficult to prevent. Can transparency on what the software is made of help to prevent future cyber-attacks?
The morning of last December was disastrous for the U.S. government. As the last month of 2020 started, FireEye, a cybersecurity company, announced that a state-sponsored hacker stole its red teams' tools.
As the company found out, the breach involved the SolarWinds Orion system and infrastructure monitoring and management platform, among others used by government agencies.
Software providers were not mandated to reveal information on their product, and companies just didn't bother to do it,Nikhil Gupta.
It took weeks to understand the scope of the attack, which has entered history as one of the worst cyber incidents. Most of the U.S. government departments were infected together with hundreds of other organizations, including NATO, the European Parliament, and the U.K. government, to name a few.
Researchers concluded that the perpetrators gained access to SolarWinds systems as early as September 2019. In a classic case of a supply chain attack, sophisticated threat actors obtained sensitive government information by abusing third-party software used by the authorities.
Among measures to prevent future supply chain attacks, President Biden signed an executive order with software bill of materials (SBOM) as one of its underlying focuses.
In its very essence, the SBOM is meant to provide software transparency in the face of the attack. More so, SBOM should, in theory, make it clear which software vendors take security more seriously than others. At the very least, companies will have to know what their software is made of.
Mid-July, the American National Telecommunications and Information Administration (NTIA) published the minimum requirements for an SBOM. According to Nikhil Gupta, a software security veteran, CEO of a software security company ArmorCode, and a co-author of The Purple Book, the new rules are supposed to bring order in a chaotic environment.
"Safety is the key concern here since it's crucial to know if there are any vulnerabilities in critical infrastructure. However, software providers were not mandated to reveal information on their product, and companies just didn't bother to do it," Gupta told CyberNews.
We fired up a Zoom call to discuss why the SBOM is important, what it means in the company's day-to-day operation, and what implications the new rules have.
The recent changes regarding SBOM are still somewhat a novelty. Could you elaborate a little bit on why it is important in the first place? I mean, why is it important at all to know what the software is made up of?
Simple analog for that here is food. Let's say you have a nut allergy. It's perfectly fine to ask to know the contents of a dish you're ordering at a restaurant. It's the same thing with the software bill of materials (SBOM).
Software development has transformed in the last 40+ years. We used to have monolithic applications, and now, they're all microservices-based applications. One application can have 50-100 microservices, and each microservice is written in a different programming language.
We also have software releases every month, every week, or even multiple times a day. The use of open-source software has increased dramatically, with 70% to 80% of the software using open source. With all these things happening, the probability of attacks has increased significantly.
We used to have nine months of development and three months of testing. Now that luxury is gone. With releases several times a day, you can't do it. With microservices written in multiple languages, the complexity of security testing increases significantly.
If a mobile phone gets locked in a ransomware attack and someone can't make a 911 call because of that, that could become a life-threatening issue,Nikhil Gupta.
And with open-source software, there is always a risk that a developer might download a library that bad guys have injected with something malicious. As a result, it's essential to understand what the ingredients in software are.
If there are any changes, you can look at it and figure out that if I am using library A, B, and C, and such library has X, Y, Z vulnerabilities, it's vital for you to know whether you have the component or not.
We have the same thing for hardware. If a component has a problem, you can go back and easily notify people which one it is. So, it's the same concept.
The legislation on software materials came in light of significant ransomware and other malicious attacks. Do you think cyber-attacks made the bill more urgent?
Companies have been asking for this for a very long time. Especially the companies who are required to provide support on the hardware. So, on the Software-as-a-Service (SaaS) solution companies, you're moving fast. Let's say there's a vulnerability that comes up, and you can immediately upgrade the software.
But let's say you are building a hardware infrastructure that is required to be supported for the next 5-10 years. And if there is a vulnerability in the operating system or on the application, your information can be compromised. And it's not like you can mandate a person to say that they have to be on the latest software, but the providers or the manufacturers are liable if something happens.
Imagine a situation where you find out that a particular operating system has an issue. You send a notification to the consumer who probably does not have time to read into it and is not tech-savvy to know that's important. So, as a result, that becomes a liability.
If a mobile phone gets locked in a ransomware attack and someone can't make a 911 call because of that, that could become a life-threatening issue. Since there are more and more attacks happening, the government should intervene and say, you have to make information on software components mandatory.
Going back a bit, what is the current status quo does the SBOM change? I mean, what does it actually mean for day-to-day operations?
It's adding some order to chaos. There are a lot of companies who wanted the SBOM and were asking for it. Very large companies, which provide industrial products, have had tens of thousands of products in the last century made.
Because they make critical national infrastructure, they are required to have information on the software they use. Safety is the key concern here since it's crucial to know if there are any vulnerabilities in critical infrastructure. However, software providers were not mandated to reveal information on their products, and companies just didn't bother to do it.
Historically, nobody wants to pay even a single extra dollar for security. Now, with the introduction of SBOM, we're talking about a lot of investment on the company's part to provide information,Nikhil Gupta.
So, I think SBOM brings significant change. Historically, nobody wants to pay even a single extra dollar for security. Now, with the introduction of SBOM, we're talking about a lot of investment on the company's part to provide information. Companies were cutting corners, but now, if the government intervenes, that will change people's behavior.
Do you think this change will affect other companies operating in the EU and Asian markets? After all, executive orders are meant for the U.S. legal system.
Absolutely. The standards may be different, but underlying problems are the same. The government of the U.S. is working with its counterparts in Europe and the Asia Pacific to have a unified approach.
And the classic example of the cross-national effect is GDPR. Legislation for GDPR came out in Europe, and then the U.S. introduced something similar because there's a fundamental need.
Same with SBOM. It's just a matter of time. I think it will help to happen in other countries, too. The U.S. is a big consumer of software, and they can mandate their vendors, which will further push and promote the idea.
What can people responsible for information security in a company do with a list of software materials? I imagine it's a big piece of information that requires multiple hours to dig into.
You're spot on. If you get a list of 100,000 components, what good does it do if you don't understand them? Let me go back to the food analogy for a little bit, however.
I grew up in India, and around 20 plus years ago, there was little information about food ingredients. As a result, people had a lot more allergies. Once they come to the United States, they know some products have gluten, and some have lactose, and so on.
This brings basic awareness. And as a result, people are healthier, since they can choose what's better for them. And that gives them the power. So the same thing would happen with SBOM implementation. With the implementation of GDPR, a whole industry formed around it.
What you're saying is that there's a new ecosystem of services around SBOM forming?
Absolutely. And SBOM just came in July. We are working closely with the government to make this work. For example, there are people on the extremes who say, publish your software bill of material on the internet.
That's a big no-no. Because it's like opening up your library and inviting the bad guys to attack you. I think the suppliers should have information ready but should only provide it on demand.
If we know that these are the specific libraries, it's very easy for bad guys to come and exploit various vulnerabilities. On average, it takes 200 to 265 days for an organization to fix a known vulnerability. If the bad guys know these are the 500 components a company is using, and they also know it will take 250 days to discover the issue, threat actors can easily go ahead and attack you.
More from CyberNews:
Subscribe to our newsletter