About ten years ago, I was working as a network
administrator for a large insurance company. One day, I got a phone call from a
company looking for a Windows expert who was willing to write about an emerging
technology called Windows 95 (wow I feel old). The money was good and I liked the
idea of working with cutting-edge software, so I gave my boss a letter of
resignation. Although I was parting with the company on good terms, I was fired
on the spot because letting me continue to work there was considered a security
risk.

My dismissal seemed like a joke. My boss gave me a check
that was the equivalent to two weeks pay and then had one of our company’s
rent-a-cops watch me clean out my desk and escort me from the building. I got
home, called my travel agent, and about a week later my former boss was very
upset when he received a post card from the Bahamas in which I thanked him for
the time off. Oh, sweet revenge!

My boss’s actions were widely considered excessive and
unnecessary. Most systems at the time had little security. The company was
running Windows 3.1 at the desktop and Novell NetWare 3.x on the servers, so for
my boss to suddenly become concerned with security seemed absurd. However, in
retrospect, my former boss was ahead of his time. Today, controlling the damage
that could be caused by a disgruntled or an incompetent IT staff member is a
very real concern. The real question is, What can you
do to make sure that a member of the IT staff doesn’t trash your network or use
data for a purpose that wasn’t intended? In the sections below, I’ll make
several suggestions.

Limit access to data

One way that you can limit the power held by IT staff
members is to limit their access to data. There are several ways of doing this,
but one method that is making a comeback is application-level security.

To illustrate how application-level security works, I’ll use
as an example a Web site that I used to own. This particular site was an e-commerce
site that I hosted with an ISP. The main problem that I had was that the site
collected lots of sensitive information, such as customer’s contact information
and credit card numbers. Although my ISP took the appropriate steps to prevent
users of the Internet from gaining direct access to the site’s back-end
database, the ISP’s employees had full access to the database because it
resided on their own server. Although the company hosting the site is owned by
a trusted friend, I still wanted to make sure that if he ever hired additional
employees, they would not be able to steal credit card numbers from my Web
site.

My solution was to use application-level security. The
people at the ISP still had full access to my database, but the information
within the database was encrypted. I used a proprietary encryption technique
that I developed myself to ensure that the database’s records could not be easily
decrypted through an off-the-shelf hacker tool.

If someone needed access to the information found in the
database, they would have to access the information through my Web application,
which required authentication. The application had its own authentication
mechanism with user account names and passwords also stored in encrypted format
within the database.

The idea of using application-level security to prevent
administrators from accessing data is not an idea that I came up with on my own,
though. The insurance company that I mentioned during my introduction used
application-level security all those years ago. The company wanted to make sure
that the IT staff could not directly access or manipulate the company’s payroll
database. Therefore, the database was encrypted, and only members of the Human
Resources staff were given access once the initial development and testing of
the application was complete. The company’s CFO was on hand to witness the
deletion of the developer’s accounts. Likewise, only the CFO was authorized to
grant access to the application, although the CFO’s username and password were
stored in a safe in case of emergency.

Limit scope of domain

Another way in which you can limit the power of the IT staff
is to split the network into multiple domains. In doing so, you can limit
administrative power. Just because someone is an administrator in one domain
doesn’t mean that he or she has to be an administrator in another domain. If
you work for a midsize to large company, the network is probably already
divided into multiple domains. Smaller companies may also benefit from enhanced
security by dividing the network into multiple domains.

In the days of Windows NT, splitting a network into multiple
domains pretty much guaranteed that an administrator in one domain could not
take any action in another domain unless they had been specifically granted
permission to do so. In Windows 2000 Server and in Windows Server 2003, though,
this just isn’t the case.

As you probably know, both Windows 2000 and Windows 2003 are
based on the Active Directory, in which all domains exist in a common forest.
The problem is that there is a transitive trust between all domains in the
entire forest. This means that even if you create multiple domains, Domain A
will automatically trust an administrator from Domain B. That doesn’t
necessarily mean that the administrator from Domain B will be able to modify
Domain A, unless the administrator in Domain B happens to be a member of the
Enterprise Admins group. Even so, the simple fact that transitive trusts exist
between domains can be a little unsettling. After all, if you manage a domain,
why should you automatically trust someone from another domain?

One way of getting around this problem is to implement
multiple forests within your organization. Setting up multiple forests greatly
increases the complexity involved in designing and maintaining the network, but
it also increases security. You can configure a trust relationship between a
domain in one forest and a domain in another forest, but the trust will not be
transitive.

Access to logs

Another way that you can limit the power of IT staff members
is to enable auditing, but also set limits as to who can view and/or clear the
audit logs. At one of the places where I used to work, for example, it was
policy that the network administrator was not to have access to the security
event logs. Only the people in charge of security were given access to the
logs. Since the security team did not have administrator credentials, they were
not able to create back-door accounts. Likewise, the network administrators had
the ability to create accounts, but they could not cover their tracks by
clearing audit-log entries. The idea was that if someone on the IT staff was up
to no good, their deeds would be discovered by an independent security team.

Of course, by default administrators have access to the
security logs. To change this, you have to modify the group policy for the
domain. If you open the Default Domain Security Policy console, you will find a
setting called Manage Auditing And Security Log at
Windows Settings | Security Settings | Local Policies | User Rights Assignment.
The Managing Auditing And Security Log group policy
element isn’t enabled by default, but you can enable it and assign access only
to your security team.

Alert triggers

Limiting those who can access the event logs is a good
start, but if one of your administrators does create a back-door account, you
still have to hope that one of the members of your security team notices a
suspicious log entry. Why not help the security team out by automatically
generating an e-mail alert if an administrative account is created?

Unfortunately, this is one area where Microsoft has really
dropped the ball. While you can control what types of events are audited, there
is no corresponding alert mechanism. Furthermore, the auditing feature does not
differentiate between the creation of an account with administrative access and
a basic user account. Therefore, if a back-door administrative account is
created, the security team may not even notice the corresponding log entry.
Even if the security team does notice the log entry, if they are feeling lazy,
they might just assume that a normal account has been created.

I recommend getting around this problem through the use of
third-party software. One tool that I think does a particularly good job of
alerting you about potential security breaches is GFI’s LANguard Network Security Scanner.

Unfortunately, when someone creates a new administrative
account, you aren’t going to be instantaneously notified that
an account was created. I honestly don’t know of any security programs for
Windows that work in this way. Instead, you would use LANguard to scan the
network and see which shares, accounts, permissions, etc. exist. After taking a
long look at all of the current settings to make sure that they are valid, you
can create a schedule for future scans. After a scheduled scan runs, LANguard
can compare the results against the results of the previous scan and look for
discrepancies. If a new administrative account has been created or if a new
network share has been created, the product can send you an alert via e-mail.

I like LANguard as a supplemental security product for other
reasons, too. It can be used to deploy security patches and to search your
network for known vulnerabilities, unused accounts, insufficient audit
policies, and other types of suspicious configurations

Watch the watchers

It has been said that power corrupts and that absolute power
corrupts absolutely. If this is true, then it is very important to limit how
much power your IT staff really has. While it is important for your IT staff to
have full access to the systems that they must support, no one person should
have full access to everything, unless it’s a small company with only one or
two IT staff members.