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?
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
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
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
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.
people come and go, but old security plans never die.
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,
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
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
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
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
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
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
20 Security Logs Aren’t
Need I say more?
21 Weak Attempts at
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...