Supply chain attacks are growing more common. According to the Identity Theft Resource Center (ITRC), there were just 19 supply chain attacks in the final quarter of 2020. In the following quarter, that volume grew to 27 attacks — an increase of 42%. Those incidents in Q1 2021 affected 137 U.S. groups and a total of seven million people. Why are they such a problem? And, how can you protect against them in the course of vendor management?

The second quarter of 2021 brought another increase for supply chain attacks, with the number of incidents growing by 19% to 32. The 59 supply chain attacks detected through June fell just behind the 70 malware-related compromises in H1 2021. So, the training provider predicted that third-party risks stemming from supply chain attacks and other incidents will surpass malware as the third most common source of breaches by the end of the year.

Why Supply Chain Attacks Are So Difficult to Block

Many businesses and agencies struggle to defend themselves against the growing volume of supply chain attacks discussed above. Why? Well, it’s not always easy to ensure defenses after vendor management begins. As reported by Opus, organizations share sensitive information with 583 third parties on average. Those entities all have different policies when it comes to what they do with their clients’ data. Some might not have processes in place that accord with existing policies, for instance. This puts them and their data at risk. Depending on those policies, such risk might persist even after a group terminates its contract with a vendor. Attackers could perform business identity theft using these forgotten accounts and data.

However, IT and security teams must commit a lot of time and resources to review the policies of all their third parties. Putting so much of their time into vendor management would pull personnel away from their current projects and thereby undermine IT resilience and security in other ways. It also wouldn’t account for the other companies to which the vendor connects. Those might retain access to systems or data outside the knowledge of IT and security teams.

Screening: The Beginning of Vendor Management

Keeping in mind the challenges discussed above, it’s key to not delay vendor management until they already have their work agreements in place. That’s why they need to begin screening vendors as part of the process of making those arrangements.

They can do this by requiring an explicit security policy for review during the beginning of vendor management. Such a policy should include information about the vendor’s disaster recovery capabilities, its procedures surrounding the retention of its client information as well as its programs for managing privileged access and for responding to a confirmed security incident. Organizations can review the details of the policy and confirm whether they accord with their requirements. What if they find an area of weakness that they feel could put their systems and/or data at risk? They can refuse to work together or demand that they rectify the issue as a condition of doing so.

Where Vendor Management Goes Next

The work doesn’t end with screening vendors, either. Per CIO, organizations can uphold their other vendor management duties by conducting regular security audits of their third parties’ existing controls and scheduling reviews of those policies on an ongoing basis. Some might struggle to complete those steps on their own. It becomes more difficult with the volume of vendors that they need to manage. As a result, consider automating vendor management using managed software solutions such as privileged access management.

More from Incident Response

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Breaking Down a Cyberattack, One Kill Chain Step at a Time

In today’s wildly unpredictable threat landscape, the modern enterprise should be familiar with the cyber kill chain concept. A cyber kill chain describes the various stages of a cyberattack pertaining to network security. Lockheed Martin developed the cyber kill chain framework to help organizations identify and prevent cyber intrusions. The steps in a kill chain trace the typical stages of an attack from early reconnaissance to completion. Analysts use the framework to detect and prevent advanced persistent threats (APT). Organizations…

Defining the Cobalt Strike Reflective Loader

The Challenge with Using Cobalt Strike for Advanced Red Team Exercises While next-generation AI and machine-learning components of security solutions continue to enhance behavioral-based detection capabilities, at their core many still rely on signature-based detections. Cobalt Strike being a popular red team Command and Control (C2) framework used by both threat actors and red teams since its debut, continues to be heavily signatured by security solutions. To continue Cobalt Strikes operational usage in the past, we on the IBM X-Force…

What is a Red Teamer? All You Need to Know

A red teamer is a cybersecurity professional that works to help companies improve IT security frameworks by attacking and undermining those same frameworks, often without notice. The term “red teaming” is often used interchangeably with penetration testing. While the terms are similar, however, there are key distinctions. First and foremost is the lack of notice from red teams. Pen testing may be scheduled in advance to assess the ability of specific security measures to handle a simulated attack; red team…