Are You Challenged with the Azure Sentinel Investigation Graph?
Use a focused methodology to avoid getting lost.
Azure Sentinel’s investigation graph uses nodes to represent security data, and those nodes can be expanded to view all the related entities. If a security analyst expands the investigation graph information just once for each node, the investigation graph looks like the example image below.
Therein lies the issue. It would take a talented analyst a long time to plow through all this information. If cybersecurity analysts want to use the investigation graph effectively, they will need a methodology for sorting through the information in the investigation graph.
In this blog, we show how an analyst can go over the investigation graph in the example image using the investigation phase of CyberMSI’s incident management approach. By using a focused methodology, a security analyst can turn a half-day project into a half-hour task.
|Gather Incident Information||The node at the start of the investigation graph has incident overview details like an incident description and timestamps that analysts can use to organize the timeline of their investigation.|
|Sort Entities||In this scenario an analyst opened their investigation graph and discovered 11 entities in a random order. To focus their investigation, they need to sort these nodes.
Who: The first pile has identities associated with the incident. There is only a single AAD identity involved in this case.
Where: The next pile has where the incident happened. The incident happened on a registered device and on a file on that device.
What Happened: The last pile has all the actions that were taken during the incident. A process with the ID 7496, cmd.exe, explorer.exe, and 4 file hashes were all involved with the incident.
|Investigating the “Who”||The analyst took note of the AAD identity’s information and temporarily expanded the alerts related to the identity. The analyst took note of other alerts that happened near the timeline.
Once an analyst is done with the expanded information, it is important that they collapse that information to make sure that the investigation graph does not get crowded with information that is already processed.
|Investigating the “Where”||The analyst took note of the registered device’s information and temporarily expanded the alerts related to the device. The analyst took note of other alerts that happened near the timeline before collapsing the related alerts.|
|Investigating “What Happened”||The analyst went through the executables found by the investigation graph and used the information from those executables to figure out what happened during the incident.
The analyst also copied the file hashes generated into virus total to see if any of them are indicators of compromise (IOCs).
It is up to the analyst to decide if they need to expand any of these nodes, but most of the actions have diminishing returns when expanded.
|Triage||The analyst was able to find enough information to finish piecing together what had happened during this incident, and they were able to do it in a timely manner because they used an effective investigation methodology.
The analyst was able to determine that this is a medium severity true positive because using the command prompt to add guest users to an administrator account is an obvious sign of malicious activity.
We will continue to share best practices and lessons learned in future posts on using the investigation graph in customer environments. The investigation graph may continue to evolve, but the underlying methodology will always be useful for keeping priorities straight during investigations.
In closing, consider these three questions when using the Azure Sentinel investigation graph in your organization:
- Do we have an effective way of sorting the investigation graph?
- When do we reach the point of diminishing returns by expanding related information?
- Is there an effective training program in place that will allow us to use the investigation graph at its full potential?