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, open-source providers, 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. More recently – and different from the Solar Winds, Log4j, or the Codecov incidents – we've seen the XZ Utils vulnerability, where an attacker used social engineering to get into the backdoor of the widely used open-source data compression utility in Linux systems.
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.
9 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 advocated for organizations to 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 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 creating 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 are 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.
This latest vulnerability serves as a reminder that organizations should have a third-party incident response plan in place to quickly determine the impact of software supply chain compromises on their third-party vendors. Here are four best practices to consider:
This will enable you to tier and profile your vendors according to the criticality of the services provided and to quantify the likelihood and impact of a breach. Accurate profiling and tiering also enable you to right-size your ongoing due diligence based on the vendor’s tier. High-tier vendors (e.g., those whose failure created an operational problem for your company) get the most attention.
Collecting fourth-party technologies deployed in your vendor ecosystem during the inventorying process helps identify relationships between your organization and third parties based on certain technology usage. This will help you visualize attack paths in your enterprise and take proactive mitigation steps. You can accomplish this through a targeted assessment or via passive scanning.
Proactively engage vendors with simple, targeted assessments aligned with known industry supply chain security standards such as NIST 800-161 and ISO 27036. Results from these assessments will help you target needed remediations to close potential security gaps. Good solutions will provide built-in recommendations to speed up the remediation process and close those gaps quickly.
Being continuously vigilant for the next attack means looking for signals of an impending security incident. Monitoring criminal forums, onion pages, dark web special access forums, threat feeds, paste sites for leaked credentials, security communities, code repositories, and vulnerability and hack/breach databases is essential. You can monitor these sources individually or look for solutions that unify all the insights into a single solution, so all risks are centralized and visible to the enterprise.
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.
Learn how a third-party risk management (TPRM) policy can protect your organization from vendor-related risks.
11/08/2024
Follow these 7 steps for more secure and efficient offboarding when third-party relationships are terminated.
10/17/2024
Third-Party Risk Management (TPRM) has advanced from being an annual checklist exercise to a critical daily...
10/07/2024