Sunday, February 15, 2015

Blacklisting and Whitelisting

Whitelisting and blacklisting are two extremely common methods security folks use in attempt to identify threats. If they whitelist x, they are claiming that x is not dangerous and can be ignored - probably even if x exhibits malicious behavior. If they blacklist y, they are claiming that y is dangerous and special attention needs to be paid to it. There are inherent flaws in both approaches. That does not mean the method is broken; however, it simply means that as usual it must not be the single point of failure.

Blacklisting
Let us take the example of domain names (for example, www.phrack.org). If we blacklist this domain, it means that we think it is bad, and we could do something such as deny access to this domain or send a warning to your system administrator / security analyst. Phrack is a simple example, as we might think "I do not want someone to browse hacking related websites" or "I want to know who is interested in hacking so I can keep an eye out for that person". But this goes beyond hacking related websites. For example, we would also be interested in blocking and knowing attempts to connect to botnet command and control servers.

And therein lies the start of the problem. One of the buzzwords the security community tends to use as of late is threat intelligence/information, and the sharing of it. Look at the example of Facebook, which recently set up such an threat intelligence sharing platform. At its most basic, what this means is something like this: Twitter starts getting attacked by the Syrian Electronic Army (SEA), says their sea.sy domain is bad because it was used to attack them. And so since everyone trusts Twitter, they block sea.sy too. That is a good thing.. somewhat. But what happens when the attacker starts to use new domains? What happens if they hack a legitimate website to attack others? Nothing. As in, nothing is detected.

In sumamry, blacklisting is very effective against known threats but worthless against new ones. Another inherent flaw about blacklisting is size. A security program which is trying to fight fast flux, domain name generators, or polymorphic viruses simply cannot win over the long term. The blacklist would get bloated and still be useless against new threats. Proof? Symantec, one of the largest antivirus (which works based on blacklisting) players in the market, states that "Antivirus is dead". Blacklisting is a nice addition to have but a very bad thing to be reliant on.

Whitelisting
Since blacklisting identifies what is bad, whitelisting identifies what is good. When you set up your new database, for example, you may wish to allow connections to it only from your application server. That is great for security. But the problem with whitelisting is that you need much more than one item in your list. Suppose you want a whitelist which contains all executables which should be allowed to run on your computers. This is a huge task that only a security vendor would be willing to create. Even then, what happens when new legitimate applications get created? What happens when illegitimate applications get signed with legitimate code? Obviously, there are inherent problems with whitelisting too.

My thoughts
Let us get to the reason why I started this blog post. As I mentioned earlier, using blacklists is a horrible thing to rely on alone. But it does what it claims very effectively: if it is on the blacklist, it most likely is a threat. It should be blocked. A security vendor is not going to purposely put a good guy on the blacklist. A good guy is not going to pretend to be some guy on the blacklist. Someone who was on the blacklist but should not be there will eventually be removed from it (and if that person got on for whatever reason, that person should stay there for a while).

Whitelists, on the other hand, can get pretty dangerous. This is because of what it is meant to do: a blacklist says something like "tell me if there is a threat", but a whitelist says something like "do not show me anything if there is no threat". If there are no other indicators of compromise, something malicious which has been whitelisted somehow can wreak havoc in an organization undetected for a long time. Recently, I happened to be reviewing the logic behind some code in a security application which basically said "do not show me anything related to this if it is regarding communication from x". That works if you know x is something you can trust for a long time - which it was. However, the problem was that as I dove further into the logic, I realized that the application derived it was communicating with x through something an attacker could control. This means that if an attacker knew how the application was working, the attacker could hide entire communication streams from the defender. Very, very bad. Obviously, I am going to fix it.

No comments:

Post a Comment