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. We can man the castellation with the finest archers. But all will be for naught when 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, he'll 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 is critical that passwords are protected to the maximum extent possible. To accomplish this on an enterprise wide basis requires the establishment of 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. One that I might suggest is probably no better.

To be as unpredictable as possible it should be one devised within the enterprise and should be malleable, changing its characteristics from time to time. There are, however, some considerations that can be listed that can provide some food for thought in the process of devising a policy.

One size does not fit all.

Users of the system fall into a variety of categories ranging from a guest to a system administrator. 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. It might even be non-existent. This would not be sufficient for a system administrator! While a little extreme, this does illustrate the point.

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, except that one or two may 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, Back-up Operators, etc. There is no sense in re-inventing the wheel! Users and Guests round out the categories list.

Page 2: continued...