CISOs: Do you know what’s in your company’s products?

In the guidance issued by the Cybersecurity and Infrastructure Security Agency (CISA) in April 2021 on securing one’s supply chain, a portion of the guidance was dedicated to the threat vector posed to entities during their design phase.

The question COOs should be asking their CISO’s is: “How can I make my product and processes the most secure and operate within acceptable risk parameters for the company and our customers?” 

In many companies, both large and small, operations and production operate separately from information security. Some CISOs lack the recognition that the latter is the support element to the former. This dichotomy often creates friction and abrasive relationships when the situation calls for the exact opposite.

Operations own the risk; CISOs and their teams provide support to close the gaps and minimize the identified risks (and to be prepared to pivot when new unexpected exposures are revealed).

When product design takes place, and third-party firmware or software is identified to be a part of the product, who conducts the security review? The vendor, the CISO’s team or operations?

The answer is, “Yes.”

Product and software review

Speaking at the conference on Security and Privacy in Communications Systems in 2017, a team from Shanghai’s Jiao Tong University, noted in their presentation “Security Analysis of Vendor Customized Code of Firmware of Embedded Device”  how the necessary security analysis was difficult at best and often ignored. They cited the tedious, time-consuming, and ad hoc effort required to reverse-engineer processes and procedure within an embedded device’s firmware. Their solution? Focus on “only a particular part of the entire embedded device’s firmware”—that portion called “customized code.” They posited that such often is created for the customer without security implementation guidelines.

The National Counterintelligence and Security Center (NCSC)’s March 2021 Software Supply Chain Attacks guidance update touches on the methodologies with examples of each. The NCSC points out how “attackers have inserted malware before the software code has been compiled and signed, embedding it behind standard security signatures and decreasing the likelihood of its detection.”

The NCSC observation was exactly what happened to Seagate in 2007. Seagate saw its Maxtor disk drives had a capability allegedly inserted by the Chinese during the parts provisioning before being provided to the plant in Thailand. Approximately 1,800 devices arrived at a distributor in Taiwan ready to compromise targets of interest with the goal of copying and forwarding data from Taiwan into the PRC, quite literally right out of the box. It was a scatter-gun targeting approach, but the Taiwanese Intelligence Bureau was called into investigate by those who saw their data leaving and going to China.

Meanwhile, the ACLU, taking a bit more of a jaundiced view at the need for software updates, has created a primer on the dangers of such and how to navigate through the morass of potential evil implementation. It is, and should be, a mandatory read for anyone responsible for the risk assessment associated with either side of the software update coin.

On one side of the coin, those responsible for including third-party software into one’s ecosystem should understand how software is updated, authenticated, and verified pre-implementation. On the other side of the coin, those responsible for conducting software updates need to ensure their processes and procedures are visible to their customers’ information security teams for examination and validation prior to injecting the new code into their environment.

The Chinese team in 2017 was spot-on then, and their admonishment is spot-on today in 2021. Engaging in product and component review is not for the faint of heart. It is work. Though one might take exception to the Chinese suggestion of focusing only on the customization of a vendor’s product for implementation into your widget or service, it is a start.

CISOs need bigger role in product security

That start means infosec teams need a seat at the table both for product security as well as networking (intra-company or external facing) with customers, suppliers, and employees/contractors. This only happens if you use the tent concept of including all concerned parties in  information security implementation and not a siloed concept. It is incumbent upon all to work in unison to identify and minimize risks. A zero-risk state exists only in Nirvana.

CISOs have a dynamic engagement with product and operations. This engagement will benefit by adopting the Cyber Supply Chain Risk Management Framework (C-SCRM). To assist in the understanding of the why behind the need for C-SCRM, CISOs may wish to point to the “key practices” guidance and observations provided by NIST in February 2021. This document was crafted after surveying companies on what their practices were with respect to securing the supply chain and therefore of value to both the operations and information security teams.