In recent years, cyberattacks have evolved right along with our defenses (to absolutely no one’s surprise). Attackers are looking for, and finding, new and innovative ways to compromise assets and data – from end-user attacks like credential theft and browser-based malware, to cloud-focused attacks that leverage APIs and cloud native services.
Unfortunately, cyber attackers have also discovered how to compromise us through software, which is undoubtedly the weakest link in many corporate environments. Let’s face it: a huge percentage of large enterprises don’t have an accurate or up-to-date software inventory, and we often know very little about the software developers creating, packaging and delivering this software to us.
Just because we purchase software from large, well-known providers doesn’t mean attackers haven’t infiltrated their environments and shipped out something nasty, unbeknownst to the software manufacturer. This is exacerbated when dealing with smaller firms and start-ups – whether packaged software, SaaS or other cloud services – due to their lack of resources dedicated to software security.
In short, the software supply chain is a mess.
If you say “SolarWinds” to anyone in IT security, you’re likely to get a shake of the head and a frown – yes, it was that bad. They were owned, they shipped, we got owned, and there you have it – a very elegant malware distribution supply chain at its best.
We’ve seen the crushing impact of the Log4j vulnerability in development environments, and now attackers are loading compromised packages and content to package repositories. Third-party breaches won’t slow down, either. That is until we start to get a handle on who we’re buying software from, where it lives in our environments, what privileges it has, what it has access to – and, most importantly, whether we can trust it in the first place.
8 Steps to a Third-Party Incident Response Plan
When one of your critical vendors is breached, being ready with a prescriptive incident response plan is essential to preventing your company from becoming the next victim.
There are some great industry efforts underway to strengthen software supply chain security. Many in the IT security and software industries, along with the entire risk management community, have been advocating that organizations publish and maintain a software bill of materials (SBOM) that can be disclosed to customers upon request. An SBOM is a formally structured list of components, libraries and modules that are required to build a piece of software. SBOMs provide a much deeper insight into the potential vulnerability posture of the software itself by enumerating its components.
Some software manufacturers have resisted crating SBOMs, likely due to the perception that they’re somehow disclosing sensitive intellectual property. However, we all know that everyone uses open source everywhere. SBOM isn’t source code; it’s a list of packages and components used to build software, many of which have been found to be highly vulnerable to attacks over the years. The U.S. government is pushing for SBOM, and it could easily become a leading element of third-party risk management monitoring and reporting in the near future.
Other focal areas in the industry include the creation of software supply chain attack workflows such as MITRE ATT&CK, a universal vulnerability reporting mechanism and syntax for software bugs.
I’ve partnered with Prevalent to deliver a best-practices webinar on software supply chain security that examines how a mature third-party risk management strategy can help you get a handle on attacks against your IT vendors. Watch How to Assess Your Software Vendors' Cybersecurity below.