In this series, we have been taking a long look at the risks and challenges that modern supply chains pose to enterprises as well as the suppliers and OEMs who make up the supply chain.
Part 1 covered the fundamentals of supply chain security including:
- The root causes of supply chain security problems.
- Why those problems are not addressed by traditional tools.
- The core capabilities that supply chain security tools bring to the table.
Part 2 took a deeper dive, specifically at the supply chains of devices and equipment including:
- The complexity of supply chains supporting physical equipment and how a limited “span of control” affects all layers of the supply chain including the ultimate buyers.
- The critical role that firmware and other machine-level code play in the equipment supply chain.
- How to apply an Identify, Verify, Fortify approach to mitigate supply chain risks.
In this installment, we build on this foundation to show how to extend these same concepts to all critical code in an enterprise whether that code lives on a device, in the cloud, or is created by internal developers from open-source components. The end result is a unified and consistent approach to supply chain security that supports virtually every job role and every type of supply chain in an organization.
Extend Security to All Your Code
Simply put, supply chains are behind virtually every type of technology that organizations rely on. But not every supply chain is the same. Software, hardware, and cloud supply chains are quite different, and each class of technology can introduce its own challenges and requirements. For instance, the web app that a company’s developers are building almost certainly has a very different supply chain from the laptops they use to write the code and the servers it ultimately runs on.
So while the core tenets of supply chain security will remain the same, organizations will need to account for what makes each type of supply chain tick, and likewise, what makes each tricky. This requires an approach that is flexible enough to account for different types of supply chains, yet maintains a consistent, simple, and unified approach across them.
- Hardware – If it has a power button, it probably has supply chain risk. This includes standard IT devices such as laptops and desktops. It includes networking equipment such as switches, routers, VPNs, firewalls, and telco equipment. It includes servers, data centers, and cloud hardware. It includes IoT devices, medical devices, and OT and industrial control systems.
One of the biggest challenges of hardware supply chains is their depth and complexity. Virtually every piece of equipment is a complex amalgamation of physical components and code, sourced from dozens of suppliers and sub suppliers, from any number of regions and countries. And these supply chains are always changing as manufacturers try to cope with component shortages and rising costs.
- Infrastructure Software and Firmware – All software has supply chain risk. As the SolarWinds attack illustrated, even compiled software, developed and delivered by a single vendor, can carry devastating supply chain risks. The same risks apply to SaaS applications and web services. It includes the code that runs infrastructure and the firmware that all devices rely on. And it likewise affects open-source software packages that are continuously reused by countless organizations and developers.
Software supply chains can pose very different challenges depending on the type of software involved. Open-source projects are open to anyone who may accidentally or intentionally include vulnerable or malicious code into a project. Some of the most popular open-source libraries have recently been found to be inundated with malicious code. The good news is that open software is also open to audit and a supply chain security tool can verify the provenance and integrity of code and dependencies, and analyze that code for threats and vulnerabilities.
Software in compiled applications and SaaS applications can pose the opposite problem in that much of the supply chain may be opaque to the customer. Supply chain security tools can help here by making sure that all code is valid and properly signed, that all update procedures are implemented securely, and by monitoring the actual behavior of products to identify signs of malicious behavior or vulnerabilities.
Firmware deserves additional focus because it is some of the most privileged and powerful code, and also often the code that is the least audited. This includes system firmware such as BIOS, UEFI, Intel ME, and Mac EFI. It also includes firmware embedded within hardware components such as CPU microcode, SSD firmware, and NIC firmware. Network devices heavily rely on firmware within their operating systems (e.g. Cisco IOS, F5 TMOS, Juniper JuneOS, Fortinet FortiOS, Huawei, etc). IoT devices often exclusively run on firmware such as Linux-based embedded firmware, router OpenWRT, RouterOS, and others.
Firmware, particularly in network devices has become one of the most popular ways for attackers to get into and take control of an organization. Firmware can be a somewhat arcane specialty and most organizations lack the skills and staff needed to verify and manage all their firmware by themselves. A supply chain security tool can demystify and automate this work by quickly scanning all firmware to make sure it is valid, free from threats and weaknesses, and hasn’t been tampered with.
- Cloud – Moving to the cloud doesn’t mean that risk magically disappears. The hardware within a third-party private cloud will have all the same supply chain risks organizations would have if they bought the hardware themselves (see CloudBorne). Likewise, public cloud infrastructure such as AWS, Microsoft Azure, and Google Cloud can have their own vulnerabilities and misconfigurations. The same is true for cloud infrastructure software as well as third-party SaaS software and APIs hosted in the cloud.
Challenges can vary depending on the specific cloud assets and services that an organization uses. Hosted bare-metal servers can be reallocated repeatedly to different customers, allowing vulnerabilities or threats in firmware to be passed down the line. On the other hand, cloud infrastructure providers often obscure the details of the actual infrastructure itself. A supply chain security tool can help in both cases. In all cases, the solution can analyze exposed infrastructure and services to verify the integrity and detect threats and weaknesses. They can also provide a common format and set of requirements that organizations will require from their providers.
Enable All Your Staff
So at this point, an organization may have a good idea of what they’re looking for and where, but it may be less obvious who is going to be doing the looking and when. Naturally, there is no one-size fits all approach for every organization. However, it is important to recognize that the importance of, and responsibility for, verifying the integrity of supply chains will often cut across many job roles and across many phases of an asset’s lifecycle. Let’s look at a few scenarios where organizations will likely want to have strong visibility and control over their supply chains.
- Product Evaluation – IT and procurement teams must be able to evaluate a technology and its supply chains long before it ever reaches the organization. When assessing their options, teams will need to understand not just the cost, but what is actually inside a given solution, and if the product has any vulnerabilities or components with suspicious origins.
- Pre-Deployment Validation – IT and/or Security teams should verify all newly acquired assets before they are put into production. A quick scan from a supply chain security solution can verify the integrity of the product and all critical software, firmware, and hardware components to validate that everything is authentic, unaltered, and has not been tampered with in the supply chain. Likewise, teams can use these scans to generate a complete Software Bill of Materials (SBOM) for the received product and verify that it matches the SBOM from the vendor.
- Continuous Monitoring After Deployment – Supply chain issues don’t end once the product is deployed. New vulnerabilities can be discovered (e.g. Log4j) or new updates can be delivered (e.g. SolarWinds). Security or IT teams can perform ongoing automated scans of assets to identify any changes in integrity, identify new vulnerabilities, or detect signs of compromise. This ongoing analysis should also be able to analyze the behavior of updates and newly deployed code to identify new threats that may be hidden within signed vendor code.
- Vulnerability Management and Updates – There are a variety of ways that supply chain vulnerabilities can slip past an organization’s existing vulnerability management program. Supply chain vulnerabilities are often hidden below the level of traditional scans, or may be within classes of devices that are not covered by regular scans such as VPNs, network controllers, IoT devices, and server BMCs. Supply chain security tools can arm IT and vulnerability management teams to discover these devices and surface hidden vulnerabilities. When problems are found the solution can assist with safely and properly applying updates to resolve the issue.
- Incident Response and Threat Hunting – Lastly, we need to remember why threats are coming in through the supply chain in the first place. By using an organization’s own technology as a trojan horse, attackers can not only sneak into an enterprise, they can also maintain ongoing persistence while hiding from traditional threat detection tools. Threat hunters should be armed to look for implants, backdoors, and other threats that are embedded within seemingly valid products. Likewise, IR teams should be able to quickly assess any asset involved in a security incident to verify the integrity of all code before returning the asset to service.
Consistency and Simplicity
At this point, it should be clear that supply chain security is an exceptionally broad discipline that can cut across many types of assets, business units, and job roles. And organizations can be quickly overwhelmed if they try to tackle the problem in a fractured or siloed approach. For example, the procurement team that selects an asset, the IT team that verifies it on delivery, and the teams that monitor and maintain it after deployment should all have a consistent way of viewing and assessing its security.
Likewise, the organization should have a consistent set of requirements and a single place to monitor supply chain security across its many classes of assets. Ultimately, the business relies on hardware, software, and the cloud. It only makes sense that there is a unified place to see the integrity of all these types of apply chains.
This means that supply chain security must be incredibly simple. If many different teams are going to take a consistent approach, then it must be very easy for each unit or job role to incorporate supply chain measures into their existing workflows. As such, one of the most important traits of a true supply chain solution is the ability to take the incredibly complex nature of supply chains, and boil it down to a simple scan that can clearly show if there is a problem, and if so, how to fix it. That in a nutshell, is our raison d’être – to enable you to safely and easily focus on using your technology instead of worrying about where it is from. If you’d like to learn more, please reach out to the team.