Mitigating Service and Administrative Dependencies

Mitigating Service and Administrative Dependencies

At this point, the obvious question you should be asking is how to mitigate these dependencies. (A few of you may be asking yourself which other careers you should be looking into since network security seems like such a losing proposition at this point, but don't despair.) The answer is, frankly, quite simple: micromanage service and administrative accounts. How you actually implement that suggestion is an entirely different question, however. Think about it this way, the least secure solution is to run everything as an administrator, and then use that same administrator account everywhere. In Figure 8-1, this is the rightmost side of the spectrum. The most secure solution is to use one account for each system, once. That is the leftmost side of the spectrum in Figure 8-1.

Figure 8-1. The security dependency spectrum.

Clearly, the most secure option is completely infeasible, and the most insecure option is how we got into the dependency problem in the first place. The right answer is somewhere in the middle. Where, exactly, depends on your environment, your risk tolerance, the resources you are trying to protect, and, frankly, your personal interest and skills. The objective, however, is to minimize the exposure of accounts, and we shall look at how to do that for both administrative and service accounts.

Protecting Administrative Accounts

NOTE: You minimize service and administrative dependencies by minimizing the exposure of accounts to systems.

The first thing to do to achieve the objective is start segmenting the systems. We discuss this at length in Chapter 9. For now, you need to keep in mind that systems have different sensitivities. You need to define segments of systems with similar sensitivities. After you do that, you can define a set of accounts for each segment, and then keep the exposure of that account to the segment. For instance, as a domain administrator, you may have a domain administrative account for use on domain controllers, you may have another account that is an administrator on all the workstations, yet another one that is an administrator on a Web server, one for the database server, and, finally, one account that you use for everyday productivity applications. Ideally, you should never use these accounts on the same systems, but that would require you to have four different computers for your everyday work. Unless you have an unlimited budget, that probably will never work. You have to judge according to what you are trying to protect what will work here. Only you can do that. Just be aware of the potential exposures you are opening yourself up to. If you took the Certified Information Systems Security Professional (CISSP) exam, you would have encountered the Bell-LaPadula model of information security. It taught us that we can write up and read down. The same thing applies here. If you have a system in which you expose a domain administrative accounteither through a service or by logging on with oneit is just as sensitive as a domain controller, even if most of the time you are logged on as a regular user . Keep that in mind before you double-click that next e-mail attachment.

NOTE: Domain administrative accounts are for logging on to domain controllers and other systems that are as sensitive and as well protected as domain controllers. They must never be used on any other system.

The general idea behind managing administrative dependencies is simple enough, but how do you actually operationalize it? The first thing to do is to develop an effective way to manage your passwords. First, you need to get over your aversion to writing down passwords.

NOTE: There is nothing wrong with writing down passwords, as long as you adequately protect the written copies!

Recording your passwords is critical due to the fallibility of the human memory. Recording your passwords allows you to remember more and better passwords. In spite of that we far too often hear that you should never write down a password. That is patently wrong. It is wrong because if you cannot write them down, you are forced into either using the same password everywhere, or using only one account (both of which have the same effect). Let's be realistic, you will never be able to remember all the passwords if you use complex passwords, so how do you protect them? One way is to only write them in electronic form, and then encrypt the document. For instance, you could fairly easily write a small program that calls the Data Protection APIs and encrypts passwords using your accounts master key. That is, in fact, what many of the better password managers do. If you go to the Windows Catalog (available on the Microsoft Web site), you will find at least one password manager tool that has received Windows logo certification. Using a tool that records passwords is one way to manage them, but it still involves software security, which is really just smoke and mirrors. A more secure way is probably to write the passwords in a document that is stored on a USB token, which is then kept jealously guarded . This option is handy for passwords that several people need access to. Although you should never share accounts with other people in large networks, it is an option that works for accounts you share with your significant other at home. You could also write passwords on a piece of paper and then properly safeguard the piece of paper, for instance, in a safe. Whatever seems to provide adequate protection for you works well.

A couple of other technologies can help you here, too. If you have a Public Key Infrastructure (PKI), you can leverage smart card logon. You could issue a different smart card for each account and then use one or a few pass phrases to access the keys on the smart cards. Using smart cards also makes it increasingly unlikely that the user identity and associated secret can be logged, such as an attacker might be able to do with passwords. Contrary to a password, the secret in a smart card, the private key, never leaves the card. The actual digital signature used for verification is normally performed on the card itself, so the key is never exposed. Therefore, it is very hard to steal credentials from a smart card by using software. That does not, of course, mean that someone that gets you to run their code cannot take actions on your behalf . It only means they cannot get your private key so they cannot authenticate as you later, but that is really irrelevant if you run their evil code.

Another option is to use RSA SecureID tokens. Again, they are combined with a password; if you have one token per account, however, you are approaching the left side of the spectrum in Figure 8-1, where you have only one administrative account for each system, and you only use it once. It is only the password (more correctly, the random value on the token) that is used only once, but it is at least a start.

Of special note is the built-in Administrator account, the one with relative identifier (RID) 500. Many environments use a standard build that sets the password to the same value on all systems. Usually, someone thought up that password sometime in 1997, and it is still used. Such practices are entirely inappropriate. The security of that environment is equivalent to that of the least-secure system in the environment. There are several better options for handling this situation.

One option (although a bit drastic one) is to disable the Administrator account. We know what you are thinking, but there really is some logic behind this. What is it used for? (If "reading e-mail" is your answer, go back and read the first section of the chapter again.) The answer is that it is basically a disaster recovery account. If the problem is so severe that our domain account cannot be used to solve it, we will probably save both time and money by rebuilding the system instead of trying to resolve the problem. Therefore, in many situations, the local Administrator account should never even be used. Of course, there is one problem: the Administrator account cannot normally be completely disabled. That is correct, but we can do the next best thing by setting an impossible password and then forgetting what it was. On the CD, you will find a tool that can helppassgen.exe. Passgen can set a fully random, arbitrary-length, extremely complex password on any account, and not tell you what it is! That is about as good as disabling it. You can even script this up to "disable" the Administrator account on multiple systems. (Hint: if you have renamed them, specify 500 as the ID. Passgen will automatically resolve that to the real name of the Administrator account.)

Keep in mind that if you disable the Administrator account, you want to make sure that it is not the only key recovery account on the system. The key recovery agent is used to recover data encrypted with the encrypting file system (EFS) in case users forget their passwords. If you do not designate another key recovery account prior to disabling the Administrator account, you would not be able to recover encrypted files, possibly resulting in severe data loss.

Another really good option for managing the built-in Administrator account is to ensure that it has a different password on each system. Obviously, that's not easy to do, but passgen can help here, too.

Passgen can generate random and deterministic passwords and configure them on arbitrary accounts. It can also set passwords on service accounts and configure services to start up in a particular context. Earlier we discussed its ability to generate completely random passwords, but the more interesting functionality is the deterministic generator (the g option). In this mode, passgen takes some identifier, a pass phrase, and optionally the desired password length and the character set to use. From these parameters, it generates a pseudo-random password. If you want to generate a password for a different system, use the same pass phrase, but a different identifier. That will give you a completely different password. In other words, it allows you to use a single pass phrase to generate unique passwords for multiple accounts. Given the proper options, passgen will also set the password on the account for you, and you can even hide it from the output, to make sure it does not appear on the screen to protect it from prying eyes.

The recommendation not to show the password on the screen when you set it implies that you do not have to write it down. However, passgen generates passwords, it does not store them. What it does is quite ingenious and based on an idea our esteemed colleague David LeBlanc had. It bases the sequence of random numbers on the inputs, specifically , on the combination of the identifier and the pass phrase. Because the password is entirely dependent on these two inputs we can easily recover the password by running the tool again with the same input parameters. This allows you to configure different passwords on multiple systems while only having to remember a single pass phrase. If an attacker compromises one of those systems, he may be able to extract password hashes from it (as we shall see in Chapter 11, "Passwords and Other Authentication MechanismsThe Last Line of Defense," cracking passwords is strictly speaking not necessary), but those hashes are not valid anywhere else. All the other systems have different passwords. For complete details on the passgen tool, see Appendix D, "Password Generator Tool," which contains a copy of the readme file.

Obviously you would need to protect the pass phrase extremely well. Should it get compromised, the entire network is compromised, just as if you had used the same password on all the machines. Keep in mind, attackers will have access to the tool, too, and the identifiers are likely stored in a file somewhere. The only secret is the pass phrase, so be very careful with it!

Mitigating Service Account Dependencies

The key to mitigating service account dependencies is really to ensure that you do not use the same service account on multiple systems with different sensitivities. That really means you have to micro-manage service accounts. This is relatively straightforward; you create a separate service account for each segment of systems and then ensure that they are used only within that segment. The only problem is coming up with the resources to support it. This implementation may require multiple implementations of management infrastructures such as enterprise management systems, backup solutions, and so on.

Of special note is also the need to ensure that you get good passwords on all these accounts. Passgen can not only help you generate these passwords, it will also set them on the service accounts if you so desire . If the service is currently configured to start up in a different context, passgen reconfigures it to start in the new service account with the new password.