What you’ll learn:
- How to assess the security of your own supply chain.
- Understanding how the software works in your supply chain.
- Steps you can take to improve the security posture of your supply chain.
Managing a supply chain has always been complex—from finding the right parts from the right suppliers at the right price, to mitigating supply constraint risk through second sources. The success of your supply-chain management often is a leading indicator to the success of your products and your company.
Unfortunately, with many systems and their subassemblies, integrating software as well as hardware components increases the complexity of supply-chain management. Managing it all to ensure reliability and sustainability is already difficult enough, but it becomes even more challenging when we start to consider security aspects of these software components.
With a broadening view to the security of systems, along with regulation to mandate security baselines, what are the best ways to manage this complexity?
First, Know Yourself
We’re all very familiar with the concept of a physical bill of materials (BOM) listing all of a system’s components and elements. However, very few companies have a similar list of components for their software, at least to a level that’s useful. This may seem like an easy thing to fix, but the complexity of creating and managing a good software BOM can’t be overstated.
It’s easy enough to track whole software packages, which are integrated into your system, but what about individual libraries or sections of code copied and pasted across your software applications? Which distribution site did you get the software from? Was it pre-compiled or modified by someone else prior to distribution to make it easier to use? Where did they get it from? What software/libraries does it integrate or require use of?
Taking an existing code base and building up a complete and fully granular software BOM can be almost impossible. However, this shouldn’t stop you from taking some important steps to understand what software exists in your systems and ensuring that there’s more visibility of what’s being integrated into the future. Certain tools can be used to perform “software composition analysis” on existing code bases to determine, at least at a high level, the various software components in the mix. Even small steps can help when starting from scratch.
At the most basic level, you want to know how much of your software is actually yours: How much has been created by you, and how much is obtained by other sources. Only then can you start to consider how to manage those sources.
Source Control
It’s very likely that when upon finishing this first exercise to inventory your software, you will find that the vast majority of the software in your system, by any metric with which you may measure it, isn’t created by you. The same way that for any electronic device, the vast majority of the internal parts—the electronic components, the plastic casing, the printed circuit boards (PCBs), and the fasteners—aren’t made by you either.
That’s why we need supply-chain management, because as a manufacturer you don’t really “manufacture,” you assemble. The quality of your product is entirely based on the quality of the components you use to create it.
This is also true of the software components you use, both for quality and security.
So, knowing where your software comes from is vital, but so is the way in which you use that software. When did you take copies of the software you’re using in your systems? How have they been stored? Have they been altered or replaced in some way?
When we’re creating plastic parts, it’s common for the tool to have a date reference as part of the mold, to show when that part was created. This helps with managing the supply chain—if issues arose with a particular batch of parts, or if the tools were modified at some point, individual parts can be identified and managed. We need similar levels of control over the software components used in our products and subassemblies.
Of course, software is only one piece of the supply chain for any system. Many of the physical subcomponents used will have their own software, and there will be countless other contractors, partners, and suppliers that are relied upon for aspects such as the creation of PCBs, shipping, and even maintaining IT systems in the factory.
Understanding Before Mitigation
With all of this complexity, it can be overwhelming and easy to give up and consider the problem unsolvable. However, like all large problems, the way to address supply-chain security issues is by segmentation and prioritization. Which aspects of your supply chain are most risky? Which are the easiest to address? Can you do something to get started on your supply-chain security in the short-term—even if it doesn’t address all of the risk—in specific areas that help to minimize the risk? Where are the quick wins?
The process for understanding this risk is referred to as “threat modeling,” and getting used to it can be quite difficult. Gaining these insights will help you to understand what could go wrong, even if you think it may be unlikely.
Supply-chain issues may not be caused by you, but they can, and do, impact you directly. If a supplier provides a Wi-Fi module with an easy to exploit vulnerability, the news on the IT and security websites will be about your brand being hacked—not the brand of the subcomponent provider. If you use some software and it leads to a large failure of your system, it’s still your system that fails and your customers who are inconvenienced.
A Path Forward
So, what can you do? A holistic approach would include the following steps in your process:
- Get buy-in from your management. Nothing will change until you have a mandate from management to make a change, so do this first.
- Determine what you’re doing today to manage your supply chains.
- Ensure this includes both components—hardware and software—as well as service providers.
- Develop a process to create a software BOM for your systems, starting at as high level as needed, but with scope to become more granular as you create new systems.
- Make sure this includes details on versions and sources of software, not just names.
- Consider what could go wrong, develop your threat models, and how it fits in with your list of components and providers.
- From all of the above, create a plan to address the high-risk items, as well as quick wins, as soon as possible. Ensure it includes technical controls as well as operational and procurement controls for third-party suppliers and systems.