There’s been a lot of talk about what role whitelisting will play in the endpoint protection suites of the future.  Opinions dissent about what it will take for whitelisting to become easily implementable for users and whether it will replace or augment the traditional anti-virus approach.  Whatever the opinion, I think most folks can agree that there are more malware threats coming at us than we can keep up with today and a better overall approach to endpoint management (and ultimately change control) is needed for the future.

Historically, most security suites have been designed around a “threat centric” approach, where the end goal was to identify and filter anything deemed to be “bad”.  These suites have become pretty sophisticated and use multiple layers of identification to weed out threats.  AV, heuristics, sandboxing, fragment matching, etc., are all part of what we have come to expect to see in our endpoint protection products today.  The traditional approach has basically been to add different types of interrogations to ask the question: “Do I have a reason to distrust this piece of code?”  “Is this thing a virus?”

Whitelisting in its raw form seeks to ask the opposite question: “Do I have a reason to trust this piece of code?”  “Is this thing a valid application?” Most of the debate around whitelisting to date has been about this pure form and whether or not it’s a better approach from a security perspective.  Well sure, if you limit all executions of applications/code to a verified known list of good,  then you’ve got a pretty solid methodology to preventing malware.  The problem is that unless you are in a very tightly controlled environment, you’ve also got a terrific methodology for inhibiting your business and end user productivity.  It’s funny how ineffective employees are when they can’t download and install the tools they need.  Or, how constrained endpoint operations become when users can’t deploy patches or roll out new software without first updating their whitelist.

So how does whitelisting become adoptable and flexible for users, and what will its relationship with current anti-virus technologies become?  Most likely what we’ll see is a trust centric approach to endpoint protection which is a hybrid of these two approaches plus some new methodology.  We are going to start asking many different kinds of questions about the code that wants to run on our systems and we’ll have different tolerances for how much uncertainty we’re willing to live with.  What kinds of questions might we ask in the future?  Here are a few…

  • Is this known bad?
  • Is this known good?
  • Is this unwanted?
  • Do I trust the vendor?
  • What program introduced it?
  • What URL/UNC did it come from?
  • Should this user be able to install anything?
  • Am I licensed for this application?

Instead of asking ten different ways if something is bad (like we do today) we’ll also start questioning where the code came from, is there an explicit reason to trust it, what program introduced it, what vendor authored it, and so on.  This is a remarkably lightweight approach that doesn’t add huge databases of known bad and long scanning delays. At the end of this truly layered interrogation, we’ll have some very useful data points to make an informed decision about whether something should execute.  Depending on our appetite for risk, we’ll be able to set different policies that balance flexibility and security.  In very secure and static environments, a pure whitelist policy may be used – “do I have an explicit reason to trust what I see?”  In dynamic, mobile environments, we may just need to trust the vendor and ensure that we can’t identify that it’s a virus.  In the corporate network, maybe new code that can’t be identified on a whitelist must be introduced by our systems management tools.  The point is that this blended trust-centric approach can be flexible while also far more secure than our current approaches to endpoint protection. Organizations will be able to determine how strict their policies are and balance usability with security.  This “trusted change” approach to endpoint protection makes a lot of sense and is something I think we’ll start to see as a standard capability set in the future of integrated suites and platforms.