Keep Up with Vendor PatchesReligiously

Anybody who has worked in software development knows that accidents happen. When
a bug is discovered in a Microsoft product, however, the rush to gain fame and popularity
typically results in a published exploit within mere hours. This means you have a
continually shrinking window of time to apply patches from Microsoft before someone
comes knocking on your door trying to exploit the hole. As you will see from the severity
of some of these issues described in this book, the price of not keeping up with patches
is complete and utter remote system compromise.

Authorize All Access Using Least Privilege

This concept is the one most infrequently grasped by our consulting clientele, but its the
one that we exploit to the greatest effect on their networks. Authorization (which occurs
after authentication, or login) is the last major mechanism that protects sensitive resources
from access by underprivileged users. Guessing a weak password is bad enough, but
things get a lot worse when we discover that the lowly user account we just compromised
can mount a share containing sensitive corporate financial data. Yes, it requires a lot of
elbow grease to inventory all the resources in your IT environment and assign appropriate
access control, but if you dont do it, you will only be as strong as your weakest
authentication linkback to that one user with the lame password.
The modern (post16 bit) Windows authorization architecture isnt your best friend
in this department. It is primarily centered around access control lists (ACLs) applied
across millions of individual objects within the operating system (from files, to Registry
keys, to programmatic structures such as named pipes), the net intersection of which is
poorly understood even by Microsoft itself (or so it seems sometimes). We will discuss
relevant tactical ACL settings throughout this book, but we forewarn you that creating a
comprehensive, heterogeneous, distributed authorization policy using Windows today
can be daunting. Keep it simple in design, and stick to time-honored principles (such as
role-based access control, or RBAC).

Limit Trust
No system is an island, especially with Windows. One of the most effective attacks w
use against Windows networks is the exploitation of an unimportant domain membe
computer with a weak local administrator password. Then, by using techniques discussed
in Chapter 6, we extract the credentials for a valid domain user from this computer
which allows us to gain a foothold on the entire domain infrastructure and possibly
domains that trust the current one. Recognize that every trust relationship you set up
whether it be a formal Windows domain trust or simply a password stored in a batch fil
on a remote computer, expands the security periphery and increases your risks.
A corollary of this rule is that password reuse should be explicitly banned. We can
count the number of times weve knocked over a single Windows system, cracked
passwords for a handful of accounts, and discovered that these credentials enabled us to
access just about every other system on the network (phone system switches, UNIX
database servers, mainframe terminals, web applicationsyou name it).

Be Particularly Paranoid with External Interfaces
The total number of potential vulnerabilities on a network can seem staggering, but you
must learn to focus on those that present the most risk. These are often related to systems
that face public networks, such as web servers and so on. Front-facing systems (as well call
them) should be held to a higher standard of accountability than internal systems, because
the risks that they face are greater. Remember that the public-switched telephone network
is a front-facing interface as well.

Practice Defense in Depth

Overall security should not be reliant upon a single defense mechanism. If an outer
security perimeter is penetrated, underlying layers should be available to resist the
attack. The corollary to this principle is compartmentalizationif one compartment is
compromised, it should be equally difficult for an intruder to obtain access to each
subsequent compartment.

Fail Secure
When a systems confidentiality, integrity, availability, or accountability is compromised,
the system should fail to a secure state (that is, it should become nonfunctional).

Practice Defense Through Simplicity

A simple system is more easily secured than a complex system, as simplicity means a
reduced chance for errors or flaws. A corollary of this principle is the concept of dedicated
function or modularity: systems or components of systems should be single-purposed
to avoid potential conflicts or redundancies that could result in security exposures.
Be prepared to defend this principle against the potential costs of maintaining single-
purposed systems. (One classic argument weve had over the years is whether its wise
to install Windows IIS and SQL Server on the same machine; well leave the resolution of
this discussion as an exercise for the reader.)