A Password Policy Primer
A weak password policy can undermine your IT department's efforts to secure the systems that host your critical data. Vince Barnes examines ways you can keep intruders from slipping past your network's defenses and offers tips on creating easy-to-remember, yet tough-to-crack passwords.
We can build our fortress with towering fifty-foot high, four-foot thick walls. We can build a moat thirty feet wide to surround those walls. And we can even man the castellation with the finest archers. But all will be for naught if the enemy crosses the drawbridge in the guise of one of our fellows and gives a good password to the gatekeeper.
Not knowing any better, our gatekeeper will surely open the gate and allow the enemy in. Once inside, the enemy wait until our guard is down, then open the gate himself to allow his cohorts in, and all we keep inside will be lost in no time.
Colorful as this analogy is, how close is it in fact to the truth of our situation? Are we really that vulnerable? The answer is yes, I'm afraid we are. If our enemy, a hacker or a corporate spy, comes to our system with a recognizable user name and armed with the corresponding password, our only remaining protection will be our internal vigilance mechanisms, which, especially on larger systems, are liable to be less than adequate to reliably detect the intruder.
Being thus the weakest chink in our armor, it's critical that passwords are protected to the maximum extent possible. Accomplishing this on an enterprise-wide basis requires establishing a sound password maintenance policy. To create a policy of this sort requires some careful consideration and planning. If the policy is hurriedly thrown together, it will almost certainly be weaker than is desirable.
In general, passwords must be unpredictable, and the policy that protects them should be as unpredictable as possible. This being so, your friend's policy is probably not the one you want for yourself, and thus one that I might suggest is probably no better.
To be as unpredictable as possible, it should be a policy devised within the enterprise and should be malleable, changing its characteristics from time to time. There are, however, some considerations that can provide some food for thought in the process of devising an effective policy.
One Size Does Not Fit All
Users of the system fall into a variety of categories ranging from guests to system administrators. The policies for these users will not all be the same. A guest password may be public and static, for instance. The guest would be so limited in the scope of their capabilities that such a password might be adequate for the need. For that matter, it might even be non-existent. Of course, the same would not be sufficient for a system administrator!
The following categorization illustrates a possible grouping. The top-level passwords, that is, the built-in system administrator (or root) passwords, should be known to as few personnel as possible, although limiting it to just one or two people might not be the best of ideas. For contingency reasons, three or four may be the best minimum number.
In my own little organization, four people hold this key — two of whom are actually well-trusted outsiders. The next level, or category, is the group of people who are system administrators, that is, whose user IDs have administrator privileges. This group can be further sub-divided into the built-in groups within Windows, such as Enterprise Admins, Domain Admins, etc. The number and scope of these sub-divisions will depend on the size and complexity of your organization and what makes sense for it.
Operators make up the next category. This category comprises the built-in operator groups such as Print Operators, Backup Operators, etc. There is no sense in re-inventing the wheel! Users and Guests round out the categories list.