Supply Chain Attacks: Who do we trust?


Posted on by Roderick Chambers, CISSP, CISM

In December 2020, reports surfaced that a system servicing multiple government agencies, including the US Department of the Treasury and the US Department of Commerce’s National Telecommunications and Information Administration (NTIA), were the targets of one of the most prolific supply chain attacks ever. While reviewing the investigation, it was rather curious that there was no mention of a typical infiltration through a social-engineering phishing attack. The threat actors, most likely a nation-state sponsored advanced persistent threat, apparently didn’t send an email to the weakest link and worm their way into the system.

What happened here is far more sinister, mainly because of two key points. First, the threat actors were able to gain covert access to thousands of systems through the supply chain’s distribution side because of the assumption of customer and vendor trust. Second, experts do not know the extent of the compromise of information in these systems. The threat actor has had access to many important and sensitive networks for six to nine months or more. It could be quite some time before security experts can determine how widespread was the attack.

What type of cyber-incident occurred?

A major technology provider was the initial target of a supply chain attack. A supply chain attack, also referred to as a third-party or value-chain attack, occurs when a malicious threat actor accesses an organization’s network by infiltrating a business partner or supplier with authorized access data. Supply chain attacks evade traditional network analysis and detection tools, do not depend on human error as required in phishing and vishing attacks, and grant unauthorized access to hardened targets.

What have been the immediate effects of the attack?

Supply chain attacks are particularly bothersome because the threat actors violated the basic, requisite and assumed trust between the provider and its consumer. Customers are conditioned to buy and install software only from trusted sources, and download patches or updates only from authorized vendors. Now, users must be cautious of performing those basic cybersecurity tasks and conduct proper due diligence when purchasing software and maintaining systems since, as this attack has shown, even trusted, authorized sources may be compromised. The following recommendations are high-level examples of focus points that security experts should review with their vendors and third-party service providers. 

  • Third-Party Service Provide Cybersecurity Management: Security practitioners should investigate and review the organization’s methodology for layered security, especially with third parties. The concept is if one tool fails, another steps up immediately to prevent an attack, usually called defense in depth.
  • Identity and Access Control: Entities should apply the principle of least privilege—in other words, allow only enough access to each employee as required to perform their specific job. Adhering to the principle of least privilege access reduces the risk of threat actors gaining access to critical systems or sensitive data by compromising a low-level user account, device or application to access more sensitive, nonpublic information. Separation of duties is effective, which implements a fail-safe requiring more than one person to complete a task. When properly designed, separation of duties ensures that no single person has complete control over the information system environment. No one has all the keys.
  • Reviewing the Incident Response (IR) Plan: Reviewing IR plans include how the vendor intends to prevent, detect or recover from the Internet or cyber-based incidents. IR plans are tested annually, or when there have been changes to the IT environment or the information security program, usually as a tabletop exercise. An IR tabletop exercise is the equivalent of a cybersecurity fire drill. The tabletop exercise provides a platform for the security team to discuss, in a classroom-type setting, their roles in response to an incident.

Vulnerability Management: To patch, or not to patch? That is the question.

Those impacted by the supply chain attack did not intentionally make themselves vulnerable, but it did create an environment that compromised security. Vulnerability management is a constant race to fix vulnerabilities in an IT environment. In this supply chain attack, there are two camps of IT administrators. In one camp, some administrators followed the industry recommended vulnerability management practices. They implemented a software update patch to their operating environment purportedly issued by the trusted vendor to quickly remediate any vulnerabilities.

In the other camp, some users delayed implementing the patch for one reason or another for up to 10 months. Those users dodged the download of the infected software; however, they accepted the risk of operating a system that required a patch issued by the vendor to remediate a vulnerability. Did this group of campers avoid the chaos, or did they get lucky?

If there’s a bright side, it’s that this supply chain attack has shed light on an attack vector that has proven one vulnerability can lead to thousands of compromises. 

Contributors
Roderick Chambers, CISSP, CISM

Lead Security and Risk Engineer, Recorded Future

Human Element

security awareness

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs