The Hamletic doubt about DB2 native auditing

Most of companies are adopting audit solutions to ensure security compliance with international Regulations. But, probably, the major effort is to provide more security in data protection, and regarding z/OS system, the most important data are in the database such as DB2. To protect the data and the resources you can implement any type of strong security policy but you can't ignore the importance of having a well done audit plan with processes capable to certify the efficency of your security. And that’s the recursive doubt: which type of audit is better for DB2? Is it better the native auditing or other external software solutions (perhaps based on appliance) ? 

This is an interesting matter, because it requires considerations about multiple factors such as: security connections between different devices/servers, segregation of duty, bandwidth performance, CPU consumption, ecc.

A possible approach is: why not starting with native auditing ? I know, this is nothing new and there are many concerns on the probable CPU overhead using this method, but as early as DB2 v.10 you can have a fine grained control on the audit parameters that can help the tuning.

Using the DB2 trace facility it is possible to collect monitoring, auditing and performance information about your data, application and system. In particular, you can define specific audit policy to generate trace records based on specific audit category. DB2 audit policies are defined by inserting rows into the new table named SYSIBM.SYSAUDITPOLICIES, and each policy is relative to one of these categories:

• CHECKING:     to log audit access denied attempts (authentication failures).
• VALIDATE:      to log events regarding the start of connection (new and trusted).
• OBJMAINT:     to log events relative to tables (alter, drop, clone, ecc.).
• EXECUTE      to log the first access and bind time to an object schema, name and type
• CONTEXT:      to log the use of all utilities.
• SECMAINT:     to log grant, revoke, create trusted context and alter trusted context.    
• SYSADMIN:    to log actions performed by sysadm authority
• DBADMIN:     to log actions performed by dbadm authority

Now you are ready to start the trace by using the START TRACE command for an audit with the policy parameter AUDTPLCY(policyname). Another option is to start the audit trace automatically whenever Db2 is started. Now you can check the overhead during a significant timeframe in order to verify if it is less than 5% as asserted by IBM.

Of course you have to consider the frequency of the events. For example, the security violations probably are not as frequent as table accesses.

Another good example is when you want to set a minimal audit trace intended to cover only auditing for security (not the specific auditing for changes or access to data) that could be :

Audit class 1,2,3 using IFCID:

• 0140: audit all authorization failures
• 0141: audit all grants & revoke 

In this case the performance overhead should be much smaller than 0.01%, unless you have severe security problems.

Let’s go try and if we obtain satisfactory outcome then we have also saved further expenses for external solutions.