427 Botnet fm qxd

party applications. It is not reasonable to expect them to have absolute control
over the quality of those third-party applications.The bad news here is that
the odds of your host system having been tested for security bugs in any
meaningful way is darned near zero. IT workers have the daunting task of
taking miscellaneous hardware, an operating system, random drivers, a dif-
ferent set of applications per host, and the pile of patches needed to keep
those systems “up to date” and somehow make it all work with other systems
over the network. Put another way, the combinatorics of testing of any sort is
a very difficult problem. Couple the complexity of software with the fact that
the hacker needs one bug that works and the “anti-hacker” needs to know all
the possible bugs.This is a very tough nut, indeed.
www.syngress.com
Responding to Botnets • Chapter 12
425
427_Botnet_12.qxd 1/9/07 3:08 PM Page 425

---

In the botnet world, we seem to have some tough problems, too. One of
them is the ever-increasing amount of spam we discussed in the previous sec-
tion on the phishing phenomenon. Another is that we lack effective means of
dealing with large-scale DoS attacks.These are both hard problems.
Lack of Effective Security Policies or Process
To be owned, each botnet client has to have at least one security issue. In
some cases, the issue is technical, but in many, many cases, the fundamental
local enterprise security policies or the lack thereof may be the problem.To
quote from our hero, Bruce Schneier, security wizard: “security is a process,
not a product” (www.schneier.com/crypto-gram-0005.html). In other words,
a new shiny firewall won’t solve the problem unless it somehow is part of a
process of incremental improvement with some brainpower and policy
thinking behind it. IT process and wise implementation is fundamental.To
illustrate this problem, let’s tell a little story before we go on.
One fundamental problem with PCs is that most software applications can
require local admin to install software. Many companies and institutions grant
users local administrator access, either by putting their domain account in the
local administrators group on the workstation or by creating a local account
and putting the account in the local (workstation) administrator group for
them.This account is different from the institution’s local administrator
account. Giving the user’s Domain account local admin privileges means that
every time the user goes to a site that downloads and executes malicious
code, it will execute with local administrator privileges.This is not good.
Giving the user a separate local account with local administrator privileges is
better from this perspective, but then you have to ensure that the account is
properly protected and the users understand that they are to use this account
only when they have to have (not want) admin rights. Many IT organizations
split the Windows administration tasks between two groups. One team
administers the group policy and enterprise level aspects.The other team
maintains the local policy and workstation level aspects. Windows does not by
default carry over the domain security policy regarding password complexity,
strength, and expiration into the local policy unless you explicitly tell it to do
so. In addition, the limitation on the number of guesses you can make when
trying to log in to a local account across the network does not match the
limits placed on the domain accounts. For local accounts, the default for