Companies and organizations have more options than ever for sourcing software applications and services from third-party suppliers. This rich software and systems ecosystem means that organizations can purchase rather than develop in-house the software capabilities that are needed. This outsourcing, however, has created risks. Organizations using third-party applications have little control over how those applications are coded, monitored and maintained, but often may be among the first to suffer the effects of exploitation.
As supply chain and third-party risks have grown, limiting vendor exposure is a mandatory exercise. It is critical to perform a comprehensive risk assessment that covers vendors’ cybersecurity systems and incident response. This vetting has evolved into its own category of services called information technology (IT) vendor risk management (Gartner’s profile here). A number of firms specialize in executing audits and studying outside metrics to determine the cyber resiliency and continuing resilience of organizations. This blog post focuses on how organizations can use vulnerability monitoring to continually evaluate their own security stance and that of their suppliers.
Supply Chain Chaos
Applications and services are like nesting dolls, composed of software libraries, open source components, bits of code from GitHub and other sources that were not directly developed by the software vendor on the label. This is recognized as an increasing source of risk and prompted movements toward creating software bill of materials (SBOMs), which detail the components of a software program. For threat actors, this complicated software ecosystem is advantageous: discover a vulnerability in a widely used application – or better yet, an open source component used in hundreds of applications – and unleash chaos.
This scenario increasingly has played out. In December 2021, threat actors started exploiting a vulnerability in the Log4j open source logging tool. Log4j was a Java-based open source logging library prevalent in applications and services. After the vulnerability was disclosed, it wasn’t necessarily clear which services were at risk due to the opaque nature of how different software components are used to make an application. The information imbalance around where Log4j was present meant threat actors could explore an internet-wide attack surface with defenders questioning if they were even vulnerable.
Risk also comes from organizations sharing access to each other’s systems. Third-party suppliers and vendors are increasingly connected. However, they may not share the same levels of cyber resilience and maturity. In turn, a third-party service usually also uses third-party services, resulting in a dizzying maze of online assets with varying security. If threat actors exploit a vulnerability in one organization’s supply chain, they may be able to gain access to another party, eventually installing malware and exploiting data for financial gain.
Causes of Third-Party Vulnerabilities
Misconfigurations
Many apps and cloud services require manual configurations which render them susceptible to exploitation by threat actors if misconfigured. For example, cloud services often use a shared responsibility model for cybersecurity. Customers may be responsible for certain aspects of their application, which if not carefully managed can result in misconfigurations. Those misconfigurations in the infrastructure may permit unauthorized users to access systems or data.
Unpatched software
Vulnerability management is one of the most challenging areas for any organization. Large organizations may use thousands of applications in which over the course of a year thousands of vulnerabilities may be collectively discovered and disclosed. Security teams often can’t patch all applications upon the release of a fix (and neither is it necessary depending on the severity of the flaw and other factors). But failing to apply patches for critical vulnerabilities in internet-facing applications is a gamble. Threat actors will actively conduct reconnaissance to identify unpatched systems.
Zero-day vulnerabilities
Zero-day vulnerabilities are software flaws that are being exploited by attackers before the software vendor is aware of a defect. Because the flaw was unknown, no patch is available. Threat actors race to exploit the vulnerability before a patch is released or mitigation advice is provided.
Using Vulnerability Intelligence
Monitoring third-party services is a component of a comprehensive vulnerability management strategy. Cyber threat intelligence (CTI) can provide timely information about active threats, vulnerabilities and threat actors relevant to the organization and their third-party suppliers to stay one step ahead of attackers.
Tracking the different phases of how vulnerabilities are being disclosed and discussed in the underground can give practitioners a view of the evolving risk. The disclosure and use of vulnerabilities by threat actors can be swift and unpredictable.
For example, a zero-day vulnerability may first start being exploited only by a single threat group. The vulnerability may become public and then acknowledged by a vendor. An independent researcher not affiliated with a threat group or vendor may suddenly drop details of the flaw on social media, increasing threat actor interest. Adversaries may start inquiring on underground forums about whether working exploits are available. The vendor might deploy a patch, but a malicious actor may successfully reverse engineer it and start looking for related flaws that the patch doesn’t fix. Eventually, proof-of-concept (PoC) code may be developed, an exploit is weaponized and then offered for sale.
By collecting intelligence, these stages can be tracked depending on visibility, allowing practitioners to determine their risk and prioritize.
Because of the sheer number of vulnerabilities reported and cataloged day to day, our vulnerability monitoring triages and prioritizes them with the highest impact and likelihood of exploitation. Analysts manually review and validate vulnerabilities based on criteria including exploit status, threat actor interest level, patch availability, Common Vulnerability Scoring System (CVSS) score, Common Vulnerabilities and Exposures (CVE) ID and more. Below is an example of how these metrics are tracked in our platform.
In the above dashboard, the red dash means a patch is unavailable. The amber “interest” dash means the flaw is being discussed in the research community, and the green dash means the flaw is a publicly disclosed CVE. The green “location” dash indicates where actors are discussing the flaw, such as in open source channels, private communications or underground forums. The bomb symbol under “exploit” means that there is a working exploit. A shopping cart indicates when a working exploit has been confirmed as sold. This exploit lifecycle indicator allows for recognizing different threat levels associated with a vulnerability. Analysts can pivot to related intelligence reports and risk assessments and then inform a third party about the impending exploitation of a system they own.
Conclusion
The risk from third parties and suppliers should not be underestimated. Threat actors view these relationships as weak side doors into hardened targets. By focusing on the weakest point, adversaries can achieve the sought-after initial access. Exploiting vulnerabilities is one of those attack methods, but with close monitoring of vulnerability lifecycles, organizations can become more agile in defense.
