• Former employees. Of all the 'targeted' attacks that are truly aimed at your company, former employees are probably the single most common source. While some attacks take skill to execute, others hardly take any at all, and instructions for performing them can be found on the web. Don't take, "Oh, he/she doesn't know anything about the system" as a reason not to take precautions. Former employees are also one of the worst threats because they know significant inside information about the company itself.
• Competitors. Most of the time, your competitors won't think to try to hack your computer systems. If they were to get caught, the potential repercussions would be sufficient to deter most of them. Still, if one of your competitors holds a grudge, or is unethical, it's a potential (though unlikely) source of hacking attempts.
• Current Employees. Is there information on your systems that you'd prefer an existing employee not access, such as HR records, salary figures, profit-and-loss statements? Employees can sometimes be interested in this information, and might try at least casual hacking attempts to get it.
• Random Individuals. This a catch-all category. Disgruntled customers, people offended by your web page, people who dislike your corporate stance on certain issues, people who want to make a statement.
• Script Kiddies. The above perpetrators are all targeting your network specifically. Script Kiddies are a different sort of attacker. They don't care that much about who they attack, usually; they just want to control a large number of machines for various reasons. They range from bored teenagers who know little to those with more technical sophistication, but they use scripts to attempt to locate security holes or vulnerabilities you have left open. When they find one, they exploit it and use it to gain access to your machine. On the up-side, most of them don't actively destroy your data or system configuration, and they usually don't care about the data stored there, but they can significantly disrupt network operations.
• Experts. A truly expert hacker may find vulnerabilities that a script kiddie might overlook. The only benefit is that most people with the knowledge to fall into this category have too much to lose by hacking, and too little to gain. Frankly, the concept of playing IRC games bores them. For this reason, they're actually less of a threat.
• Viruses and Worms. Pieces of self-replicating code have begun appearing that scan the Internet, looking for improperly secured systems. When found, they infect the system, causing it to begin scanning. Once one of these gets inside your network, it can spread like crazy internally. It's best not to let them get in.

The movie 'Hackers' got it partly right. The most commonly used passwords, that I've seen in use in the real world are:

• The username.
• Names of significant others, children, or pets.
• The user's birthdate.
• The name of the company or organization or its date of founding.
• The word 'password' or a blank password.

• Entered backwards.
• Entered with the number '1' appended to it.
• Entered with the current year appended to it.
• With an exclamation mark at the beginning or end.
• Combined with another common password item.

With a quick call, or a little research, I could in most cases guess a user's password by knowing the above pieces of information -- many of them fairly easy to discover. I could reduce it to under a hundred passwords I would have to try to get into the system. And it would work probably three times out of four. If I can do it, so could a malicious user.

Most network operating systems have the ability to force users to change their passwords every so often, and enforce criteria about password length and compexity. It's usually a good idea to use them. Circulate policies about passwords forbidding the use of any of the above techniques. Add 'dictionary words' to the list, at least if they are used alone or not made more complex in some unusual fashion.

Changing passwords is less a function of time and more a function of events. When an employee leaves, it is good policy to change all the passwords in the organization -- they might easily have found out another user's password. If you enforce password changes too frequently, you encourage users to engage in other unsafe practices, such as writing down their passwords or using passwords that are easy to remember but also easy to guess.

Educate your users on the importance of not giving out the password to anyone they don't know. If they're suspicious, have them apologize and offer to call the person back to give that information. Very few hackers will want that to happen. There are times when you may have to know your users' passwords, so you might not want to make a policy of never telling anyone their password. However, instructing them to be cautious and revealing the dangers through a fictional conversation skit might well make it memorable.

Unless this service is absolutely needed, remove it. If the user doesn't host any printers other users use, and if the user doesn't have a shared folder on their hard drive that needs to be accessed frequently, remove the service entirely. It's just one more way that intrusions can occur. If it must remain, consider switching them from 'Share Level' access to 'User Level' access; at that point, it can access the username/password database on the domain controller and require users to actually have a valid account before they can access the service.

Even on Windows NT, every share is another set of permissions that has to be checked. Don't close a share used by an application, but if you're sharing the entire hard drive, you've got a security hole open. To begin with, the root directory typically doesn't have any special permissions. This means it's usually set to 'Everyone: Full Control'. This means anyone could drop in a new executable, then simply find a way for it to get executed. Instant server control.

Instead, try to share the least amount possible. Don't worry so much about the 'Administrative' shares like C$, D$, etc. Those require the administrator password or administrative rights. It's the other shares you or somebody else might have created that pose a potential threat.

If you are using NTFS, use those permissions. Anything you're sharing should have some sort of permissions associated with it, with the possible exception of the CD-ROM drive. While it's sometimes not possible, under NT 4.0, to set NTFS permissions because of the lack of inheritance (setting permissions on any system directory, with subdirectories and files, overwrites anything that was there already and can break some systems), any non-system and non-program directories are usually safe to modify. Only let those who need access to it have access to it, and remove the Everyone: Full Control group.

Anytime I've left a company, I've made sure to remind them to change my passwords and any passwords I knew. I want to make certain that I can't be blamed for abusing the passwords I have. I wouldn't, but I want to shield myself from any possible suspicion. Do the same for those leaving your company.

In addition, it's usually a bad idea for too many users to have administrative access. There's a lot of power and a lot of responsibility associated with those accounts. There's a lot of rope available, and you don't want people with inadequate training or experience to hang themselves with it -- or your servers.

This requires some explanation. Every Windows NT machine, both server and professional, contains its own username and password database (called a 'SAM Database', or an Account database under Windows 2000). Each machine's database is completely separate, and they do not replicate back and forth (exception: Domain Controllers do replicate their SAM database with each other).

Under Windows NT 4.0, the SAM database can be viewed using the User Manager or User Manager for Domains utility. Using the 'Select Domain' option under the 'File' pull-down menu. Typing the name of the domain shows you the domain SAM, while typing two backslashes and the name of a workstation or server shows you that workstation's SAM. Under Windows 2000 and XP, the domain account database is viewed using 'Active Directory Users and Computers', while the local account database is viewed under 'Computer Management' and then 'Local Users and Groups'.

When a computer joins a domain as a member server or as a workstation, two things happen. First, the computer is added to a list on the server of computers that are authorized to retrieve SAM information. Second, the computer has the global 'Domain Admins' group on the domain added to its local 'Administrators' group, and the global 'Domain users' group on the domain added to its local 'Users' group. Several other groups are updated in this fashion. It's this second step that causes the domain Administrator account to have administrative rights on the local machine, and for users of the domain to be able to use their domain account locally on the workstation.

It's important to remember, though, that the domain 'Administrator' account and the local 'Administrator' account are different accounts. They have the same name. They might even have the same password (though there's no reason they have to). But they are different accounts, since they are part of different SAM databases. This distinction is important to remember.

Here's the problem. When most people say they changed the Administrator password, what they mean is that they changed the Domain Administrator password. However, each client also has an Administrator account. You can't delete it. You could, potentially, set it to gibberish -- but this leaves a potential problem waiting to happen. Let's say the domain is inaccessible for some reason, such as a failed network card driver. You won't be able to log into the workstation with the domain administrator account to fix the driver because the failed driver won't let you connect to the network. So you can't fix the driver to get back into the network. Where's that Windows NT CD again?

Setting it to the same as the domain Administrator password causes another pair of problems. First, most of the time, you don't keep each workstation's Administrator account updated with the latest Administrator password, so you're left trying to historically guess all the Administrator passwords that might have been used. If it's a three-year-old workstation, this might be a pretty significant number.

But let's suppose you do keep it updated. There are various password-cracking programs out there, and in some cases, local users can access the SAM database. If nothing else, they can boot to DOS and use a program called NTFSDos (freely downloadable) to read this database. Then, there are some nice programs out on the net that can be used to crack the SAM database's encryption and cheerfully extract any and all of the passwords in it. Including -- you guessed it -- your domain Administrator password. This is a bad thing.

While you may think this is a lot of work to go through, consider this. Windows XP is based on the same technology as Windows 2000, which uses a very similar scheme to Windows NT 4.0. I will give good odds we will soon see a virus that, upon breaking into a system, sends the SAM database somewhere, such as an E-mail address or an IRC channel. This is just a guess, but it would not surprise me in the slightest. So far, only Windows 95/98/ME have been targeted by most viruses, but as Windows 2000 starts to gain market share we are seeing viruses specifically targeted for it.

The best approach is to set the local Administrator password on all non-domain controllers to be a randomly generated sequence that is stored someplace secure. A sheet of paper in a fireproof safe, perhaps. That way, if it's needed, you can get at it, but you don't have to worry about somebody guessing it and thus compromising your network security. All they can do is compromise the machine they're on -- which they've already done to get as far as they have.

One important service to be aware of is IIS. It's often installed on systems, even those that don't need it. Unless you're actively serving web pages, whether internet or intranet, from the server, or plan to in the near future, uninstall IIS. It closes one major security hole that might be exploited.

Another set of items to be careful with include backup tapes and emergency recovery diskettes. Your backup tapes contain a full copy of your system, including the SAM database. It also contains all your files, as well; if someone wants to take your data, then your backup tapes provide them everything they need. An emergency recovery diskette also contains a copy of the SAM database. Store it in a secure location.