Some employees are held to a higher standard of behaviour than most. Anyone in a position with broad powers or influence falls into this group, including accountants, managers, systems administrators -- and information security professionals.
Like systems administrators, information security professionals generally have access to a great deal of data and information. Even if they don't have direct access, they generally know how to obtain it by exploiting a weakness (like hackers, but with the opposite intent) or by simply giving themselves elevated privileges.
In our small shop, the systems administrators, helpdesk workers and security people all have a great deal of access.Some issues arose recently that caused me to go back to some best practices regarding access. One is called separation of duties, and the other is called the principle of least privilege.
Raising the bar
It all started when a co-worker told me he suspected that one of my staffers was snooping around on employee computers. Over the past year, I had heard similar complaints from various managers, but the staffers who had been the cause of those earlier concerns are no longer employed here, and I thought that it was a dead issue.
However, I had failed to change processes so that such an issue couldn't arise again, and if you set low standards, some people who don't personally have high standards will drop down to the lowest common denominator. It was time to raise the standards and change some processes so that the potential for abuse would be minimized.
While much attention in the world of information security is given to technology, the most overlooked security risk is the level of access that systems and security people have on the network.
In the IT world, you have to have gurus running around who can not only fix a network problem, but also troubleshoot issues that crop up with operating systems, databases or the application layer. The gurus have godlike status on the network, and that status demands integrity on their part. You have to be able to trust the people you open your network to. Once trust is lost, it's game over.
An audit trail is one way of finding out when trust is lost. There should also be an acceptable-use policy for systems administrators that's published and enforced. Violations of the policy should be punishable by termination.
With a small team, addressing separation of duties is a challenge. The purpose of separation of duties is to make sure that no single person can control a transaction or process from beginning to end. That's a beautiful thing in the banking world. It's not so hot in the IT world, where it's very difficult to achieve pure separation of duties.
Ideally, you want to make sure that the person who troubleshoots the desktop systems doesn't have the same privileges as the person who manages the servers, the switches, the routers or the firewalls. In most cases, it isn't feasible unless you have a very large staff among whom you can divvy up the myriad duties.
Turning to separation of duties, I first addressed our use of the administrator account. Before, staffers had permission to log into a server or to remotely administer a desktop using the administrator log-in.
Now, each person must use his own account with administrative privileges. This doesn't change the level of privileges held by each staffer, but it does create an audit trail that specifically names the person who owns the account used, rather than providing a generic log-in name.
Second, the senior systems administrator reset the administrator password, wrote it down, locked it up and gave a key to only one other person. On pain of termination, the password is not to be given out. Of course, this could be a problem if any system accounts were running under the administrator account, since each of those accounts would have to have its password reset as well. It's a poor practice to bring up operating system services under an administrator account, but it happens all the time. A better practice is to always create special system accounts with appropriate permissions for particular applications and services.
Next, I told my staffers that they need permission from the end user before making a remote connection to a desktop system. In fact, the end user must call the helpdesk and specifically request assistance. After the user's request is made, the sysadmin must say to the end user something like, "I'd like to log into your desktop remotely to see if I can troubleshoot the problem for you. Is now a good time?" The exchange between administrator and end user must be documented in the helpdesk ticket. While this may not be a foolproof method for ensuring that administrators don't abuse their privileges, it carries a message to them and creates an audit trail.
The second best practice I set out to address is the principle of least privilege. Administrators should have the least amount of privilege possible to get the job done. The log-in and password to the firewall should not be the same as those for the routers, the switches, any of the servers, the database, and on and on.
I once performed a security assessment for a large company that had acquired a smaller one. My job was to assess the security of the acquisition before the network connections were made. The network manager's easily crackable log-in/password combination was the one and only log-in/password to everything in the enterprise, including the firewall.
In my current job, things aren't that bad, but we're working to make sure they're as good as possible.
This journal is written by a security manager whose real name and employer have been disguised for obvious reasons