——————————————————————————————————————-

The infamous stealing of government network access in California this summer naturally resulted in a plethora of “I told you so’s,” and “our solution will help” and various renditions of “the sky is falling.” Like many other security professionals, I was concerned about the possibility of this happening across most public and private organizations—possibly resulting in my missing a pay check.

When these events happen, it’s important to put them in perspective. For example, what is the risk of IT personnel doing the “wrong thing” when terminated, angered, or just bored? I was surprised by one possible answer to this question, provided in the form of survey results from Cyber-Ark.

A staggering 88 percent of IT administrators admitted they would take corporate secrets, if they were suddenly made redundant. The target information included CEO passwords, customer database, research and development plans, financial reports, M&A plans and the company’s list of privileged passwords. The research also revealed that, of that 88 percent, a third would take the privilege password list to gain access to valuable documents such as financial reports, accounts, salaries and other privileged information.

[…]

The survey also found that one third of IT staff admitted to snooping around the network, looking at highly confidential information, such as salary details and people’s personal e-mails.

Source: stealing of government network access in California, Computerworld, 28 August 2008

Even if these numbers don’t accurately reflect attitudes of IT professionals world-wide, business and security managers need to take a closer look at network administrator management processes just because it’s the right thing to do.

The following are some thoughts I have about practices limiting IT personnel access to network resources:

1. In the spirit of least privilege, restrict network administrators to only those resources they actually manage. For example, many organizations divide network admin tasks among two or more teams. A help desk might manage account creation and group memberships. A LAN/WAN team might implement and control switches, routers, etc. Server engineers may only be responsible for keeping servers running and optimized. No one in any of these groups needs complete access to all network resources. Design access controls to limit resource use to only what is absolutely necessary to perform job tasks. As with other sensitive company resources, segregation of duties applies.
2. It’s a fallacy that everyone in IS—or at least all the techies—need to know the domain administrator passwords or be members of all domain admin groups. Each admin access request must be vetted to ensure access is needed to perform one or more daily tasks. Further, access to the enterprise domain admin account—for example, the administrator account at the root of an Active Directory implementation—should be tightly controlled. Even administrators granted access to these all-powerful accounts should have to “check them out” when needed, with the check outs logged. Use of a password repository, like eDMZ’s Password Auto Repository, can help. Further, key personnel (read more than one) should have access to configure and manage the repository. Logging/alerting should make it difficult, if not impossible, to make PAR repository changes without at least two people knowing about them. Finally, you can configure some repository solutions to automatically change critical passwords each time they’re used.
3. Daily checks of additions to admin-level groups should be facilitated by security or other analysts responsible for access control oversight. For example, we have a script that runs each night, which compares an authorized list of admin accounts to members of AD admin groups. If a user account is found in an admin-level group, and it isn’t in the authorized list, it is removed from the group and an email sent to security. We occasionally find that one of our users with administrator access “forgot” to follow the process for adding an account.
4. Every administrative activity on the network—and I mean every activity—should be logged. Logging isn’t just a good idea when looking at ways to identify intruders. It’s also a good way to validate that IT personnel are following policy-guided processes. Log management doesn’t have to be a boulder chained to internal staff. Managed security service providers, like CentraComm Communications, provide excellent log aggregation, correlation, and alerting services. Regardless of who actually reviews the logs, make sure expected security and control outcomes expected from reviews are clearly defined. The person reviewing the logs should clearly understand what constitutes anomalous behavior and what it looks like in individual or aggregated log data. The OWASP provides an excellent list of log review guidelines.
5. When a member of an IT team is terminated, or quits voluntarily with attitude, he or she should be immediately escorted to his or her desk to collect personal items, security badges and keys. At the same time, an account administrator should be disabling appropriate resource accounts. Under no circumstances should the now former employee be allowed access to any information resources from the time he or she is terminated to the time he or she is escorted to the door.

I’m sure you can think of additional ways to protect network resources from disgruntled IS administrators. However, these are practices I believe every organization should practice at some level—yes, even SMBs.