QRadar Use Case Series: Part 3: Data Exfiltration Attempt Through Online Storage
Welcome back to the IBM QRadar use case series. I am going to give ‘User Activity Monitoring’ a break for some time and focus this particular post on ‘File Activity Monitoring’. Although, not that dissimilar, we are identifying trends around directories and in particular files.
This particular use case will consist of a combination of log sources and rules, to identify potential data exfiltration attempts via the means of online storage. A common example here would be ‘Dropbox’, ‘Google Drive’ etc. The interesting element of this use case is taking File Integrity Monitoring data from core directories or particular files, and in turn having the ability to continuously monitor for file modification in real-time.
As mentioned briefly, this use case consists of a combination of log sources, these are as below:
- Windows Security Event Logs
- File Integrity Monitoring Logs
- Firewall Logs (Layer 7)
Although, this may seem like a varied list having all of these combined will help build the full picture of users attempting to execute a data exfiltration attempt.
The Ins and Outs of Data Collection:
In this section of the blog I will talk about the different types of log sources and events required to make this use case successful. I will briefly identify the products used to collect / produce the data.
Windows Security Event Log:
Monitoring the Windows Security Event log is a priority not just in terms of this use case, but as general good practice (especially when it comes to compliance). In this use case however, we are specifically looking for 2 events types:
- Successful Account Logon
- Account Logoff
This is essentially the first phase of our use case… identifying the specific time a user signs into the network and more importantly where this user is signing in.
File Integrity Monitoring:
Now this is the cool part. Continuously monitoring core files in real-time for detection of file changes, with the added visibility of user and source information. In an ideal world companies will know where their sensitive data is kept, we all know this is not the case. Due to this fact, there may be a period of interviewing key stakeholders to identify where this data is kept etc. In this particular use case we used ‘Digital Guardian’ to carry out the data discovery piece. ’The key event types we will be monitoring here are:
- File Moves
- File Renames
- File Modification
- File Deletions
- File Attribute Changes
Firewall Events – Layer 7:
We are looking for the normal firewall accept and firewall denies with the added visibility of layer 7 information. This is a key aspect in detecting access to sites such as drop box and google drive. In this particular use case we are going to be using Palo Alto as our chosen firewall.
Method behind the Rule Logic:
This use case consists of one rule comprised of two building blocks. These building blocks are detailed below:
- Corp Directory: File Attempt
- Data Exfiltration: Online Storage
I will dive a little deeper into the individual building blocks a littler later. But for now the logic involved Is looking for ‘when Corp Directory: File Attempt, Data Exfil: Online Storage, DLP: Data Exfil USB Device match at least 1 times with the same Username in 5 minutes’
If this rule triggers the default response is to generate an offense which is indexed on the username. The key indicator which links the events to an actual offense being triggered is a username.
Building Blocks – what is included:
Slight change in direction for this use case, instead of using ‘Reference sets’ I have instead used building blocks, which are not dynamic in nature. The two building blocks we have identified are looking for...
Corp Directory: File Attempt
The logic behind this building block is to look for a custom property ‘Directory’ which has been taken from the payload of the ‘File Integrity Monitoring’ event.
Data Exfiltration: Online Storage
Similarly, the logic behind this building block is to use a custom property to extract a certain piece of data from the payload. For this instance, we are identifying the category in the Palo payload. An example would be ‘Social Media’.
Here’s one I made earlier:
So, QRadar is now set and ready to detect ‘potential data exfiltration attempt’ through online storage. The above is a brief snippet of what to expect if or when this rule is triggered.
One last thought for the road:
I hope this blog has given you some insight into the power behind implementing use cases alongside your SIEM to identify common vectors of compromise.