Neo4j Network and Security Demo

Introduction

Security breaches are rarely caused by a single vulnerability. More often, attackers exploit the complexity of modern environments, where users, systems, and data are deeply interconnected. Permissions overlap, roles evolve, and infrastructure spreads across multiple clouds. This interconnected sprawl creates gaps that are difficult to detect and easy to exploit.

IT infrastructure today operates as a dynamic, layered system where changes in one area can quickly impact others. Users, devices, services, and policies constantly evolve and intersect, creating environments that are harder to trace and secure. A single user might have access to dozens of systems through different identity providers, roles, and permissions. A vulnerability in a shared library might affect multiple apps across departments. A misconfigured network setting could expose critical data without anyone realizing it.

Storing networy and security information in an interconnected graph captures the important relationships between components, enabling use cases such as:

Identity and access 360
Identity resolution
Reputation scoring
Threat detection
Zero trust
Blast radius analysis and containment
Adaptive access control
Dependency modeling and management
Hierarchy management and policy propagation
Incident investigation and response

The Challenges of Legacy Approaches

Relational databases and traditional security tools were designed for structured records, not relationships. They struggle to model complex connections between users, devices, software, and policies. Answering even simple security questions often means writing long JOIN-heavy queries, building brittle scripts, or exporting data for manual analysis.

This becomes a problem when time is critical. During an incident, teams need to know what’s at risk, not spend hours parsing logs or correlating spreadsheets. And when infrastructure changes, static models fail to keep up, leaving gaps in visibility and delaying response.

Legacy tools were not built to track how systems are interconnected or how access is inherited across layers of identity and permissions. Attempts to model this using traditional structures become unwieldy, especially when dealing with nested groups, shared components, or third-party dependencies.

Multi-level queries often underperform at scale, making it difficult to analyze environments with thousands of assets, identities, and connections. This leads teams to rely on partial views or offline analysis, increasing the risk of blind spots during high-stakes scenarios. Teams need a model that mirrors how infrastructure actually operates: flexible, relational, and constantly changing. Without it, they’re left reacting to incidents instead of anticipating them.

What You Will Learn

This demonstration shows how to use Neo4j graph database to trace the impact of network vulnerabilities; in it, you will learn:

How to set up a Neo4j AuraDB instance with sample data
Understanding a starter graph data model for modeling a network and identifying the impact of vulnerabilities
Sample queries for analyzing network vulnerabilities and clusters of suspicious devices. You will see how to use the queries to create a comprehensive interactive dashboard

Prerequisites

To run these examples, you will need the following:

Web browser and Internet access.
A Neo4j AuraDB database instance. These examples will run on any tier, including the Free and Professional tiers (including the free trial). You can sign up for AuraDB here. Following the instructions in this demo will replace the data in your database instance, so be sure to back up any data you do not want to lose; alternatively, you can create a fresh instance to use.
(Optional, but recommended) git client software to download the demo assets.
Optional: a local setup of Cypher Workbench, if you want to experiment with tools for editing the data model.

Setting Up

Ensure you have a Neo4j AuraDB instance running. If you are new to AuraDB, create an account here, then click Create Instance. You can select any of the instance types:

Be sure to save the credentials to log in to your database instance. Wait for the instance status to reach “RUNNING” before proceeding to the next step.

Clone the git repository from https://github.com/neo4j-product-examples/demo-network

git clone https://github.com/neo4j-product-examples/demo-network.git

Alternatively, you can use the “download ZIP” option on GitHub to download a copy.

Using the “3 dots” menu in the Aura console, select Backup & Restore

Use either the Browse button or drag-and-drop to find the dump file in the dump directory of the git repository you cloned in step 2.

Review the warning about replacing your instance data and proceed when you are ready:

You are ready to run the examples when your database instance reaches the “RUNNING” state.

The Graph Data Model

The figure below shows the data model used to illustrate the CX concepts:

The key types of entities (also called labels) in this graph include:

Device - Different devices that are on the WiFi Network. These devices can be access points, wifi clients (e.g. laptops, tablets, and phones), wifi bridges, etc.
Snapshot - A snapshot of a particular Device captured at a point in time.
SSID - A service set identifier for a WiFi network
SSID_Snapshot - A snapshot of a particular SSID captured at a point in time
Security_Posture, Signal, Mobility, Performance - Additional information captured as part of the snapshots

This data represents information captured by scanning wifi information at a company location that suffered a cyberattack that was initiated through the company’s visitor WiFi network. In this demo, you will see how you can use the graph to:

Understand connections between wifi devices and access points
Investigate anomalous behaviors, such as rogue devices
Uncover patterns that signal potential security threats

If you would like to experiment with the data model in Cypher Workbench, you can find a copy of the data model export in model/network_model.json in the copy of the repository

Investigating the Network

This demonstration uses NeoDash to show various scenarios using the sample dataset. The scenarios we will walk through include:

Investigating the WiFi clients and the history of their snapshots to see their activity trends and look for suspicious behavior
Using Graph Data Science to uncover clusters of suspicous devices

The dashboard is saved in the database backup that you restored in the previous step, so to run the dashboard, simply visit https://neodash.graphapp.io/, click Existing Dashboard, and provide the credentials and connection details for your database:

Navigating the Dashboard

The dashboard has eight pages - we will look at three of them in detail for this demo. When you first open the dashboard, you will see a summary of the database - including the data mode and metrics such as the total number of nodes, relationships, and properties:

Each dashboard page is composed of rectangular sections called "reports." You can view the details (such as the underlying query) by clicking the 3-dots "kebab" menu in the upper-right corner of the report.

Investigating WiFi clients

Click the "Client Overview" tab to select that report. This report displays 4 reports, showing the total number of WiFi clients, a breakdown by manufacturer, a selectable list of clients with snapshots, and a visual representation of the selected client together with its snapshots and associated signal information:

Try exploring different WiFi clients by clicking a ClientCanonicalName in the Details report; when you click, the Client Journey report will update to show you the snapshots their signal information for the selected client. To see how the reports are built. let’s look at the queries behind the Details and Client Journey reports. You can see the queries by clicking the 3-dots at the upper-right corner of the report.

The Details report uses this Cypher query to return tabular information:

MATCH (cli:Client)-[:LAST]->(snap:Snapshot)-[:SIGNAL]->(cs:Signal)
WITH cli.cname as ClientCanonicalName, cli.key as ClientKey, cli.manufac as Manufacturer, snap.lbssid as LastBSSID,
    cs.max as SignalStrength, snap.timestamp as LastSnapshotTimeStamp, cli as cli
MATCH(cli)-[:FIRST]->(:Snapshot)-[r:NEXT*]->()
RETURN ClientCanonicalName ,ClientKey,Manufacturer,LastBSSID,SignalStrength, count(r)+1 as TotalSnapshots,LastSnapshotTimeStamp

There are two main parts to the query. The first part finds clients and their last snapshot together with its associated signal information. This ensures that we only return clients for which we have snapshots. The second part matches the client together with all of its snapshots (found by traversing the FIRST and NEXT relationships between snapshots). Finally, the query returns the detail information from the client, a count of the snapshots for the client, the time of the last snapshot. and the last SSID the client connected to. When you click on one of the clients in this report, NeoDash sets a parameter to the client name of the selected client so that the Client Journey report can show the details.

The Client Details report uses a simple Cypher query and displays the results as a graph:

MATCH path = (:Client {cname:$neodash_clientName})-[:FIRST]->
    (c1:Snapshot)-[r:NEXT*]->()-[:SIGNAL]-(),
    path2= (c1)-[:SIGNAL]-()
return *

This query displays the selected client (filtering on the parameter $neodash_clientName which is set when you click on a client) and traversing all of the snapshots and signal information for that client. This graph enables the user to investigate the behavior of a particular client over time - this is where the power of Graph shines; imagine trying to do this analysis in a relational database. A SQL query would need to use 2 or 3 joins (depending on the data model) per snapshot and a recursive join to connect all of the snapshots in order. As the number of snapshots grows, performance in a relational database would rapidly degrade. On the other hand, a native graph database such as Neo4j can traverse the relationships rapidly by walking pointers in memory - giving the end user a responsive application.

Investigating Connected Groups

Neo4j Graph Analytics provides over 70 data science algorithms that you can run to uncover insights from your data. One such algorithm, Weakly Connected Components, can be used to detect communities of nodes that are interconnected with one another. In the case of our demo, the communities can expose groups of devices that are connected together (possibly acting together in a cyberattack). To make things easy for the demonstration, we have already run the Weakly Connected Components algorithm against our data and stored the community ID on each node as a property wccFullvalue. In this way, nodes that share the same wccFullvalue property belong to the same connected community of devices.

Click on the CG Groups tab to begin exploring these connected communities:

You can use this page by picking one of the Values from the All CGs report and typing it in to the wccFullvalue field on the Search CG Value report. When you do that, the table will update to show you all of the nodes in that community, and the graph will update to show you the nodes and relationships making up the community.

The query behind the graph is an interesting one to look at:

MATCH (n)
WHERE n.wccFullvalue = $neodash_wccfullvalue
OPTIONAL MATCH (n)-[r]-(m)
WHERE m.wccFullvalue = $neodash_wccfullvalue AND type(r) <> 'HAS_SAME_ISOLATED_SUB_NET'
RETURN n, r, m

The interesting thing about this query is that none of the match statements use a label to indicate a type of node or relationship. This type of query is very powerful and practically impossible to recreate in a relational database. It uses MATCH (and OPTIIONAL MATCH) statements to retrieve nodes and relationships in the community regardless of the type (label) of the node or relationship. The equivalent in SQL would be to select some data from any number of tables and possibly join the data to other tables without knowing any of the table names. Querying data in this way lets us analyze very complex sets in a flexible way, without having to change our query code when our data model evolves over time

Other Pages in the Dashboard

You can explore the dashboard on your own to see other types of analyses using the data. Use the three-dots in the upper right corner of a report to see how the query is built for the report.

Next Steps

Now that you have seen how you can use Neo4j Graph Database to investigate WiFi networks and understand potentiol security problems, here are some ideas for your next steps:

Load your own data into the same graph data model and run the same queries from this demo. An easy way to do this is to create relational tables or CSV files that match the format of the files in the data directory of the repository and use model/Neo4j_importer_model.json to load the data using AuraDB’s data import service