427 Botnet fm qxd

www.syngress.com
428
Chapter 12 • Responding to Botnets
427_Botnet_12.qxd 1/9/07 3:08 PM Page 428

---

enterprise security if they would collect the intel in these files and report
them to the information security organization. Gathering and analyzing the
security event, firewall, and anti-virus logs told us who was attacking the
infected client before it joined the botnet and where the payload might be
hidden.The firewall log also told us which computers connected directly to
this workstation. In most organizations, it is rare for workstations to connect
to one another—workstation to server, yes, but workstation to workstation
not very often. Note that none of this intelligence is possible unless opera-
tions permit you to collect this small set of forensic data before scanning or
re-imaging.
One could probably stop here and argue as to whether the cup is half full
or half empty. Half full because any security professional can come up with
techniques for fixing the aforementioned problems (turn on updates, use
better authentication techniques, check the crufty PHP software with web-
checkers (check out nikto, which is open source at
www.cirt.net/code/nikto.shtml). From the half-empty point of view, we can
despair of ordinary users. Can we ever educate them? That is a very good
question. Perhaps the vendors could help, and instead of pitting security
versus usability, help make security more useable.The bottom line, though, for
botnets is that a lot of the exploits are used over and over again. If you saw an
attack against X yesterday and it worked, why should they bother to develop
a new attack? We may have hard engineering problems, but we feel that secu-
rity engineering in terms of process and policy are a key answer to the
problem. We strongly suspect that simple policy measures can pay off.