• SNB #1: We Need a Global Industry-wide Application Whitelist
• SNB #2: Use whitelisting in the hypervisor/VMM (especially in the “parent” or Dom0 partition) to prevent the execution of unauthorized code in this security-sensitive layer.
• SNB #3: Root of Trust Measurements for Hypervisors

(Relating to SNB #1 – check that one off. We did publicly announce our working relationship with Microsoft in the area of software whitelisting at the RSA show. A key element of that announcement is the standards for whitelist exchange using a Standard Whitelist Schema Definition – or Data Exchange Format. So an important sub-text SNB is: We need standards in method, protocol and exchange).

So against the backdrop of the RSA events, this blog heading, and staying within the limits of several NDA’s that we (SignaCert) are bound by – let posit a connect the SNB dots:

It seems the goal in both the P (physical) and V (virtual) world are ultimately the same; that is to instantiate a software stack on a hardware platform that is secure, reliable, safe and trusted. This larger stack (hardware plus software) now becomes one of the cogs of a business process (A *Service* in ITIL parlance).

All of the cogs of any completed service should ideally be “trusted” right? Not just a point of instantiation, but all the way thru the point of de-instantiation (There are some interesting compliance issues here to, but that is for later).

1. So the root of trust for measurement (RTM) should be established in the hardware in some fashion, say with a Trusted Platform Key, and establish RTM for HV/VMM (SNB #3)
2. And the Trusted Platform Key should be passed and used to request and validate (attest) the HV/VMM in the Dom0/parent layer (SNB #2)
3. And once we have a “known/trusted” parent environment (and hopefully a way to keep it that way), we pass our “trust baton” up the stack.
4. We then need the HV/VMM to instantiate *the rest of the software stack* with positive attestation methods provided by the Global Industry-wide Application (software) Database (supported now with ISV-sourced software “measurements” aka SNB #1)

And we need some way to make sure what we have instantiated with a proactive statement of platform/image trust, and that it stays that way and we can “prove it”. We might also want a way for that service process stack to offer its “platform trust credentials” to other members of the broader business/service process both in and out of the physical domain that it may reside in (to a partner service process for example).

(public disclaimer on this one too: we have two US patents issued on the precise method of Stack/Platform Trust derived from element trust scores)

To make all of this really work, the platform players must work with closely with the virtualization players, and those player should work closely with the whitelist eco-system folks. And all of the players should work well with the systems management vendors/solutions.

By the way, in our experience one of the trickiest parts relates to #4 above. That is:

How do we manage multiple complex heterogeneous V and P stacks? How do we create and express broader trust credentials across a matrix of dynamic business/service processes?

And another design tenet that we must undertake are persistent and non-persistent connect scenarios. We need to carefully address the prospective circular loop issue of “we need a connection to attest trust credentials – but can’t get a connection because we don’t have trust attestation”.

Cooperation with our eco-system partners is required to pull this one off.

Net-net:

We agree. We need to think and act differently. The “old” P security methods are running out of gas already, so let’s use the virtualization transition to bake trust and security in as we stand up the V ecosystem.

Wyatt.

A parting P.S. Does Security drive Trust, or Does Trust drive Security?