Networking

SolutionBase: Protect your network from your IT department

Keeping your network safe is the job of the IT department. However, for mid-size to large companies, a disgruntled IT professional could wreak havoc on your systems. Use these tips to thwart such an attack.

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.

Editor's Picks

Free Newsletters, In your Inbox