The “Whitelist Space” seems to be heating up a bit….

These pages have been talking about the bigger issues of “IT in Transition” for a long while. The shift to “defense in depth”, with the AV players adding whitelist methods, has been a persistent theme on these and other blog pages.

Well in the last few weeks, we’ve seen a couple major moves: first, Microsoft endorsing the concept and working with us to provide their signatures to the market, and now a significant move with the imminent acquisition of Solidcore by McAfee (MFE).

It is interesting that MFE will assimilate Solidcore in the Governance, Risk and Compliance Business Unit. It is what I would consider a “bite-size” move to application enforcement based on whitelisting by MFE. Recently, Solidcore has done a good job delivering value to fairly static endpoint devices – largely focused on the embedded device, ATM, and POS market spaces.

There is also mention in the release of SCADA devices commonly used to control physical infrastructure devices such as electrical and water control/management systems. This could bolster work that MFE may be targeting in Government, where they have done well with the ePO platform.
Solidcore describes their method as “dynamic whitelisting” – also pretty good marketing IMHO. So now we have another bullet on the whitelist method slide. So far we have:

  • Application Whitelisting or Allow Listing (single executable locking/blocking/allowance)
  • Dynamic Whitelisting (aka Self-Referencing – see below)
  • Whitelist Caching (this is what Symantec is doing in their latest Norton offerings so that they don’t have to rescan “known code” again with their malicious detection tools)
  • Comprehensive Whitelisting (this is a superset of Application Whitelisting where entire applications or software stacks may be “measured”, and based on device health” determined by these broader measurements – certain policies may be invoked (like allow/deny platform access to other resources)

(These are the just the “code signing” methods. There are other whitelisting and reputation services being employed for email and URL filtering that is another category entirely.)

Dynamic whitelisting is basically a synonym for “self-learned or self-referencing” configuration image and integrity models where the “whitelist” is derived from the device(s) themselves. Tripwire has been doing this pretty well for a few years.

(Full disclosure again – I co-founded Tripwire, and Solidcore competes directly with Tripwire in the desktop and server integrity market space)

While Self-Referencing whitelisting can be useful, it has a number of limitations and drawbacks. Scalability, manageability, and noise management are just a few of them. By “noise management”, I mean too many false positives, such as when merely upgrading a version of software generates thousands of “file-changed” hits. Also, what if your reference master was corrupted? Or … ?

So, on the one hand, we are happy to see a major AV player dip a toe into the whitelist waters as another validation for the space. We’ll be even more excited when customers and vendors really stretch their legs – and push the envelope with deep and comprehensive whitelisting and reference configuration management methods.

Let’s move beyond executable-lock-and-block methods, and configuration monitoring based on self-learned methods – and get to full and scalable compute-platform attestation, with both root of trust (Trust PROOF built INTO the platform) and known-provenance, list-based whitelisting (PROOF that the code was built by the named authors).

Connecting these dots is necessary to have true platform-intrinsic, end-to-end trust – not just to validate the “easy devices” like POS – but for the more complex servers and workstations use cases.
Yes, it is hard. But the pain will be worth the gain.

It’s time to build more trust into our systems.


3 Responses to The “Whitelist Space” seems to be heating up a bit….

  1. Wyatt,
    A major correction about the definition of Dynamic Whitelisting. Dynamic whitelisting is not self-referenced or self creating whitelisting. It is based on a trust model (the words that you love). The key is to automatically augment the whitelisting with new approved software if the software comes in from a trusted provisioning software, from a trusted software repository on network, Signed installers and many such enterprise software update processes.


  2. Wyatt says:

    Thanks. I was likely overly simplistic is casting Dynamic Whitelisting in the same “self referencing” method category as Tripwire.

    Yes, both Solidcore and CoreTrace do create/supplement the image reference from “trusted sources and stores” — however in both cases the trust is set “locally” with trust inheritance coming from the cert in the installer, or other domain-deemed trust authority.

    This method certainly is better than just extracting image info from each device under management.
    While still short of the trust and flexibility/scalability that can be extended from an external and normalized “trust reference”, with ISV provenance inclusions linked to installer certificates.

    Thanks for the correction Rishi.

    Did I say “trust” anywhere in this post? 🙂


  3. […] The “Whitelist Space” seems to be heating up a bit…. […]

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: