Securing your network means ensuring the security of your suppliers.
2024 MDR Buyer's GuideA supply chain attack is one in which an organization is victimized by a threat actor that has gained access to the target network via one of the organization’s supply chain partners. In this way, the threat actor not only has access to the organization whose network security they’ve managed to penetrate, but also to any third party plugged into the breached network.
According to the Cybersecurity Infrastructure and Security Agency (CISA), a supply chain attack – also known as a software supply chain attack – can occur “newly acquired software may be compromised from the outset, or a compromise may occur through other means like a patch or hotfix.”
Supply chain attacks work by an attacker strategically deploying malicious code into updates they know are meant to go off-network almost immediately. This is because the threat actor has chosen to target an organization acting as a vendor to another organization, to whom they might be supplying regular updates in the form of things like patches for vulnerabilities. CISA identifies three common attack techniques preferred by attackers:
Supply chain attacks are on the rise due to a number of factors such as the digitization of much of the world’s communications and enterprise information sharing. Attackers, too, are growing more confident in their abilities to breach a targeted organization via one of its supply chain partners, such as a trusted vendor or contractor.
Another major contributor to the recent rise in supply chain attacks is proliferation of open source software procurement. Some security organizations don’t even regularly learn of new open source vulnerabilities in the short term – even after they’re disclosed.
Perhaps a project is shipped on time, but malicious code was long ago injected into those open source components on which that project was built. If the malicious code is discovered prior to the project shipping, that’s great. But now, instead of continuing with forward progress, remediation becomes the name of the game.
Open source code can create amazing efficiencies within a development organization, but if vulnerabilities or attacker signatures aren’t detected, then it could be disastrous to that organization and business at large. Security in open source software also carries some other unique challenges due to the open environment. A project that leverages open source software libraries tends to accept – by the very nature of leveraging open source – a wide variety of contributions.
Within a project of this type, for example, a new feature might not be prioritized highly enough for the primary developers engaged in the software development lifecycle (SDLC) to dedicate time to it. But anyone in the open source community who takes the time to develop the feature while staying within the bounds of the project’s goals and best practices may very well have their contribution accepted and merged into a project.
Thus the project suddenly may find itself an unwitting target of malicious contributions through "convert defect introduction."
In addition to the types of attacks mentioned above, let's take a look at some additional types of supply chain attacks threat actors like to leverage when going through an intermediary to achieve a primary target.
According to the National Cyber Security Center of the United Kingdom Government, there are a few common vectors through which attackers regularly make their way to a preferred destination:
We've covered many types of supply chain attacks that threat actors tend to deploy onto unsuspecting vendor/client relationships, so let's take a look at a few well-known recent examples of malicious attacks.
There are obviously many tactics a security operations center (SOC) could employ in order to mitigate the risks and/or effects of a supply chain attack. But let's take a look at some of the more common best practices in creating a more secure supply chain.
Every organization has ingress and egress points with various external applications and service providers. When new services or vendors are procured, access control lists (ACLs) are updated to accommodate the new data streams.
Early stages of an incident are often daunting, frustrating, and confusing for all parties involved, and one of the most critical elements of incident response is containment. Many vendors will immediately disable external connections when an attack is discovered, but relying on an external party to act in the best interest of your organization is a challenging position for any security professional.
If your organization has a list of external connections open to the impacted vendor, creating templates or files to easily cut and paste commands to cut off the connection is an easy step in the planning phase of incident response. This ensures whatever nefarious behavior occurring on the vendor’s network cannot pass into your environment.
Having a centralized repository of vendors with key points of contact (POCs) for the account and service-level agreements (SLAs) relevant to the business relationship is an invaluable asset in the event of a breach or attack.
The repository enables rapid communication with the appropriate parties at the vendor to open and maintain a clear line of communication, so updates can be shared and critical questions answered in a timely fashion.
Create templates for communications about what your team is doing to protect the environment and answer any high-level questions in the event of a security incident. For these documents, it is best to work with legal departments and senior leadership to ensure the appropriateness of the manner in which this information is disclosed.