Access in a compliance world

By on
Access in a compliance world

Regulatory pressures continue to shape the demand for "more security" in IT operations. Sarbanes-Oxley is being implemented with a fair bit of grumbling, but it has caused many organizations to strengthen their security posture. CIOs who were previously stymied in their efforts to implement security programs can now wave the "Sarbanes-Oxley flag" to justify their IT investments.

These pressures are also forcing organizations to more closely examine who has access to sensitive data. This examination has lead to an increasingly common challenge for many organizations — how do I grant administrators just the right amount of access to do their job, while complying with regulatory mandates.

Auditing has never been the sexy part of security, and many commercial products still do not have good auditing options for basic user actions, let alone the ability to audit highly privileged users. That is changing. Commercial products are beginning to support an audit administrator role separate from the database administrator (DBA), who decides what to audit and whom.

Even customers who "vet" their highly privileged users through extensive background checks would like to minimize their risk by clearly separating the ability to manage a database from the ability to administer an application. The need has continued to grow as customers move to more data consolidation. If customers felt slightly uncomfortable with giving a single individual the ability to access data in a single sensitive database application, they feel less comfortable as the data from multiple such databases is consolidated into a single database for data warehousing, or better information sharing across organizational boundaries.

Absent a clear, customizable separation of function, earlier approaches to this issue have largely been focused on data encryption to protect selected sensitive data from administrators. Of course, the tricky bit in encryption is managing the encryption keys, and ensuring that those who need data access also have key access: thus, keys must be hidden from highly privileged administrators yet accessible to users of data. Data encryption has moved from "roll your own" to becoming an innate feature of commercial databases, so data is encrypted within the database itself, transparent to the application.

At least privileged users, who have historically held an undue responsibility, can now breathe a sigh of relief as a result of the compliance restrictions placed on them. Sarbanes-Oxley may have caused much weeping, but it may yet turn out to be "The DBA Full Employment Act." DBAs, rejoice.

30 SECONDS ON...

Data overload?

Companies are beginning to collect far more audit data in the course of regulatory compliance and are looking for solutions to manage the data, says Mary Ann Davidson, chief security officer, Oracle.

Wish list

The wish list, she says, includes the collection of multiple audit logs in a single tamper-resistant repository, the ability to set and manage audit policies and the business intelligence "smarts" to mine the data.

In particular

As customers in the defense and homeland security sectors move from "need to know" to "need to share," they are deciding that "need to know" applies even more strongly to highly privileged administrators, says Davidson.

Additional support

Davidson adds that having a separate person to manage the keys, or support for hardware modules so that keys cannot be accessed by the administrator, all add more robustness to database encryption.

Copyright © SC Magazine, US edition
Tags:

Most Read Articles

Log In

Username:
Password:
|  Forgot your password?