• United States



Christopher Burgess
Contributing Writer

CISA issues guidance on defending against software supply chain attacks

News Analysis
Apr 28, 20215 mins
CyberattacksSupply Chain

The government makes recommendations for both organizations and software vendors to minimize the risk of software compromised by a criminal or foreign adversary.

vulnerable breach cyberattack hacker
Credit: Thinkstock

The Cybersecurity and Infrastructure Security Agency (CISA) has issued guidance this week following the compromise of the SolarWinds software that affected thousands of entities across the United States and beyond. The guidance took the form of a primer for companies, explaining the nature of the software supply chain and the various access points where supply chain vulnerabilities exist. It concludes with concrete recommendations for both vendors and their customers with discussion on the Secure Software Development Framework (SSDF) and Cyber Supply Chain Risk Management (C-SCRM).

What is a software supply chain compromise?

The adversary’s intent is to compromise third-party software being installed on a given target’s system to gain access to information or capabilities of the target entity. This avenue of attack, when successful, might lead to compromise of many or all those using a given vendor’s software package. This was the case with the recent SolarWinds compromise when the Russian SVR targeted one company’s software update and patch infrastructure and opened the door for themselves to a wide swath of customers, to include those within national infrastructure and government.

Successful attacks have been documented across the CISA report’s five identified threat vectors:

  • Design: In 2016, Kryptowire discovered a backdoor in the firmware of BLU Products low-cost Android phones. The phones would send the device’s information to China every 72 hours. Interestingly, the code to affect the delivery of the phone owner’s data was implanted via commercial firmware over the air (FOTA) update installed by AdUps, which also provides similar services to Huawei and ZTE devices.
  • Development and production: A current example of such can be found in the 2020 compromise of SolarWinds. A third-party service provider is compromised and its customers are by extension compromised. Then the adversary exploits those of interest. Russia’s foreign intelligence arm, SVR, has been identified as responsible for the SolarWinds supply chain compromise.
  • Distribution: An enterprising Chinese businessman in 2012 used counterfeit copies of Microsoft’s software, which he had pre-installed on new machines to save money. Microsoft, while investigating the counterfeit situation discovered that not only did the bogus software not operate like the original, but it also carried a malware payload that posed a serious cyberespionage risk.
  • Acquisition and deployment: A US government contractor Nghia Hoang Pho, who worked at the National Security Agency (NSA) within the Tailored Access Operations (TAO), found out the hard way in 2017 that the Kaspersky antivirus running on his machine was not only providing “protection” but was also harvesting content from his device. Unfortunately for Pho, he had brought classified documents home and those were the ones harvested by Kaspersky and by extension the Russians.
  • Maintenance: While the world was reeling from SolarWinds, a separate attack was taking place compromising IT infrastructure with the installation of a persistent backdoor in SolarWinds Orion software. The late-2020 compromise, called Supernova, has been attributed to China.
  • Disposal: IT asset disposition (ITAD) is a necessary housekeeping task often neglected. Example after example percolate to the top of entities whose jettisoned devices contained sensitive data. In early-2020 a German military ruggedized laptop was purchased on eBay for 90 euros (US $109) and no surprise, the laptop was full of classified materials. In late 2019 a company specializing in ITAD conducted a survey by purchasing devices originating from a number of countries. The result: They found 42% still contained data, 15% of which being personally identifiable information (PII) or corporate data.

CISA supply chain risk recommendations

The guidance recommends that customers use the NIST Cyber Supply Chain Risk Management (C-SCRM) document to understand the risks involved with the use of a given piece of software in the infrastructure. The eight NIST-suggested practices are:

  1. Integrate C-SCRM across the organization.
  2. Establish a formal C-SCRM program.
  3. Know and manage critical components and suppliers.
  4. Understand the organization’s supply chain software for which a vulnerability is disclosed.
  5. Closely collaborate with key suppliers.
  6. Include key suppliers in resilience and improvement activities.
  7. Assess and monitor throughout the supplier relationship.
  8. Plan for the full lifecycle.

One vector worthy of approbation is that of the third-party software integration into a vendor’s offering. Transparency requires vendors to disclose the existence of such. Chris Blask, global director of applied innovation at Unisys, notes, “CISA has taken a significant step by including the term ‘software bill of materials’ (SBOM) in today’s cyber supply chain security guidance.”

Blask explains that SBOMs are one of several supply chain attestations that will become more common. He cites the open-source digital bill of materials (DBOM) attestation sharing infrastructure referenced in the CISA guidance. It is intended as a common framework for supply chain partners to control and use these attestations in programmatic C-SCRM structures. “We are at the beginning of a persistent era where vendors and integrators and enterprise will be using, producing, and requiring SBOMs,” he says.

Recommendations made to software vendors included creating a software development life cycle (SDLC) as the norm and not the exception. This would include using, as best as possible, NIST’s secure software development framework (SSDF). The four recommended steps for software vendors to include in developing secure code are:

  1. Define software development security requirements.
  2. Establish SSDF roles and responsibilities within the SDLC.
  3. Automate developer and security toolchains.
  4. Establish software security criteria and processes to collect the data necessary for security checks.

The CISA guidance report contains a plethora of resources worthy of staff review, though review won’t be sufficient. The keys to a secure environment are in the hands of the CIOs, CISOs, and DPOs who are in the position to both demand and ensure their teams learn from the lessons of others and understand the “why” behind the implementation of both SSDF and C-SCRM in products created and used.

Christopher Burgess
Contributing Writer

Christopher Burgess is a writer, speaker and commentator on security issues. He is a former senior security advisor to Cisco, and has also been a CEO/COO with various startups in the data and security spaces. He served 30+ years within the CIA which awarded him the Distinguished Career Intelligence Medal upon his retirement. Cisco gave him a stetson and a bottle of single-barrel Jack upon his retirement. Christopher co-authored the book, “Secrets Stolen, Fortunes Lost, Preventing Intellectual Property Theft and Economic Espionage in the 21st Century”. He also founded the non-profit, Senior Online Safety.

More from this author