DB2 LUW SecurityTrading up with the New,

Improved DB2 Auditing FeaturesPresented by: Rebecca Bond

a.k.a. DB2LocksmithDB2Locksmith@securedb2.com

Phone: 434-DB2-0070

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?

Old cars – New carsOld Audit – New Audit

Being Proactive about Being ReactiveDB2 Auditing...approaches, tips and concerns

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.

 

CAUTION Database Auditing is ONLY one Layer –

It has to be supplemented!

•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 !

•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

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.

EXECUTE – the new and improved "CONTEXT"Works for both static and dynamic SQLOptionally 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.

It’s Splitsville for AuditingThe split between

Instance/Database layers makes the auditing process much more

granular AND robust and aids with the concept of Separation of Duties.

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.

The SYSADM vs The SECADMThe 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.

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

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

Database Level AuditingDatabase Level AuditingDatabase 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.

Database Level – Audit PoliciesSECADM Creates Audit Policies

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)

•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.

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).

DB Audit Policies are Assigned by the SECADM

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?

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.)

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?

Putting Auditing on a DietExecute, 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.

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 audexeNow 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“

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.

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"

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)"

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 !

• 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

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.

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.

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.

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.

Audit_Buf_SZA 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.

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)

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.

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.

Some resources:

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

Rebecca BondA.K.A. DB2Locksmith

DB2Locksmith@securedb2.comPHONE: 434-DB2-0070

Trading up with the New, Improved DB2 Auditing Features