Intrusion Prevention System To Detect BotNet

The second half of the year 2010 saw stuxnet all over the news. Stuxnet, a cyber worm, is believed to be the world’s first publicly identified known cyber weapon. Such worms are designed to destroy the control system in a factory, refinery or even a nuclear power plant.

Computers are infected with such worm through websites, USB sticks or other external media drives connected to it. The worm causes no harm to its host and uses the host computer as a launch pad to attack a primary target. A botnet is created when the same worm infects multiple computers on a network. The primary target and the time of attack are set by a command center from where the botnet is controlled.

Since the worm behaves like any other legitimate software (uses stolen certificate) installed on the computer, antivirus software would have hard time identifying them. The worm has the tendency to change its characteristics to fit the environment of the host. Once it gets into a computer, it tends to go into a sleeping mode waiting for commands from the control center. However, the moment command is received from the command center; it wakes up and starts attacking a specific target. By the time an antivirus or a firewall picks up that behavior, it’s already late – the damage is already done at the target from a host system. If your computers are part of the host system of botnets, then you are liable for the damages.

So what do you do to prevent your computers being part of such attack? Of course you need to have antivirus and appropriate access control systems in place. However, what you really need is an intrusion prevention system that detects and cuts away any suspicious communications on your network.

The following functional requirements need to be considered when evaluating an intrusion prevention system to detect BotNet

1. Real time detection of zero-hour, targeted attacks – Solution should be able to detect near real time attacks based on behaviour on the network
2. Real-time termination of threats – Solution should be able to terminate data theft transmissions in real time
3. Botnet Outbound callback blocking (CnC) – Solution should be to block any callback to botnet command center.
4. Multi-protocol protection – Solution should be able to detect threats at different network and protocol layers.
5. Collective Intelligence Sharing – Solution should be able to leverage intelligence gained from peer deployments at other organization.
6. Works Without Virus Signature – Solution should be able to learn the behavior on the network (heuristic) and detect threats without relying on virus signatures.
7. Out-of-band deployment – Solution should be able to be deployed out-of-band from the network so that it does not pose as a bottleneck to network traffic.
8. Detection of botnets by endpoint scanning – Solution should be able to scan endpoint for any presence of malware that could potentially participate in botnet activities.
9. Management – Security Dashboard – Solution should be able to provide comprehensive view of activities on the network.
10. Management – Event Reporting and Correlation – Solution should be able to capture and maintain audit trails of all network activities which could potentially be fed into an SIEM solution.
11. Management – Centralized Configuration – Solution should provide interface for easy configuration deployment and to update them whenever necessary.
12. Management – Replay of CnC sessions – Solution should be able to replay Command and Control (CnC) session from captured audit trails.

FireEye and Damballa are two products that are competing in this space helping corporations prevent botnet attacks. At the recent RSA Security Conference 2011 at San Francisco, I was able to compare these two vendors.