Database Auditing Essentials
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.
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
You May Also Like