IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Demystifying audit in IBM Security Identity Governance and Intelligence (IGI); Part 1: Auditing Access Request Authorization

By NISHANT SINHA posted Tue October 22, 2019 11:51 AM

  

By Nishant Sinha and Saurabh Agarwal

Auditing
, in general, is a mandatory feature in an Identity Management system, that helps an enterprise align themselves with various audit and compliance requirements. While in IGI, almost every event that’s generated by an operation performed by either an end user or IGI, is audited, the system administrators find it a bit challenging to extract the relevant information from log records that gets generated, primarily because of lack of documentation. 

  

In this blog, we intend to clear some of the air around the auditing in IGI, and what is the significance of the objects that are logged in the AUDIT_LOG table. We shall be going through Access Request Authorization scenario, to understand the objects that gets logged and their purpose. 

 

Scenario: 

An end user having IGI master UID as JPool, submits an access request for an entitlement, which is approved by his line of business (LOB) manager having IGI master UID: ALong. 

 

The audit log record relevant for this category of event would have following fields and corresponding values: 

 

Field Name 

Value 

OPERATOR_CODE 

ALong 

OPERATOR_KEY 

3487 

EVENT_ID 

90001 

EVENT_DESC 

authRequest 

EVENT_DESC_LONG  

N/A 

SEVERITY 

0 

COD_OPERATION  

378 

EVENT_DATE 

2019-07-18-14.46.30.951000 

EVENT_MILLIS 

1563441390951 

AUDIT_DATE   

2019-07-18-14.46.30.951000 

TARGET_TYPE  

com.engiweb.profilemanager.common.bean.UserBean 

TARGET_KEY_ID 

2289 

TARGET_KEY_NAME 

Jpool 

TARGET_ATTR1  

Jeffery Pool 

OBJ1_TYPE  

com.crossideas.ap.common.bean.SwimRequestBean 

OBJ1_KEY_ID 

378 

OBJ1_KEY_NAME  

null 

OBJ1_ATTR1  

6 

OBJ1_ATTR2  

6 

OBJ1_ATTR3 

377 

OBJ1_ATTR4  

id=1468, name=Gas Contract Manager, type=ITROLE 

OBJ1_ATTR5 

id=108, name=Pivotal 

OBJ2_TYPE  

N/A 

OBJ2_KEY_ID  

0 

OBJ2_KEY_NAME  

N/A 

OBJ2_ATTR1 

N/A 

OBJ2_ATTR2  

6 

OBJ2_ATTR3  

6 

 

Table 1: Audit log entries for Access Request Authorization event 

 

  

The three critical objects in this log record are: 

  • Target:the beneficiary of the event 
  • OBJ1:the object that affected the beneficiary in a certain way 
  • OBJ2:any additional information in the context of the event being logged 

 

From Table 1, we can draw following inference: 

  • Target contains the information of the user for whom the access is being authorized. 
  • Obj1 contains the information about the request, like its ID, parent ID, entitlement ID and its name, application name and. In addition it also contains the request status, and the request type in OBJ1_ATTR1 and OBJ1_ATTR2 respectively.  
  • The value of 6 for OBJ1_AATR1 and OBJ1_ATTR2 corresponds to EXECUTED and ROLE ASSIGN respectively.  

 

The other important information in the log record (Table 1) above is the OPERATOR, which shows the code of the user authorizing this request (i.e. line of business manager, in this case). 

 

All these audit records are stored in AUDIT_LOG table, and a custom database query can be developed to generate the required report. 

 

We will continue our series where we will take a look at what information is stored in other events. 

0 comments
9 views

Permalink