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.