Although locked doors protect many computer rooms, the cables and telephone wires that enter and leave these rooms are often left unprotected. Access to cable and telephone wiring closets or local exchanges should be as secure as access to the computer room. Otherwise, an eavesdropper armed with a network sniffer may be able to obtain all the information he or she needs without ever setting foot inside the computer room itself.
Securing Hardware
If an intruder is able to gain physical access to the inner sanctum, all may not be lost. If the intruder is interested in acquiring some piece of data on one (or more) of the servers, as opposed to destroying or stealing the hardware, then hardening the server may either
thwart or at least delay intruders long enough for their illicit activity to hopefully be detected. Server-hardening options include the following:
Enabling screensaver password protection.
Locking down any network-accessible tape unit or CD jukebox.
Removing all floppy drives and CD (or other external media) drives. Note: This measure may be circumvented if external ports are available for an intruder to plug his or her own media devices into and the operating system is able to auto detect the device (plug-and-play style).
Removing all nonessential external ports: serial, parallel, IDE, SCSI, USB, and firewire. Note: This measure may be circumvented if an intruder is able to gain physical access to the machine's motherboard and is able to install his or her own interface cards.
Using a locked shield to restrict access to the server's on/off switch or reset button (and thereby inhibiting an intruder from rebooting the machine). Note: This measure may be circumvented if the power cable is easily accessible.
Configuring machines to boot from their hard drive first (just in case intruders try to boot from their own floppies or CDs). Note: This measure may be circumvented if an intruder is able reset the machines' BIOS configuration.
Enabling BIOS-level password protection.
Automatically sending an alert to the LAN administrator every time the machine is rebooted.
Securing Software
Often-overlooked physical assets that should be secured against thieves are CDs and other media used to store the system software, third-party software, and application software used by the Web site. Although it may prove easy to obtain the most recent version of an operating system, it may be much more troublesome to try and locate an older version that is not being distributed by the vendor but is still being used by the Web site. In some instances, the vendor may have stopped supporting the product or even gone out of business. Conversely, the challenge with application software is making sure that the version used for a restoration is up-to-date with the most recent fixes. No one wants to restore a server back to a previous version and then have to manually reapply the last 20 fixes before it can go back into production.
SAMPLE SECURE ROOM AND SERVER ACCESS TESTS
To test the physical security of a Web site, consider asking an unauthorized fellow employee to attempt to gain physical access to a target machine located within a supposedly secure room. Then once inside, attempt to copy the machine's password file (such as the SAM file on a Windows NT/2000 system or the passwd file on many UNIX systems) to a floppy disk. Once captured, this file could be cracked at leisure by a real attacker. Some tactics that the unauthorized employee could use include the following:
Working late and attempting to follow the cleaning crew into the locked computer room
Carrying a clipboard and toolbag with a utility company's name on it and then requesting to be allowed access to the utilities junction box
Offering to pick up lunch (pizzas, sandwiches, and so on) for someone in the computer room or even pretending to be the pizza delivery guy
If the fellow employee is successful, consider repeating the test, but this time using the assistance of a contractor or somebody off the street.
Software libraries (ideally located off-site) and configuration management systems should also be audited to ensure that in the event of a disaster this software vault contains a copy of all the software needed to recreate the Web site and its associated application(s). In addition, the mechanism for checking out any physical copies should be checked to ensure that an intruder could not easily pilfer a critical disk or review an application's source code to look for an as-yet-undiscovered vulnerability.
Securing Data
Many organizations offload historical data from production servers onto backup/ archival mediums such as tapes, Zip disks, and CDs. For a Web site that does so, the storage of these tapes and disks should be checked to ensure that they are stored as securely as the current production data. For instance, a DBA backing up the production database onto tape and then storing it in a home office may sound like a cheap off-site backup strategy, but it may also be easily exploitable by an intruder knowledgeable about this practice and willing to break into a residence while no one is home. That's much easier than having to deal with those pesky guard dogs and heavyset guards protecting the facility housing the Web site. In addition to checking the security of any off-site location, the transportation of any sensitive data to or from the site should also be considered, especially if a predictable pattern is used to transfer this information. Although carjacking is perhaps a little farfetched, walking off with the floppies sitting in the network engineer's briefcase is not. Table 7.6 summarizes this list of physical security checks.
Table 7.6: Physical Security Checklist YES NO DESCRIPTION
□ □ Does the organization have security policies in place that provide guidance on what physical security measures should be implemented at each secure facility?
□ □ Are all recommendations on obscuring the actual location of a facility followed?
□ □ Are all recommendations on securing the facility's perimeter followed?
□ □ Are all recommendations on securing the entrance to a facility followed?
□ □ Are all recommendations on securing the room(s) used to house the Web site's hardware infrastructure followed?
□ □ Are all recommendations on securing any cabling that the Web site depends on followed?
Table 7.6: Physical Security Checklist YES NO DESCRIPTION
site followed?
□ □ Are all recommendations on protecting the media that stores software used by the Web site followed?
□ □ Are all recommendations on protecting the media that stores current or archived data used by the Web site followed?
□ □ Are all unannounced attempts by the security assessment team to gain physical access to the hardware, cabling, or media used to store software or data thwarted?
Planning against Mother Nature
Planning against and recovering from natural disasters is in itself an entire discipline and, as such, developing a disaster recovery plan and an associated business continuity plan is in all probability outside the scope of any security-testing effort. That said, during a security assessment, it would be prudent to check that these plans do indeed exist and cover such major eventualities as hurricanes, tornadoes, floods, earthquakes, subsidence, and lightning strikes. Maiwald et al. (2002) and Toigo et al. (1999) provide additional information on disaster recovery.
One area that may not be covered by a disaster recovery plan is that of environmental degradation caused by nature. Examples include dust, mold, bacteria, condensation, humidity, ultraviolet light, cosmic radiation, and static electricity slowly corroding away hardware components. Fortunately, such slow-acting deteriorations should ensure that only one hardware component will fail at a time and should therefore not seriously impact the Web site. Two exceptions do exist, however; if the failing component is a single point of failure, or if the failure of one component can cause a chain reaction that results in additional components failing, then the entire Web site may be affected. Hopefully, any single points of failure and potential chain reactions were evaluated as part of the Web site's reliability and availability test plan, and they can therefore be regarded as outside the scope of the security-testing effort. Of course, this assumption should be confirmed. Table 7.7 summarizes this list of checks.
Table 7.7: Protection from Nature Checklist YES NO DESCRIPTION
□ □ Has a disaster recovery and business continuity plan been developed for the Web site?
□ □ Do these plans cover all conceivable natural disasters that could in any way affect the Web site?
Table 7.7: Protection from Nature Checklist YES NO DESCRIPTION
could significantly impact the Web site?
□ □ If a chain reaction could occur, is the organization willing to accept the risk associated with this event occurring?
□ □ Have the disaster recovery and business continuity plans been fully tested?
□ □ Has environmental compliance been covered by another testing effort?