Some of the main topics of this chapter are
Securing computers in a corporate environment is tricky business. The more complex the network topology, the more complex the security administration will be. Many factors help determine the way you actually go about securing your environment; everyone's needs are a little different. This chapter is not an informational cure-all for network security; it does provide, however, realistic information that will help you make your systems much more secure. You find some of the information contained in this chapter in other parts of this book; it's combined here to provide a convenient place to look up security information. Remember that security is an ongoing process, so you cannot set it up once and forget about it; you must handle it on a daily, case-by-case basis.
Most of the security situations in Windows NT revolve around either user accounts or file permissions--that is to say, controlling access to objects means controlling access to the file system and user accounts. This chapter begins by talking about Windows NT file systems.
Windows NT supports two files systems: NTFS and FAT. It's always preferable to use NTFS wherever possible because FAT provides no means of directly securing directories or files.
Under the FAT system, the root directory has a fixed size and location on the hard disk. Directories are a special file type having 32-byte entries for the files they contain. Each 32-byte section consists of the following file information:
Windows NT 3.5 and later uses the attribute to support longer file names that can be up to 256 characters in length. Windows NT accomplishes this by storing the extra information in a conventional directory entry for the file. Then Windows NT creates one or more secondary directory entries that store the file name information in 13-character increments. Each of these secondary entries stores its corresponding part of the long file name, where Windows NT marks the entries as part of a long file name by setting attribute bits. When DOS or some other DOS-compatible operating system accesses a file with all four attribute bits set, it simply ignores the extra entries, acting as though they are invisible to the operating system.
This functionality by Windows NT in lengthening DOS file names beyond the older 8+3 standard has its merits, but on the other hand, it has caused problems for people who have used older disk repair utilities because these utilities had no way of understanding the Windows NT enhancements. Many hard drives are corrupted by these older utilities. To stay on the safe side, you should only use FAT disk utilities that are certified to be compatible with Windows NT. Better still, you shouldn't use the FAT system under Windows NT at all unless you absolutely have to. You'll be giving up a wealth of security features found in NTFS. Remember that the FAT file system offers little or no security at all.
The Windows NT File System (NTFS) is designed specifically for Windows NT. NTFS was designed to include most of the features found in other file systems in use today. NTFS as a whole provides a balance of performance, reliability, and compatibility. NTFS enables the use of long file names and, at the same time, maintains the older 8+3 file naming convention for use by older software packages. NTFS also supports case-sensitivity in file names for compatibility with UNIX variants, yet still enables case-insensitivity for use with DOS, Windows, and OS/2. NTFS supports a variety of multiuser security models, including a means of maintaining POSIX compliance and for emulating an Apple-style file server.
With NTFS, everything is viewed as a file or part of a file. Each allocated sector on a given disk is part of a file--even file descriptors are part of a file. Each file has a record in a special file called the Master File Table (MFT). The MFT is similar to the File Access Table found in FAT file systems.
The first 16 records of the MFT are reserved for special use. The first record describes the MFT itself, and the second record contains a pointer to the MFT mirror file, which is a copy of the MFT that is kept for fault tolerance and safety. If by chance the first MFT record becomes corrupt, NTFS reads the second record to find the MFT mirror file, whose first record is identical to the first record of the original MFT. NTFS records the locations of both the primary MFT and MFT mirror file data segments in the boot sector of the hard disk. A copy of the boot sector itself is recorded at the logical center of the disk.
The third record of the MFT is the log and is used for file recovery operations. NTFS writes updates to a log area of each volume. Although FAT systems also keep a second copy of the FAT table for recovery purposes, after a system crash on NTFS, this log area can be used to straighten out problems almost instantaneously, producing a much faster recovery than with FAT.
Access permissions to file objects on Windows NT systems are known as Access Control Lists (ACLs). ACLs are assigned to each object as it is created. Two basic types of objects can be secured on Windows NT: container objects and non-container objects. Containers are objects that contain other objects, such as a directory, which can contain other directories and files.
This is important to understand because an object can inherit permissions from its parent object. For example, if an object is a file being created by a program in a given directory, the file object inherits the permissions of its parent, the directory itself.
ACLs can be adjusted and set as desired to a large extent. When changing permissions on a directory, those permissions immediately apply to the files contained in the directory but not to the subdirectories and their files. Changes to objects of this type must be intentionally made or propagated down, either manually or by selecting the Replace Permissions on Subdirectories and Replace Permissions on Files boxes located on the Properties page under Permissions. Propagating permission changes down the directory tree is a bad idea unless you know it's necessary.
Typically, Windows NT permissions follow the strongest security model defined and in the order in which they're listed. As an example, assume the following:
When John tries to gain read/write access to the file, Windows NT reads the Access Control entries one at a time in order until it finds entries either granting or denying John read/write access. In this example, John would be denied access because the TESTUSER group has been denied access before the MGMT group has been granted access.
The only exception here is if John is the Owner of the file, in which case Windows NT recognizes John's ownership and immediately grants him read access only.
In any network environment, the best practice is to grant as few permissions as possible. This means that if a user only needs execute access for a program directory, there's no need to allow read, write, or full control. Each software package behaves differently. A bit of trial and error here might be necessary, but it's well worth the effort to find the minimal permissions required.
A shared resource is any object that has been made sharable and available on the network. The most common types of shared resources are files, directories, and printers, although there are a few other specialized shares established by the Windows NT operating system for various uses. The person or process that establishes a shared resource becomes the creator/owner of that share. Each share has its own unique share name on a given server and is assigned by the creator/owner.
All shared resources under Windows NT can be secured against unauthorized access. Each share has a set of security attributes called the security descriptor. Each security descriptor consists of four parts, defined as follows:
Users and administrators can share files, directories, and printers for use on the network. When establishing an object as shared, the user must first choose a unique name for the share and then assign access permissions to users and groups that will be allowed to access it. After this information has been established, it is used to create the security descriptor described in this section.
Establishing shared resources is something that every administrator should know how to do. Yet, some tricks of the trade go a long way toward preventing unwanted access. One of the most basic techniques you can apply to your shared resources is to simply hide them. Hiding shares under Windows NT is incredibly simple to do, yet few practice the technique. To hide a shared resource so that it doesn't appear in an Explorer browse list, all you need to do is append a dollar sign ($) to the end of the share name. For example, instead of defining a shared directory called WORK, you would instead name the share WORK$.
The only implication in doing this is that you must already know the share name to connect to it.
CAUTION: If you forget the share name, the only way to get the name again is to log on to that Windows NT system and view the shared resources by using Explorer or use Server Manager to display them from a remote workstation, which requires administrative access to the server.
Windows NT defines a few of these hidden shares by default each time the operating system is installed. Typically, the most common hidden shares established during a Windows NT install are the basic drive shares for drives C:, D:, E:, and so on. If you view your shares by using Server Manager, you'll see them quite easily. These are administrative shares, defined so that your system administrators can gain access to them quickly, without having to define them after an install.
The downside to this is that most intruders know about these default shares and frequently attempt to access them during an intrusion effort. You might want to rename or disable these default administrative shares to something a bit more obscure, which will help you fend off intruders. On the other hand, you can leave them in place and minimize their permissions so that no one can use them effectively, which is probably the better choice. To disable the shares completely, edit the following Registry key for servers:
HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\LanManServer\Parameters\AutoShareServer
Edit this key for Windows NT Workstations:
HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\LanManServer\Parameters\AutoShareWks
Change the key setting to 3D0, and reboot the machine. You will see that the default administrative shares have been disabled.
NOTE: For detailed instructions on how to modify the Registry, see Chapter 43, "Editing the Registry."
User accounts are at the heart of Windows NT. These accounts create an identity for each person, program, or service that accesses resources on the Windows NT system. You should pay attention to several areas when handling user accounts and permissions.
See "Creating Users and Groups," p. 380
First and foremost, make sure that all the Windows NT password control features have been implemented. This includes requiring users to have strong passwords, forcing users to change their passwords at regular intervals, and giving users the option of changing their own passwords at regular intervals.Figure 26.1 shows the available configuration options in the Account Policy dialog box.
Windows NT can lock out accounts after so many bad password attempts. Be sure to enable the Account Lockout setting because it greatly impairs an intruder's capability to "brute-force guess" your passwords. After you've checked the appropriate box in the Account Policy dialog box, you need to make a few other adjustments to the settings:
The Account Policy dialog box is used for managing special access types.
Password Restrictions can be enforced by using this dialog box as well. There are two basic options for restrictions:
Setting the Minimum Password Age is allowed, which forces a user to keep the same password for some amount of time defined in days. The setting works hand in hand with the Password Uniqueness setting. Typically, for the Password Uniqueness setting to be effective, you need to define a Minimum Password Age as opposed to letting the user change her password immediately.
It is always a good idea to establish some type of password uniqueness, which basically means that a user will not be able to reuse old passwords for a given amount of time. The amount of time is controlled by the number of old passwords kept by Windows NT, in conjunction with the amount of time between password changes. Normally, it is a good idea to force Windows NT to keep at least five old passwords and to allow those passwords to be used for approximately one week, up to one month maximum.
The Password Length setting shown in Figure 26.1 is incredibly important. You should never allow an account to use a blank password. This is very dangerous indeed. Instead, force users to use a password length of at least eight characters and preferably at least 16 characters if you can get away with it.
It's a little known fact that Windows NT transmits a user password twice during authentication: The first transmittal is the entire encrypted password, and the second transmittal is just the first 14 characters of a user's encrypted password, with all alpha characters in uppercase. This means that any intruder with some knowledge can use this fact to find easier ways to break the password by intercepting these 14 characters, as opposed to intercepting the entire encrypted password. Therefore, it stands to reason that using passwords 16 characters or longer can be a stronger way of protecting against a break-in.
Generally, you should force the use of strong and complex passwords and instruct users not to write them down anywhere unless the passwords can be safely locked up afterward. Brute-force guessing of passwords is one of the most popular ways of penetrating a network today, and it can in fact be done against Windows NT.
You might want to note that with Windows NT 4.0 and Service Pack 2 or greater, it's possible to include additional password-checking routines in the form of a DLL. These DLLs could serve to check a user's password when it's being defined or changed, at which point it could reject the password, based on its complexity. Doing this requires that you first obtain or write your own password-checking DLL and that you install it on the Windows NT Domain Controllers, as well as make some Registry adjustments--all of which are well worth the effort. According to Microsoft, a DLL named PASSFILT.DLL ships with all versions of SP2.
Securing Built-In Groups and Accounts. A major target for intruders is the default Administrator account. You can greatly impair an intruder's capability to break into your system simply by crippling this account. If you delete it, the intruder can detect that the account does not exist and therefore move on to other accounts. But if you leave it in place and cripple it, the intruder will not discover this until he has taken the time to brute-force guess the password--at which point all that time spent will have been wasted.
In most cases, the best practice is to create a new Administrator account by creating a new user, adding him to the Administrators group, and duplicating all the account policies and permissions that belong to your particular Administrator account. After this new account is established and tested correctly, remove all permissions from the Administrator account but do not disable it. Leave it in place as a makeshift decoy.
CAUTION: Another point to remember about administrative access is that you should always minimize the number of users who belong to the Administrators group. Don't ever add someone to this group for the sake of convenience and check the membership routinely for errant entries. Also, revoke the Access From Network privilege for user accounts that don't need access to that Windows NT server; this prevents the user from being able to connect to that particular server.
Removing Inactive User Accounts. Old user accounts are a basic hazard in most network environments. You should routinely check your systems for user accounts no longer being used and delete or disable them. Frequently, accounts are established for part-time, temporary, or contract employees. These accounts should be disabled or deleted immediately after the users leave the company. All too frequently, the accounts are left in place, which, in turn, leaves your system a bit more open than it should be.
One way to handle this is to establish a documented procedure, complete with a checklist for creating and removing old accounts. Perhaps enforcing the use of some type of scheduling software such as Schedule+ or Outlook is in order here because those packages have the capability to produce reminders that can be used to inform an administrator when it's time to delete a user account. When deleting user accounts, you might first want to disable the account before actually deleting it.
NOTE: Microsoft recommends you not delete user accounts, as there are a limited number of SIDS. After a SID is assigned and removed, it can't be regenerated without reinstalling Windows NT Server. Thus, Microsoft suggests you rename and disable an account.
Controlling the Guest Account. A topic of heated debate in the security world is the validity and use of the Guest user account. This account is created by default with each new Windows NT installation. On versions prior to 4.0, this account was installed and left enabled--which is dangerous. On Windows NT version 4.0 and later, this account is automatically installed but disabled by default. If you don't need to permit Guest users on your system, then disable or delete the Guest account from the system and set up a unique user ID for each person who must access your system temporarily. If you choose not to delete this account and prefer to simply leave it disabled, check it routinely to ensure that it remains disabled.
One situation seen over and over again in almost all network environments is users remaining logged on to their workstations while they are away from their desks. Make sure that your users do not leave their Windows NT workstations turned on and unattended. Your policies should dictate that password protected screen savers be activated before leaving a workstation momentarily, and users should log off when they aren't going to return in a reasonable amount of time. Additionally, you might want to have a policy mandating that systems be powered off when users leave for the day.
An important defensive action you can take is to display a legal notice on your systems, warning each user that system access is restricted to authorized users and that sessions can be monitored. This serves as fair warning to potential intruders and gives you the legal grounds to monitor activity in most cases without fear of reprisal down the road.
CAUTION: In some places, it's against the law to monitor computer user sessions--even on your own network! By using warning messages, you might be able to legally watch your network traffic (or an intruder's traffic) if you need to, without any fear of legal recourse against you. Do this on your Web site, FTP server, Windows NT logon screens, and any other services that provide a means to do so. Also, be sure to check with your attorney about what implications are carried by warning users about monitoring all traffic.
On Windows NT version 3.1-4.0, you can insert a logon warning message by making the following changes to the Registry:
2. From the HKEY_LOCAL_MACHINE subtree, go to the following subkey:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
| Name | Data Type | Value |
| LegalNoticeCaption | REG_SZ | Dialog Caption |
| LegalNoticeText | REG_SZ | Dialog Message |
NOTE: The warning message usually appears after you log on to Windows NT, but on some Windows NT 4.0 systems it might appear before logon takes place.
http://www.microsoft.com/kb/articles/q101/0/63.htm For more information on this, see Microsoft's TechNet article #Q101063, or visit the online version of TechNet on its Web site.
One of the most overlooked areas of network security is auditing. Windows NT provides the means to perform auditing on many of the critical system objects and events, such as logon attempts, object access attempts, and so on. Each type of audible event can be set to record successes and failures. If you're shooting to meet C2 security compliance, then you will definitely need to turn on auditing.
You can enable auditing in an overall sense with User Manager. Choose Audit, Policies to open the dialog box shown in Figure 26.2. Here you will see that you can either turn on or off auditing. When auditing is turned on, you have the capability to track several basic event types, defined as follows:
You adjust what audits take place in the Audit Policy dialog box.
TIP: We recommend that you at least turn on Audit Failure for all the previously mentioned events. This provides the means to determine whether someone is taking unwanted action on your network. Additionally, after auditing is enabled in this dialog box, you gain the capability to audit events on the file system and your printing systems. Auditing for files and printers is established by using the Permissions dialog box found in the Explorer for each respective object.
To enable auditing on a file, directory, or printer, locate that resource by using the Explorer and right-click the name; then choose Properties. On the Properties page, select the Security tab and then click the Auditing button. The auditable events are listed and can be tracked by success or failure. It's a good idea to track all audit failure events, which, like account auditing, can help reveal intrusion attempts before they have a significant impact on your network.
See "Audit Policy," p. 504
The capability to install services on Windows NT is one of NT's finer points. Each installed service requires a user account to run under, which, in effect, defines its level of authority on the operating system.
In practice, most installable services use the built-in SYSTEM account as their authoritative account. This means that the service has the same level of power as the operating system itself, and therein lies some danger if you aren't careful. Sometimes services contain bugs that can be exploited, enabling a user to gain SYSTEM-level authority on your Windows NT machine. This is rare, but nonetheless the risk is real. Unfortunately, most services that install themselves by using the SYSTEM account do in fact require this level of authority to perform their tasks, so changing the account to something less powerful doesn't always work. In fact, more often than not, it "breaks" the service, causing it to malfunction.
Some services enable you to choose an account for the service to run under, which is a good thing because you can control the level of permission and privileges the account has. Sometimes a bit of trial and error is necessary to determine an acceptable level of minimum privileges.
Any time you install a new Windows NT service, immediately examine the account it runs under. Open Control Panel and then the Network Control Panel applet, select the Services tab, and view the service properties for the service in question. You will notice account information in the dialog box, and if the Use Built In SYSTEM Account box is enabled, then obviously the service is running under the authority of the SYSTEM account. If the service has a different account defined, however, be sure to examine the permissions assigned to this account by using User Manager.
In addition to concerns about service accounts and permissions, you must also watch the services themselves. Frequently, new problems will surface that affect a particular service from a security perspective. For example, today a service might appear completely safe and reliable. Tomorrow, though, somebody might discover a slight problem that creates a giant security hole that anyone can easily walk through. It happens all the time.
This means that part of securing your services is watching for new problems that might arise. In most cases, a vendor will release service packs or hot fixes to correct various problems, but one thing is sure: They aren't going to call you on the phone and let you know these things are out there. You have to constantly look for the problems and fixes yourself. Many sites on the Internet track Microsoft-related security concerns, and some even alert the public to new developments as soon as they arise.
By far, most computer break-ins occur from over the network. Therefore, always monitor your network traffic closely. Most network break-ins occur on networks that were already secure to some extent but simply weren't monitored closely enough. You can ease the burden of network monitoring by using a robust network monitoring package to perform the task for you. Several inexpensive and robust monitoring packages are available today. NTManage is one such package and can be located on the Internet at http://www. lanware.net.
One important area of configuration on the network is domain trust. Always be careful about establishing domain trust. Things can get out of hand quickly on larger networks with several Windows NT domains. Experts agree that consolidating your administration into a single domain wherever possible is the best path to follow.
You might be pleased to learn that Microsoft has released a new Domain Planning Guide that helps a lot when designing your domain layouts. Check the MS Web site for more information on this tool at:
http://www.microsoft.com/ntserver/info/domainplanwp.htm
If your network has a firewall in place, or you plan on installing one in the future, you might want to make a few specific settings to the firewall, above and beyond the obvious. Blocking all inbound access to UDP ports 137 and 138, as well as TCP port 139, stops any possible attempts to connect to your network resources using NetBIOS over TCP/IP--commonly known as the NBT protocol. This one simple step can greatly reduce the probability of your network being infiltrated. Also, be sure that you log and monitor all packets arriving at the firewall destined for these ports. Doing so reveals how often people attempt to pass this type of traffic into your network and also can reveal the source address of the packets, which can help you identify the culprit.
A common occurrence in businesses today is to connect your network to a business partner's network--which is great if you protect yourself first. Remember, your network is only as safe as its weakest point. Therefore, consider any network other than your own untrustworthy until proven otherwise.
If you find it necessary to connect your network to a business partner's, make sure that you install some type of firewall between the two first; don't blindly trust their network users and administrators to think of you when they make changes. For example, you might connect to a partner's network that you know is currently secured to your satisfaction. Then one day, this partner decides to connect to the Internet. The moment she plugs into the Internet, you gain all the vulnerabilities that she has in terms of Internet traffic--and you might not be informed about this new Internet connection until later.
The best practice when connecting to any untrusted network is to close down all forms of allowable traffic into and out of the network; then systematically open up holes one at time for the specific traffic types you want to pass. Almost all the better firewall systems practice this type of security definition.
We've all heard some pretty smart and well-known Windows NT people talking about how to handle new service packs for Windows NT. Some of the best minds in the business (on Windows NT) state that you should never install a new service pack until other people have tested it first. Based on the major problems that cropped up with Service Pack 2 for Windows NT 4.0, this sounds like good advice. But we're here to explain otherwise to you.
In reality, service packs are both a blessing and a major problem. Usually, the service packs fix bugs, security holes, and other problems, but at the same time they can easily break a working Windows NT system. The truth is that Microsoft does not always explain everything a service pack will do or fix--especially when it comes to security problems. This creates a difficult situation in that no one wants to break his Windows NT system, but everyone wants the system to be secure.
Finding the idiosyncrasies with new service packs is well worth the effort because invariably service packs fix any new security holes that might have come to the surface. Our recommendation is to install new service packs religiously, but do it on a test system first. That way, you will know if you're going to have trouble with production systems.
A case in point once again is SP2 for Windows NT 4.0. This service pack fixed several security holes, some of which Microsoft didn't care to mention in the documentation. Although some people shied away from SP2 because of all the reported trouble, they left their critical systems open to easy attack.
See "Installing Service Pack 3," p. 1221
Here's how C2 is described by the Department of Defense:
Windows NT has been designed by Microsoft to meet C2-level compliance. Achieving a C2 security level is not something you can do, however, simply by taking Windows NT out of the box and installing it. Further configuration must be made, and other issues must be considered. Some of the most important requirements of C2-level security are:
Under the C2 guidelines, the following is true: "The operating system must protect data stored in memory for one process so that it is not randomly reused by other processes."
Windows NT Server protects memory so that its contents cannot be read after the memory is freed by a process. In addition, when a file is deleted on an NTFS partition, it's gone for good. Unlike DOS partitions, there's no way to undelete a file under NTFS. Users cannot access a file's data, even when the disk space used by that file is not yet allocated for use by another file.
On a Windows NT system, each user must uniquely identify himself by typing a unique logon name and password before being allowed access to the system. The system uses this unique identification to track the activities of the user. System administrators are able to audit security-related events and the actions of individual users, which are written to the Event Log where an administrator can easily review them.
The complete requirements for C2 security are outlined by the U.S. Department of Defense's National Computer Security Center (NCSC) in the publication Trusted Computer System Evaluation Criteria, commonly called the Orange Book. Microsoft has worked closely with the NCSC throughout the development of Windows NT to ensure that Windows NT complies with the government's requirements for C2 security.
In addition, the NCSC has published different interpretations of the Orange Book that serve to clarify the requirements with respect to specific system components. One such book is the NCSC's Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, commonly called the Red Book. The Red Book interprets Orange Book security requirements as they would be applied to the networking component of a secure operating system and also indicates how a network system should operate to meet Orange Book requirements for C2 security.
Microsoft signed an agreement with the NCSC in 1992 to evaluate Windows NT for C2 compliance. Since then, Microsoft has worked closely with NCSC to ensure that Windows NT stays in compliance with the C2 guidelines. To date, NCSC has found the core components of Windows NT to be C2-compliant, which means that a user can build C2-certifiable Windows NT systems, not that Windows NT is C2 secure right out-of-the-box.
The Windows NT Server implementation of C2 security is entirely software-based. Other OS vendors today use hardware components to provide some or all of the C2 security characteristics. Hardware-based C2 systems have their finer points, but having C2 security based in software components gives an operating system vendor a greater degree of control over development and evolution of the overall operating system product.
Microsoft states that Windows NT Server is so secure that certain processes such as identification, authentication, and the capability to separate a user from his functions actually meet the Orange Book B2 security, which is stricter than C2 security.
Just remember that being C2 compliant means that you've achieved a certain level of security in regards to your network and its environment--but it doesn't mean you're completely safe.
Experts says that the future of network security is not in authentication and firewall systems but instead lies in encryption--and we tend to agree. Encryption offers a layer of protection that other security systems don't, and it can be a strong last line of defense in the event your other security mechanisms are breached.
There are several ways of implementing encryption in your environment, from protecting mail messages to encrypting entire disk drives and all network traffic. Deciding what's best for you depends on your needs.
The new buzzword these days seems to be the Virtual Private Network (VPN). A VPN is just like any other network, except that traffic is typically limited between specific end points, and the traffic is completely encrypted. Several good VPN packages are on the market today, and any of them can be used effectively to protect your network traffic from prying eyes. Windows NT 4.0 even has its own version of VPN technology built in, called Point to Point Tunneling Protocol (PPTP), which can serve as a strong line of defense.
PPTP can be used by telecommuters who use an Internet service provider to reach the home network safely without risk of intrusion, hijacking, or data discovery because all packets are encrypted.
Encrypting files and directories that contain sensitive information is a good idea in most cases, as well. Several well-known products are available today, with two of the most popular produced by Pretty Good Privacy (http://www.pgp.com) and RSA Data Security (http://www.rsa.com). Both companies make products that encrypt files and e-mail, and these are two of the most secure encryption systems on the planet today.
Another company, SoftWinter Corporation (http://softwinter.bitbucket.co.il), has introduced a product named Shade designed specifically for Windows NT. Shade enables the user to create an encrypted disk device inside a file that he can then format by using NTFS or FAT and use as a regular disk drive on the system from that point on. Shade encrypts data on every write operation and decrypts data on every read operation. The encrypted file, with all the data inside, can be easily backed up and restored, and even moved between computers. Shade runs on Windows NT 4.0 with Service Pack 2 and uses the MDC/SHA 160-bit encryption scheme along with a 1,024-bit random password to get its job done. You might want to take note here that the popular DES encryption algorithm only uses 56 bits, which seems to imply that Shade might be more secure than an encryption system using DES.
Physical security is just as important as any other type of security. It does absolutely no good at all to install high-tech network security systems if an intruder can simply walk right in and take your servers. The best way to handle physical security is to think like the intruder. Ask yourself, "How would I get in here if I wanted to?"
It's important to remember that physical security does not only cover your network media and servers but also refers to your client systems and client environment. You might also ask yourself, "What good is it to use a door with locks if everyone in the shop has a key?" Examine your environment carefully to see whether there are any obvious mistakes that might lead to a breach.
You might want to start out by examining where you house your data and equipment. Examine the following list of items:
© Copyright, Macmillan Computer Publishing. All rights reserved.