Get Ready for Your Audit

Time spent with network security auditors pointed out to Roberta the most common weaknesses in companies. How does yours stack up to her list?

• By Roberta Bragg
• March 01, 2002

Good, basic security practices are well known but rarely followed. This is not an anecdotal assumption on my part. This winter I’ve been working with information system auditors as they audit networks and systems just like yours.

1 Control Freaks
From an auditor’s perspective, it’s all in the evaluation of controls. Controls, or policies and practices that protect a company’s assets, are critical. Good controls prevent or expose both fraud and accidental loss. Weak controls don’t. The auditor’s job consists of understanding what strong controls are, comparing this universally agreed upon knowledge to the information system at hand, and recommending the replacement of weak or non-existent controls with strong ones. The exercise of sound security practices is one of implementing strong controls.

In visiting companies, both small and large, the auditors and I have found with frightening frequency that even the basic, most obvious security practices aren’t being followed. Obviously, in spite of numerous books; hysterical diatribes; and calm, reasoned approaches to computer security, the message isn’t getting through. So this month, instead of explaining the esoteric, updating you on new technology, harping on some new vulnerability or otherwise adding to the list of things you gotta do to secure your network, I’ll share with you the most common weaknesses auditors are finding. Lack of attention to these controls can undermine any sophisticated security practice. Take a minute to see how your systems would score on this auditor’s report card. I’ll let you decide whether the results warrant celebration or some back-to-basics security work on your systems.

2 Grade Yourself—But Be Honest
Here are the most common problems we found. Not all problems—just the top 20. Give yourself five points for each problem you can honestly say I wouldn’t find if I came to your site. I’d be very interested in hearing your results.

3 Default Account Policy on Domain Controllers
No one’s changed the account policy since day one. This means, as you know, passwords may be blank, kept forever, changed immediately to the same thing and guessed at all day long. A strong account policy protects information systems in three ways.

First, requiring complex passwords; (passfilt registry modification in Windows NT, group policy entry in Windows 2000 and user training); long passwords (walk the line between the maximum number of characters that good security requires vs. what the average user can handle); frequent password changes (the most-agreed-upon standard is 30 days); minimum time before a password can be changed again (most-agreed-upon is at least eight days); and storing a password history (most-agreed-upon standard is 11) requires a user to think about the construction of his or her password, change it frequently and avoids the most common user tricks (like cycling through password changes to return to a comfortable password.)

Second, setting account lockout prevents the casual interloper from sitting at a console and attempting to guess another user’s password unfettered. Disagreement abounds on whether you should require account lockout to be reset administratively or allow it to automatically reset after some number of minutes and whether this could result in a denial of service attack. However, the fact remains that setting account lockout, especially coupled with auditing, can prevent simple password-guessing attacks and bring them to your attention.

Third, having an account policy provides you with a teaching tool for instructing every user on the proper access policies of your site. You’ve probably heard by now that the worst security vulnerability in any system is people. Here’s your chance to mitigate that vulnerability. Simply setting a strong account policy and insisting on its use won’t get user buy-in. Users will still seek ways around the policy, fight for its removal, write down passwords, share them with friends and create passwords that can quickly be cracked by publicly available, free tools. Instead, every employee needs to know the rationale behind the policy and how it benefits him (i.e. “If someone breaks into our systems, you may not have a job, your identity could be stolen, your address and vacation plans broadcast to thieves and malcontents,” and so on.) Instead of complaining about user stupidity, realize that it’s not stupidity, but ignorance—and educate them. Imagine if you could convince the general public not to use fake IDs. Oh well, at least you can have influence on your own user community, yes?

4 Default Account Policy on Servers and Workstations
While these machines may be domain members and logon using domain accounts is required, there’s still a default Administrator account on the box. See problem No. 1 for issues.

5 Weak Account Controls
An example we often found was the requirement to change the password every 30 days without requiring a history of password use. Users were given no training or explanation to go along with the policy and simply made their new password their old one. At other sites, password history was required, but no minimum time between password changes was required. Users simply cycle immediately through multiple password changes to return to their favorite.

6 Use of the Administrator Account by Multiple ‘Administrators’
If everyone uses the default Administrator account to perform administrative duties, does that get the job done and limit exposure? No. While multiple user accounts with administrative privileges does require you to monitor the usage of more than one account, the use of one account by many administrators prevents you from assigning any accountability for their actions. Since an administrator is all-powerful, this doesn’t make sense. Auditors want to know who changed the account policy, took ownership of financial files, gave users extended rights like “Act as part of the operating system” and so on. So should you. Come on, allowing even “trusted” individuals free range with no accountability is just asking for trouble. I’d even go so far as to allow no one the use of the Administrator account. Instead, I’d give everyone who needs administrative privileges their own account and reserve the Administrator account for emergencies. That way I’ve assured accountability. Use, or attempted use, of the Administrator account would then ring alarm bells instead of being expected activity on my network.

7Use of Administrative-Level Accounts to Perform Ordinary Functions
One final administrative thing: Each user with administrative privileges should have a separate account that she uses to exercise those privileges. No administrator should use his or her Administrator account to, say, read e-mail. (Imagine the result of accidentally running a Trojan horse program that performs nasty changes only an administrative-level person can do. If a normal user activates it, little happens; one with Administrative privileges? Game over.)

8 Large Numbers of Administrators
If all users with administrative privileges must be identified in the Administrators or Domain Admins group, you’ll see how many administrators there are. Auditors will question the existence of too many administrators. While there’s no hard and fast rule about the number really required, it’s pretty easy to suspect abuse if a large percentage (30 percent? 50 percent? 100 percent?) of your users have membership in this group. Incidentally, I caution auditors to investigate this issue and not jump to rash judgments. I’m well aware that some applications are difficult, if not impossible, to run if your account doesn’t have administrative privileges. However, a user doesn’t need membership in the Domain Admins group to run them on his workstation. Place the user’s domain account in the workstation Local Administrators group for this purpose. Better yet, audit application use to discover which registry keys and files the user needs Full Control of and grant them that access, instead of granting Administrator group membership.

9 Local User Accounts on Servers and Workstations
Servers and workstations rarely need local user accounts. Of course, the two default accounts, Administrator and Guest, will exist; appropriate control of these accounts should be exercised. But a quick audit of servers and workstations looking for other user accounts is wise. Why do these accounts exist? Who controls them? How often are passwords changed? How strong are the passwords? If the account appears to have a legitimate reason for existence, is there another way the task at hand can be accomplished? Local accounts can leave the system exposed, as they are rarely managed and often forgotten. Many have weak or non-existent passwords. The domain account policy doesn’t apply to local user accounts.

10 A Large Percentage of User Accounts that Have Never Been Used
One of the easiest things to fix, yet one of the most-often-found abuses, is the existence of multiple accounts that have never been used to log on. At several sites this fall, we found 30 percent to 40 percent of user accounts fell into this category. Each account that exists, but isn’t used, exposes the system. These accounts, once compromised, might be used to further attack the system or gain access to confidential data. Worse, some of these accounts may have membership in privileged groups or directly assigned access to sensitive resources. Where did they come from? In most cases they represent user accounts set up for employees that never came to work, left before logging on, didn’t require computer access or were assigned other accounts when they did. Obviously someone didn’t communicate well with IT, but that doesn’t excuse you from periodically examining account lists and deleting unused accounts.

11 A Large Percentage of User Accounts that Haven’t been Used in More than Three Months
Another glaring, easily fixed hole is the existence of user accounts that haven’t been used in several months. Because few folks receive multiple months of vacation time, we probably would be correct in assuming these accounts belong to users who have left the company. Are these accounts disabled? They should be, at the very least, because they represent more risk than accounts that have never been used. They might belong to disgruntled former employees and, unlike unused accounts, their existence, password and power of privilege and access are well known by at least one person. A good policy to follow when employees leave is to immediately identify their account, change the password and remove it from group memberships. Retain the account until you’ve verified you no longer need it for an audit trail, then remove it from the system. In addition, if the user had administrative privileges, a good practice is for every administrator to immediately change passwords and the passwords of any service accounts and local Administrator accounts.

12 Groups with No Members
In addition to unused user accounts, we often find groups with no members. I’m not referring to the Power Users or other default groups that have no members, as they have no use on a particular machine. I’m talking about global groups and local groups created and then never used. If these groups have been given privileges and/or resource access rights, they could easily be abused. When you have thousands of users and groups to manage, some are bound to escape attention. Why burden yourself with excess baggage?

13 Use of the Administrator or Other User-Assigned Administrative-Level Account as the Logon Account for a Service

We often found the Administrator account or other assigned account used as the logon account for a service. By assigned account, I mean one that’s used by a person to log on. Service accounts that require accounts other than the local system account for logon should always have accounts created especially for them. What frequently happens, though, is that the administrator installing an application that uses special services receives a request during installation to provide a user account for the service to use. Because the administrator doesn’t know better, he allows the default choice (the account installing the program) to be used. This is dangerous on two fronts. First, because both the application and the user need to use the account to log on, when the user logs off, the service may be stopped. Second, service accounts are often granted special privileges such as “act as part of the operating system” or “log on as a batch job.” These are privileges that can be abused and used to compromise the system. No user account should be assigned these privileges.

14 Poor Understanding and Use of Resource Access Controls
Some of the issues here are demonstrated by the activities that follow, but the underlying cause is in the lack of understanding. Oh, administrators know the difference between Read and Execute, but many fail to truly understand the subtleties that different types of permission sets imply. What’s more, they fail to realize the critical nature of this most basic of security defenses. They miss the objective, which is to provide limited access to resources. Instead of using these as the final defense against intrusion, malfeasance and destruction, they concentrate on simply providing access to those who ask.

15 Assignment of Resource Access to Accounts, not Groups
Long ago you learned (I hope) the acronym AGLP—place user Accounts in Global groups, global groups in Local groups, and give local groups Permissions and privileges. This is the correct way to assign privileges and grant resource access. Imagine my horror, as I visit countless Windows shops, when I find that many of you work directly with user accounts instead. Maybe it’s not your fault; maybe it got started that way and it would be difficult to rearrange this miasma. But think what you’re doing, man! When someone leaves the company, how do you ever figure out how to remove their access and privileges? How do you know you’ve succeeded? When someone joins the company, how do you know where to give them access? Furthermore, don’t you realize how bloated the DACLs on files and folders have become? If 100 accounts payable clerks need access to a file, you have a DACL with 100 entries. If all these users were members of a group, the DACL might contain one entry. Which one is harder to control and takes more time to process? Poor group management practices are time consuming, unreliable, unmanageable and create vulnerabilities.

16 Assignment of Privileges to Accounts, not Groups
See above.

17 Failure to Properly Use Security Programs and Devices
How many of you boast firewalls, intrusion-detection devices and sophisticated security management programs? In our audits we found that many organizations have these and rely on them to determine security for their enterprise. In many shops, these products are poorly understood. Often there was a lack of training on their configuration and maintenance and a lack of knowledge of their limitations. When their operation was outside of the realm of network and system administrators, these individuals were rarely advised on how the products were used. There seemed to be a sort of “don’t ask, don’t tell” mentality about them. While I agree that knowledge of a firewall’s configuration should be “need-to-know,” I believe people charged with configuring system security need to know how they can support what is, after all, only perimeter defense.

18 Failure to Have a Security Maintenance Plan
Things change, people come and go, but old security plans never die. We found that not only did organizations believe in the adage “If it ain’t broken into, don’t fix it,” they supported their beliefs by never once examining configuration settings, subscribing to security bulletins, reading log files or having patch maintenance plans.

19 Auditing Isn’t Turned On
Oh, this really gets an auditor’s ire stoked. How, they’ll ask you, do you know what’s going on with your system and how will you determine who did what?

20 Security Logs Aren’t Reviewed
Need I say more?

21 Weak Attempts at Establishing Controls
Maybe somebody got charged up about security this year. Maybe management declared, “You will have a password policy.” Maybe it was even implemented—for a time. One company implemented the simplest of policies. It said that passwords had to be changed every 60 days and they had to be at least three characters in length. During our audit we found no such requirements in place. “We tried that and it didn’t work,” they said. It turns out they’d just changed the settings and gave no warning, gave no instruction. All of a sudden, users had to change passwords. The company was in an uproar. Work wasn’t done. Management intervened. The policy was removed.

22 Failure to Physically Secure Laptop Computers, Data Centers or Server Rooms
As if the lack of attention to the basics above isn’t proof positive, let me tell you a final nonsensical tale. While inspecting a site for physical security issues, we found that only the internal auditing staff had locks for their laptops. Network hubs, routers and switches were contained in locked closets shared with telco access points. Obviously all laptops needed to be secured, and we recommended moving data system infrastructure from telephone facilities that needed to be accessed by external maintenance people. Keypad locks on doors, however, protected the data center and we had to be escorted through not one, but four, before reaching the racks. But wait: A trickle of people passed down the interior wall of the rack room and entered a door at the back. They were followed by another, larger group. By the time I reached the door, there was a real hubbub going on inside. Upon entering the datacenter, I found it was a break room with snack and pop machines, tables, chairs—even a microwave. It turns out several hundred non-datacenter workers had the codes necessary to enter through locked doors. Reason? It was the only break room on the floor.

I hope I don’t have to spell out what’s wrong with this picture.

There are organizations that mostly do security right. There are others, like that last one, that don’t have a clue.

What grade would I give your organization if I visited there tomorrow? You’d better check your security practices, because I just might...