Sarbanes-Oxley (SOX) IT controls address the integrity of databases that store sensitive financial and business information. In particular, new SOX requirements have shifted the focus from merely understanding who has access to information to continuous monitoring of database activity. These requirements target high risk database activities:
- Privileged user behavior
- Direct access to sensitive data stores
- User privilege escalation
- Failed login
- Failed database operations
- And more
Finally, while database applications like DB2, Oracle, SQL Server, and Sybase rightly
attract most of the attention, the problem invariably extends to other sensitive data stores—file server-resident financial, legal, strategic, and spreadsheet documents being the foremost examples.
SOX Section 404 demands that companies
- evaluate the adequacy of internal controls as they relate to financial reporting
- institute new controls as necessary, and
- perform and reportan assessment of these controls on an annual basis.
In short, Section 404 says, "Management must ensure that appropriate internal controls for financial
reporting are in place."
Furthermore, Section 404 requires not only that corporate and IT officers immediately put in
place internal controls to protect the integrity of financial data (and, by implication, all systems that access that data), but also that the organization must be able to demonstrate that appropriate controls are in place.
At first glance it is quite obvious that the full access credentials accorded to DBAs and system administrators creates a significant vulnerability for an enterprise’s data simply because these privileged users have access to all or a significant fraction of your data.
The problem with this approach is that it is of critical importance for DBAs to have access to database log facilities, so curtailing their privileges effectively curtails their productivity and makes their job more difficult.
This is precisely the challenge that enterprises are facing with the SOX section 404 mandate to monitor the activity, particularly database activity, of their DBAs and other privileged users. The problem arises because it makes no sense to monitor a DBA with full privileges by using the log facilities within the database applications, because their privileges will allow them to cover their tracks by deleting or otherwise altering the logs.
So many enterprises are resorting to curtailing their DBAs’ privileges to prevent them from having any access to the log facilities. The problem with this approach is that DBAs use the database log facilities as a debug tool in order to do their job, so curtailing their privileges effectively curtails their productivity and makes their job more difficult.
Corporate officers, IT auditors, and database administrators find a variety of challenges in the requirement to audit all privileged user activity, which typically ranges over a variety of platforms, applications, and data stores. This page provides detailed analysis of a number of the issues associated with privileged user monitoring.
From a data administrator’s viewpoint, SOX-related monitoring requirements are quite broad, but they can be distilled under five key headings:
Monitoring database access by privileged users—DBAs and system administrators, for example
As the title of this paper implies, privileged user monitoring is the primary objective of most SOX database auditing projects. Additional requirements generally relate to specific activities initiated by privileged users or, potentially, users masquerading as privileged users for malicious purposes.
Enterprises must audit all activity by administrators and other privileged userIDs, and, perhaps more importantly, must be able to retrieve, examine, analyze, and report on this piece of the audit trail.
Enterprises working to comply with this requirement have found that in practice it can be difficult to implement due to a variety of problems:
- The very users they are monitoring typically have full administrator credentials and can cover their tracks by modifying or deleting the logs being used to monitor them.
- Privileged user credentials can be restricted to prevent log access, but this results in lowered productivity or creates an adversarial relationship with unhappy DBAs.
- Many enterprises employ databases from several different database vendors, which require individual expertise on each database’s log capabilities and makes log consolidation into useful reports a near impossibility.
Monitoring changes in privileges
Not all users utilize privileged credentials all the time. Many times users will use privileged credentials on an as needed basis to perform specific tasks. It is imperative to track when these privilege escalation events occur and maintain and regularly view reports of this activity in order to verify the legitimacy of these events.
In order to attest to the integrity of sensitive data, it is imperative to know what is happening in the user community.
Have new users been defined, or an existing user de-provisioned? Have a user’s privileges been escalated or revoked? A complete database activity auditing solution will provide the necessary visibility in to these types of transactions without requiring auditors to search through seemingly endless database log files.
Monitoring access failures
Enterprises must know when login attempts fail, and also when data access attempts are unsuccessful. Failed access events are an indication that something is not right. Application data access attempts, in particular, should never fail.
There are various definitions of invalid logical access attempts. These two are most common:
• unsuccessful attempt to access a resource
• invalid or failed login
An effective database activity monitoring solution must be capable of capturing both classes of failed access operation.
Monitoring schema changes
To ensure data integrity, you must be able to track changes to compliance-related data structures. Monitoring, logging, and reporting on data structure changes not only permits you to satisfy routine auditing requirements, but also to identify anomalous, unscheduled activity.
Monitoring direct data access
Another common requirement is to track any direct access to sensitive system and data tables. Since direct access operations are uncommon in procedural applications, it is important to capture an audit trail of such activities. Alternative tracking techniques, including triggers and local agents, are expensive and do not scale.
Furthermore, a complete database activity auditing solution will capture the necessary detail in the audit trail to not only show that a direct SQL event occurred, but also who initiated the event (what user ID), what source IP address originated the event, and precisely what content was affected by the event (database, tables, columns, and rows).
Additional Key SOX Activity Auditing Challenges
Database managers, auditors, and security officers bear the burden of satisfying regulatory and internal audit demands for SOX compliance. Numerous trouble spots persist, in addition to privileged user monitoring. Key challenges include:
• Consistent monitoring across all databases –Large enterprises often deploy database products from multiple vendors—DB2, Oracle, SQL Server, Sybase, and so on. Until recently, monitoring access activity across varied databases in a consistent, comprehensive, and normalized way has been effectively impossible. Failed response codes, for example, differ from one product toanother, or even from version to version.
• Inadequate database logs, resulting in non-compliance –Both native logging (database and/or server) and log consolidation tools—ignoring their well-documented performance penalties—invariably fall short of SOX auditing requirements. These solutions yield paradoxical results: both log data overload and defacto non-compliance, the
worst of all worlds.
• Inadequate data management and reporting –SOX compliance includes the demonstrable, repeatable ability to reconstruct event flows by finding and extracting one or more critical events from the current or archived audit trail.
Writing filtering tools for this purpose is very difficult. Furthermore, identifying the key events is just the first of many tasks, which may include storing such events for rapid on-line examination (typically for 60-90 days), generating scheduled reports for auditors and other stakeholders, supporting audit trail search operations, and certifying audit log security.
• Inadequate analytics and alerting –The spirit of SOX adherence also includes identifying and tracking access events that signal potential fraud or other data misuse. For example, it may be necessary to detect and alert on outlier events such as N-time failed logins, large return sets, or statistically rare data access operations. Alerts may
also require integration with other security event management tools. Today’s database tools lack the analytics to support a meaningful alert detection and response system.
• Segregation of duties requirement –A special challenge arises when collecting and maintaining audit trail and report data on privileged users (DBAs, for example)—data that is typically stored on systems managed by these same privileged users. Native database logging and agent-based solutions exhibit this deficiency, which stands in direct violation of both SOX and common sense. The segregation of duties standard dictates that privileged user monitoring data be stored outside the control of the user or users being monitored.
