Lack of Programmatic Call Back with SA 10.x based on Alert - Work Around

[Anonymous]

Unlike enVision 4.x, the SA 10.x environment lacks the ability to programmatically call a program when a specific alert has been generated.

In a DB monitoring scenario, it is already known via alert that an item will require further review. Based on any report created, only the meta data will be available and that meta is constrained to 256 characters (Not good for a forensic review). In this case, log reviewers that might not be Security Analysts, will require direct access to the SA 10.x environment in order to perform their analytics via Investigator links embedded in the report. Log reviewers will have to access the report via the SA 10.x GUI and drill down on the appropriate field in the report to obtain access to the raw SQL statements for example. This is not an efficient process for Operations folks or Auditors for that matter, to facilitate access to the item that requires review.

With a programmatic call back function, one of the things that we could accomplish is:

1) A DB monitoring  rule (meta is available in SA) triggers an alert indicating suspicious activity or flagging the requirement for further review

2) Based on this alert, the event details are forwarded to the custom application via programmatic call back

3) The application consumes the alert event details and can extract full raw logs for a time period specified and with specific query criteria including time period and device.type etc. using the REST API

4) Once the report is generated the program can also mail the specific detailed report with full raw log data contained

5) Operations or Auditors will get a full detailed report without any field truncation due to meta size constraints since the program has access to the full evidence trail without truncation. These individuals would not require direct access either.

The custom application would have full access to the SA 10.x REST SDK/API and will bypass any shortcomings presented by the SA 10.x user interface.

Thoughts?

[Anonymous]

Ok, so I now see that we can create an event callback with lua.

For example, pulled the idea from "We're going to Lua"

local AlertParser = nwcreateParser("AlertParser", "Alert Callback Example")

function AlertParser:onAlert(metaId, Value)          nw:logDebug("Found alert!") end

local callbacksTable = {

     [nw:LanguageKey("alert")] = AlertParser.onAlert  -- meta callback function

}

AlertParser:setCallbacks(callbacksTable)

Not sure exactly how to test this yet but I'm getting there. So, this stub is showing what I'm trying to do.

[RSAAdmin]

Not sure if this is helpful, but are you aware of our realtime alerting capability in NextGen 9.8?  If you add application rules and enable the realtime alert flag, it will generate a SNMP trap on the stat node /decoder/stats/rule.alert.session.  The trap itself will contain the session ID that triggered the rule and the rule name.

HTH,

Scott

[Anonymous]

Thanks Scott. Great Idea. Yes, the SNMP Trap would be useful. I could setup a CentOS box to be a trap receiver and then process those alerts as they come in. I could also have another daemon process running that would consume those alerts via trigger and then make a REST/API call to perform a query to first extract the session id that generated the alert and then another REST/API call to extract the raw log details. The program would also have the ability to send the actual alert details via emails to the Security Operations Team for example and can potentially enrich the field data with a local DB for user demographics or Archer related asset enrichment if necessary via API calls.

Just trying to think a bit out of the box here. I'm excited to work on the SA 10.x environment. I have a programming background and have been in the SIEM industry for quite a while.

The reason why I'm going through this trouble is that most persons won't necessarily have access to the SA 10.x console. They will only be consumers of a report etc.

Appreciate your response and help!