What’s Going on Here?
- AOL Customer List Stolen, Sold to Spammer
- Acxiom Database Hacked Again
- IRS Computers Vulnerable, Report Says
- Offshore Outsourcing Poses Privacy Perils
to protect us. We may be spending continuous streams of cold, hard cash on security, so aren’t we justified in feeling that our databases are reasonably safe?
Apparently there’s a hole in the security cheese that’s difficult to fill.
The Hole in the Cheese
security. But it turns out that the biggest threat to our databases doesn’t generally come from that direction.
break-ins would in fact be one of the biggest piracy threats, especially considering the high value of our data to competitors and others. So we definitely need to be spending big to protect
against potential unknown intruders.
contractors, and so forth.
How Big is the Risk?
losing customer confidence when a data loss becomes known. Focusing on security and data privacy is certainly a good practice for all these reasons and more.
regulations in this area, such as HIPAA, FERPA, Sarbanes-Oxley, Gramm-Leach-Bliley, and California SB 1386.
do. They apply to virtually every organization having databases: universities, health providers, financial institutions, and businesses of every sort.
so big on everyone’s radar screen these days.
mechanisms such as passwords, smart cards or biometrics, and access controls such as rights lists, group memberships and so forth.
Benefits of Conventional Safeguards
complex or nested access controls may occasionally challenge this). They’re highly auditable. And they just plain work well. When an outsider doesn’t have a valid username and password, he can’t
log in. When a customer service representative isn’t authorized to see payroll data, he won’t. And when an accounting clerk has been authorized to update accounts payable records, the bills get
Limitations of Conventional Safeguards
door key; or just find a window to climb through.
sensitive data from a remote location after hours, through a VPN connection. Someone in the IT organization may be using a privileged username, intended for data backups, to steal sensitive data.
Going beyond Conventional Safeguards
we need to be alerted whenever one of those safeguards has been circumvented. That’s not “if,” but “when.” We must assume it will happen, if we are to take the possibility of data piracy
What Else Can We Do?
accesses. Of course, this knowledge would be overwhelming in volume, and since well over 99% of these accesses would be for legitimate purposes, we would really want to have only unusual or
suspicious accesses brought to our attention, so we could then examine the audit trail as needed.
What Can We Expect from Data Access Auditing?
“customer” table may contain a “credit-card-number” column. Access to the data generally occurs through a language called Structured Query Language, or SQL. These are
technical details that may not be apparent to the person accessing the database, but they go on under the covers just the same.
- Who – Who accessed the data?
- What – What tables and columns were accessed?
- When – When did they do it?
- Where – From what location on the network?
- How – Using what SQL query, and what computer program or client software?
Result – Was the query successful; and if so, how many rows of data were retrieved?
Assuming these questions can be answered, one would also want:
- Exception reporting – Functionality to interpret the audit trail and bring only the “unusual” or suspicious accesses to our attention.
there are effective ways to accomplish data access auditing. As you might expect, some solutions come much closer to meeting the standard than others do.
How Can We Audit Data Access?
pre-determined data in a well-defined manner, or general-purpose, accessing whatever data the user desires to see in an ad-hoc manner.
typically occur across a network, although the client software may also work from the same machine where the database resides.
The Worst Choice: Auditing Within the Client
In fact, this feature has been showing up recently in an increasing number of database access tools, and is being marketed as an effective solution for data access auditing.
management really know whether anyone were sidestepping the mandate? In reality, it would be practically impossible to ensure that 100% of data access would only be done through the “authorized”
Second Best: Auditing Within the Database
- Limited audit functionality – DBMS vendors offer varying degrees of support for data access auditing. Some are stronger; some are weaker.
Upon close scrutiny, we find that for many DBMS vendors, the audit capabilities provided (if any) are insufficient to the task. It is usually impossible or at least extremely difficult to meet
all seven facets of the gold standard we defined above. For some DBMS types, it is difficult to meet even half of the requirements.
Inconsistency across DBMS types – As you might expect, the various DBMS vendors take different and incompatible approaches to access auditing. The implementation steps vary from
one database to the next, the mechanisms work differently, and even the concepts can differ (triggers versus logging, for example).
In a heterogeneous environment, where more than one DBMS type is in use, this makes data access auditing not only inconsistent, but also unnecessarily complex to set up and to use.
Performance penalty – If a given DBMS vendor’s subset of audit capabilities appears adequate for a particular situation, there is still one more drawback to consider. Most DBMS
types incur a huge performance penalty for turning on the auditing mechanism, especially for 24x7x365 monitoring of all accesses to all tables and columns.
This can cause overall database performance to go from good to bad (or from just bearable to absolutely awful). Very costly hardware and software upgrades may be required to regain the
pre-auditing level of performance, if it can be regained at all.Auditing within the database is certainly a better choice than auditing within the client. But with this approach, we are likely to end up with insufficient and inconsistent audit
functionality, undesirable complexity in our total data access auditing solution, and a database performance penalty that makes everyone suffer and that takes dollars directly off the bottom
The Best Choice: Auditing Between the Client and the Database
comprehensive data access audit while avoiding all the drawbacks of auditing either within the client or within the database.
- Data capture – Some mechanism is needed for capturing these conversations, and
- Diversity and complexity – The technical details of these conversations vary from one DBMS to the next. In fact, some of these client/server data streams are quite complex.
create a foundation for comprehensive, uniform data access auditing. This foundation will be strong enough to support the construction of a single architecture for data access auditing throughout
the enterprise, even when many different DBMS types are in use.
What’s Actually Available?
Supported DBMS Types – Some specialize on just one or two DBMS types, while others support many more. Clearly the more the better, to support having a single access auditing
architecture throughout the enterprise.
Coverage – Some use periodic sampling of activity that can miss short-duration accesses while others perform comprehensive monitoring of all SQL activity. In fact, some claim
complete coverage when in reality they are just sampling a shared memory area (SGA) multiple times per second. Of course, many SQL accesses may start and finish between the sampling intervals and
therefore go unseen.
Quality/Maturity – Some are unable to interpret complex data streams or extremely complex SQL, resulting in untracked data accesses, while others handle these quite well. Of
course, all vendors will claim to do this well. Comparative trials against actual workloads are the only way to absolutely identify which products are truly mature in this area. A reasonable
proxy might be the number of years each vendor has actually had their access auditing products deployed into customer sites.
Usability of Results – Some implementations only store access audits as text logfiles while others can use standard database tables that greatly improve the usability of the
results. For those that offer both, some have a weak database structure and others have a robust one. A strong database orientation is generally preferred.
Ease of Implementation – Some implementations require a lengthy or complex installation process and may even require the installation of software drivers or other changes for
every client computer that accesses the DBMS. Others are simple to install and transparent to the end-users.
- Performance – Some implementations actually slow down the client/server conversations while others offer extremely low overhead or even zero overhead solutions.
In particular, solutions that try to combine access auditing and query-blocking generally have very high overhead, since they have to evaluate 100% of the queries against blocking rules before
deciding whether to pass them on to the DBMS. This results in slower performance for all queries in order to block a minuscule fraction of them.The fastest solutions are those that just watch the client/server network traffic without impeding it.
clearly an important step in the process.
Obstacles to Data Access Auditing
Whenever one sets out to implement change in an organization, it’s obviously wise to consider the obstacles up front rather than just jumping in and waiting for surprises. Overcoming these
obstacles will usually take some work, and we should certainly expect this and plan for it when we decide to introduce a data access auditing solution into an organization. Technical
architecture and the architecture of the underlying DBMS. Some include special client software for viewing and monitoring the auditing results. None should require drivers or other changes on all
the database client machines.
client/server database conversations. With the right access auditing solution, these are generally not major obstacles. There’s no rocket science here.
security administration, and so forth. Any endeavor that involves this many people had better be worth the effort! I think it’s safe to say that protecting sensitive databases from piracy is worth
the objection might really be motivated by fear. There may be fear of change, fear of losing control, fear of “being watched” by the data access auditing solution, and so forth. If some of the
players are feeling overloaded already, there may just be a reluctance to take on something new.
and/or hardware involved. Just as important is to understand who will administer the solution once installed, and who will monitor the results. Separation of duties may be appropriate, especially
when there is already a distinct security team that can assume the access-auditing role.
The State of the Art
The good news is that the gold standard of data access auditing is available today. We can know who, what, when, where, how, the result, and have exception reporting for all SQL accesses to all
tables and columns in our databases. And with wise vendor selection, it’s possible to enjoy an optimum implementation that includes:
- support for a large number of DBMS types,
- complete coverage rather than just sampling,
- a high quality, mature implementation for complex data streams and complex SQL,
- storage of results in standard database tables for usability,
- simple and transparent implementation, and
- high performance with low or zero overhead.
Data Piracy, or Data Privacy?
Conventional safeguards are necessary but not sufficient. To defend against piracy, we must implement comprehensive data access auditing. The best place to do this is between all clients and all
databases. If we choose our solution wisely, we’ll be able to catch data thieves before it’s too late.