Why Software Provenance Matters, Part III: Supply Chain Management

Another interesting use case for whitelist-based configuration management is bubbling to the surface (again): IT Device Supply Chain Management

I say *again* because this one came to our attention several years ago, when we built a successful Proof of Concept (PoC), but the IT device manufacturer (who will go unnamed in this blog post) never deployed the PoC as they believed that it was either not that big of an issue/risk/priority or they decided they could handle internally with their own workflow management and in house systems.

Ultimately in that case, the problem was never fixed effectively – and now it has become a high-profile issue in the marketplace.

So here is the problem statement/use case:

I am a manufacturer of a piece of IT hardware that contains software. It may be a computer, a mobile device, a medical device, or even network devices (routers, switches etc.).

I build the hardware, provision the software (most likely these processes are geographically distributed and often outsourced) and then the device is boxed up (with MY brand on the box, shipped thru a few levels of distribution, in and out of customs, and eventually ends up at a customer site.

How do I (as the manufacturer) assure my customer that what was built, shipped and branded by me is what the customer received and installed.

Why does this matter you might ask. Or more specifically, what is the risk?

Well the box may have been opened a couple of times, a VAR or reseller may have added or changed some software (to include their branding or logo for example) – so what I built and shipped IS NOT what actually ended up in the customer site. But I still have warranty responsibility. And I am responsible for my BRAND regardless of how the product made its way to the customer.

Let add another risk dimension:

The device ends up at the customer, it has my brand on it, may have been sold thru channels as “new” but it is actually remanufactured – or worse yet – an actual reproduction that LOOKS LIKE my product. Even though this is not my “fault” – it is still my brand, and my channel (potentially) that is compromised so at least some of the blame/brand damage falls to me.

Ok, you seeing the risk here I hope….but how does known-provenance whitelisting help? Glad you asked.

The PoC that we did a couple of years ago was intended to support this workflow:

– We cryptographically “captured” the software/firmware archive as the device manufacturer built and released new “production code” from their software build systems.

– When the software is “married” to the hardware as a part of the final product/device assembly – we established the relationship of the hardware is connected to the software that is populated on the product/device. This can be as simple as capturing the serial number and the software revisions and cryptographic meta-expressions in a database. In more advanced platforms and use cases, a hardware cryptographic token (such as a trusted platform module) might be used to anchor the authenticity and provenance of the device/platform.

– When the customer installs the device, as a part of the installation/registration process the device reaches out to the database (via encrypted web services) to make sure that the build status aligns with the install status.

This is a classic “close the loop” validation process. Pretty simple to do. And it has many of advantages beyond device/brand integrity. Perhaps the manufacturer has updated the firmware/software and it needs to be reflashed. Also (as the manufacturer) I might be able to benefit from some of the “phone home” data interchange that is enabled by this method. Also gray market or clone products will likely be revealed by this work flow.

These supply chain issues are another important use of known-provenance whitelist software validation.
All of these statements known-provenance, measurement and attestation are really intended to solve the same basic issue. Our compute platforms are “open-loop” by design, as are many of our IT methods and best practices.

We cannot secure what we do not monitor. And we cannot monitor what we do not measure. It is as simple as that.

We MUST fix these issues, and sooner is better than later.



2 Responses to Why Software Provenance Matters, Part III: Supply Chain Management

  1. I am thankful for the new things I learned reading your post. Thanks.

  2. supply chain says:

    Software provenance is a new concept to me, thank you for sharing this!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: