Back in my days at IBM T.J. Watson Research Center where we were working on techniques to detect known and unknown malware, the fast growing challenge was the rising threat of malware’s abilities to become polymorphic.
Malicious snippets of code encrypted themselves and made it very difficult to apply conventional signature based detection techniques.
We’ve developed a tiny virtual machine in C language that was able to load malware code in real time and analyze it’s behavior without need to figure out how to decrypt it. Certain score metrics were assigned to keypoints and function calls and logic was put in place to trigger an alert if “risk” score exceeded certain heuristic threshold.
That technique allowed us to deliver top quality enterprise security solution (purchased by Symantec later on) that was capable of detecting previously unknown threats. That was more than 15 years ago.
While working with financial clients and technology companies today I can see that old behavior pattern analysis stays as strong as ever helping enterprises to discover new types of suspicious behaviors and investigate malicious activities with previously unknown patterns from previously unknown sources.
Industry leaders seems to agree that some of the recent high profile breaches could of been thwarted with properly configured behavior analysis SIEM system in place.
With attackers and fraudsters changing their approaches and techniques daily – the behavior analysis based solutions seems to be the most promising in offering detection and protection layers against previously unknown threats.
The advantage of Splunk in tackling such a complicated tasks is that it’s very opened and scalable framework.
You don’t need to “pay extra to enable feature A, B and C” (as usually the case with many appliance-based offerings) and you don’t need to hire army of vendor consultants to tweak their solution to your business specifics.
In fact in my experience I helped clients to use Splunk’s free license to successfully detect, investigate and eliminate very nasty malware cyber attacks on web application hosting services.
I. Capabilities of user behavior analysis systems
Modern user behavior analysis systems generally encompass the following capabilities:
- They are able to sessionize user activity, in other words – group isolated hits and events coming from possibly different sources into clusters of activities driven by the same user.
This is very important steps that adds identity metadata to every hit and event and allows for further analysis and establishing of baselines of typical user behavior.
- They offer risk scoring approach where certain scores are assigned to significant events (money transactions, securities trading, account updates, password changes).
Scores may also be assigned to more complex event dependencies such as order of appearance, timing in between events, “rush” factor into money moving transactions, and others.
Summary risk score is calculated automatically and security alerts are issued when risk score threshold is exceeded.
- They offer automated machine learning approach where system-wide baseline of behavior is automatically calculated and alerts are issued when user session activities exhibits strong enough deviation from established baselines.
In this post I will show you how to use Splunk to implement all three of the above.
I will make this post somewhat cater to financial services sector, securities trading and e-commerce type of enterprises. These are usually high profile targets for attacks where breaches can cause significant monetary and trust factor damages.
II. Sessionizing user activity and implementing risk score based alerting
In the first part of this post I’ll show how to setup alerts when suspicious activity is detected within active online financial application. This will cover points #1 and #2 of “Capabilities of user behavior analysis systems” above.
In the second part I’ll cover point #3.
Just like in earlier posts we need to make a set of assumptions. You’ll be able to substitute names to your specifics later on if wanted to.
- Lets assume you have your WEB traffic logs with all the event data coming into Splunk.
All web events are located within the index named: logs.
- Field names (or aliases):
- HTTP request method (GET, POST, HEAD, etc..): method
- Session tracking cookie (such as: ASP.NET_SessionId, PHPSESSID or JSESSIONID): session_id
- URL of page accessed: page
- Referrer for each web page hit: referer
- Username field: username
- IP address of visitor: ip
- USER_AGENT value: ua
- Name of website: site (Could be: www.your-bank.com or www.your-brokerage.com)
- Data coming into Splunk in real time.
Note: If you have users activity traffic data coming in with delays (on a scheduled basis) the alerting schedules will need to change slightly to accomodate for that.
Here’s what needs to be done:
- Incoming traffic activity will be grouped into sessions (transactions in Splunk terms).
- Risk score will be assigned to specific events.
- Each session will be scanned for the presence of high risk events and risk score will be updated.
- Email alert will be issued automatically if any session is detected with score exceeding predetermined threshold.
And here’s the beauty of Splunk: we can accomplish all above with one search in one step of creating scheduled alert:
- From Splunk menu, select: Settings -> Searches, reports and alerts
- From App context, pick the App you want to create alert in, or “Search & Reporting” if you don’t have custom app.