Isn't embarrassing when someone posts a guide on how to secure a database and doesn't even mention logging and audit logs? It sure it, but at the same time it shows something pretty pervasive and unfortunate: many folks who run database have no idea who does what with the data (and, to a lesser extent, with a database itself) since no logging is enabled, with the possible exception of logging major failures with the database software itself.
DBAs who don't care about data in "their" databases is a sad phenomenon indeed. But then again - somebody got to help the incident response consultants to get rich! And the media needs constant flow of hotter and hotter breaches and data thefts! Go ahead, help these folks, continue to ignore logging on your database and reap generous rewards, such as seeing yourself on CNN (right before you "see yourself" on a pink slip! :-) )
2 comments:
Securing a database requires more than auditing and logging. How about better enforcement mechanisms to start?
Do you think that DBs have proper enforcement mechanisms to prevent the leakage of personally identifiable information or should we simply pontificate on after-the-fact logging...
"Securing a database requires more than auditing and logging."
No kidding, it is much more!
But it does require that! And that is what the author of the paper totally missed...
Post a Comment