A Gaping Hole In Compliance Efforts
By Robert Gardos

LINK

Thanks to Sarbanes-Oxley and other compliance regulations, companies have gone to great lengths to ensure they're not breaking the law when it comes to information security and reporting.

But in spite of their best efforts, the vast majority of organizations have left a gaping hole in their compliance efforts by ignoring the database and database administrator (DBA).

At the heart of this issue is a very important question that many CIOs, CFOs and CEOs of large enterprises should be asking, but aren't: Who controls the data? If they were, they would realize that the person with the greatest unimpeded power over their data integrity is the administrative-level DBA.

Currently, most efforts to comply with Sarbanes-Oxley have concentrated on monitoring at the application level, leaving the database to be managed manually by individual DBAs.

Control of the database is a powerful thing. The disturbing rise in internal security breaches confirms the problem that even seemingly secure organizations have in controlling their database infrastructure. Case in point: the U.S. Air Force. This summer, the Air Force reported that a malicious user obtained access to an assignment and career database using a legitimate user's login.

The information contained in the database included the birth dates and Social Security numbers of nearly 33,000 high-ranking personnel. These types of intentional (or unintentional) breaches of security not only compromise an organization's strongest compliance efforts, but call into question the privacy and validity of all information tracked.

Lack of Control : How Did We Get Here?
The degree of an organization's vulnerability to rogue DBA activity or DBA errors is alarming, particularly as the penalty for non-compliance can mean jail time. The reality is that very few enterprises have installed software or hardware controls that monitor DBA activity, empowering the DBA to circumvent controls by connecting directly into the database. As a result, DBAs have the power to change, delete and alter data virtually unchecked.

Auditors and accountants can spend countless hours and precious resources ensuring the integrity of data and investigating potential rogue activity, but if the data is manipulated at the system level by people who have an inside understanding of the data model and an ability to modify the audit trail, reporting and validating methods become largely ineffectual.

Manipulation aside, what about common data entry mistakes that inevitably occur? And how do we differentiate between rogue activity and an honest mistake?
DBAs typically have direct access to the inner workings of an application's data repository and are tasked with keeping the motor running smoothly. When it comes to looking at data, changing data and even deleting data, they need a great degree of power and control to get their jobs done. That said, no employee within an organization should have such unfettered abilities to compromise data, especially in light of the following facts:

" The number of databases and amount of data tracked is growing. Fast. Database environments are getting more complex as the number of databases - and the amount of data within those databases - continue to increase. Moreover, the ongoing need to implement hundreds of different patch levels, as well as the introduction of new versions and security updates, are serving to tax DBA resources more than ever.

" The DBA is a high turnover position. Nearly half of all DBAs will leave their job within 24 months. Additionally, the DBA is one of the most difficult positions for an organization to replace.

" Enterprises are increasingly reliant on DBAs. The number of working DBAs has grown significantly faster than other IT-related jobs, jumping 10% from a year ago and 36% since 2001. The demand for database administrators is expected to continue with Labor Statistics projecting a 66% growth in jobs through 2010. This is a clear sign of how enterprises are becoming increasingly reliant on DBAs.

Increasing complexity, rotating bodies and inadequate auditing translates into more opportunities to compromise data security. It's not merely about conscious vindictive behavior. It's about the large number of reports that ultimately feed a company's final financial documentation - documentation upon which the careers of CFOs and CEOs are riding.

Database Automation: Plugging the Hole
But what options do we have to get a handle on both the growing data beast and its tamer? The one currently most favored within enterprises is to throw more bodies at the problem. Theoretically, if everyone serves as a watch-dog and monitors everyone else, legitimate and illegitimate mistakes can be identified and averted. Although this certainly helps mitigate this issue, it is an incredibly expensive approach that is still error-prone.

What the enterprise needs is a centralized, automated mechanism to track DBA behavior that is both manageable and irrefutable. When DBA and database monitoring is systematized and automated, data integrity can be reliably ensured even as the IT architecture grows in size and complexity. The good news is that databases are already capable of providing users with just the sort of information they need to ensure compliance and monitoring, so addressing this problem is simpler than most CIOs - or even DBAs - may realize.

What Should be Audited?
The degree to which an organization audits its database operations will vary, depending on the organization. At a minimum, anomalous behavior should be the first to be examined. Other items include data structure and configuration modifications, since changing schema could have dramatic effects on data collection.

To make the data useful, it must be filtered based on relevant rules that are put in place to handle the problem of information overload. Finally, this information must be tracked in a protected data store where transactions are signed to guarantee authenticity at the database system level, rather than the application level where many auditing tools reside.

Tools which are limited to guaranteeing authenticity at the application level are not tamper-proof and can be easily circumvented. By contrast, authenticity that is guaranteed at the database system level cannot be altered by even the highest-ranking DBA, thus providing the highest level of assurance and due diligence. This can be accomplished simply and without limiting the effectiveness or productivity of the DBA.

Enterprises need to understand that this threat to their compliance is real and present. Take for example one large pharmaceutical company that was given a mandate by its auditors to log all data model changes and delete activities on its more than 1,000 Oracle and SQL Server databases.

The company proceeded to create a Data Compliance database, aggregating application and database audit information onto a separate database. They believed reporting on this information would provide the necessary information and meet their compliance needs.

But the auditors rightly questioned the DBAs ability to manipulate the Data Compliance database, essentially asking, "who is watching the watcher?" Additionally, by simply aggregating information, the size of the new database made it slow and cumbersome.

By embracing a solution that could guarantee the tracking of transactions at the database level - as well as filter this information to prevent data overload - the company was able to comply with its auditor's request and get a better handle on its data integrity.

Ultimately, it comes down to the fact that organizations must have one reliable and automated source of truth at the database level to ensure compliance. Without it, businesses are betting their futures on the competence and integrity of every DBA they employ, which is at best overly optimistic and at worst negligent.

Remember one thing: though DBAs might have the power to compromise data security, the ones who will ultimately pay the price for non-compliance are the officers who employ them.

Sarbanes-Oxley Database Compliance
By Ron Ben Natan

Sarbanes-Oxley database compliance Over the last few years, numerous prominent and headline-grabbing accounting scandals have taken place in major corporations. As a result, the Sarbanes-Oxley Act (SOX) was designed in the hopes of reducing fraud and conflicts of interests, while increasing financial transparency and public confidence in the markets. SOX defines a framework that makes it harder for executives to claim that they were unaware if information is compromised. Under the act, companies must maintain proven auditing practices and assure integrity and timeliness of data.

While these stipulations might seem straightforward in theory, the reality is that they can be relatively difficult to meet. Most enterprises store financial records on relational database repositories. Access to these records is usually restricted to authorized personnel via corporate applications such ERP, CRM, and SCM. However, authorized staff may also use other clients, (e.g. Excel spreadsheets) to access or update financial records. An inadvertent mistake made to the records can be completely invisible to the financial and auditing teams responsible for attesting to the records' accuracy. A worse scenario is that of malicious activity perpetrated by a person who has the knowledge to bypass the perimeter firewall or who has local access (e.g., using telnet, direct console, or a developer/DBA tool) to critical financial databases.

Internal auditors facing these issues need application access visibility and effective controls to support compliance initiatives, because, in addition to monitoring and securing financial systems, SOX requirements necessitate comprehensive tracking and management of systems that handle critical corporate data. The bottom line is that while SOX compliance is primarily the responsibility of the CEO and CFO, the CIO and other IT professionals also need to implement strategies that support the explicit and implied integrity, security, credibility, and transparency requirements defined in this act.

Sections 302, 404, and 409 in particular affect IT organizations, requiring:

Internal control
Ongoing assessment (i.e., governance, measurement, and record keeping)
Disclosure (i.e., investigation, reporting, and certification)
These requirements embody logical best practices. Even so, they can be difficult to follow, in particular since the technology available until now has generally not been adequate to meet rising compliance needs. Traditional database audit limitations The task of constant manual database auditing and compliance is impractical and sometimes even impossible. Continuous, real time visibility to database access activities is difficult for security personnel to achieve because few products offer granular monitoring capabilities that provide an understanding of the who, what, when, where, and how of all database access activities.

Most database administrators are reluctant to turn on database logging facilities because of the resulting impact on performance and disc space. Even if they do turn various logging and auditing facilities, the data generated requires a tedious data reduction effort. This endeavor is like the proverbial search for a needle in a haystack - just imagine looking through three months of logs in support of a quarterly statement. Additionally, anyone with access to these database logs could potentially change records and remove any audit trail of this activity, perpetrating the intrusive event.

Database auditing requirements To accelerate your database compliance, as well as to safeguard your databases, you need a solution that provides a means for comprehensive database activity visibility. In addition, the solution must have advanced reporting, alerting, access control, and auditing features. These capabilities help establish an environment of accountability as required by sections 302, 404, and 409 of SOX act ensuring that you can:
Achieve ongoing security health assessment
Maintain privacy through internal controls
Prove claims
Implement full disclosure when needed
To discover and document existing organizational policies, the solution selected should be able to automate a process of report production that covers such topics as planning and organizing for database compliance, certification and control of database activities, risk assessment, and investigation and disclosure of any exceptions. Having access to report templates that were built to address SOX implementations creates an ideal situation, since such templates do not require a great deal of setup but still have the flexibility to be customized to company needs.

All database requests must be able to be logged and a full audit trail should be easily and automatically extractable from this information. This audit trail needs to contain such information as which data was accessed, by whom, when, how, and from where. The exportable information can be maintained for as many years as necessary and submitted to the proper authorities as required. Automated scheduling of SOX workflows and audit tasks and dissemination of relevant information to responsible parties across your organization are also great time savers, helping to increase audit process efficiency.

When potential anomalies arise, the response must be instantaneous. Automatic alerts and access control help you handle situations in a timely and responsible manner. Database access protection needs can be met if there is flexibility in the type of alerts generated by the solution: real time, threshold-triggered, or policy-based. If an alert is triggered, you should be able to immediately ensure that all relevant parties are notified and block any further suspicious activities, in particular to sensitive data (such as social security or credit card numbers).

Other applications that are useful for SOX database compliance include a means for mapping access between financial applications database clients and servers and a detailed view of financial database access activities with continuous real time snapshots. These options provide an easy means for ongoing assessment of database access health, again increasing the atmosphere of accountability as required by SOX. Example: Guardium's SOX Accelerator Guardium has simplified the task of continual auditing and compliance by developing the SOX Accelerator for Database Compliance. Tailored to address financial system monitoring of an organization, the SOX Accelerator report templates can be customized to directly reflect specific organizational and regulatory requirements. These templates are divided into specific categories to help increase visibility into database activities while simplifying discovery of issues that need a closer look:
Plan and Organize View information about who and what touches financial information, which financial servers and databases are available, and more - to help with the planning phase of SOX database compliance.
Certify and Control Certify that all database access activities are above-board and that those that fall outside of SOX required parameters can either be rectified or explored further.
Assess Risk Receive information that can be used to gauge possible risks, with emphasis on those areas referred to in the database requirements of SOX.
Investigate and Disclose Dig deeper into any possible exceptions to discover the origin of any exceptions as well as whether or not they are issues that warrant further handling.
Other tools help to audit database activities, with the resulting data saved into an easily downloadable format:
Financial Applications Access Map Easily view access between financial applications database clients and servers using advanced visualization technology. This graphical map provides an at-a-glance view of activities by access type, content, and frequency.