Sarbanes Oxley and UNIX Privileged Access

Sarbanes-Oxley section 404 is summarized as follows:

Issuers are required to publish information in their annual reports concerning the scope and adequacy of the internal control structure and procedures for financial reporting. This statement shall also assess the effectiveness of such internal controls and procedures. The registered accounting firm shall, in the same report, attest to and report on the assessment on the effectiveness of the internal control structure and procedures for financial reporting.

How this translates into UNIX privileged access is a topic of much confusion. After researching, there are several decent resources out there that help to clarify:

From a white paper, Controlling Privileged Accounts by Fox Technologies (manufacturer of Keon/BoKS):

For a SOX audit, it is no longer sufficient to say you trust your administrators; you must have controls in place to convince your auditors that no administrator, trustworthy or not, is able to abuse the authority granted.

Organizations struggling to resolve these issues often end up evaluating three different alternatives:

1. Create home-grown solutions based on Operating System capabilities, available utilities such as “sudo”, clever password management procedures, and lots of scripts. Except for in very small organizations, these attempts will either become extremely costly with system administrators programming instead of doing their jobs. This approach is often found insufficient from an auditor’s perspective. Even if home-grown solutions achieve an acceptable level with regard to password management, they fail to provide corresponding auditing capabilities.

2. Combine various commercial or open source point-solutions, to create an operating environment that takes many of these requirements into account. This typically involves using one solution for user provisioning, another for centrally managed secure communications (SSH), a third for password management or other types of root account management, a fourth for keystroke logging, and yet another tool for audit log consolidation. This could actually amount to something quite powerful in the end, yet one important aspect by necessity is lost: centralized management on one security system. Combining multiple technical solutions into one leaves conceptual gaps which in turn leads to security flaws and inefficient management. All things considered, this is not a cost-efficient approach although, ironically, cost-awareness may well be the primary driver for organizations exploring this option.

3. Invest in an Enterprise Access Management solution (EAM). These solutions are everything but lightweight and in reality there are only a couple of vendors offering full-blown EAM solutions. This third alternative is actually what analysts Jay Heiser and Ant Allan have recommended for larger organizations. “Gartner advocates use of an enterprise access management product for large and complex organizations that can derive benefit from having an external access control system for multiple Unix targets. Although these products do address the control of superuser privileges, they do much more beside and, consequently, are more expensive and more complex to install than the Unix-focused tools.” (Controlling Unix Superuser Privileges Is Critical, Gartner Research G00130427, August 31, 2005).

It is not difficult to see the rationale for the Gartner recommendation: Alternative 1 and 2 do not provide a complete solution. Yet, apart from the fact that EAM packages are “more expensive and more complex to install” and to operate, they may also fail to deliver all necessary components.

From a different paper, Delegating Root Authority and Auditing Activities on UNIX/Linux Systems:

Most native operating systems in the UNIX and Linux world, generally regardless of vendor, fail to meet the required levels of accountability required for Sarbanes-Oxley compliance, though SELinux goes some way toward correcting these deficiencies. The simplest administrative tasks require users to have access to the root account, which has no granularity of control in the native environment, leading to an abstract picture of which users have had access to and have modified data.
...
Section 404 is especially important to IT managers, because
companies must have begun to comply by 15 November 2004,
and must be able to verify the following for their CEOs and
CFOs to sign off on their annual assessment:
• Access controls surrounding financial data
• Data encryption
• Authorization to access and modify systems
• Systemwide intrusion monitoring
• Intrusion response
• Indelible auditing

There's another paper out there that discusses Sarbanes Oxley and UNIX at large: Unix and Sarbanes-Oxley: a management and auditors guide. It doesn't go into much depth on the specific issues addressed above, but discusses some items .

Symark (manufacturer of PowerKeeper) has several papers that seem to be potentially interesting (free registration required), although some of it seems to be more marketing-focused:

• Meeting the Access Security Requirements of Sec 404 of the Sarbanes-Oxley Act in a Heterogeneous UNIX/Linux Environment
• Guide to Creating a Secure Access Control Environment
• Passing UNIX/Linux Audits and Meeting Regulatory Compliance
  

On a related note, Gartner has published some good research on this topic with their paper Toolkit: Password Management Tools for Shared Accounts and Service Accounts. This paper is not free; I believe it is available for purchase.

- John