The Honeynet Project — which started as Lance Spitzner's private Wargames mailing list in April 1999 — has formally announced itself this week as a non-profit research organisation. The website is up. The membership is documented. The first papers are imminent.
This is the moment I was predicting at the start of the year: the deception-research community formalising into something organisationally visible. I want to write about what the formal structure changes and what it does not.
What the Project is
The stated mission, distilled: to research the tools, tactics, and motives of attackers, and to share what is learned with the broader security community. The vehicle is honeynets — networks of carefully-instrumented hosts deliberately exposed to attack, with comprehensive monitoring of what attackers do once inside.
The approach is distinct from traditional research:
It is observational rather than experimental. Honeynets capture what attackers actually do, in the wild, against real production-like systems. Not what attackers would do given a research scenario. The data is, in the right sense, ecological.
It is open. Research output, including specific captures and detailed analyses, is published openly. The Project's stance is that defenders benefit more from shared intelligence than the attackers who might also read it.
It is collaborative. The Project is a federation of operators running honeynets, sharing data and analyses, rather than a single team running a single system. This produces breadth of geographic and architectural coverage that no single team could match.
It is non-commercial. The work is volunteer-funded. There is no product to sell, no consulting engagement to pitch, no commercial interest in the findings. The output is research, distributed for free.
The membership and structure
The core team, based on the published list, is about thirty people from across the security industry — practitioners, academics, a few people from law enforcement. Most are based in the US, with growing representation from Europe and Asia.
Lance Spitzner remains the public face. The technical leadership is shared among several long-term contributors. Membership is by invitation; the Project is being deliberately careful about who joins, both to maintain operational discipline and to manage the legal exposure that comes with running honeypots.
Why the formal structure matters
A few specific things change when the Project moves from a private list to a formal organisation.
The legal posture is clearer. Honeypot operations have legal subtleties around wiretap laws, privacy expectations, and liability for harm. A non-profit research organisation with documented governance is in a better position to handle these questions than an ad-hoc mailing list.
The output is citable. Academic security research has been, for years, hampered by the lack of authoritative public corpora of attacker behaviour. The Project's published papers and captured data become reference material that other researchers can build on.
The membership is verifiable. Operators considering whether to share data with "the honeynet community" now have a documented entity to verify against. Trust questions become tractable.
The funding becomes feasible. A formal organisation can accept donations, apply for grants, support specific research projects. The volunteer model is sustainable for hobby-scale work; substantial research projects need money.
What I am most looking forward to
The Project has announced several research papers and tools coming soon. The ones I am most interested in:
The first "Know Your Enemy" paper. A detailed analysis of attacker behaviour patterns observed over months of honeynet operation. This is the kind of empirical data the field has been short of. From the previews shared on the list, the analysis is careful and the conclusions are nuanced.
Tooling for high-interaction honeypots. Building a high-interaction honeypot is non-trivial; there is no single tool that does it. The Project is putting together a toolset that handles the network-level containment, the log forwarding, the deception-realism work. If this gets to a usable state it dramatically lowers the barrier to entry.
A standard data-format for honeypot captures. Different honeynet operators currently produce data in incompatible formats. A shared format would make cross-operator analysis tractable. The Project is working on this; it is the kind of unglamorous infrastructure work that compounds.
Educational materials. The Project is producing introductions to honeypot operation aimed at people who want to start. The materials I have seen drafts of are good — clear, technically careful, honest about the operational costs.
What this changes for me
For my own work, three things.
The Wargames list becomes the Honeynet list. The communication channel I have valued for over a year is moving to a more formal mailing-list infrastructure. The volume will probably increase as new members join. The signal-to-noise ratio will be the question to watch.
My own honeypot can plug into a larger ecosystem. If the Project's data-format work succeeds, I can contribute captures from my honeypot in a format that is useful to the broader research effort. My modest single-host setup becomes part of a larger collective observation.
The legal questions are clearer. I had been operating my honeypot with a careful but private reading of the relevant UK law. The Project's legal-posture work will give me a more authoritative reference. I will probably continue with my own setup but with more confidence.
What this does not change
A few things worth being clear about.
Honeypots are still a research tool, not a production defence. The Project is, sensibly, being clear about this. A honeypot is not a substitute for actually defending your real infrastructure. It complements but does not replace conventional defence.
The threat data is still imperfect. Honeynets observe what attackers do to honeypots. This may or may not match what attackers do to real production infrastructure. The biases of the observed sample are real and need to be acknowledged.
The Project does not solve the structural problems. Egress filtering, platform monoculture, legacy code, slow patching cycles — none of these get fixed by better intelligence on attacker behaviour. Better intelligence informs better defences; deploying those defences is still the operator's job.
A small reflection
I have been on the Wargames list for fourteen months now. The discussions have shaped my thinking in ways no public source has. The formalisation of the Project is, in a real sense, the public emergence of a community of practice that has been operating quietly for a while.
For the broader security industry, this is a good moment. Operational research at this depth has been thin on the ground; the Honeynet Project is among the few groups doing it openly. The field is better for their work.
For my own work, the next year will involve closer engagement with the Project. I have not been an active contributor — mostly a reader. The captures from my own honeypot, sanitised and contributed, may eventually be small additions to the corpus. The discipline of writing them up properly, for an audience of researchers, will be its own training.
More on this as the Project develops. The next couple of months should produce the first published outputs.