Thank you on research

Two years ago, I knew very little about New Zealand and virtually nothing about Christchurch. In 2025, my wife Mai and I did a 5,000 km road trip from the top of the North Island down to the bottom of the South Island (scouting the country before we moved here, as I mentioned in New Zealand Move Notes). Along the way, in Christchurch, we were introduced to the University of Canterbury (Te Whare Wānanga o Waitaha, or simply UC around here). Scott Collier, who looks after outreach and relationships for UC's computer science and software engineering department, was good enough to take a meeting to explain industry engagement with the university.

Through that introduction, I met Dr. Etienne Borde (who coordinates the department's software engineering research projects course with industry) and became quite excited about the potential of working with the university to scale WitFoo's operations and to accelerate our research. In October 2025, I had only been in Christchurch for a few months and was invited to the graduation projects from the undergraduates at UC (the department's Final Year Project Showcase). I was quite impressed by the quality and the diversity of experiments and projects that were presented that day.

Two Proposals and a Dataset

In early 2026, I wrote up two proposals to sponsor projects for this year. I was fortunate to be paired up with Dylan Costello and Matthew Schwartfeger on their two projects. Additionally, at the request of Dr. Borde, we produced a dataset of live traffic that could be used in academic research. The dataset is now available on Hugging Face, and it was used by Ben Irvine to attempt to validate research that had been published in the field.

If you haven't bumped into it, the Precinct 6 Cybersecurity Dataset holds more than 114 million security events from the real security operations of five organisations, captured in 2024, sanitised to strip out identifying details and released under the Apache 2.0 licence so anyone can use it. It is the opposite of synthetic lab data, which is exactly why researchers want it (and exactly why it's hard to get right, as Ben was about to show us).

Over the course of this last year, it was a pleasure and an honour to work with Matthew, Dylan, and Ben on their projects. I was able to understand the great education and support that was extended by the University of Canterbury, and to see the potential and acumen of these new computer scientists. (I said it in our press release on 9 October, and I'll say it again here: the work they delivered would hold its own in any engineering team I've led.)

Matthew's research revolved around how to improve speed and memory utilisation in cache across the large graphs in the WitFoo system (he benchmarked caching and mapping strategies for the graph processing at the heart of WitFoo Analytics, while keeping memory use predictable). Dylan worked through distributed processing inside of our system, and Ben applied the dataset to researching and exposing deficiencies in published research around intrusion detection. Dylan's and Ben's work is now written up on witfoo.com, and both deserve more than a sentence.

Dylan: One Owner for Every Node

When WitFoo Analytics reads an organisation's security data, it builds a graph. Every user, host, address and file it sees becomes a node, and every interaction between them becomes an edge. (This is the Temporal Link Analysis I described in Empathetic Processing and Temporal Link Analysis: link events over time and you can reconstruct what actually happened.) Spread the work of building that graph across several machines and you run into a classic distributed-systems headache. Each machine builds its own copy of a node before the results are flushed to storage, so the same thing can be written twice. Dylan's project set out to give every node and every edge exactly one owning machine.

His answer pairs a published consistent-hashing algorithm called DxHash with an ownership directory. Picture five people sorting the mail for one long street. If they each start a pile for number 42 as letters turn up, number 42 gets several deliveries. The fix is a rule every sorter can apply on their own: the house number tells you which sorter keeps the record of who owns that house's pile, so everybody asks the same place and gets the same answer. Consistent hashing is a clever version of that rule (it barely reshuffles anything when a sorter joins or leaves), and DxHash gives every address an ordered list of candidate sorters, so the next name on the list is a ready-made backup when someone calls in sick. That list is how Dylan designed for a machine failing. He also worked through the alternatives (from gossip protocols and consensus algorithms like Raft and Paxos to other consistent-hashing schemes) and explains why he set each one aside.

He tested the design in simulation, on a model network WitFoo provided, running one to five processing machines against a single-node model. In every test of 10,000 artifacts (WitFoo's word for a parsed, normalised security record), the cluster stored exactly what the single-node model stored, with no duplicates and nothing missing. Five machines together used 54% of the memory the single-node model needed, and delivered 134% of its throughput once CPU use was accounted for.

Dylan is the first to call it a proof of concept, and he's candid about the limits: the equivalence tests were small (about 2,000 nodes and edges), recovery from a failed machine was designed but not yet tested, and five machines is not 50. He suggests testing at 10, 20 or 50 machines next. His conclusion is that it's a promising foundation for scaling WitFoo's processing out across machines, and I agree. The results have already been broken into a dozen work tasks, and when Dylan joins WitFoo full-time (more on that below), he'll keep working on them until they're production-ready. The full write-up, Distributing graph analytics across machines with DxHash, is on witfoo.com, along with Dylan's own report.

Ben: When the Benchmark Meets a Real SOC

Ben took on a family of research systems called provenance-based intrusion detection systems (PIDS, because our industry has never met an acronym it didn't like). A PIDS builds a graph of what touched what (processes, files and network endpoints are the nodes, and the interactions between them are the edges), then scores how unusual the activity looks. They're aimed at advanced persistent threats, the long campaigns built from individually ordinary steps that signature-based and endpoint tools miss. (Longtime readers know I have my reservations about those three letters, but it's the term the research uses.) Several of these systems post impressive numbers on research benchmarks. Ben asked two questions: do the published results reproduce, and do they hold up on real security operations data?

He ran four of them (NodLink, ORTHRUS, Velox and R-CAID) through PIDSMaker, a research framework built for comparing these systems. NodLink's authors reported a precision of 0.14 at full recall on a DARPA benchmark. Running the framework's reimplementation 10 times (it keeps NodLink's anomaly-scoring core, but not the rest of the pipeline the paper describes), Ben measured a mean precision of 0.0010, and the threshold rule and the random seeds moved the results a great deal. On real data (one organisation's day of telemetry from the dataset, with 54 labelled attack incidents and the benign activity sampled at one event in eight), NodLink caught all 54 and buried them under 215,467 alarms, 98.6% of them false. ORTHRUS raised a far more manageable 1,204 alarms and caught 17 of the 54. Given the same budget of 26,422 alarms, a simple off-the-shelf anomaly detector (an Isolation Forest) covered 39 of the 54 incidents, more than ORTHRUS, R-CAID or Velox managed, and only NodLink clearly beat it (not a perfect like-for-like comparison, as Ben notes, since the baseline flags events and the systems flag nodes). Ben's answer to his second question is that the benchmark results don't transfer to this operational data, and that the threshold rule, the density of the data and the shape of each attack mattered more than the model architecture.

To be fair to those systems (and Ben is scrupulously fair), the 54 attacks in that day of data were short scripted bursts lasting under 10 seconds, not the slow, multi-stage campaigns the systems were built to catch, and the labels come from WitFoo's automated correlation engine rather than from analysts. His results describe how these systems behave on operational telemetry, not their value against the threats they were designed for. Here's the thing, though. A SOC runs on operational telemetry, and Ben's work shows how much a published number can hinge on choices like the threshold rule, the random seeds and the density of the data. He closes with practical recommendations for how the field reports its results (starting with keeping how well a system ranks activity separate from the threshold rule that turns those rankings into alarms), and they're worth reading even if you never build one of these systems.

Ben also made our dataset better. He wasn't one of our sponsored students; he worked from the open data, and the design, the experiments and the analysis are all his. Along the way he found real problems. In the original release, the attacks for the organisation he studied sat in a multi-year archive with no matching normal traffic around them (he had to shift benign traffic in time to overlay them, which he treated as an artificial baseline). He reported what he found, WitFoo checked every suggestion, and the dataset was rebuilt so the attacks in its capture window sit inside the live benign traffic around them. He kept digging, found that about 15% of the incidents in the rebuilt version were duplicates, and those were fixed in the release after that. That's how open research is supposed to work, and the dataset is better for everyone who uses it next. Ben's write-up, Testing provenance-graph intrusion detection on real data, is on witfoo.com with a link to his full report.

Guests in 2025, Sponsors in 2026

On 15 October, WitFoo hosted the students and the UC staff who had guided them for an end-of-year dinner at the Arts Centre, and the next day Dylan, Matthew and Ben presented their work at this year's showcase. A year earlier, I had been at the showcase as a guest.

The success that we had together in 2026 has led us to double the projects that we'll sponsor next year from two to four, and we've begun looking for PhD candidates for the computer science scholarship we've committed to fund, which we expect to begin in 2027. Dylan is staying, too: WitFoo offered him a role as a Junior Software Engineer with WitFoo Limited (the first role we've offered in Christchurch), and I'm delighted he's joining us. We've also launched an internship programme to allow more University of Canterbury students to gain work experience with WitFoo and for WitFoo to benefit from the skills and insights that the students from UC bring to the table. As Dr. Borde put it in the release, "the benefit flows both ways and extends beyond the technical results of each project."

The work has crossed faculty lines, too. Following an introduction from Dr. Borde, WitFoo and Dr. Chat Le Nguyen of UC's Faculty of Law (Te Kaupeka Ture) have begun exploring interdisciplinary research into the legal questions raised when organisations share cybersecurity evidence, from privacy to how machine-generated evidence is used by Police and the courts. If you've read The Deterrence Delusion, you'll know how close that question sits to my heart.

Last Words

I've said it before (on this blog and in that release), but I do believe that Christchurch is quickly becoming the garden city of innovation. The relationship with the university is one of the core reasons I believe that. I look forward to the research and collaboration that we'll have together in 2027, and I'm thankful to Dr. Borde, Scott Collier, and Chenyi Zhang (who supervised Dylan's project) for their assistance and guidance this first year.

It's sort of amazing to think back that two years ago I really knew nothing about Christchurch, and today I'm just overwhelmed with anticipation and excitement about the capacity of Christchurch to accelerate research, development, and economic outcomes for WitFoo and our research around collective defence against cybercrime.

About the Author

Charles Herring

Charles Herring

Co-founder & Chairman, WitFoo

I started WitFoo in 2016 to make information and operations shareable across the craft of cybersecurity — between companies, law enforcement, national security and insurers, who mostly cannot see what each other sees. Before that I was at Lancope and Cisco, and I began in 2002 as Network Security Officer for the Naval Postgraduate School.

I lead research and development on a platform that ingests trillions of messages a day across hundreds of clusters. It is sold as Conductor, Reporter and Analytics, licensed flat per appliance with unlimited data — because a team charged by the gigabyte ends up making coverage decisions on a spreadsheet, months before the incident that needed the logs they dropped.

Everything here is mine, not the company's, and it wanders. Corrections are genuinely welcome — I would rather be right than consistent.

A note on how this was written: I use artificial intelligence tools to help me research, check facts, and edit these posts. The ideas, the arguments, and any mistakes are mine. I read the sources, I check the claims, and I take full responsibility for what I publish here. The views are my own and the writing is my intellectual property.