In the last cliff hanger episode, we were just leaving for a 5 mile run after accomplishing some really great work. I guess that means that if we want to run today (we do), then we need to accomplish some more great work. The algorithm is: Work=Reward.
That actually is an excellent lead-in to this post. Setting up and using auditing can indeed be a challenge. But the rewards, while difficult to measure sometimes, can be as major as saving your data from a significant breach...which translates into continued employment...which is always a good thing.
Ok, down to work. DB2 auditing with V9.5 and V9.7 is a like building a two story house. Each story is, in some respects an independent level, but you don't have a whole house without both levels "working" together.
This is one of those times when your past experiences with DB2 can work against you. If you used db2audit in DB2 8.2 for example, you probably performed a “db2audit configure scope….” and a “db2audit start” and that was the foundation for your database auditing approach. You will probably remember that there was only one level of authority (SYSADM) needed to administer auditing and that all auditing took place from the instance down and was based solely on that one configuration setup step.
This new granular approach to auditing provides a much greater ability to configure db2audit to capture only what you need, but, I would caution you to realize that running a "db2audit configure" command is only giving you one layer of your two layer cake…er house..guess I’m getting hungry. With DB2 9.5 or 9.7, the SYSADM configures INSTANCE LEVEL auditing using the db2audit command and SECADM configures DATABASE LEVEL auditing using DB2 audit policies. If you want the complete "whole" of db2 auditing (and, trust me…you do), you will want to audit at both levels.
So, sit your SYSADM and SECADM down (give them a couple of lattes if necessary) and start to decide how you want to audit at the instance and database levels so that you capture all the pertinent details. To show them how helpful you are, give them some additional good news. There is a nifty new database level audit category, EXECUTE, which can be set to capture SQL statements a user issues. So, if you are one of the hundreds of folks who lost the battle over setting the db2audit scope to include the CONTEXT category in the past, you now have some new ammunition to enable you to use database level auditing to capture those SQL statements….and speaking of ammunition…
Did you know that I will be presenting at IDUG NA being held in Tampa, Florida on May 10 -14? My topic is 'DB2 Security – Ammo From the Trenches'. I hope you can attend. If you’ve never attended an IDUG event before, send me an email and I’ll try to explain what you’ve been missing.
IDUG North America Conference
I also just finished a new post for my column on Database Journal.
I WELCOME YOUR EMAILS TO:
db2locksmith at securedb2.com