Blacklists, Whitelists and Secure Computing

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!

Recently I responded to a thought out blog entry at British Telecom’s Secure Thinking ‘blog.   BT bought both INS (consulting) and CounterPane (Bruce Schneier’s MSSP company) to create a strong presence in the US.  They employ, along with my friends Ben Rothke and Jim Tiller, some of the best minds in the information security industry today.

In that blog entry, they discussed something they call CMAL, which is a nice tool.  They are creating sort of a Blacklist that keeps customers’ informed of malicious actions, or, as they state, Correlated Malware Detection (CMAL) module provides our customers with a global security perspective on every session that is logged by any monitored firewall.

There is no need for me to further extol the virtues of Bruce.  While we don’t always agree, he is amongst the brightest lights in information security today, world wide.   Bruce can see things coming "around the bend" ahead of their time.  

This was a well thought out article, and I see the value of CMAL.  And knowledge-sharing between the infosec community, be it regarding 201 CMR 17 or, as the case is in this article, Malware blacklists, is a boon and benefit to would-be effected users.

That said, we need something even better.   At the very least, we need a coordinated approach between all (not just major) players to create a blacklist-like database that deployed IPS’ can query and cache in real time.  We need a mesh approach to such sharing, and we need a US-CERT like ability to cross industries and geographical boundaries. 

Even better?  It is time for the entire infosec community to stop using blacklists and start using either whitelists or… more robust technologies (such as an inherently secure computing base).   Blacklists no longer work.

 

What do you think?

 

Permalink

5 thoughts on “Blacklists, Whitelists and Secure Computing

  1. Echos of Marcus Ranum’s “Don’t enumerate badness” advice in his list of “The Six Dumbest Ideas in Computer Security” (http://www.ranum.com/security/computer_security/editorials/dumb/) His well pointed out that the “badness” has outpaced the “goodness” on the systems and networks. Blacklists cannot keep up (but the updates can be quite profitable for the vendors).

    Whitelists are quite helpful but many people, including security product vendors, still avoid them. One reason, besides the BL revenue stream, is the potential for things to “break” because a legitimate site, person, or process wasn’t on the WL. Tuning a WL can be a challenge especially for multi-use consumer systems. For servers and other business systems where their functions are better defined, WL should be easier to set up.

  2. Blacklist approaches have been failing for years — polymorphic and self-encrypting code, as well as code delivered in parts, means that blacklists stop only a portion of what is getting thru and can never hope to get it all. Add in VPNs and other encrypted tunnels (SSL) and even things blacklists might catch will not be stopped.

    Whitelisting controls aren’t a perfect answer, but go a long ways towards fixing the problem. Only running something that is known to be allowed is the right thing for most enterprises. It’s one reason why I came up with the design behind SignaCert’s offerings, which are being widely adopted.

  3. Ariel,

    I appreciate you reading my CMAL post and writing about it on your own blog as well. This is an interesting topic and I concur with your conclusion on the need for a coordinated approach. On that score, I am participating in the OISF effort, specifically the “IP Confidence” working group that is debating the Whitelist v. Blacklist vs. Scoring vs. Applications.

    Regards,
    Rob Jamison

Leave a Reply

Your email address will not be published. Required fields are marked *


*