Access control is a fundamental concept of information security. Nearly all computer and network operating systems offer some form of access control. To pass the access control, a security principal must identify itself, authenticate itself ( prove its identity), and receive authorization to access the item in question.
Indeed, good security systems provide access control at all layers . Some examples: firewalls and routers provide perimeter access control, 802.1X provides network access control (but see Chapter 10, "Preventing Rogue Access Inside the Network," to learn why 802.1X is insufficient for wired networks), IPsec provides host access control, user accounts provide system and application and data access control. Access control is well understood at these layers. But what's missing here? Controls at the very bottomcontrols for physical access.
Figure 6-3. How not to operate a domain controller.
Is this your domain controller? Some of you are laughing now, thinking, "Surely you mocked that up just to take the picture for the book." Others of you are now worrying, "Oh no, how'd they manage to get inside our building and take a picture of our domain controller?" If you're in the second group , you indeed should be worryingnot about us, but about two things: whether someone really could get into your building and take such a photograph, and how to explain to your significant other that you can't take that vacation you planned last year because you have to rebuild your hacked domain controller.
Actually, the photograph is staged. We did it to illustrate the point: critical information resources that lack physical security cannot be considered secure. We've seen examples of poor physical security that are indeed so bad as the photograph shows. A thief who's managed to get into your facility, or a disgruntled  employee sufficiently motivated, could do some serious damage to the network if he or she can get to your domain controllers. Were that to happen, you've had not only a breach of physical access but you also can longer rely on the integrity of your account database (and possibly those of any domains and forests who have a trust relationship with yours). What's the repair/recovery tool here? FDISK.
So What Should I Protect? And How?
Physical access controls, like all other forms of access control, help ensure that your systems remain available for legitimate users and the business processes that require those systems. Just like you invest in physical access controls to protect the inventory in your warehouse (so that you can earn profit by selling that inventory rather than incur costs by giving it away to thieves ), it's important to invest in appropriate access controls for your information assets, too. If information is valuable to your business, the loss of information (or access to it) would most certainly affect your ability to continue to do business.
The amount of protection can vary, of course, and should coincide roughly with the value of the information stored on the systems (or the estimated cost of recovering that information). For instance, your home computer overflowing with questionable BitTorrent downloads, embarrassing photographs of your fifteenth high school reunion, and untested recipes for 49 different kinds of fruitcake probably doesn't need to be kept in a locked cage inside a windowless concrete building fortified with armed former Marines. But your domain controller deserves greater physical security than what it receives if you park the thing underneath Alice's deskespecially if Alice has a habit of poor workspace hygiene.
Lock Your Doors
For most large and medium businesses, we recommend a locked room that contains all information resources (application servers, database servers) and infrastructure resources (domain controllers, certificate servers, DNS servers, and so on) that provide the plumbing for the access controls you impose on the information resources. Limit access to the room by using a device that enables you to audit individuals who come and go. A shared key (we mean a real metal key here) is insufficient: you only know that any member of the set of owners of keys is allowed to enter, but you never know which individual member entered at any particular time. These keys are also trivially easy to share with unauthorized people and to duplicate. Put a small piece of masking tape over the Do Not Duplicate marking on a "secure" key and see whether you can get it copied . Most key machine operators won't bother to remove the tape first.
The minimum standard is an electronic lock with unique combinations for each authorized person. Make sure the lock keeps a log and fails closed if it detects tampering. Depending on your needs and assessments, however, a per-person combination lock might not be enough. Combinations can still be shared, and locks like this make the common mistake of combining identity with authentication. You can't assume that because you gave the combination 39185 to Bob that only Bob uses that combination to enter the roomwhat if he gives the combination to Alice? This is authentication without identity: the lock authenticates the possessor of combination 39185 but doesn't truly identify who that possessor is. Proximity badges have the same problem, by the way: Bob can (and probably often does) let Alice " borrow " his badge from time to time.
If your assets require stronger protection, or if you believe that a nonidentifying access control doesn't eliminate risk, consider a lock with multiple factors. Some locks require a proximity badge and a PIN: only the combination of the correct badge and PIN unlocks the door. This is better than requiring only a PIN or only a badge, but is still circumventable by two people working in cahoots. These locks are easier, however, to keep updated with fresh PINs because your proximity badge software system most likely is also helping you keep track of the PINs assigned to individuals and locks. Change a PIN on a lock and the software can automatically notify all those whose proximity badges are authorized to open the lock.
Fingerprint or (more common) palm readers combined with a PIN solve the identity-plus-authentication requirement. Your palm identifies you, your PIN authenticates you. We've seen this in hosting data centers, in large organizations, and in government and military installations. Once we saw a system use all three factors: a person inserts a proximity badge into a slot, which opens a little door covering both the palm reader and the PIN keypad.
Further Protect Things That Secure Other Things
Within the locked room, consider at least one additional layer of physical security for especially sensitive infrastructure resources. If you've implemented a public key infrastructure and have followed the guidance recom mending a twoor three- tier hierarchy,  you have an offline root certificate authority computer that you've got to do something with. Remember in a PKI that trust extends from the CA to the certificates it issues. If a CA gets compromised, you can no longer trust any of its issued certificates and therefore must revoke and reissue all of them. Because the trust of your entire PKI is, well, rooted in your root CA, protecting this computer is extremely important. Purchase a safe, place it in your locked room, and store the offline CA computer in this safe. Only administrators responsible for your PKI should know the combination.
If you use SYSKEY  to change any of the startup secret keys of computers in your locked room and have chosen to keep the keys on floppy disks, it's a good idea to keep those disks in a safe, too. We generally don't recommend changing SYSKEY on servers (but for laptops it can be useful; see the section below on laptop security). Remember that changing SYSKEY from its default setting to either the startup password or key-on-floppy options requires that an administrator be physically present at the server whenever it boots. Although at first this might seem secure, it'll quickly become a hasslewho enjoys trudging through 20 inches of freshly fallen snow to restart a server at 2:30 in the blessed a.m.? Nevertheless, some people do set SYSKEY, and we've seen people select the key-on-floppy choice and then leave the floppy in the drive ! This is operationally no different from SYSKEY's default setting but has the added risk of exposing your server to complete and total inoperability if the floppy gets lost. If you choose to use key-on-floppy SYSKEY, store your floppy disks in a safe. And don't use the same safe that you've put your offline root CA in: usually it isn't the same people who reboot servers and function as PKI administrators.