Microsoft Sentinel Custom Graphs – From SIEM to Relationship-Based Security Analytics
For a long time, the event- and log-based approach dominated the field of security analysis. SIEM systems were based on this model: data collection, normalization, followed by queries and detections built on tabular structures.
This approach still works today, but it has a structural limitation: it describes security events, but not security behavior. Modern attacks are often complex. They unfold as a sequence of actions across identities, devices, applications, and network resources, where the relationships between entities are often more significant than the individual log files themselves.
In real-world investigations, this results in a fundamental shortcoming. Alerts are typically isolated, correlation is query-intensive and manual, and attack paths must be reconstructed rather than observed directly. As environments become increasingly complex, this approach becomes increasingly ineffective and prone to error.
In reality, an incident can rarely be described as a single event. Rather, it is a process in which users, devices, applications, and network entities are interconnected, and it is these connections that provide the full picture. To understand an attack, it is not enough to simply examine the events; it is essential to uncover the full network of connections.
Graph-based security analysis addresses precisely this shortcoming.
Microsoft Sentinel’s “Custom Graphs” feature, built on the Microsoft Sentinel Data Lake, introduces a new type of analytical model. Instead of treating telemetry data as isolated rows in a table, it visually represents the data as relationships. This shifts the focus of the analysis from individual events to the relationship structure between them.
This model is particularly effective in multi-layered attack scenarios, such as phishing campaigns leading to identity theft, lateral movement between devices, or command-and-control communication chains. In these cases, the value does not come from a single event, but from understanding how events connect to form a coherent attack path. Graph-based analysis makes these relationships clear, rather than requiring analysts to manually reconstruct them using complex queries.
One of the key features of Custom Graphs is that it is not a predefined, “off-the-shelf” feature, but rather the result of a well-thought-out data modeling process. The graph’s construction typically begins in the Microsoft Sentinel and Data Lake notebook-based environment, where data preparation and modeling decisions are made. This is not merely a technical implementation step but also an analytical planning decision: what you choose to model determines what you will be able to detect later.
In a simplified model, entities may include users, devices, IP addresses, or applications, while relationships describe interactions such as logins, network communication, or access to resources. Through PySpark-based processing, these entities and relationships are transformed into nodes and edges at scale. This step is critical because it defines the graph’s entire analytical surface. A poorly designed model may still function technically, but it will not provide meaningful security insights.
Even after the graph is completed, it does not remain static. It goes through an iterative phase during which analysts refine the structure, adjust the relationships, and improve the model based on the findings. This iterative process is often underestimated, yet in practice, this is precisely where most of the value of the analysis is created. Security data is rarely perfect on the first try, and graph-based systems are no exception.
Once the model reaches a usable level of maturity, it can be transformed into a persistent object within the environment. From this point on, scheduled runs ensure that the graph remains up-to-date as new telemetry data arrives. This transforms the graph from a one-time diagnostic tool into a reusable analytical layer. However, this also introduces real-world constraints, such as dependence on fresh data, the quality of the input, and the operational costs of maintaining complex relationships at scale.
This is where reusable knowledge from threat hunting comes into play. A well-designed graph is not limited to a single investigation. Instead, it becomes a reusable representation of the environment’s behavior, allowing multiple security use cases to be built over time on the same relationship model.
During the analysis, Graph Query Language (GQL) becomes the primary interface for the investigation. Instead of filtering tabular data and writing complex joins, the focus shifts to uncovering paths, relationships, and patterns within the graph. This approach better aligns with how attacks actually unfold in practice, where movement between entities is often more relevant than individual log entries.
Visualization further enhances this investigative workflow. The interactive graph view allows analysts to start from a compromised entity to uncover related systems and quickly identify potential lateral movement paths or affected resources. However, visualization is only as reliable as the underlying data model. Without robust graph design, even advanced visual tools can lead to misleading interpretations.
Despite its strengths, the Custom Graph approach has significant limitations. Its effectiveness depends heavily on data quality and identity resolution. Poorly normalized data can distort relationships and lead to incorrect conclusions. Graph design requires upfront engineering work, and maintaining large-scale relationship models introduces additional operational complexity. This does not replace traditional SIEM logic, but rather serves as a complementary analytical layer built upon it.
Microsoft Sentinel’s custom graphs therefore represent not just a new feature, but a shift in analytical thinking. The real change is not the introduction of graph technology itself, but the transition from event-driven analysis to relationship-driven security investigation. In this model, understanding the relationships between entities will be just as important as understanding individual events.
Ultimately, the value of this approach depends less on the technology itself and more on how effectively the graph is designed, maintained, and integrated into actual security operations.