Network Audit and Password Policies

Network security is always a popular subject, and even= more so every time the latest and greatest virus is released. Sometimes network administrators though forget that security includes a foundation designed to minimize risk, to be able to identify potential problems before they occur,= and to be able to document what happened should a security breech actually occu= r. To that end, this time around we’ll discuss a couple of aspects of a solid network security foundation; audit policies and password policies.

Audit Policies

A key component of managing security on a Windows netw= ork is an audit policy. Auditing allows an administrator to view an event log and identify security related events that have happened. The information in a l= og entry includes the time and date, the user account the event occurred under= if relevant, the computer it originated from, the event ID, the source and typ= e of event, and a description of the event. This information can be extremely helpful in troubleshooting problems, both those caused by legitimate use of= the network and those caused from someone trying to get into things they shouldn’t.

As an example, consider a user who is attempting to di= al into the network from home, and is just getting a vague error message that there is a problem with their login and they are disconnected. If you have auditing of logon events enabled, you could view the security log and get m= ore detailed information. There you might find that the account hasn’t be= en given permissions to dial into the network (a common mistake when new users= are setup), or you might find that they entered their password wrong too many t= imes and locked their account out, etc. This information enables you to quickly resolve the problem, without having to resort to trial and error.

Another example of the effectiveness of audit policies= would be in proactively identifying a “curious” employee who decides = to browse the network to see what all is out there. By auditing failed attempt= s at file and object access, you could quickly identify a pattern of behavior if someone was doing something like that, whi= ch is fairly common on large corporate networks.

Enabling auditing on an NT-based network depends on wh= ich server OS you are running. On Windows NT 4.0 and earlier domains, you use t= he User Manager for Domains administrative tool to enable auditing. Once you op= en it, click the Policies menu then select Audit. You then have = the option of enabling auditing of successes or failures (or both) of the follo= wing:

Logon and Logoff=

File and Object Acces= s

Use of User Rights

User and Group Manage= ment

Security Policy Chang= es

Restart, Shutdown, an= d System

Process Tracking=

Initially, many administrators simply enable auditing = of everything, thinking that gives them the best amount of information. One important thing to consider, however, is information overload and what is t= ruly important. If you enable auditing of everything, you’ll find yourself wading through lots of junk in the security log, and it will be much more difficult to find the kind of events you really need to view. That is especially true if you enable process tracking, which will create events constantly. It is recommended therefore that you only enable auditing of processes if you have a specific need to do so. That typically involves a scenario of a developer testing applications.

As we mentioned, you have to consider what information= is truly important. Do you really need a log entry every time a user successfu= lly logs onto the network? Or, every time they successfully access their home directory (use of user rights, file and object access)? Most likely you won’t have a need for that type of information. However, it can be extremely important to know about the failures of those types of things bec= ause they could indicate a potential problem for you to address. For the average network we recommend the following settings:

<= ![endif]>

For Windows 2000/.NET Active Directory domains, the pr= ocess of getting to the account policies for the domain is different. You open Active Directory Users and Computers, then right click on the domain and selec= t Properties. When the property sheet opens, select the Group Policy tab and then click edit to edit the Default Domain Policy. Expand the C= omputer Configuration container, then Windows Settings, Security Settings, L= ocal Policies, Audit Policy. Initially all of the events are set to “n= ot defined.” You then double-click the type of event and select the chec= kbox to define these policy settings, then enable or disable. The dialog looks like such:

<= ![endif]>

Password Policies

Another key component to network security is a good pa= ssword policy, something which causes a lot of frustration in the life of a network administrator. Users tend to hate password policies because it forces them = to periodically change their passwords. They fight against them by doing things such as writing passwords down, saying they can’t remember them otherwise. This often turns into somewhat of a political battle in companie= s, so insist that adherence to a password policy be included in the terms of u= se your company requires employees to sign as part of their new employee packe= t.

A password policy actually consists of five components= . They are:

Password Age – how many days before the u= ser is required to change their password

Minimum Password Age – how long must a us= er wait after changing their password before they can change it again

Minimum password length/Password complexity = 211; prevents users from using short or easily cracked passwords

Password Uniqueness – How many passwords = will be remembered, prevents users from alternating between a couple of passwords

Account Lockout – how many failed login attempts can occur before the account is locked

A good password policy should incorporate all of the a= bove elements. For the average network, you should expire all passwords every 60-90 days. If your security requirements are higher th= an normal, make the duration shorter. It is important to note that administrat= ors need to subject themselves to these policies as well! We’ve seen many administrators enforce password policies on users only to set their own passwords to never expire. This is even worse because a hacked administrator account can do much more damage on the network than a regular user account.=

The minimum password age is used to prevent users from overcoming the password uniqueness setting. A good setting for password uniqueness is 10, which means 10 passwords will be remembered. If you allow= the user to change their passwords immediately, they can simply keep changing t= he password until they can get back to their original one. Not all users will = go through the trouble, but inevitably you’ll have some that will. A good setting for minimum password age is three days.

Minimum password length (NT/Win2K/.NET) and complexity requirements (Win2K/.NET only) are used to combat would-be hackers who use dictionary and brute force style attacks to try to crack passwords. In the former method the hacker runs through a large dictionary of words, hoping t= hat the user selected a common word for their password. In the second method the hacker use= s a program that attempts all combinations of letters, numbers, and special characters in an attempt to crack the password. This brute force method is = made more difficult if you have long passwords that are a mix of letters and num= bers and special characters.

Account lockout is the final piece, and is a good frie= nd of the network administrator. This allows you to set a number of failed passwo= rd attempts that can occur over a 30-minute period of time before the account = will be locked. Once the account is locked you can choose to have it unlock by itself after a period of time, or remain locked until an administrator manu= ally unlocks it. I prefer the latter just so I easily know whenever a lockout ev= ent occurs (the user typically calls saying they can’t login).

Password policies are configured in the same places as= audit policies. In NT4, you use User Manager for Domains and select the Policies menu then Account. In Win2K, follow the steps above that you did to = get to Audit Policies, except choose Account Policies as the last step.

Questions or Comments? Will can be reached at WWillis@Transcender.com