I've had a lot of people ask me recently, "what do I need to do with root in a SOX world?". It's a good question. Sarbanes Oxley (SOX) places a large focus on logical access to systems. This really means that only people who are authorized to access systems are able to access them. Root runs counter to the spirit of SOX.
With most modern UNIX-based systems, there can be only one root. On some, it is possible to create additional uid 0 accounts, but this is a somewhat unwieldy way to operate.
The core of the issue is that ample logical access controls dictate that you know who exactly has access to a system, and be able to verify who made a particular change to a system. For small companies with only one or two administrators, this is not a big problem. It can be argued that the potential source of any misuse is very limited . For most larger companies with more that one or two admins, root access becomes a big issue. Potentially any one of the administrators was the source of a change, with no good way to verify who it was.
There are a few ways to handle this problem to provide adequate access controls:
Sudo – sudo is an application that allows the delegation of tasks that require root (or elevated) privileges to run. If it is reasonable to delegate most of the routine tasks, granting permission through sudo, which will provide auditable logging of who executed commands or made a certain change. It is impossible to eliminate the need to root access altogether, so placing root passwords in an escrow that requires some form of approval to retrieve and a mechanism to change the password immediately afterward should provide a workable solution to control access to root.
The use of authentication tools like Vinetella or Powerbroker. Both applications allow you to leverage Active Directory to control access to your UNIX-based systems, gaining the benefits of AD’s account and password management, while also being able to assign elevated permissions on an account by account basis. Again, escrowing the root password is a necessity in these environments.
Here are the things you need to consider about logical access and root accounts:
The process by which someone is granted elevated or root privileges, with documented evidence.
Password security for UNIX accounts (length, inclusion of special characters and expiration)
Ability to differentiate between administrators who are working on a system and making changes.
A change management process that you can line up changes and/or login in & application execution records against.
Ensuring that system logs are maintained as evidence of control effectiveness.
A process by which elevated permissions are revoked upon termination or transfer with documented evidence.
If you keep the above goals in mind, you will be able to find many different ways to meet the needs of SOX with respect to root access control. I would certainly recommend running this or any new process that you create to address SOX needs to your external and/or internal auditors to gain consensus that the approach meets the specific objectives of your company’s controls.
Print