Whitelisting is Dead, Long Live Whitelisting!

I believe in application control, often called application whitelisting. A lot of FUD (fear, uncertainty, and doubt) gets spread about today’s cyber threats. Bad actors continue to break in through not-so-advanced and not-very-persistent threats (as opposed to APTs). The entire situation often gets spun horribly, with whitelisting companies claiming a panacea and non-whitelisting security companies asserting it’s too expensive. Nevertheless, I still believe that application whitelisting will take over as the defacto way to secure our digital endpoints, and NIST agrees.

Then why on Monday did Carbon Black, a visibility company, swallow up Bit9, the premiere whitelisting company? While the complete answer has many facets, I think a lot of it has to do with the oncoming death of the whitelisting application business model. OS vendors have already embraced and extended whitelisting in a number of ways, and will continue to do so. Right now their solutions may only come out half-baked, but go ask Netscape or Zone Alarm about the feasibility of competing with products baked into an operating system. Eventually, OS-based whitelisting will rule them all, but what do we do until we get there?

There are definitely many good reasons to NOT roll your own whitelisting solution. Although the typical “build vs. buy” issues arise, I’ll go over a few specific reasons you may want to still purchase a whitelisting solution:

  1. Lack of expertise. Setting up a whitelisting solution still requires domain-specific knowledge. Rolling your own requires knowing many different tools across many different platforms.
  2. Desire for support. Experienced IT workers know that installing software actually makes up only a small fraction of total cost. Issues will arise, and somebody will have to service the issues.
  3. Ease of use/maintainability. Your environment will change. Computers will get upgraded, new software will come out, security postures will change. A home-grown solution might not have the capabilities to handle all that.
  4. Experience of others. Although you will use available parts in your homegrown solution, you will eventually arrive at a unique conglomeration. That places you in a user group of one.
  5. Specific features. Certain integrations and capabilities require more effort and care to implement correctly. Purchasing a solution may be the right answer if your deployment requires one complex or many smaller additional features.
  6. Integrated solutions. We all have limited time and limited space, so there’s something to be said for having a single pane of glass to look at for all your security information. Some solutions do not surface the desired information through APIs, making it difficult to consolidate.

Having given all those reasons to purchase a solution, let’s go over the reasons to roll your own:

  1. Avoid mash-up of 3rd party OS hacks. Application control requires hooking into the operating system at a low-level, typically the file system and/or system calls. Here there be dragons.
  2. Initial cost. I do not have the data to compute the long-term cost of maintaining a solution, so I do not know how it compares between the two options (although I suspect it’s comparable, even factoring in opportunity costs). I can say that the initial out of pocket cost of purchasing will be higher.
  3. Different attack surface area. If we consider malware as parasites on our technology assets, then homogeneity facilitates their spread from host to host. While purchasing a single solution for all platforms may look good on paper, it means just one exploit on any of the platforms leads to total compromise.
  4. Control backdoor access. All software has bugs, so most prevention vendors realize that their software will have a negative reaction to other software on a system, no matter how extensive and thorough their testing. They need a way to fix these systems, which means they need a back-door. You may build in a backdoor for yourself, but then at least you know who holds the keys.
  5. Get ahead of the curve. Application control will eventually be baked in and on by default in every operating system. It’s going to happen. It needs to happen. Why muck around with a temporary solution for a few years before going with the integrated OS solution that will be pervasive eventually?
  6. In-house understanding. At the end of the day, whom do you trust with the power of application control? IT might administer the purchased tool, but only the code’s authors can know what they originally wrote it to do.

I definitely forgot a few reasons on both sides of the argument. Let’s say you add those in, tally up the pros and cons, and pick a path forward. Assuming you decide on not purchasing a solution and instead plan on using free alternatives, what does that entail? Let’s start by looking at endpoint solutions for the major server and workstation operating systems:

  • Where Microsoft has Applocker, Apple provides Gatekeeper. Unfortunately, Apple’s finds itself a little behind the game due to lack of transparency, historically smaller deploy base, and indecisiveness about targeting the enterprise. A lot of their technology revolves around code signing and controlled distribution, and that has some limitations. They will continue to plug known vulnerabilities until they get it right, but in the meantime we have some guides for managing Gatekeeper from the command line.
  • I should mention the mobile OSes: iOS and Android. BYOD continues to happen, so any security strategy has to take it seriously. Luckily, Android skins Linux and has gradually adopted more and more uses of the Linux Security Module framework (Kernel API for SELinux). Apple provides its own whitelisting in the form of its App Store, but they control the whitelist. I suspect that Android’s utilization of SELinux will increase while Apple will eventually open up whitelisting apps to IT administrators.

Having application management on the endpoints in your organization does not satisfy our success criteria. Maintaining each endpoint independently becomes infeasible for large organizations, so tools need to automate adjusting whitelists and reporting verbosity. Commercial applications tend to shine better than homegrown solutions in this area, though not always. Depending on your operational aptitudes and needs, we may be able to get “good enough” without having our integration needs swing us into the eager arms of a whitelisting vendor. I divide the options into four categories:

  1. Open sourced integrations. At first glance, this category seems the most attractive. For example, Netflix gave the world FIDO and that looks pretty cool. The drawback of using another company’s solution mostly gets the worst of both worlds: less support and less control. If the boot fits, go ahead and wear it. If it does not fit, don’t force it.
  2. Logging systems. Many underestimate the difficulty of collecting logs intelligently. If your organization does not already pay for Splunk or Papertrail, then try the open source version: Logstash.
  3. Automation tools. Pick your favorite and leverage it. I do not want to get into the whole Puppet vs. Chef vs. Ansible argument. Or whatever else is out there. You could even lash things together with python scripts and cron jobs, although I would recommend against that particular approach.
  4. Infovis. While a huge body of active research exists in this topic for a variety of disciplines, you do not need to go all crazy here. I suggest starting with Graphite or Librato, or whatever tool you already know. Then iterate.

So pick the one(s) that work for you. If somebody else did all the work for you then grab their open source solution, otherwise piece together the other options with DevOps!

Congratulations on improving your security posture with application control. Combined with a next-generation monitoring solution such as Threat Stack, you can see what you’ve been missing and make sure it does not happen again. Think of it like locks on the doors and cameras on the premises. You probably want both.