Potential Day Trading

Description

Detect users who exhibit a large amount of stock trading activity in their proxy logs.


Use Case

Insider Threat

Category

Insider Threat

Security Impact

Users who are day trading rather than focusing on their actual jobs are a risk in many ways to organizations. At a base level, it indicates that the employee is not focused on their job, which is typically an HR issue. Some Splunk customers have discussed this detection to detect flight risks. Some organizations believe employees who do day trading have generally questionable judgment and shouldn't have access to high value resources, though this is typically reserved only for very sensitive and risk adverse organizations.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 1

Data Sources

Web Proxy

   How to Implement

Honesty first: this particular rule has had no testing in real world scenarios and should be considered very beta-quality. Ultimately we are trying to infer that a user is exercising day trading from their proxy logs with categorization, which is very tricky. Really what this detection looks for is "sustained heavy access to websites that are associated with stock trading." In most organizations, many users will periodically trade stocks. Some users may even leave a stock website up all day (or leverage widgets that track stock access). The goal is to set the bar high enough that anyone who triggers this particular rule is spending lots of time trading, with traffic to a number of different sites.

To build the rule, we looked at an organization that did not have any known day trading behavior -- we looked for users who had large amount of trading-related activities, and looked at what a heavy versus light hour was, to try to determine what it would look like when a user was focused on this. However, because we don't have a few bad users to make sure we would detect the right or wrong things, we can't say with confidence that we have exactly the right patterns. That said, this should be a good foundation. If you have the opportunity to tune this in your organization and can offer some real-world experiences, please provide feedback!

There are three thresholds in this particular search.

  1. In the first, we look for connections that last longer than 60 seconds. Most web servers that expect return traffic will keep connections open for prolonged periods of time to improve performance and reduce utilization on their load balancers. In testing, this seems to filter out some advertising.
  2. For the second filter, we look in a single hour for where there are at least 30 different connections. Thirty different connections lasting longer than a minute indicates a very heavy amount of activity in that hour.
  3. Finally we count how many hours have that amount of activity over the last week (specifically, looking for at least 20 hours of heavy activity).

Again, we would love to get feedback on the viability of this rule based on real-world experience.

   Known False Positives

This search is beta -- refer to How to Implement for details.

   How To Respond

Because this search is beta, tread carefully. Your first action should be to inspect the sites that the user was browsing to, to see if they do in fact resemble stock trading activities. If it does, most orgs will pass to HR as desired to deal with it, or just combine it with other activities to indicate a flight risk user. Your final action should be to tell us (dveuve@splunk.com) whether this was a false positive or not, so that we can improve our detections.

   Help

Potential Day Trading Help

This example leverages the simple search assistant. Our dataset is an anonymized collection of proxy logs.

SPL for Potential Day Trading

Demo Data

First we bring in our demo dataset of anonymized proxy events.
Next, we filter to look at just financial-services data, which is the PAN categorization for used for trading applications.
Next, we look at the number of connections per user per hour, so that we can filter for where there are is a decent amount of activity. We also bring along the max(duration) so that we can later show how long the longest session was.
Now we count how many hours had active trading activity over our time window (the last week). We also provide a few data points for illustration.
Finally, we look for users that have concerted amounts of trading activity at least 20 hours out of the last 7 days.. which seems pretty hard core.

Live Data

First we bring in our dataset of proxy events, filtered for trading categories and where there is a duration of at least one minute for the connection (we don't want to accidentally include one-and-done ad serving).
Next, we look at the number of connections per user per hour, so that we can filter for where there are is a decent amount of activity. We also bring along the max(duration) so that we can later show how long the longest session was.
Now we count how many hours had active trading activity over our time window (the last week). We also provide a few data points for illustration.
Finally, we look for users that have concerted amounts of trading activity at least 20 hours out of the last 7 days.. which seems pretty hard core.

Screenshot of Demo Data