15.3 Avoiding Common Mistakes

Despite the best efforts of security administrators, there are still many common network security mistakes made. This is a top-10 list ^[2] of security mistakes commonly found on networks. Some are configuration mistakes while others are process mistakes. This list is by no means exclusive, but it is a good way to perform a quick evaluation of the security level of a network.

^[2] Despite our best efforts, we could not get David Letterman to run this list.

15.3.1 Bad Passwords

The number-one mistake found in a network environment is bad passwords. Bad passwords can be the result of a password policy that is too restrictive , or nonexistent. A password policy may be in place, but not enforced, rendering it useless.

In addition, this includes default passwords that are not changed. All default accounts on all network devices should be renamed , if possible, and the default password should be changed. If the account is not needed, it should be deleted, or the service should be disabled.

Even more grievous than default passwords are systems that are secured with no password. If a device does not require a password or some other form of security key to logon, it should not be part of an enterprise network.

NOTE

It bears repeating that a common source of "no password" network devices is the back door that administrators will often install on the network. Some terminal servers ship with no password set, allowing anyone who connects access into the network.

15.3.2 Failure to Create a Security Policy

One of the biggest mistakes made by corporations is the failure to create a solid, effective, and realistic security policy. Users and administrators are not going to know how to handle security issues unless it is communicated to them.

A security policy should be well documented and take into consideration not just security needs, but the needs of the business and the needs of the network users. If a policy is so restrictive that it prevents users from being able to do their jobs effectively, they will begin to find ways around it, and it will become useless.

Ineffective security policies also do not examine the entire network and can leave gaping holes easily exploited by attackers . Involve administrators and managers from all areas when devising a security policy and keep them informed of updates to that policy.

Keep users informed about security policies and explain to them the necessities for security restrictions in language that is clear and easy to understand. The more effective the communication of the policy is, the more likely network users will be to adhere to it.

15.3.3 Insecure Access to Devices

Too many devices in use on the network allow administrators to access them via Telnet, FTP, or some other form of access that is not encrypted. This is a mistake on the part of vendors and should not be perpetuated through an enterprise network.

All devices on the network, especially devices from the firewall out, should be accessed only through encrypted connections. If an encrypted connection is not available, demand one from the vendor, or switch to a new vendor.

NOTE

Remember, the vast majority of attacks occur in-house. Someone with a network sniffer can gather a lot of information about network topology very quickly. Don't further assist them by allowing them to gather password information as well.

15.3.4 Over- reliance on a Firewall

Firewalls are great. They can provide a lot of network protection, and can greatly increase the security of the network. However, firewalls should not be the only means of securing a network.

Too often, administrators rely on the firewall to completely protect a network, and a firewall is simply not able to do that. A firewall used in conjunction with solid security practices in other areas gives a network several layers of security and provides much better protection.

Over-reliance on a firewall can have especially disastrous results if the firewall rule set is not properly managed. It is not uncommon to start off with a firewall configuration that is especially restrictive and then add in rule sets as the need arises. If these changes are not carefully managed and filtered, an organization can wind up with a firewall that has so many holes that it is, essentially , useless.

15.3.5 Back Door Access

Administrators will often make secondary accounts, add a secondary network interface, or find some other way to give themselves a backup method of accessing a server or the network. There is nothing wrong with this as long as the method is properly documented and proper security precautions are taken.

Most of the time these access methods are neither documented nor properly tested for security holes. These access methods are put in place for convenience, but they may be creating huge security holes within the network.

After all, if back door access allows administrators to bypass security precautions, those same methods will allow an attacker to bypass the same security precautions.

15.3.6 Backups

Backups themselves are not a mistake, but many administrators do not take proper security precautions, and do not back up the correct information. This is especially true when it comes to networking equipment. Router and switch configurations are not backed up when they are initially deployed, or when changes are made. Firewall configurations are also frequently not backed up, or if they are, changes to the rule set are not backed up.

Backups should be done daily on servers and other machines considered critical to the network infrastructure. Router, firewall, and switch configurations should be backed up every time a change is made. In a dynamic network where changes are made frequently to these devices, backups should be performed every day, just as they are on the servers.

The part of backups where administrators are often very lapse is testing. Backups should be tested randomly to ensure that data is actually being backed up. There are two ways to do this:

1. Examine the log files for failures. If a backup failure is reported , the backup should be immediately rerun.

2. Spot restore. Attempt to restore files randomly ”to a test workstation to ensure the backups are working. It is possible that a backup server will report everything was successful, when the file is actually corrupted. Even worse , the medium (the tape or disk) can become corrupted, ruining all the data stored on it.

The worst time to find out there are problems with a backup system is when there has been a critical failure, and a restore is the only fix.

15.3.7 Not Updating Antivirus Software

Antivirus definitions have to be updated often. Virus definitions should be updated weekly, at a minimum ”more often if there appears to be a lot of virus activity. That may seem extreme, but remember when the Melissa virus was initially released it spread across three continents in less than 24 hours.

Consider running virus software from two separate vendors on your network as an added layer of security. One vendor should be used for mail and groupware servers where virus scanning is critical to prevent files from entering, or being propagated, through the network. A second vendor should be used for workstations, to catch any viruses introduced at the access level, and possibly catch any missed by the software on the servers.

15.3.8 Failure to Follow Through

After a security policy has been implemented, you must follow through. Security policies put in place should be adhered to and maintained by administrators, managers, and other network users.

If a user violates a security policy, appropriate action should be taken, and the human resources department should be willing to follow through with any punishment . If network users do not take security policies seriously they will become impossible to enforce, and render any network security ineffective at best.

There is a tendency among companies to get very excited about network security, and be very gung ho to implement tough security policies after a security incident has occurred. The excitement dies down several weeks later, and users relapse , returning to their old behavior patterns. This does not make for effective security, and should be discouraged.

15.3.9 Failing to Update Systems

Administrators are busy people with a lot of work that always seems to be piled up. There is never enough time to get caught up, and some things are forced to wait. Software patches are a prime example of something that is often put on the back burner , because a lot of testing may have to be done before the patch can be implemented.

That type of thinking cannot exist in a security-aware organization. Patches, especially patches that have security implications, should be tested and installed as soon as possible. After a security hole is made known, there will be attackers looking for systems to exploit. If an organization has not patched its system, that organization will be a likely target.

A time should be set aside each day to look for new security patches that apply to network devices within the network. A list of all potential security holes should be compiled and ranked in order of importance. After the list has been created, someone should devote one day a week to testing the patches, so they can be applied to the necessary systems.

Of course, if a patch is considered critical for good network security then it should take priority over other day-to-day tasks and be tested and installed immediately.

NOTE

In June 2002, a security hole was found in the Apache web server, leaving more than 60 million web users vulnerable to a theoretical attack. Within 48 hours, a worm was released that changed the theoretical attack to a very real possibility. Fortunately, the worm turned out to be a dud, and never spread. The Apache Software Foundation responded with a fix before the worm was released, but administrators who were not quick to update could have been at serious risk.

15.3.10 Unqualified Personnel

Effective security administration requires a lot of training. Not only does a security administrator need to understand security issues in great detail, he or she also has to have an extensive knowledge of different types of systems.

Security administrators frequently work with routers, servers, switches, firewalls, monitoring devices, intrusion detection systems, and many more devices. Because of this it is often hard to find qualified security personnel.

There is a temptation to use unqualified employees ”or employees who only understand some of the technologies ”and hope for the best. This is never a good idea. There is nothing wrong with having a new employee who is not familiar with all of the systems work with experienced employees to learn more, but the entire security staff should not consist of partially trained employees .