DB2 LUW Security introduces new auditing features in DB2 9.5 that make auditing more flexible and granular. Key points include: - Database auditing now has separate instance and database levels for more flexibility and separation of duties. - New auditing categories like EXECUTE allow auditing just SQL statements instead of entire operation contexts. - Audit policies are used at the database level instead of the old db2audit commands. Policies are created and assigned to objects by SECADMs. - Instance level auditing is still done with db2audit commands by SYSADMs, while database level uses stored procedures delegated by SECADMs. - The new

1. DB2 LUW Security
Trading up with the New,
Improved DB2 Auditing Features
Presented by: Rebecca Bond
a.k.a. DB2Locksmith
DB2Locksmith@securedb2.com
Phone: 434-DB2-0070

3. Breach attempts are up, but DBA participation is
NOT trending up as well. Databases are complex
and the skills to effectively manage them take
years to learn. Database security adds complexity
to the equation, but ignoring database security –
the current approach of many organizations --
doesn't seem to be working out too well.
The database does not have to be at risk, even if
other layers of defense are pierced. But, this
protection comes only when the appropriate
database security steps are well understood and
implemented….by the DBAs.
Did you know you are a security guru?

4. Old cars – New cars
Old Audit – New Audit
Being Proactive about Being Reactive
DB2 Auditing...approaches, tips and concerns

5. Think it’s time for a trade-up for your Audit Security?
Do I have a deal for you.
DB2 9.5 introduced some nifty auditing capabilities
.
Let’s discuss Auditing, and these new features and how
they can make auditing setup more flexible so that they
will closely track to your specific needs.

6. CAUTION
Database Auditing is ONLY one Layer –
It has to be supplemented!

7. •Audit activity is now highly granular and can be limited
to activity for selected users or tables
•The SYSADM can use the db2audit functionality to
archive both instance and database logs and to extract
from archived logs from either.
•Stored procedures are now available to make the
SECADM's work easier and this work can be delegated
•Prune is Gone !

8. •The active audit log is archived before data is extracted
which benefits performance.
•The location for Active and Archived audit data can be
changed … no need to use the old default path
•DPF dbs can use local file systems for the audit logs
•SECADM role is greatly enhanced, but work can be
delegated

9. What Are the Audit-able categories?
•AUDIT – records info regarding changes to audit settings or when the audit
log is accessed
•CHECKING – authorization "checking", attempts to access or change
DB2 objects or functions
•OBJMAINT – creation/drops of data objects
•SECMAINT – Grants/revokes, privileges, DBADM, modifications to
SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP
•SYSADMIN – SYSADM,SYSMAINT,SYSCTRL operations
•VALIDATE – for each connection attempt, generates audit records when
validating users and their associated groups or when retrieving system
security information
•CONTEXT – "context" of the operation. Aids in interpretation of the info in
the audit log file. Likely will capture a HUGE amount of information.

10. EXECUTE – the new and improved "CONTEXT"
Works for both static and dynamic SQL
Optionally include Data (host variables and/or parameters)
Doesn't capture statement preparation
Doesn't include LOBS, LONG, XML & structured types
The Execute audit record is only produced when
execution completes, so failures are not captured via
EXECUTE.

11. It’s Splitsville for Auditing
The split between
Instance/Database layers makes the
auditing process much more
granular AND robust and aids with
the concept of Separation of Duties.

12. 2…2…2 Audits in 1 !
• Where else can you get 2..2..2 DB2 Audits in 1 ?
• Instance AND Database Levels with greatly increased
granularity
• No need to waste time chewing on auditing features
you don't need.
• SYSADM uses DB2AUDIT command at the Instance
Level
• SECADM creates audit policies at the database level
• An Active audit log is archived BEFORE data is
extracted from it which helps performance.

13. The SYSADM vs The SECADM
The SYSADM user can use the db2audit
command to archive instance OR database
level audit data.
SECADM uses the AUDIT_ARCHIVE stored
procedure to archive database level audit
data.

14. Instance Level Auditing
• This is most like the old "pre 9.5" days
• SYSADM uses DB2AUDIT to configure at instance
level
• Db2audit is Explicitly started and stopped
• Uses "Describe" to determine current
configuration
• Records can be "Flushed"
• Archive (and can also archive logs for an
associated database)
• Extract data from an archived audit log

15. The SYSADM’s commands:
db2audit configure – what do you want to audit?
db2audit describe – what ARE you auditing?
db2audit archive -- moves the active log to an archive
db2audit flush – flush the audit buffer explicitly
db2audit extract -- from archived logs
db2audit start/stop

16. Database Level Auditing
Database level auditing is done via policies
that are created by the SECADM.
There is no "start" command.
Auditing begins as soon as the
policy is CREATED AND ASSIGNED.

17. Database Level – Audit Policies
SECADM Creates Audit Policies

18. Database Audit Policy Categories. What do they do?
•ALL - Sets all categories to the same status. (However, the
EXECUTE category is WITHOUT DATA.)
•AUDIT - Generates records when audit settings are
changed or when the audit log is accessed.
•CHECKING - Generates records during authorization
checking of attempts to access or manipulate database
objects or functions.
•CONTEXT - Generates records to show the operation
context when a database operation is performed. (A lot of
information, choose wisely)
•EXECUTE - Generates records to show the execution of
SQL (WITHOUT DATA /WITH DATA)

19. •OBJMAINT - Generates records when data objects are
created or dropped.
•SECMAINT - Generates records when object
privileges, database privileges, or DBADM authority is
granted or revoked.
•SYSADMIN - Generates records when operations
requiring SYSADM, SYSMAINT, or SYSCTRL authority
are performed.
•VALIDATE - Generates records when users are
authenticated or when system security information
related to a user is retrieved.
FYI: If ALL is not specified, the STATUS of any category
that is not explicitly specified is set to NONE.

20. Policies are assigned to objects by the
SECADM using the AUDIT statement.
Once assigned, the audit policy is active
(but may need to wait on the next UOW if
an old policy was in place).

21. DB Audit Policies are Assigned by the
SECADM

22. DATABASE — All auditable events that happen on the DB
are audited according to the audit policy.
TABLE — Can be a table, MQT nickname. CANNOT be a
view (views are audited according to base table policy),
catalog table, declared temp table or a typed table (Only
execute category audit events, with or without data, will be
generated when the table is accessed, even if the policy
indicates that other categories should be audited
Which Policy for Which Purpose?

23. Which Policy for Which Purpose?
TRUSTED CONTEXT -- Specifies that an audit policy is to
be associated with or removed from contextname (which
must exist)
USER -- Specifies that an audit policy is to be associated
with or removed from the user with authorization ID
<authorization-name>.
GROUP -- Specifies that an audit policy is to be associated
with or removed from the group with authorization ID
<authorization-name>. (Note: If user membership in a
group cannot be determined, the policy will not apply to that
user.)

24. ROLE -- Specifies that an audit policy is to be associated
with or removed from the role with authorization ID
<authorization-name> (must pre-exist).
Note: SYSADM, SYSMAINT, SYSCTRL, SYSMON,
SQLADM, WLMADM, DBADM or SECADM — All
auditable events that are initiated by a holder of this
authority are captured, even if that authority is not
required for the specific event
Which Policy for Which Purpose?

25. Putting Auditing on a Diet
Execute, a new database (ONLY) level category, allows audit
of JUST the SQL statement, versus the entire CONTEXT.
Context generates a LOT of audit information.
Since it is database specific
and not instance specific,
it uses audit policies, not the db2audit syntax.
Use the WITH DATA option to capture data values for any
host variables and parameter markers. EXCEPT, Be Aware,
that not all input values are logged.
LOB, LONG, XML, and structured type parameters appear as
a null value.

26. Some Audit Syntax:
$> db2 "create audit policy audexe categories execute with data status both error
type audit"
Status both means that successful and failing attempts will be audited.
Error type audit means that all errors (incl. audit errors) will be returned to the
application. If error type was normal, errors generated by the audit facility are
ignored and only the SQLCODEs for errors associated with the operation being
performed are returned to the application.)
$> db2 audit table locksmith.sensitive using policy audexe
Now the audit policy is assigned to the table named sensitive in the schema
locksmith. This audit policy is now active.
I think I'd like to know what the SYSADMs are up to, so I'll create an audit policy for
the database:
$> db2 "CREATE AUDIT POLICY ADMPOLICY CATEGORIES SYSADMIN STATUS BOTH,
SECMAINT STATUS BOTH ERROR TYPE AUDIT"
$> db2 "AUDIT DATABASE USING POLICY ADMPOLICY“

27. At the database level, the SECADM can delegate
running the audit stored procedures and table
functions to another user by appropriately granting
execute authority on the SYSPROC audit procedures.
These are: AUDIT_ARCHIVE stored procedure and
table function, AUDIT_LIST_LOGS table function and
AUDIT_DELIM_EXTRACT stored procedure.

28. One example (using a Role to do this)..as the database SECADM:
db2 "create role auditwrk"
db2 "grant execute on procedure sysproc.AUDIT_ARCHIVE to
role auditwrk"
db2 "grant execute on function sysproc.AUDIT_ARCHIVE to role
auditwrk"
db2 "grant execute on function sysproc.AUDIT_LIST_LOGS to
role auditwrk"
db2 "grant execute on procedure
sysproc.AUDIT_DELIM_EXTRACT to role auditwrk“
db2 "grant role auditwrk to locksmith"

29. I hold SECADM. I want to get some info.
First, I'll archive the current log.
Then I'll extract the data to delimited files
so I can load it in to tables and query it.
$> db2 "call sysproc.audit_archive ('',-2)"
$ >db2 "call sysproc.audit_delim_extract
(null, '/SecDB/auddel', NULL, '%20100210%', null)"

30. Auditing is a Big GUN for Reactive
Monitoring
But a Big Machine Gun that is Never Fired is Worthless
If you aren't extracting Audited Data and if NO ONE is
Reviewing it Regularly, then your Big Machine Gun is
totally RUSTY and WILL NOT FIRE when Needed.
BE PROACTIVE. Set up Audit, USE AUDIT, ReView Audit !
Keep your Big Machine Gun READY !

31. • The Location for the Active Audit Log is now
configurable
• There are separate logs for instance & DB audit activities
• Audit activity is now highly granular and can be limited
to activity for selected users or tables
• The SYSADM can use the db2audit functionality to
archive both instance and database logs and to extract
from archived logs from either.
• Stored procedures are now available to make the
SECADM's work easier and this work can be delegated
• Prune is Gone !
Port able

32. Making the Audit Wheels Turn
If multiple instances exist on a server, then
EACH INSTANCE should have separate locations
for ARCHIVEPATH, AUDITARCHIVES.
The goal is to get these audit logs on to speedy disk
locations,
especially for the ACTIVE ones.

33. Where are you? Where do you want to be?
EXAMPLE SYNTAX for moving ACTIVE audit log locations
## for Single Partition DB
$> db2audit configure datapath </myspeedydisklocation>
## For DPF databases,
I can choose an NFS Shared, or do something like....
$> db2audit configure datapath <'/Lockit/SpeedyAud $N'>
Make sure to keep the space before the $N
(For moving audit ARCHIVE logs for DPF database, I can NOT
use the data partition expression ($N), my only option is a shared disk).
## Note: '/SecDB/auddel' has to exist.

34. As you can imagine, migrating from an earlier product level
to 9.5 or 9.7 will require some special considerations.
Auditing is one of those special considerations.
If you were using auditing prior to the migration then you will
want to consider how the changes will impact your setup.
Review the documentation for your specific migration
approach.
Have a plan to proceed that includes backing up current
audit settings.

35. When you migrate an instance from an earlier release to DB2 9.5
The audit configuration file is converted to DB2 Version 9.5
format.
When you migrate a database from an earlier release to DB2
9.5 the instance-level configuration settings for auditing are used
to create an audit policy in the database. If the audit facility is
enabled at the instance level, the audit policy is associated with
the migrated database to enable auditing. Otherwise, the audit
policy is not associated.
After the migration, audit settings should be re-visited, both to
determine if it meets requirements and to take advantage of new,
robust options.

36. Audit_Buf_SZ
A consideration: audit_buf_sz: a DBM configuration
parameter.
If set to zero auditing records are written synchronously to
disk which means that the event that caused the audit
record has to wait on the write. Possible to lose one audit
record if this is zero. Downside is potential performance
impact.
Larger audit_buf_sz can mitigate performance impacts,
but places a larger number of audit records at risk of not
making it to disk. The "flush" operation can also be
performed to force the writes at any time.

37. A Personal Journey
Long ago in my youth, I read and heard that setting
audit_buf_sz to zero was reported to cause some
serious performance degradation on audited DB2
systems. I believed the claim. It certainly seemed
plausible.
But, being a security junkie, my job was SECURITY not
PERFORMANCE....boy was that a bad assessment on my
part. If security has to battle performance in an
enterprise, security is going to be at a distinct
disadvantage, right? (Note to self: Buy Boxing Gloves
before the next battle)

38. But then, I actually had a performance tuning exercise
and I was REQUIRED to set the audit_buf_sz to ZERO
so that, at most, only one audit record was ever at risk
of loss. I was auditing for everything except CONTEXT.
Even without auditing CONTEXT events, I was
concerned (actually terrified) that this would cause a
HUGE problem.
Ok, at first, it appeared my fears may have been valid.
The entire system looked over tasked, overworked and
just plain old unhappy (a technical term). But then, some
tuning changes were made, some code re-written, some
OS parms tuned and before I knew it, I had forgotten
all about the audit_buf_sz being zero....oh....and our
performance tuning exercise was so successful that
management was "shocked" at what we had
accomplished.

39. The material in this presentation is an overview.
The time to deep dive into DB2's Robust
Auditing Capability would have exceeded the
length of this session. Please be especially
aware when you upgrade from 8.2 or 9.1 to 9.5
or 9.7. Things have changed and you will need to
adapt. But the upgrade benefits are GREAT.
I strongly encourage you to learn much about
auditing.

40. Some resources:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp
DB2 9.7 Security Guide: http://www-
01.ibm.com/support/docview.wss?rs=71&uid=swg27015148
DB2 Security Redbook (LUW):
http://www.redbooks.ibm.com/abstracts/sg247555.html?Open
DB2 Security Redbook (z/OS):
http://www.redbooks.ibm.com/abstracts/sg247720.html?Open

41. Rebecca Bond
A.K.A. DB2Locksmith
DB2Locksmith@securedb2.com
PHONE: 434-DB2-0070
Trading up with the New, Improved
DB2 Auditing Features