We have announced and talked about the concept of “known provenance” as a crucial software-assurance and IT-lifecycle-management metric for some time, but it struck me today that I haven’t really underscored some of the reasons and use cases that led us to this conclusion.
Firstly, there are multiple dimensions to software integrity assurance that leverage cryptographic validation (hashing) methods including:
1. Do I know that the software elements that I am loading and running on my platform ARE what they say they are?)
2. Security quality assurance – can I couple (1) with a quantitative expression of code vulnerability statements? (Is it the code it purports to be and is it secure?) For example, our recent work with Veracode.
3. And what proof do I have that this was the code that I am using was actually built by the named vendor? (The filesystem may think that it is XYZ ISV, but it is the software that is vouching for itself, perhaps with the aid of a installer-embedded certificate. Inconclusive at best, especially after installation)
So we have taken the position early on that we need PROOF that the code was actually built by the named supplier as a crucial attribute of software and device validation or attestation. We call this (AKA Source Origin or Known Provenance.
The road to obtaining provenance and delivering it across various use cases is clearly the harder road when collecting software measurements. It requires “quality over quantity” dedication…..means that ISV’s and other software producers and integrators need to be involved. After all, true known provenance can only be delivered with a certifiable “chain of custody” all the way from the original software vendor and then managed all the way to the end system.
Open standards in method and schema are key, and the industry has done a decent job at collaborating on these—with additional iterations now pending.
But back to the title of this blog: So What?
Here is quick snapshot of use cases where provenance is increasingly critical:
1. Software Forensics – The objective here is to identify the problem by definitively separately the “good” from the “bad” (and the “unknown”). This is simply common sense, as our objective with forensics is to spend our time as efficiently as possible while looking for the “needle in the haystack”. Efficiency demands that we make the haystack smaller ASAP in our quest for the needle.
2. Supply Chain Assurance – This one deals with both the supply and purchaser concern of “Is this the device that I think it is? (i.e., was it in fact built by the named supplier, and is the h/w and s/w integrity demonstrable?).
3. Service Level Assurance (SLA) Management – This is the classic issue of “Ok, something doesn’t work, and whose fault is it?” (I’m sure you’ve never seen finger pointing on this one.)
4. Compliance – Needless to say, when provenance is clear and trusted, we can improve statements of compliance as well. (I know that I have the right software build in place—i.e., the right software manifest and integrity; and I prove the software and work product in the build is from the named author?)
So the power to prove, enabled by software and hardware provenance, is not a luxury item. In this age of globalization and outsourcing of design, manufacture, distribution, and systems management, we must establish and maintain “trust chains” to all the devices that we build and supply.
For suppliers of complex hardware and software, provenance is a cradle-to-grave issue. How can we truly and cost-effectively own and support our “Brand” without it?
So, as we enter the next chapter of ubiquitous computing (aka Web 2.0), our ability to design trust into our devices early in their lifecycle and systematically validate and pass that trust through the lifecycle of our “brand” in a non-repudiated manner will become a key market differentiator.
One might even go as far as to say:
Those who do not embrace this view may not survive the next wave of consolidation (which by the way is already well underway).