ISAM Appliances (or containers) have plenty of audit features that all serve their own special purpose.

For Reverse Proxies there is native auditing (a logging engine that lives in the WebSEAL process itself) which can optionally send data to a remote syslog server.

Refence: Native Security Access Manager Auditing

There is a Remote Syslog Forwarding functionality that can ship locally stored logs (of various types) to a remote syslog server.

Reference: Forwarding logs to a remote syslog server

And on top of that, there’s also AAC (Advanced Access Control) and Federation Auditing that can be switched on.

Reference: Configuring auditing on the appliance

With several of the AAC/Federation related functionalities relying on Javascript mapping rules, the more recent versions of ISAM (≤9.0.6.0) have added functionality for emitting Audit events using  IDMappingExtUtils.logAuditEvent() 

Reference: Auditing from Mapping Rules

Recently I encountered a very specific question, where the requirement was to send “in some way” a custom Event from an ISAM InfoMap mechanism (which is essentially a type of javascript implementation of a custom authentication mechanism) to QRadar.

Both  IDMappingExtUtils.logAuditEvent()  and  IDMappingExtUtils.traceString() didn’t meet the requirement, as they would write too much data that was not applicable for consumption in the QRadar stack.

In this blog post I’m covering one alternative approach( perhaps less frequently used) to send such custom trace points (from the InfoMap) to a SIEM server.

This will make use of QRadar HTTP Receiver Log Source/Protocol

Reference: HTTP Receiver protocol configuration options

The basic steps to achieve this, involve:

• Write ISAM InfoMap code to send ‘trace’ statements via HTTP to a remote server.
• Configure QRadar with an HTTP Event Reciever
• Preferably adding some intelligence to QRadar to parse out event data, by creating a UDSM Parser.

I’ve re-used sample code from the following InfoMap blog posts to get started easily.

An Introduction to the InfoMap Authentication Mechanism in ISAM 9.0.2

Implementing an ISAM credential viewer in Infomap

Using the basic usernamelogin.js sample code, which does nothing more than create an established session for any given username. (don’t put this in production, just don’t 😉 …

importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingE xtUtils); 
importClass(Packages.com.tivoli.am.fim.base64.BASE64Utility); 
importPackage(Packages.com.ibm.security.access.httpclient); 
 
// hard-code QRadar HTTP Receiver endpoint - TODO to see if this can further configured as Server Connection"   
var endpoint = "http://1.2.3.33:12469"; 
var bauser = ""; 
var bapassword = ""; 


// Get username from request parameters  
var username = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "username");  
IDMappingExtUtils.traceString("username from request: " + username); 
 
 
if (username != null) {     // username found, set this as the user to login     
    context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attributes", "username", username); 
    
var RequestBody = '{"name" : "' + username + ' ", "authenticated" : "true"}' 
    var headers = new Headers();  headers.addHeader("Content-Type", "application/json");  var httpsTrustStore = 'rt_profile_keys'; 
   
   /**   
   * httpPost(String url, Map headers, String body,String httpsTrustStore,   
   * String basicAuthUsername,String basicAuthPassword, String   
   * clientKeyStore,String clientKeyAlias);
   */  
   
   var hr = HttpClient.httpPost(endpoint, headers, RequestBody, null, null, null, null, null);  
   if (hr != null) {   
          var code = hr.getCode(); // this is int   
		  var body = hr.getBody(); // this is java.lang.String 
		 
   IDMappingExtUtils.traceString("code: " + code);   
   IDMappingExtUtils.traceString("body: " + body);      
   
// sanity check the response code and body - this is "besteffort"   
if (code != 200) {    
IDMappingExtUtils.throwSTSException("Bad response code from QRadar HTTP Receiver: " + code);   } 

 ]success.setValue(true);  } 

Reference: usernameloginmechanism.js

NOTE: I’ve realized now that above code is likely not implemented in the most optimal way, as a connection hiccup to the QRadar SIEM server would possibly also impact end-user authentication (delays for failures). Move the HttpClient.httpPost outside of the if (username !=null) block.

This same if block includes a sample custom JSON event

{"name" : "username", "authenticated" : "true"}

That’s it for the ISAM side. Now over to QRadar, where the Log Source Management App can be used for creating a new HTTP Receiver log source.

In the right top corner click the “+New Log Source” button to create a new Universal DSM log source.

A couple of key points here.
Naming the log source. Generally I want to use an functionality@host naming approach. As our “isam” host can have multiple Log Sources (one or more Reverse Proxies, Runtime Server, message logs,..) a good clarifying prefix could be the name of the infomap rule.

The Log Source Identifier needs to be the ISAM Appliance outbound IP addres (or hostname)

The Listen Port must match what is set in the InfoMap code, by default starts at 12469.

The Log Source Type is Universal DSM (creating a parser for the Universal DSM is the next step.

Because the InfoMap code is emitting a JSON HTTP Event, we need an HTTP Receiver Protocol Type.

Once the HTTP Receiver Log Source has been configured and deployed in QRadar. Fire off a couple of sample authentications in ISAM. This will populate QRadar with the so called “SIM Generic Log DSM-7” events (essentially non-parsed or unmatched log source events).

Useful here on the QRadar side, is to select the display filter to show Raw Events

Now, should for any reason no raw events show up (perhaps things haven’t completed deployment yet on the QRadar side, or network-wise something is wrong), a tool like tcpdump (on QRadar) or ISAM Packet tracing can help as sanity check during troubleshooting.

To make the new / custom Events actually useful for a SIEM tool (like QRadar), Events need to be parsed, so later on they can be used in Custom Rules.
Back in the QRadar Log Activity tab, select one or more of the “SIM Generic Log DSM-7” events. and right click to open the DSM Editor.

The idea here is to “Override system behavior” and create a JSON expression to search for the “Username” and “Event Name”, “Event Category”, … info contained in the emitted HTTP Event.

In the {"name" : "username", "authenticated" : "true"} case, the event properties are limited to username “testuser” and category “authenticated”.

Subsequent InfoMap authentication steps should now start appearing as recognized (and parsed) Log Sources.