Identify Users via API

GuardAppUser - Identify Users by API

Use two pre-defined triggers to set GDM_CONSTRUCT_INSTANCE.APP_USER_NAME and GDM_APP_EVENT.* for both Application User names and Application Event data.

These predefined triggers are:

• GuardAppEvent

• GuardAppUser

These each have start and stop triggers, and the Event has sub-triggers to set Type, Username, StrValue, NumValue, and Date.

The Guardium system is able to read special Select statements for the AppUserName and the AppEvent details.

The form is:

 Select "action" [additional parameters] FROM [location]. 

Some examples of select statements follow:

Select guardappuser:tiberius from dual

Select guardappuserreleased from dual

Select GuardAppEvent:Start, GuardAppEventType:Event1, GuardAppEventUserName:Tiberius, GuardAppEventStrValue:abc, GuardAppEventNumValue:123, GuardAppEventDateValue:2016-01-26 15:55:28 from dual

Select GuardAppEvent:Released from dual

The FROM portion of the statement varies by database type.

Oracle: from DUAL

DB2 from SYSIBM.SYSDUMMY1

Informix from SYSTABLES

MS-SQL <blank>

Sybase <blank>

MySQL either <blank> or from DUAL

Guardium Identify App User name and Named Templates

There are several way to capture App User Name through Guardium. Guardium has two Turbine tables where APP_USER_NAME field values are stored, based on the way the data was received:

GDM_CONSTRUCT_INSTANCE

GDM_APP_EVENT

The Named template %%AppUserName parameter in Guardium (see Global Profile menu) is mapped to the Turbine table, GDM_CONSTRUCT_INSTANCE. In order to use it in the Named Template, Guardium needs the APP_USER_NAME in the GDM_CONSTRUCT_INSTANCE table to be populated with the App User value.

Change the syntax of SQL command in the application to the following:

SELECT 'GuardAppUser:<value>'

This will put the values into the right table and this will replace the %%AppUserName parameter in the Named template with the right value.

Example

........

select 'GuardAppUser:Db2_User' FROM SYSIBM.SYSDUMMY1 ;

select * from AppUser_DB2;

select 'GuardAppUserReleased' FROM SYSIBM.SYSDUMMY1 ;

select * from NoMoreUser_DB2;

........

Look for the results in /var/log/messages file:

Jan 24 12:49:41 vx64 guard_sender[28274]: LEEF:1.0|IBM|Guardium|10.0|Alert per match|ruleID=20003|ruleDesc=Alert per match|severity=INFO|devTime=2016-01-24 11:50:39|serverType=DB2|classification=|category=|dbProtocolVersion=3.0|usrName=Db2_User|sourceProgram=DB2JCC_APPLICATION|start=1448383760000|dbUser=DB2INST1|dst=9.70.144.126|dstPort=50000|src=9.70.144.126|srcPort=58781|protocol=TCP|type=SQL_LANG|violationID=20|sql=select * from AppUser_DB2 FOR READ ONLY|error=

Set the Application User via GuardAppUser

Use this call to indicate that a new application user has taken control of the connection. The supplied application user name will be available in the Application User attribute of the Access Period entity. For this session, from this point on, Guardium will attribute all activity on the connection to this application user, until Guardium receives either another GuardAppUser call or a GuardAppUserReleased call, which clears the application user name.

To signal when other events occur (you can define event types as needed), use the GuardAppEvent call, described in the following section.

Syntax: SELECT ‘GuardAppUser:user_name’ FROM location

user_name is a string containing the application user name. This string will be available as the Application User attribute value in the Access Period entity.

FROM location is used only for Oracle, DB2®, or Informix®. (Omit for other database types.) It must be entered exactly as follows:

• Oracle: FROM DUAL
• DB2: FROM SYSIBM.SYSDUMMY1
• Informix: FROM SYSTABLES

Clear the Application User via GuardAppUserReleased

Use the GuardAppUserReleased call to signal that the current user has relinquished control of the connection. Guardium will clear the application user name, which will remain empty for the connection until it receives another GuardAppUser call.

Syntax: SELECT ‘GuardAppUserReleased’ FROM location

FROM location is used only for Oracle, DB2, or Informix. (Omit for other database types.) It must be entered exactly as follows:

• Oracle: FROM DUAL
• DB2: FROM SYSIBM.SYSDUMMY1
• Informix: FROM SYSTABLES

Set an Application Event via GuardAppEvent

This call provides a more generic method of signaling the occurrence of application events. You can define your own event types and provide text, numeric, or date values to be stored with the event, both when the event starts and when it ends. You can use this call together with the GuardAppUser call. Guardium will attribute all activity on the connection to this application event, until it receives either another GuardAppEvent:Start command or a GuardAppEvent:Released command.

Syntax:

SELECT ‘GuardAppEvent:Start|Released’,        

‘GuardAppEventType:type’,        

‘GuardAppEventUserName:name’,        

‘GuardAppEventStrValue:string’,        

‘GuardAppEventNumValue:number’,        

‘GuardAppEventDateValue:date’ FROM location

Start | Released - Use the keyword Start to indicate that the event is taking control of the connection or Released to indicate that the event has relinquished control of the connection.

type identifies the event type. It can be any string value, for example: Login, Logout, Credit, Debit, etc. In the Application Events entity, this value is stored in the Event Type attribute for a Start call, or the Event Release Type attribute for a Released call.

name is a user name value to be set for this event. In the Application Events entity, this value is stored in the Event User Name attribute for a Start call, or the Event Release User Name attribute for a Released call.

string is any string value to be set for this event. For example, for a Login event you might provide an account name. In the Application Events entity, this value is stored in the Event Value Str attribute for a Start call, or the Event Release Value Str attribute for a Released call.

number is any numeric value to be set for this event. For example, for a Credit event you might supply the transaction amount. In the Application Events entity, this value is stored in the Event Value Num attribute for a Start call, or the Event Release Value Num attribute for a Released call.

date is a user-supplied date and optional time for this event. It must be in the format: yyyy-mm-dd hh:mm:ss, where the time portion (hh:mm:ss) is optional. It may be the current date and time or it may be taken from a transaction being tracked. In the Application Events entity, this value is stored in the Event Date attribute for a Start call, or the Event Release Date attribute for a Released call.

The GuardAppEvent call populates an Application Events entity (see Application Events Entity in the Entities and Attributes section of the Appendices). When creating Guardium queries and reports, you can access the Application Events entity from either the Access Tracking domain or the Policy Violations domain.

If any Application Events entity attributes have not been set using the GuardAppEvent call, those values will be empty.