Eric Byres, the Chief Technology Officer at aDolus Technology Inc., sat down with SafetyDetectives to share his cybersecurity journey and the founding of his company aDolus, which is aimed at combatting software supply chain attacks. Byres, with a rich background that includes creating the Tofino Security Firewall and serving as CTO at Belden, became acutely aware of the threats in software supply chains through attacks in Europe by Russian intelligence. This awareness led him to leave Belden and start aDolus, with a focus on developing solutions like the FACT platform to provide transparency and security within software supply chains, benefiting both producers and purchasers of software.
Eric is widely recognized as one of the world’s leading experts in the field of Operational Technology (OT) cybersecurity. He is the inventor of the Tofino Security technology – the most widely deployed OT-specific firewall in the world – licensed by industry leaders like Honeywell, Schneider Electric, and Caterpillar.
Eric now focuses on improving the security of the software supply chain for OT. He is member of the NTIA SBOM Awareness & Adoption Committee and has authored numerous articles on Software Bill of Materials.
His many accomplishments include chairing the initial ISA SP-99 Security Technologies Working Group (now known as IEC-62443) and testifying to the US Congress. He has received numerous awards from international organizations and was made an ISA Fellow in 2009. In 2013 he received ISA’s highest honor: Excellence in Leadership.
Hi Eric, thank you for taking some time for us today. Can you talk about your journey and what led you to aDolus?
I’ll start off with where the name aDolus came from. It’s an amalgamation of two ancient Greek words. Dolos was the Greek demigod of deception and treachery. He made statues of the Goddess Aletheia that were so realistic that the people made offerings to this fake goddess; he is considered the ultimate fraudster. In ancient Greek, adding an “a” to a word inverts its meaning, so if Dolus is all about deception, then aDolus means no deception, which is what we’re trying to achieve.
To answer your question though, how did I get started in this field? I’ve been involved in cybersecurity for a long time. When I was a university professor, I invented a product called the Tofino Security Firewall. It was a firewall for industrial systems and today if you buy a firewall from Schneider Electric, Honeywell, Invensys, or Caterpillar, you’re buying our technology. The company was a big success, and like many small startups, it got acquired in 2011 by a Fortune 500 company, Belden.
I became the CTO for the security products division at Belden. While I was there, we became aware of attacks occurring in Europe – a Russian intelligence agency was attacking tier-two industrial providers and Trojanizing their software, so that when their customers, pharmaceutical companies, and possibly energy companies, downloaded software directly from the supplier, they were unknowingly downloading malware. The companies trusted the software because it was coming directly from their suppliers’ websites.
I became aware of this poisoning of the supply chain going back to 2014. I was also aware that despite Belden’s excellent lineup of security products — we moved approximately a quarter of a billion dollars a year in security products — our portfolio had nothing to address supply chain attacks. So, I left Belden in 2015 and got funding from the US Department of Homeland Security to look into the risks and solutions for software supply chain attacks. That’s what led me to found aDolus.
What is the FACT (Framework for Analysis and Coordinated Trust) platform and what motivated its creation?
Using our DHS funding, we started looking at possible solutions to identify what was poisoning the software supply chain. We quickly determined that better information sharing about software products between suppliers, users, resellers, and government agencies was needed. There were criminal groups and foreign spy agencies taking advantage of the fact that corporate users don’t know what’s in the critical software they deploy. The bad guys knew more about the software than the companies using the software did. This was unacceptable if we wanted to secure our businesses and critical infrastructures.
So FACT is really an information sharing service. It gives executives visibility into the software they produce, purchase, or use. And to do that, FACT performs two essential functions.
- It analyzes the software and firmware binaries to produce what’s called a Software Bill of Materials, or SBOM. This is like an ingredients list you’d find on food. The idea is that if you want to buy a software package, say an accounting package, you know that some of the software was written by the software company. But, by most estimates, around 90% of the software is actually from a third party. It might be open-source software, or proprietary software that the accounting software company has licensed, but they didn’t create it – someone else did. Therefore, the first thing FACT does is provide the complete software bill of materials for a software package of interest.
- It creates a risk profile. Next the FACT platform inspects the list of included software, and runs it through a risk analysis process. It is looking for answers to questions such as do the software components have vulnerabilities, are they well signed, is there any software that could be used by attackers as Living Off the Land (LOTL) malware, and are there software providers that you don’t really want to deal with? FACT does this on a large scale so an organization like an oil company can look at its entire software portfolio, which might include 10,000 different software products. FACT then rates all those software products to give managers and security professionals an idea of the risks they face.
What types of organizations or industries stand to benefit the most from adopting software supply chain visibility solutions like FACT?
In the short term, it’s the software producers. They benefit because they’re scrambling to comply with new regulations like the Federal Acquisition Regulation for Cyber Threat Reporting and Information Sharing, or the EU’s Cyber Resilience Act. These regulations require companies that provide critical software to also provide SBOMs for those products, something many companies currently can not do.
But the whole reason these regulations exist is so that companies buying software have visibility. So software purchasers are going to be the real beneficiaries down the road. FACT will give them visibility into the software they’re buying. It answers immediate questions such as: Is the software risky to use in our environment? Can I uncover any undesirable components hidden in the software before I buy it? What third parties were involved in creating the software? And FACT will provide visibility into these security questions as risks evolve.
A good example is the Log4J catastrophe from December 2021, where a major vulnerability was found in Log4J, a widely used open-source software product. The trouble was that nobody knew who used it, and where it was used. I remember listening to a talk by the Chief Security Officer at one of the big three defense companies in the US. For two weeks, he had his staff make phone calls to hundreds of their suppliers, asking if they used Log4j. And almost without exception, the answer they got was “we don’t know, we’ll get back to you”.
FACT is helping companies make quick decisions when there’s a new risk appearing. It answers questions like; Do we ship products with Log4j? Do we use products with Log4j? And when we discover we do have a vulnerable component (like Log4j) running in software we use, we can now act quickly. For example the user can contact the vendor for an emergency patch or add a firewall rule to cordon off the risky component. Actions like these must be prompt because the bad guys aren’t going to wait for us — we saw Log4j exploits in the wild within hours of its announcement.
Therefore, the major beneficiaries down the road for a product like FACT will be the companies that are buying and using software, which of course is everyone.
What are the most common vulnerabilities or risks associated with software supply chains today?
The risk that most of the industry is focusing on right now is uncovering vulnerabilities in subcomponents. Software vulnerabilities are often not listed in databases like the National Vulnerability Database against the product you buy; they’re only listed against the subcomponent. If you’re unaware of the subcomponent, you won’t know you have the vulnerability.
Again, Log4j is a great example. You might not have purchased Log4j directly, but you may use a product that incorporates Log4j, thus inheriting its vulnerabilities.
Another serious example was the Codesys vulnerability in April 2022. A Russian government agency exploited vulnerabilities in Codesys at liquefied natural gas (LNG) facilities in the US. However, no company operating an LNG terminal buys Codesys directly — it’s the software inside the industrial controllers sold by companies like Schneider Electric or Omron.
Most users of industrial control products within an industrial system use Codesys somewhere in their environment, often without knowing it. When the Department of Homeland Security issued a notice about Codesys, there was little reaction because users were unaware they were using it.
The second set of risks is related to the suppliers of the software. There are instances of foreign agencies creating open-source projects that are problematic. These projects may seem legitimate until it’s discovered that the development team works for a foreign government agency. For example, we helped a US pipeline analyze the software in the devices used to control oil flow in the pipeline. They discovered that while the devices were sold to them by an approved US company, they contained chips and software from a prohibited company that had ties to the Chinese People’s Liberation Army.
This can go both ways. We had one case of a client selling software to the US federal government. During due diligence, it was discovered that they had been buying software components from a Russian company, which jeopardized the entire deal. However, further analysis using FACT clarified that none of the software purchased from the Russian company was embedded in the software being sold to the US government. It saved the deal.
What’s your perspective on the balance between automated software supply chain assessments and human oversight?
Assessments have to be done in an automated fashion. When we take apart a piece of common software today, we’ll find 100,000 software packages — analyzing that number of components just can’t be done manually.
But ultimately, you need a human being to oversee the final results. I think this is true in cybersecurity in general; there’s just too much data, whether you’re tracking vulnerabilities or attacks on your firewall, the amount of data is overwhelming. You need AI to dig through the noise and present the likely suspects, and then let people make the final decision.
That’s exactly what we did for that US pipeline company mentioned earlier. FACT dug through thousands of providers and then narrowed the results down to the top five providers that were of concern. Then it was up to the security and governance people to make the final decisions.
What challenges do you foresee in the domain of software supply chain security in the coming years?
The biggest challenge is the namespace problem. Anyone who’s worked with SBOMs quickly realizes that there’s no standard database of company or product names.
We’ve seen a single product that has multiple names associated with it. And we see companies that have been buying and selling divisions so that the company name associated with a product changes a lot.
Even within a single organization, there will be different terminologies and spelling mistakes for names. We saw one particular vendor whose developers had managed to create 47 different ways to spell the company name, like BigCorp Inc, Big Corp Incorporated, Big Corp, and so on.
The inconsistency in naming within the industry and government databases presents a big challenge for security professionals. An industrial product like the GE Fanuc programmable logic controller illustrates this issue perfectly. The product was initially produced by a joint venture between GE and the Japanese company Fanuc. When looking for vulnerability information on this product, one has to look under “GE” in the Department of Homeland Security’s advisories (not GE Fanuc). However, the National Vulnerability Database lists associated vulnerabilities under “Emerson” because Emerson acquired the division from GE few years ago.
This lack of consistency can lead to gaps in security coverage, as a single entity may be referenced in multiple ways across different databases and records. To address this, FACT goes to considerable lengths normalizing the names found in an SBOM to a unified name. This eliminates confusion arising from multiple variations for the same company or product due to spelling mistakes or name changes. By normalizing these names, it becomes possible to effectively hunt for all related vulnerabilities and maintain a more secure supply chain.
For example, imagine an SBOM tells you that your software contains a component that came from the Apache Software Foundation. Now there are about 20 ways the Apache Software Foundation is commonly described – Apache, Apache Software, Apache Software Foundation, ASF, and so on. With a list of normalized names you can go to the various vulnerability databases and use those different names to see which one uncovers vulnerabilities. So SBOMs combined with name normalization give security professionals the tools they need to truly understand and respond to the vulnerabilities hidden in the software their company is using. Armed with that knowledge, they can make our world safer and more secure.