Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How Security Teams Use Graph Analytics for Threat Hunting
Transcript
- Lucas: If these conversations are useful for what you're building or running, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, even a couple of coffees a month really adds up and keeps us independent. Lucas: Alright, so graph analytics for threat hunting — this is one of those topics that sounds like pure math but has very concrete operational impact. I was talking to the CISO of a regional bank last week, mid-sized, about fifty billion in assets. They had a credential-stuffing campaign running for six weeks before their SIEM caught it. But when they ran the same data through a graph database query, it took fourteen milliseconds. Luna: Fourteen milliseconds? That's the difference between a breach and a blip. Lucas: Exactly. And the reason is that traditional security tools look at events in isolation — an IP address, a username, a timestamp. Graph analytics looks at relationships: who connected to what, from where, using which credentials, and how that chains together. The bank's graph query traced a path from a known phishing domain to a compromised VPN endpoint to a service account that had privileged access to the core banking system. The SIEM never connected those dots because each event looked mundane on its own. Luna: So it's not replacing the SIEM, it's adding a relationship layer on top. Lucas: Right. Think of it as a map instead of a log file. The technology underneath is usually a graph database — Neo4j is the most common, but there are also purpose-built security graph platforms from Microsoft and Elastic. You model entities as nodes: users, devices, applications, network addresses. And you model interactions as edges: 'logged into', 'sent email to', 'accessed file from'. Then you query for paths that match known attack patterns — or better, you look for anomalies in the graph structure itself. Luna: Give me an example of a graph query that would catch something a traditional rule wouldn't. Lucas: Sure. One classic is what's called an 'unusual transitive trust' query. Say you have a user who never accesses a particular server, but that user's manager does. And that manager's laptop was recently seen talking to a command and control IP. The graph query can find a two-hop path: user -> manager -> C2 server. That's suspicious even if no single event matches any signature. There's an open-source tool called BloodHound that does this for Active Directory — it maps all the privilege escalation paths in your domain. Attackers use it to find their way to a domain admin; defenders use it to close those paths. Luna: BloodHound is basically the same tool on both sides of the fence, right? That's a weird arms race. Lucas: It is. And that's why the MITRE ATT&CK evaluation last year was so interesting. They ran a simulation of twenty different attack techniques against both traditional log-based detection and graph-based detection. Graph methods caught ninety-four percent of the simulated attacks; log-based caught seventy-eight percent. The gap was biggest on things like lateral movement and privilege escalation — exactly the techniques that rely on chaining multiple steps. Luna: Seventy-eight percent is still pretty good. Why isn't every team already doing this? Lucas: A few reasons. First, building the graph is non-trivial. You have to ingest data from all your sources — endpoints, network flows, cloud APIs, directory services — and normalize it into a consistent graph model. That's a data engineering project. Second, querying at scale requires skill. Cypher, Neo4j's query language, is different from SQL. A lot of security analysts don't know it yet. And third, the tools are still maturing. BloodHound is great for Active Directory, but if you want to model cloud infrastructure or network traffic, you're often building custom integrations. Luna: So the CISO who wants to adopt this needs to hire a data scientist or train existing staff? Lucas: Yes — and that's exactly what I'm seeing. In the last year, I've talked to three security teams that created a new role: 'threat intelligence engineer' or 'security data analyst'. They're people with a background in data science or software engineering who focus on building and maintaining the graph. One team at a large retailer told me they hired a former Neo4j consultant full-time. The investment is real, but the payoff is too — they caught a supply chain attack where a compromised vendor account was used to access their inventory database. The graph query found it because the vendor's access pattern suddenly included an unusual sequence of database tables. Luna: That's a very specific behavioral change. Would a traditional SIEM rule catch that? Lucas: Only if someone had written a rule saying 'vendor accesses inventory tables in a new order' — which is too specific to anticipate. But a graph query that models 'normal access paths' can flag any path that deviates from the baseline. That's the real power: anomaly detection on the structure of the graph, not just on the volume or timing of events. Luna: Let's talk about scale. How big can these graphs get before they become unmanageable? Lucas: The largest production security graph I've heard of is at a major cloud provider — they have about two billion nodes and ten billion edges. They use a custom graph engine built on top of Apache Spark. But for most enterprises, you're looking at tens of millions of nodes, which Neo4j handles fine. The challenge is query performance: if you run a traversal that touches millions of nodes, it can take seconds. But for targeted queries — like 'find all paths from this user to this server' — it's sub-second. Luna: And what about real-time detection? Can you do graph queries in line with network traffic? Lucas: Not really, not yet. Graph analytics is better suited for retrospective hunting and investigation. You ingest data, build the graph, and then query it after the fact. Some vendors are working on streaming graph processing — where edges are added in real time and queries run continuously — but that's bleeding edge. For now, the typical workflow is: SIEM generates an alert, analyst pulls up the graph to investigate the context. Or proactive hunts where the analyst runs a query looking for suspicious patterns. Luna: That still sounds like a huge improvement over sifting through logs manually. Lucas: It is. And the cost is coming down. Neo4j has a free community edition. BloodHound is open source. Elastic Security includes graph capabilities in its enterprise license. Microsoft Defender for Identity uses graph analysis under the hood. So the barrier to entry is lower than it was three years ago. Luna: What's the one piece of advice you'd give a security team that wants to start using graph analytics? Lucas: Start with one data source. Don't try to model everything at once. Pick Active Directory — it's usually the highest-value graph because it contains all the privilege relationships. Install BloodHound, run the collection tool, and look at the attack paths it reveals. You will almost certainly find things that surprise you: service accounts with domain admin rights, users who are members of groups they shouldn't be, trust relationships that create unintended paths. Fix those first, then expand to other data sources like network flows or cloud APIs. Luna: That's a very concrete starting point. And it's free. Lucas: Exactly. The fastest way to get value is to look at what you already have in a new way. Graph analytics is basically a different lens on the same data — and sometimes that lens shows you the attack that's already inside your perimeter. Luna: So the technology isn't magic, but the perspective shift is powerful. Lucas: That's the takeaway. It's not a silver bullet, but it's a tool that changes what questions you can ask. And in security, asking the right question is often more than half the battle.