Knowledge Graph
The Knowledge Graph is an interactive visual explorer that maps the relationships between entities involved in a security case. It is designed to help analysts understand how users, processes, endpoints, and external destinations are connected, particularly in complex cases where lateral movement, process trees, or multi-stage attack chains are present.
Accessing the Knowledge Graph
The Knowledge Graph is accessed from within a case in the Investigate module:
- Open a case in the Investigate module.
- In the case detail panel, click the Knowledge Graph tab.
The graph is built from the observations and telemetry records linked to that case.
What the Knowledge Graph Shows
The graph renders entities as nodes and relationships between them as edges. Alongside a node for each observation on the case, the graph recognises four entity types and gives each one a purpose-built node:
- Devices (endpoints where the activity was observed)
- Users (identities associated with the activity)
- Processes (executables and their parent-child relationships)
- Network (connections, along with the source and destination IP addresses involved)
Where a case includes Reflex activity, the actions taken also appear as nodes. Edges are labelled by the pair of entities they join, for example Device User, Process Parent, or Process Network Destination.
Where a single device has many processes, the graph collapses them into one process group node to reduce clutter on the case overview, which you can expand to see the individual processes. Processes with network connections are shown in their own right rather than grouped.
Any other entity type an observation carries still appears, as a generic node joined by a generic edge, and is listed in the graph's visibility options so you can show or hide it.
What Determines the Detail in the Graph
The graph is assembled from what the observations on the case declare, rather than from everything SenseOn holds about the devices involved. Each observation contributes its own node, plus a node for every entity it names and an edge for every relationship between them.
This has one consequence worth understanding before you rely on the graph for an investigation: the detail available in the graph is set by the detection that raised the observation, not by the telemetry that exists. A detection that names a device, a user, the process involved, and the connection it made produces a graph you can pivot around. A detection that names only a device produces a device, an observation, and little else.
Why a graph can look sparse
A near-empty graph almost always means the observations on the case declared few entities, and not that telemetry is missing. The most common reasons are:
- The detection declares a minimal set of entities. Some detections are written to name only the device or user they concern. There is nothing else for the graph to draw.
- The activity has no process or network dimension. A detection about a configuration state or an identity event has no process lineage or connection to show, so the graph is legitimately small.
- The entities are of a type the graph does not model specially. These still appear, but as generic nodes without the attributes and expansion behaviour a device or process node offers.
Process tree expansion is a good illustration. It can only show a lineage where the observation carried process entities and the parent-child relationships between them. Where those are absent, clicking a process node has nothing further to expand.
Note: For custom detections your own team authors, the entity mapping defined when the detection is created is what determines the entities its observations carry, and therefore how much the graph can show. If a custom detection consistently produces a sparse graph, its entity mapping is the place to look.
When to investigate from Hunt Lab instead
Because a sparse graph reflects the observation rather than the available data, the underlying telemetry is still there to query. Move to Hunt Lab when:
- the graph shows the observation and little around it, and you need the surrounding process or network activity
- you need to establish whether the behaviour is new, by looking further back than the case covers
- you want to widen the question beyond the entities the detection named, for example every device that made the same connection
The graph is the faster route when the observations have already mapped the relationships you care about. Hunt Lab is the route when you need to establish those relationships yourself.
Key Capabilities
Process tree visualisation
Click any process node to expand the full process execution lineage, parent process, child processes, and any grandchild processes. This is particularly useful for understanding how malware propagated or how a legitimate tool was abused.
Entity detail panel
Click any node to open the detail panel on the right-hand side. The panel shows:
- Entity attributes (process name, file path, IP address, username, etc.)
- The specific observations that link this entity to the case
- A link to the related telemetry record for further investigation
Collaboration
Add a comment to any node in the graph to share context with other analysts. Comments are visible to all users with access to the case.
Navigating the Graph
| Action | How |
|---|---|
| Pan | Click and drag the background |
| Zoom | Scroll wheel or pinch |
| Select a node | Single click |
| Multi-select | Shift + click |
| Expand a node's relationships | Double click |
| Reset the view | Click Reset zoom in the toolbar |
Feedback
If you have suggestions for improving the Knowledge Graph or want to request a new capability (for example exporting the graph as an image or comparing graphs across cases), contact support@senseon.io.