It’s been an interesting few weeks for us cybersecurity and supply chain security boffins. Last week, the National Institute of Standards and Technology (NIST) held a workshop titled Best Practices in Cyber Supply Chain Risk Management. It was a great opportunity for those of us working in supply chain risk management to communicate and discuss recently completed standards like ISO-20243 (O-TTPS) and validate proposed governance, guidance and tools developed by agencies to help the acquisition community mitigate risk.

I had the privilege of participating in the workshop and discussing the history and potential use of the standards and tools created. I walked away with two observations: Firstly, most companies and organizations don’t understand the difference between technology supply chain security and implementing cybersecurity controls within IT. The other observation — which seemed to be validated by our hosts — was that government and industry appear to have many of the standards and tools necessary to address these risks.

Major Events Call Attention to Supply Chain Security

By complete coincidence, the NIST workshop came on the heels of two very public events that can certainly be categorized as cyber supply chain incidents. Both of these incidents were topics of many workshop discussions. Workshop participants agreed that these incidents should be considered from both the manufacturing/development and acquisition perspectives.

Problems With Malicious SDKs

The first incident found major mobile application vendors cleaning up their mobile app stores after discovering that application developers blatantly circumvented procedures for accessing and integrating software development kits (SDKs). As it turns out, many foreign mobile application development companies were not following policy and opted to use unauthorized SDKs instead. Of course, these SDKs turned out to be maliciously counterfeited, putting end users and their data at risk.

One might ask why a developer would access counterfeit development libraries on purpose. The fault probably comes in several flavors: Some developers might have wanted to develop applications before submitting a formal request for hosting the app — or possibly were just lazy. Another potential possibility could be limited bandwidth access in certain countries throttling access to foreign sites; it’s easier to download from local sites than throttled out-of-country sites.

Regardless, the outcome was predictable. Unwittingly, developers accessed SDKs that were maliciously tainted, which provided attackers with potential back doors to those applications. Expect changes in mobile application governance and tools to migrate this risk going forward.

Issues With the Auto Industry

Supply chain integrity practices are intended to help ensure that customers receive the product and functionality for which they paid. When this doesn’t happen, questions about supply chain standards arise — which is exactly what happened with the second incident, involving the auto industry. This incident was unique because it was actually sanctioned from within the very company that made the product, and it could be characterized as an insider attack intended to undermine the very functionality that customers thought they were buying.

This could be characterized as a supply chain attack because the code intentionally undermined the functionality of the manufactured product as advertised. In addition, we can assume that not everyone in the company knew about this rogue functionality because of the amount of time it remained hidden and the fact that no whistleblower ever came forward (that we know of).

What’s the Answer?

There are no easy solutions to prevent these types of supply chain risks. But we do have the tools to significantly mitigate them. Developers should scan code for vulnerabilities and attempt to ascertain the lineage of components. At the end of the day, supply chain security is directly proportional to the level of integrity of those manufacturers or developers that contribute to the end product.

And as we validated in this workshop, supply chain security risks are often manifested in cybersecurity incidents. Those developers who flagrantly flaunt established supply chain security policies and practices should be penalized, if not banned altogether from participating in the growing mobile and cloud digital ecosystems.

Industry best practices and security standards such as ISO 20243 and NIST 800-161 form the bases for guidance, future tools and even a code of conduct as digital markets evolve. While standards, governance and policy will not reduce the risk to zero, it does provide the guidance necessary to mitigate ignorance or laziness. Intentionally injecting a vulnerability to circumvent regulators brings to light a whole new class of supply chain risks.

To learn more, read the article I co-authored in the IBM Journal of Research and Development.