Enter Configuration-Based Whitelisting

This post is going to tie a couple of prior discussions together (I hope).

In August 2008, I posted a blog entitled:

Whitelist Emerges from the Shadows: Re-enforcing the Three-Tier Security and Systems Management Model

And in my most recent post entitled:

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

I took a stab as creating a taxonomy for whitelisting methods, as this space is really just taking shape – and clearly not all “code-whitelisting methods” are created equally.

So the “dot-connection” is this:

Effective whitelisting is really about total configuration enforcement, not just blocking individual elements. And as I stressed in the first blog, it is really a THREE-TIER architectural challenge, not a traditional two-tier problem like blacklist solutions.

And interestingly, the “heavy lifting” to make all this work is not at the ends of the architecture (Tier 1 or Tier 3) but in the middle – Tier 2.

(Refresher: IMHV, Tier 1 is the whitelist cloud services, Tier 2 is the domain whitelist caching and the reference-configuration management), and Tier 3 is the endpoint measurement and policy enforcement agent/client/OS/Hypervisor support).

We think that the real power, manageability and scalability of the method comes into view when we move from just “Good File” to “Configuration-based Whitelisting”, where we pass more whitelist “intelligence” to the method (things like parent-child relationships of the elements and provenance of the elements being enforced).

Clearly, the cloud and local whitelist agents are needed to collect and pass that information – but the key is supplementing that information with additional domain-specific configuration and element data, and organizing the entire lot into configuration-setting and software stacks that should be present on the platform under management.

And all of this must be platform/device decoupled, must be data-type independent (files, registry, config settings database fields, etc), must be mappable in the reference configurations and must be vendor/platform/software-type neutral.

Whew. Sorry, that was a mouthful.

Real and immediate use cases for this include requirements like Federal Desktop Core Configuration (FDCC) and other compliance issues.

These are exciting times for the space, IMHV. Stay tuned for more.

Wyatt.

Advertisements

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 )

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: