Auditing database activity is a core component to any data security program. Databases capture data access and alterations during transaction processing, along with modifications to the database system. These actions are captured and written into an audit log that is managed by the database internally. The audit log is the most accurate source of events because it's the database that acts as the arbiter to ensure transactional consistency and data integrity.

Adrian Lane, Contributor

October 5, 2009

2 Min Read

Auditing database activity is a core component to any data security program. Databases capture data access and alterations during transaction processing, along with modifications to the database system. These actions are captured and written into an audit log that is managed by the database internally. The audit log is the most accurate source of events because it's the database that acts as the arbiter to ensure transactional consistency and data integrity.Databases auditing is not specifically listed as a requirement in most compliance initiatives, but in practice it fills that role by providing an accurate, concise history of business processes, data usage and administrative tasks -- all necessary elements for policy enforcement.

A common question from security practitioners, IT and even database administrators is "What sort of activity should I look for? What sort of things can a database audit file tell me?" Despite the incredible amount of information available, most are only interested in a handful of events:

Failed Logins. Failed logins are an indication that someone is trying to break into the database or a system failure. It may seem counter-intuitive and most people think that a mis-typed password is not a big deal, but most users do not log directly into a database. Databases are accessed through applications, which in turn are automatically connected under a generic service account. Failed logins are an indicator of a problem, and audits files should be closely scanned for suspicious activity.

Failed queries. Attacks on databases are commonly scripted, targeting as many repositories as possible, looking for known defects or common configuration mistakes. The attacker who authors the script makes assumption that specific user accounts, database features, or structures will be present. Patched or properly configured databases will return an error rather than fall victim to the exploit. An error can also be indicative of flaws in application logic, parameters not being properly validated, or some other problem requiring immediate attention.

System Grants. User privileges are added or removed through 'grant' statements. Deviations from established security baselines are detected by monitoring for grant statements, especially those that involve administrative privileges or access to database internal functions. Reporting these changes is a common regulatory requirement.

Metadata Changes. Changes to database structure alter system function and offer new access to database contents. New views and added columns often lead to data leakage and should be monitored.

Audit logs contain a lot of useful information helpful to auditors, security professionals and DBA's alike, but they impact performance. Any conversation about the wonderful things that database auditing can provide needs to be tempered by understanding the added burden. Auditing incurs a performance penalty, and depending upon how you implement it, that penalty can be severe. In my next post I will cover audit settings, filtering, and data cleansing, which directly impact performance.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.

About the Author(s)

Adrian Lane

Contributor

Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and Unisys, he has extensive experience in the vendor community, but brings a pragmatic perspective to selecting and deploying technologies having worked on "the other side" as CIO in the finance vertical. Prior to joining Securosis, Adrian served as the CTO/VP at companies such as IPLocks, Touchpoint, CPMi and Transactor/Brodia. He has been invited to present at dozens of security conferences, contributed articles to many major publications, and is easily recognizable by his "network hair" and propensity to wear loud colors.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights