10 Common IT Security Blunders (and How To Avoid Them)

While IT managers are trained early on to avoid obvious threats, many still fail to watch out for the basics. From password issues to excessive auditing to not using Group Policy, here's a list of 10 things to make sure your shop is taking care of.

By Brien Posey 05/01/2012

No matter how hard we fight, cyber threats are ever on the rise. Microsoft and the federal government are stepping up their war on organizations driving botnets. This is part of the problem. One of the biggest threats comes from within and failure to prepare for those battles is asking for trouble.

Even if you think your shop is doing all it can to avoid common security threats, you'd probably be surprised at how easily an outsider can find common -- even silly -- mistakes.

IT pros are overworked. It's only natural that even a top dog makes the occasional blunder. Over the years I've found many oversights in otherwise tightly secure organizations.

Here are some of the more common security mistakes I've run into.

1. Using Default Passwords

IT pros have long been told to use secure passwords and change them regularly. This idea seems to go out the window when it comes to network appliances. I've lost count of the number of times I've run into network appliances in production environments using default passwords.

Default passwords are a huge risk simply because they allow appliances to be easily compromised. This is especially true for network access points, but also applies to firewall appliances, intrusion-detection appliances and just about any other type of hardware appliance.

2. Setting up Weak Passwords

A few years ago, a neighbor asked me to set up his wireless network. When it came time to enter the passphrase, I left the room and let him enter the phrase in private. Although I told my friend to use a strong passphrase, I had a hunch he'd use the name of his favorite sports team.

Later that night I connected to his wireless network from my house and after two or three tries was able to guess his passphrase. Once connected, I attached to his network printer and printed a message that his network was insecure and to call me when he was ready to fix it.

The point is that wireless passphrases are vulnerable to the same types of attacks as insecure passwords. Therefore, you should make a point of using strong wireless passphrases or at the very least avoiding those that others can guess.

3. Central Administrator Accounts

I used to work in a place where the entire administrative staff shared a single generic Administrator account. We had a disgruntled employee on the staff and she was constantly doing things to sabotage the network. Our audit logs showed her various actions as being performed by Administrator. Needless to say, a generic audit log entry wasn't enough for disciplinary action.

The IT manager was reluctant to create individual Administrator accounts, fearing multiple administrative accounts would increase the chances of a security breach. This meant the disgruntled administrator was able to continue with her shenanigans for quite some time.

Ever since, I've recommended to clients that they create two separate accounts for each member of the administrative staff. Both of these accounts should be personally identifiable. One account should lack administrative privileges and be used for all day-to-day activities. The other account should contain administrative privileges, but should only be used for administrative actions. Using this technique lowers the risk of a security breach, while ensuring that any administrative actions can be tracked back to the administrator who performed the action.

4. Failing to Utilize Group Policy Security

I recently read an article in which the author cautioned administrators to use Group Policy settings sparingly. It made the case that the more Group Policy settings are enabled, the longer the login process takes.

While I'm all for expediting the login process, I recommend taking full advantage of Group Policy security settings. Group Policy settings are the primary mechanism for ensuring the computers on your network adhere to your corporate security policy. Furthermore, if you need to make a change to your security, it's a lot more practical to modify a Group Policy setting than it is to try to update each computer individually.

5. Not Making Use of Local Security Policies

Although Group Policies are important, it's also important to make use of local security policies. Local security policies are often overlooked because they exist at the lowest level of the Group Policy hierarchy. It's usually considered a better practice to implement policy settings at a higher level, such as at the domain or Organizational Unit (OU) level of the Group Policy hierarchy. Even so, using local security policies is important.

This is the case because higher-level Group Policy settings only apply once a user logs in to a domain. If someone happens to log in to a workstation using a local account, then none of the higher-level Group Policy settings will be applied. The workstation's only defense at that point is the local security policies.

I'll be the first to admit that if someone logs into a workstation with a local account, then they can disable the individual elements within the local security policy. However, that only becomes a concern if the person who's logging in has malicious intent. There are plenty of perfectly legitimate reasons why someone might need to log into a workstation using a local account (such as to perform a repair or system maintenance). In these types of situations, the local security policy helps provide basic security.

6. Forgetting About Certificate Expiration's

I have to confess this is one bonehead move I'm personally guilty of. Recently I took a couple weeks off and went to South America to do some extreme caving and scuba diving. While I was gone I left my smartphone turned off. When I got back to the United States, I turned my phone on, but couldn't get any e-mail.

I assumed my server must have crashed, or that my power or Internet connection was out. Living in the sticks, I lose Internet and electricity all the time, so I didn't panic.

When I finally got to my house 12 hours later, I found everything on my network functioning perfectly. While going through the troubleshooting process, I found the digital certificate for my Exchange Server had expired. The certificate was valid for five years, and just happened to expire while I was on vacation. Now I'm in the habit of documenting certificate expiration dates and setting up automated reminders to renew certificates before they expire.

7. Excessive Auditing

I took my first Windows certification class back in the '90s, and will never forget the lesson on event auditing. I was utterly amazed by the granularity with which events could be audited. At the same time, I was bewildered as to why enabling auditing was a manual process. I asked why Microsoft didn't enable all the auditing mechanisms by default. The instructor's response holds just as true today as it did back then. 

Auditing every possible event is a bad idea for a couple of reasons. First, excessive auditing can degrade a server's performance. CPU and disk resources are consumed by the auditing process, but when auditing is performed in moderation the resource consumption is no big deal. However, when you audit an excessive number of events, the auditing process can have a noticeable impact on the server's performance.

A more important reason for auditing in moderation is that, when you audit an excessive number of events, the event logs can quickly become huge. When this happens, it's nearly impossible to pinpoint the events you're truly interested in. Important security alerts blend in with all of the meaningless events that have been logged. That being the case, you should only log the events that are most relevant and would provide the most useful forensic information if an attack should occur.

8. Writing Down Passwords

When I first started working in IT, I lost count of the people who told me you should never, ever write down a password. In many ways this rule makes sense. After all, if you write down passwords there's a chance those passwords could find their way into the wrong hands. But I think the idea of never writing down passwords is incredibly shortsighted.

I agree user account passwords that are used on a day-to-day basis should not be written down. After all, these types of passwords expire on a regular basis and are easy enough to reset. However, there are other passwords that tend to be a bit more permanent and are used much less frequently.

One example is my wireless router password. I probably haven't logged into my router's Web interface in at least a year. I'm not even positive I remember the password correctly. That's why I have the router's password written down and locked in a safe with the rest of my network documentation. That way, if a problem ever does occur, I don't have to worry about trying to remember an obscure password that I haven't used in a while.

I recommend writing down semi-permanent and rarely used passwords. Of course, this is assuming you have a way to adequately protect the paper containing the passwords.

9. Ineffective Service Account Maintenance

In a Windows Server environment, system services are associated with a security account. Services can't start unless the service account is successfully authenticated. Most services make use of the Local System Account, but some services (such as the ones used by SharePoint 2010) require actual user accounts. In these types of situations, there are two mistakes that are commonly made.

One common mistake is creating an all-purpose service account. This is a mistake because service accounts are almost always assigned special permissions. These permissions allow the corresponding service to perform its intended tasks. When a single account is assigned to multiple services, the service account might begin to accumulate permissions that are far beyond those required to perform any one, single task. These excess permissions could allow an attacker to exploit a service to gain control of the system.

The other common blunder related to service accounts is that administrators often require service account passwords to be changed on a regular basis. There's nothing wrong with resetting service account passwords, but you won't typically receive a reminder that the account is about to expire, and you'll have to update the service itself to use the new password. This usually means shutting down the service for a moment.

Service accounts can be a favorite target for hackers because they tend to use static passwords and might have permissions that exceed those of even an administrator (service accounts are typically able to act as a part of the OS, while admins are not). As such, it's a good idea to dedicate each service account to one specific service and give your service accounts names that disguise their true purposes. I recommend giving your service accounts names that blend in with your user accounts. For example, you might name a service account JSmith.

10. Failing to Have an Incident Response Plan

By far the most serious -- and yet one of the most common -- security blunders is not having an incident response plan. Imagine you walked into the office tomorrow and found you've been hacked. What do you do?

If you had to stop and think about it, you just demonstrated my point. It's important to develop a formalized incident response plan before a security breach occurs, so you and your staff will know exactly what to do. Initial actions you might take include disconnecting network cables, reviewing audit logs, verifying the integrity of your data and rebuilding affected servers.

The appropriate response will vary from one organization to the next, and it's critically important to come up with a security incident response plan that fits your organization's needs.