In last month's installment of Security Watch, I discussed the beginning steps of using a USB flash drive to attack a network. The attack started with an infected USB flash drive being plugged into a computer. The malicious code then executed, either automatically or with minimal help from the user (making use of some simple social

engineering). This attack remained local to the workstation, but it is clear that the malware could have spread to the rest of the network. I discuss this form of attack on a network in detail in my upcoming book, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), and I am adapting parts of that chapter for this column.

Obviously, one option for protection is to ban removable drives. While this may seem prudent, your users are likely to ambush you on the way to your car if you try to do this; and it can be hard to fault them for doing so. The better option, in all but the most sensitive environments, is to attempt to manage the risk involved and contain the exposure.

Furthermore, removable drives are by no means the only method of compromising a client computer. Remember the "10 Immutable Laws of Security" (available at microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Well, the general sentiment of Law 3 is still true: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." In the context of this discussion, if an attacker has access to your computer, that computer must be considered compromised. This can even be perpetrated remotely if the attacker can get you to run his code on your computer. You may recognize this as Law 1 of the Immutable Laws: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore."

It's safe to assume that the immutable laws still hold—they have proven to be remarkably resilient, and they are unlikely to change significantly until we fundamentally change the way computers work. Therefore, considering how these laws apply to the scenario outlined, it's critical that you defang removable drives. And you can do this with a few registry tweaks.

Of course, you must use additional layers of protection as well. You can reasonably assume that many of your client computers have either already been compromised or are operated by users who do not always have your organization's best security interests in mind. This means you need to mitigate their effects on the remainder of the network, and it increases the importance of understanding, analyzing, and mitigating security dependencies.

Definition of a Security Dependency

A security dependency occurs when the security of one computer is dependent on the security of another. You may have heard people say that if your domain controller (DC) has been hacked, your entire network has been hacked. This is a simplistic way to state that all domain members are dependent on the DCs for their security. If the DC is not kept secure, the member computers cannot be kept secure. If an attacker can change the security configuration of the domain, he can take over any computer in the domain by, for example, adding new accounts to the Administrators group on a member computer. Any vulnerability that permits compromise by an administrator just isn't interesting. An administrator is supposed to have complete access to whatever he is administering.

Dependencies in computer systems are unavoidable. In fact, they are common and often desirable; however, that doesn't mean all dependencies are acceptable. In this column, I discuss which types of dependencies are acceptable and which are not,
and then I will analyze the types of dependencies and how to mitigate them. In Windows Server 2008 Security Resource Kit, I go into more detail on the specific dependencies and discuss how to manage them.

Acceptable Dependencies

In general, a dependency is acceptable when a less sensitive system depends on a more sensitive system for security. Computers and systems in general can be divided into classes based on how sensitive they are. (The specific set of classes in any particular environment is irrelevant to the general discussion—all that matters is that there are inherent classifications.) Just for the sake of discussion, assume I have two classifications: workstations and DCs. In that scenario, it is acceptable for the workstations to depend on the DCs for their security. The DCs class is far more sensitive than the workstations so, obviously, it must be better protected.

The same argument can be made for user accounts. It is acceptable that an administrator can compromise data owned by a user. This is because administrators take on more responsibility and have unfettered (although not always direct or obvious) access to the computer and everything on it. If you understand this point and manage the computers appropriately, there is nothing wrong with this dependency.

Even software can be analyzed in the same way. It is certainly acceptable for a less sensitive piece of software, such as a Web browser, to use and depend on a more sensitive piece of software, such as the operating system, for its security. If the OS has a bug, the fact that the Web browser is now vulnerable to some new problem is not surprising and is probably low on the list of immediate concerns—the OS and other critical apps and data will be the primary focus of attention. This pertains to how bugs are fixed or where hotfixes go—a bug should be fixed as close as possible to the problem. In doing so, the protective impact of the fix is maximized. Thus, rather than working around the problem in the Web browser, the OS itself must be fixed.

Alternatively, the dependency can be removed by changing the design. For example, the Web browser can be rewritten to reduce its dependencies on the OS. This latter approach is appropriate in cases where the functionality of the more secure components (the OS, in this case) was never actually intended to be used in the way that the less sensitive component (the Web browser) is using it.

Unacceptable Dependencies

Given my explanation of acceptable dependencies, the definition of an unacceptable dependency should now be obvious. Basically, a more sensitive system must never depend on a less sensitive system for its security.

If the compromise of a workstation means that the DC's security has been breached, you have a serious security problem on your hands. It is impossible to protect a network if its aggregate security is dependent on the security of every single computer on that network.

Consider this statistically. If every computer on the network is "secure" 99.999 percent of the time, you might think you have an extremely secure network. In fact, that percentage is probably far beyond what is realistic in all but the smallest networks today. But now assume that your
network has 40,000 computers, any one of which is vulnerable .001 percent of the time. Anecdotally speaking, your overall network would be unsecure up to a potential of 40 percent of the time.

And, of course, with unmanaged dependencies it just takes one computer at that .001 percent of the time to compromise the entire network. In these terms, how secure is the network? Clearly, it is absolutely paramount that more sensitive systems are protected from less sensitive ones.

This argument can easily be extended to user accounts and software. For example, the new Terminal Services client for Windows® allows you to store user names and passwords for virtually transparent Terminal Services logon. Those credentials are stored using the Credential Manager API, protected by the credentials used for the primary logon session.

This can create a security dependency. Consider the case of a network administrator logging on to her personal workstation. She uses this workstation for e-mail, Web browsing, and other typical information worker tasks. Naturally, she uses a low-privileged domain account for this purpose.

At some point during the day, this administrator connects to one of the DCs to perform some management tasks. She uses the Terminal Services client to do this and chooses to store her password to make future connections easier. This results in at least one, and possibly two, unacceptable security dependencies. The first is that her domain administrative account credentials are now protected by her low-privileged information worker credentials. If this low-privileged user account is compromised, the domain administrative user account is also compromised and, therefore, the entire domain is compromised.

The second dependency results from the fact that she typed a domain administrative credential on a non-domain controller. Unless her personal workstation is protected at least as well as the DCs—and it probably is not—there is a dependency where the security of the DCs depend on the security of this user's personal workstation. If a disgruntled employee in the same office, for example, has installed a keystroke logger on the network administrator's workstation, the domain administrative credentials have now been captured. Any time you type a domain administrative credential on a non-domain controller you expose the entire domain to any security flaws on the non-domain controller.

Now suppose an attacker inserts a removable drive into a computer where a domain administrator is currently logged on, or has ever logged on, or will ever log on. That domain administrator becomes compromised, and, by extension, the entire domain is compromised. It is imperative that you understand this situation so you can avoid it. And, of course, the same situation can happen with software when a secure application relies on the functionality of a less secure application to perform a certain task.

Analysis of an Attack

Earlier I described what can happen if a malicious removable drive is inserted into a computer. However, it may only be obvious what would happen to the computer in which the drive is initially inserted. So assume that the computer in question is domain joined, as shown in Figure 1.

Figure 1 Ideal domain dependencies

The scenario illustrated here depicts an ideal dependency. The arrows are directional and point to where the dependency is inherited from. For instance, the security of the workstation depends on the security of the DC, and the security of the user is dependent on the security of the workstation. The attacker may be able to compromise the workstation, which would compromise any information the user has placed on that workstation, but the compromise would be isolated there.

But suppose the user logging on to the workstation is a member of the local administrators group on the server. And say the domain administrator frequently logs on to the server. Now you have the dependencies shown in Figure 2.

Figure 2 Compromised domain dependencies

By simply changing the assumption as to who has logged on to the computers in question, the security of the entire network has been compromised. Since a domain admin logs on to the server, the security of the DC and, hence, the entire domain is dependent upon the security of that server.

This would be acceptable if the server were managed as securely as the DC. However, in this case, a user who logs on to the workstation is a member of the Administrators group on the server. Thus, the security of the server is dependent on the security of the workstation. That means the security of the entire domain is dependent on the security of the workstation. And, guess what: the user on that workstation just unwittingly ran the attacker's tool.

There are probably few concepts in today's world of information security that are more important to grasp than security dependencies. If you start analyzing your network and try to understand what the dependencies are, you will almost certainly encounter unacceptable dependencies. In the worst-case scenario, which is far more common than you might think, the security of the entire network is dependent on the entire network—in other words, the security of every single computer is, in some way, dependent on the security of every other computer. It is therefore impossible to create any kind of reasonable and realistic risk management strategy in that type of environment since the relationships are impossible to control and the complexity is incomprehensible. The solution is to analyze and manage your dependencies.

In this column, I've presented only a short overview of dependencies and how you can analyze and mitigate them. You can find more information in my book, Windows Server 2008 Security Resource Kit. It contains an entire chapter devoted to the topic of securing the network by analyzing dependencies and managing them using both sophisticated techniques, such as Server and Domain Isolation, as well as more mundane techniques, such as administrative account management.

I would like to thank David LeBlanc for helping shape the embryonic ideas that led to this column.

Jesper M. Johansson is a Software Architect working on software security issues and is a contributing editor to TechNet Magazine. He holds a PhD in MIS and has more than 20 years of experience in security.