Sunday, March 21, 2010

Botnet Prevention with DLP Technologies

Last week I was asked a couple of times how good Data Leakage Prevention (DLP) products are at protecting against botnets. Before I get started describing the pro's and con's of DLP in combating professional botnet operations, there are a few things I probably need to make clear - as it'll help add some perspective to the angle I'm coming from.

As you probably already know, I spent a fair amount of time developing and improving Intrusion Prevention System (IPS) technologies in my tenure with ISS (and then later, under IBM). During that time there were a number of market dynamics that required me to spend quite a bit of time reviewing, analyzing and evaluating the various DLP technologies - both at the host and then network levels. In general though, I was not impressed with the technology - and still aren't. From my perspective, DLP is a bit of a white elephant and is probably going to go down in the annuls of Security History in the chapter next to NAC. Don't get me wrong, as a concept DLP has its place, but in practice it fails to provide any compelling features that aren't (or can't be) delivered using other more common (and existing) enterprise security technologies.

Now, being a networking kind of guy, the thing I find most interesting about network-based DLP is the show and dance the various DLP vendors make about Deep Packet Inspection (DPI) - you'd almost think that they invented the technology and that it only to DLP. Lets get this straight from the beginning - DPI existed within IPS (and IDS) for 5+ years before even the first DLP companies became incorporated and, whats more, products like ISS' Proventia fully parse many hundreds of networking and content-level protocols - many times more than even the most mature dedicated DLP product out there.

So, if you're thinking DLP is a new and vital technology to roll out in your enterprise (particularly at the network layer), my advice would be to look to a top-tier IPS appliance instead because you'll find better protocol and content inspection coverage, and higher capabilities in inspecting traffic for critical data leakage. One day I'd love to see a head-to-head appliance review of the various vendors products detecting and defending against all the most common data leakage techniques/tactics.

DLP and Botnets
So, how useful is DLP in combating botnets? First of all, we obviously need some degree of clarification about "combating botnets". Lets break this down in to three separate botnet attack phases:
  1. Preventing hosts from becoming botnet victims,
  2. Detecting and stopping the leakage of confidential corporate information,
  3. Cleanup and remediation of bot infected victims.
Preventing hosts from becoming botnet victims
In order to understand DLP capabilities in preventing hosts from becoming botnet victims (from a network perspective), we need to bear in mind the limitations of DPI and the most common mechanisms hosts succumb to being compromised and joining a botnet.
  • Criminals leverage a broad spectrum of attack vectors in order to compromise their target - with the most common being spam/phishing emails that convince the user to infecting themselves, malicious drive-by-download sites the exploit vulnerabilities in the Web browser and removable media worming (e.g. USB devices). Unless the DLP solution is configured to watch inbound network traffic and scrutinize URL's (perhaps using a URL blacklist for checking against), the probability of detecting the malicious payloads is remote - and anti-spam and perimeter Web gateway technologies would be a much more effective solution here. IPS technologies would also excel in dealing with the exploits being used to compromise the Web browser vulnerabilities.
  • Inspection of the HTTP/FTP/etc. downloads or email attachments is of course possible - but it will be a struggle to to identify the malicious intent of the binary files, but should best be dealt with using anti-virus technologies - particularly products with good behavioral analysis engines and, in a pinch, virtual/sandbox dynamic-analysis of malware.
I think you would be hard pressed to use DLP technologies as an effective tool for preventing hosts from becoming botnet victims.

Detecting and stopping the leakage of confidential corporate information
Detecting the information leakage from bot infected hosts should be an easy task - after all, that's supposed to be DLP's bread and butter. Unfortunately it's not quite as easy as it sounds.
  • The signatures (or "fingerprints") DLP devices use are generally tuned to specific forms of structured data. For example, SSN's, credit card details and address details have a specific structure. As such, DLP solutions are generally good at spotting this kind data being transmitted across a network and leaking from the enterprise (just as IPS's can too). As such, DLP appliances can easily detect the "clear text" transport of these kinds of data.
  • Unfortunately, botnet operators tend not to transport/extract confidential data past perimeter inspection/detection technologies in "clear text". Obviously, if the bot agent chooses to transport the data to a remote server over HTTPS, then all the traffic will be encrypted. But botnet operators don't even need to do that...
  • Purchasing, managing and configuring Web server certificates for HTTPS can be tedious and can often result in "invalid certificate" alerts - which would in turn alert the user of any folks inspecting the system logs. As such, many botnet operators have decided to not use HTTPS - instead they extract their stolen data over un-encrypted HTTP, but they compress and encrypt the data they're stealing from on the victims machine before sending. I.e. the transport is unencrypted, by the file being transferred is itself encrypted and cannot be inspected by DLP (or any other DPI technology).
  • Armed with a blacklist of known botnet Command and Control (CnC) channels or file drop-boxes, the DLP solution could keep watch over who the victim system is communicating with and block those - but there are already plenty of IP/Domain/URL blocking technologies already out there that are more efficient.
  • It's important to understand that many professional botnet operators have moved away from stealing classic datasets (e.g. credit card details, SSN's, etc.), and towards more valuable datasets (e.g. software source code, CFO banking credentials, prototype designs) - which happen to be considerably more difficult to detect with DLP technologies (especially if the data is encrypted of course).
  • DLP is limited to specific protocols and specific file/attachment types for inspection. To evade detection, the criminal botnet operator just needs to use an "unsupported" protocol/format.
Cleanup and remediation of bot infected victims
Well, I can't think of anything that DLP offers in this realm.

Clobbering Botnets with DLP
In general, DLP makes for a very poor anti-botnet technology. DLP is adequate enough detecting the simple stuff - e.g. a user sending an email with 10,000 credit card details - but is ill positioned to detect an automated bot agent obfuscating or encrypting a compressed file of corporate secrets.

In fact, as far as I'm concerned, I can't really see a reason for it existing as a separate security technology anyway. Existing IPS technologies and signatures include just about all of the data leakage detection features already.

That all said, DLP is probably adequate enough for detecting stupid user mistakes, but useless for combating professional criminals - whether they're botnet operators or insider threats.


  1. Hi Gunter! You has mentioned that NAC goes down in history.
    Why NAC technologies are not used widely in corporate networks and notebooks?

  2. NAC is a great technology if used and implemented by the right IT guys. I'm working for a Symantec partner in the Middle East, and had one SNAC (Symantec NAC) project for one of the banks here. It was a tough experience when it comes to make different products/technologies to the sing the same song, 802.1x Protocol. NAC in a corporate environment will touch multiple products, which have to be configured to rely on each other.

    1. Endpoints:


    - Legacy OS: Some vendors don't provide 802.1x supplicant for Windows 98, maybe open-source is another option but is not supported by your NAC vendor.

    Solution: Install Windows 98 on XP host, in Virtual PC.

    2. Switches: Different models running various firmware versions was a big problem since not all 802.1x commands were supported.

    Solution: Upgrade firmware ahead of time before NAC implementation, and use some tool to verify the running on all switches from one console. This will save you hours of troubleshooting and support calls.

    3. Printers: If you are lucky, your NAC vendor may support legacy devices exclusion.

    Solution: NAC solutions exclude printers, phones by MAC address.

    4. Phones: Same as printers, but latest IP Phones models support 802.1x authentication (username/password + Radius).

    Solution: Either enable 802.1x (upgrade firmware if outdated) if available, or bypass NAC.

    5. Knowledge: Lack of 802.1x knowledge will make network/security/IT teams a bit harder. So train your IT users on how to configure/analyse/troubleshoot 802.1x related issues.

    6. Vendor support (Switch + NAC): we've been able to solve complex issues when we consult both vendors. Don't rely on one only, NAC is not an independent technology.

    7. Software: Always be up-to-date, bugs can waste hours on the phone or remote WebEx sessions. NAC/Switch/802.1x supplicant firmware versions MUST be upgraded to evade unstable, strange, known issues.

    That all what I can recall for now

    a.qarta [@]