The suggestions presented here are part of TechRepublic’s Quick Guide: Lock Down Your IT Department. This valuable reference offers insights into the critical security concerns facing today’s IT pro, from conducting risk analysis and controlling data access to using tools, technologies, and user policies to guard against internal threats.

Mention the word security
in an IT context, and the first thought may be of protecting information assets
from plagues of virus threats and malware. But during a TechRepublic roundtable
discussion, a panel of IT pros repeatedly expressed a different security concern:
How do you protect an organization from its own IT staff? Controlling the
damage that could be caused by a disgruntled or an incompetent tech is a serious
challenge. Here are a few measures you can take to help make sure that an IT
staff member doesn’t trash your network or compromise your data.

#1: Control access to data

An obvious way to curtail the power held by IT staff members
is to limit their access to data. One approach is to implement application-level
security. For instance, let’s say that a company wants to make sure that its IT
staff can’t directly access or manipulate the payroll database. To achieve this
degree of protection, it could encrypt the database and allow only the members
of the human resources staff to access it once the application development and
testing were complete. The developers’ accounts would be deleted to ensure
access was truly limited to HR personnel, and only the CFO would be authorized
to grant access to the application. The CFO’s username and password would be
stored in a safe in case of emergency.

#2: Limit scope of domain

You can also restrict the power of your IT staff by splitting
the network into multiple domains, allowing an individual to be administrator only
in certain domains. Under Windows NT, splitting a network into multiple domains
pretty much guaranteed that an administrator in one domain couldn’t take any
action in another without being granted explicit permission. But in Windows
2000 Server and Windows Server 2003, domains exist in a common forest, and a
transitive trust exists between them. So even if you create multiple domains,
Domain A will automatically trust an administrator from Domain B. The administrator
from Domain B won’t 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. One way to get around this problem is to implement multiple forests
within your organization. This greatly increases the complexity of network design
and maintenance, 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 won’t be transitive.

#3: Control access to logs

Another security measure is to enable auditing but to set
limits on who can view and clear the audit logs. For example, network
administrators might be denied access to the security event logs, with only security
staff given access to them. Without administrator credentials, the security
team would be unable to create backdoor accounts. The network administrators would
be able to create accounts, but they wouldn’t be able to cover their tracks by
clearing audit log entries.

Since administrators have access to the security logs by
default, this approach requires modifying the group policy for the domain. Just
open the Default Domain Security Policy console and go to Windows Settings |
Security Settings | Local Policies | User Rights Assignment to access the
Manage Auditing and Security Log option. Enable the Managing Auditing And Security
Log group policy element and assign access only to your security team.

#4: Generate alert triggers

Limiting event logs access is a good start, but if an admin
does create a backdoor account, you have to rely on your security team to spot
a suspicious log entry. To make the system more foolproof, it would be handy if
you could generate an e-mail alert if an administrative account is created. Unfortunately,
although you can control what types of events are audited, there is no
corresponding alert mechanism. Furthermore, the auditing feature doesn’t differentiate
between the creation of an account with administrative access and a basic user
account, increasing the likelihood that the security team won’t notice or be
concerned about the corresponding log entry.

One third-party solution that does a good job of alerting
you to potential security breaches is GFI’s
LANguard Network Security Scanner
. Using LANguard, you can scan the network
to see which shares, accounts, permissions, etc., exist. After you verify that
the current settings are valid, you can create a schedule for future scans.
After a scan runs, LANguard can compare the results against the results of the
previous scan and look for discrepancies. If a new administrative account or
network share has been created, the product can send you an alert via e-mail.