The Impossible Traveler

Onum is optimal for more advanced use cases in behavioral analytics to collect, analyze, and interpret user behavior and gain insights into patterns, actions, or suspicious activity.

The impossible traveller use case is when user activity is detected from geographically distant locations within an unfeasible time frame.

We will use Onum to analyze user geolocations and calculate the speed between them in order to send an alert if any strange activity is detected.

First, we parse the data coming from the Listener to glean the usernames and IPs of Cisco VPN log ins.

Obtain Geolocations

In order to glean the exact geolocation of the log ins, we send the Public IPs to the MaxMind GeoIP database via the HTTP request action.

Now we have the log geolocations from the Cisco VPN Listener, we take the username field from the parser and use the Redis action to send a GET request to check if that user already exists in the database. This detects whether it is the first time this user has logged in from the VPN, or whether they have used the VPN before.

If the user does not exist, there is no previous IP information to track against, therefore this data is considered null as far as this use case is concerned. We use the filter action to separate the null from the not null values. We need to store the new user values in the database for next time, so connect the null port to a Redis action that sends SET requests. Once stored, proceed to send it to the null action to be discarded this time around.

If the value is not null, in other words, data on this user exists, we can use it for further the analysis.

Obtain coordinates

Now we know a user has previously logged in, we need to find out where and when they logged in the previous times to compare them with the most recent log.

We add a Parser action to obtain the Timestamp and City fields of the most recent geolocated public IP and another to grab the Timestamp and City from the HTTP Action providing the user data from Redis.

Now we can use the City fields to obtain the coordinates values, as later we will use the latitude to calculate the distance and time.

Calculate distance and time

Now we have the lat/long coordinates and timestamps, we can calculate the distance and time elapsed between the last redis log and the most recent log.

Time Difference

In the Math Expression action, we take the timestamp field of the log minus the Redis timestamp to calculate the difference in time.

Distance

In the same action, we use the latitude coordinates in the following mathematical expression to obtain the Distance:

(((((${redisParsedCity.lat}- ${httpOutCity.lat}) * (3.1XXXXXXX / 180)) * 6371) ** 2) + ((((${redisParsedCity.lon} - (${httpOutCity.lon})) * (3.1XXXXXXXXXX / 180)) * 6371 * ((${httpOutCity.lat} + ${redisParsedCity.lat}) * (3.1XXXXXXXXX / 180) / 2) ** 0) ** 2)) ** 0.5

Calculate the speed

Using the Math Expression action, we divide the distance field by (diffTime / 60 / 60).

$$distance / ({diffTime}/60/60)$$

As the speed values for all users, existing and new, is useful for further analysis, it is stored back in the Redis database using SET requests. Once stored, it can be discarded through the null action.

We connect the next actions to the same port to continue using the data.

Check the speed and alert of anomalous activity

We can use the speed to track the movements of the user. If not enough time has passed in the time it takes to travel between the previous latitude and the most recent latitude, suspicious behavior is alerted.

The Filter action checks for speeds greater than what is considered to be suspicious (here it is 100 km/hr). If the speed matches this condition, it is sent to the Message Builder to compose a message that sends an alert to your destination sink (in this case, an an alert is sent to Slack).

You have successfully implemented an early warning system and improved the security of your network.