Download PDF - IBM Redbooks

8.3 Writing SQL to audit SAP tables
With security auditing, you can inspect and examine the adequacy and effectiveness of
security policies and procedures that can be put into place to secure sensitive data. Another
enhancement to DB2 10 is the ability to monitor and record all types of access to particular
DB2 tables by different users. During auditing, you can obtain information about who has
accessed the data, who has read the data, and who has changed the data, such as inserting
or updating records.
This new policy-based auditing enables the dynamic activation of SQL statement auditing for
tables that might not have the AUDIT clause set in their table definition. The default value for
the AUDIT clause is set to NO.
As an example, when someone wants access for reading data, they might use a password
hash attack. In this type of attack, the hash value of a password is calculated outside of the
SAP kernel and then compared with the hash value that is stored in the database on an SAP
system. One of the reasons why this attack is possible is the ability to read certain values in
DB2 tables, such as the Advanced Business Application Programming (ABAP) password
hash value. Reading of a particular row can be done by using the following methods:
► Access to data from outside of the SAP system. This method can be done remotely at the
database layer by using the SQL SELECT statement from various interfaces, such as
SPUFI, DB2 Thin Connect, DB2 Enterprise Edition (EE), DB2 Control Center.
► Access to data using its own ABAP programs. For example, ABAP developers can use
their own programs to access any tables directly within an SAP system.
► Access to data from existing tools within an SAP system. This method can be done by
using the table browser (using SAP transaction codes, such as SE16 and SE17, or by
navigating from transaction SE11).
The currently valid passwords of users are stored in the table USR02 in a database of an SAP
system. You can audit access to the data allocated in this specific table SAPR3.USR02 for
SQL operations, such as READ, INSERT or UPDATE.
To deter threats, such as an insider threat, run the SQL statements shown in Example 8-8 to
create an audit policy that audits any SQL activity in the SAPR3.USR% table. We set the
OBJECTNAME to USR%, which causes DB2 to use a LIKE predicate when determining the
tables that will be audited. Example 8-8 inserts an audit policy that audits table names that
begin with USR% within schema SAPR3.
Example 8-8 Creating an SQL statement auditing policy
INSERT INTO SYSIBM.SYSAUDITPOLICIES
(AUDITPOLICYNAME, OBJECTSCHEMA, OBJECTNAME, OBJECTTYPE, EXECUTE)
VALUES('AUDIT2','SAPR3','''USR%''','T','A');
Example 8-9 shows how the new audit policy, AUDIT2, is activated. Before activating this new
audit policy, the system component GTF must be started in the z/OS system.
Example 8-9 Starting the SQL statement auditing policy
-START TRACE(AUDIT) DEST(GTF) AUDTPLCY(AUDIT2)
122 Running SAP Solutions with IBM DB2 10 for z/OS on the IBM zEnterprise System