The honeypot range has been running steadily for over a year now. The discipline of not changing things — leaving the configuration alone unless there is a clear reason — has been more useful than I had expected.
Why I am writing this
The operational temptation is to keep tweaking. Every interesting capture suggests a new way to instrument. Every emerging attack technique suggests a new persona to add. Every new release of Honeyd or Sebek suggests an upgrade.
The right discipline, I have found, is to resist most of these temptations. The honeypot's value comes from sustained observation over time; constant changes disrupt the comparability of data across periods.
What I have changed
In the past year:
- Updated Sebek to a newer version (once).
- Updated Honeyd to a newer version (once).
- Added one new persona (the Cisco router).
- Tightened outbound filtering after one specific capture revealed a gap.
Four changes. Each was deliberate; each had a specific reason; each was followed by a few weeks of observation to verify the change behaved as expected.
What I have not changed
Most of what I considered changing:
- Adding more personas (would dilute observation).
- Switching to a more sophisticated logging architecture (the existing one works).
- Adding application-layer honeypots (the value-to-effort ratio is not yet favourable).
- Migrating to a newer Linux kernel on the host (would require revalidation).
Each of these would have produced a small improvement at the cost of operational stability. The trade-off has consistently favoured stability.
What this teaches
Three things.
Stable observation produces comparability. Data from January 2001 is comparable to data from May 2002 because the observation conditions are the same. Comparable data over long periods is more useful than slightly-better data in non-comparable chunks.
The maintenance burden is small. A honeypot that does not change much requires very little ongoing attention. Most weeks I spend less than an hour on it.
The temptation to optimise is real. Resisting the temptation is itself a discipline. The discipline is undervalued by people who are not running long-running observational systems.
A small reflection
The principle generalises. Many security-relevant systems benefit from stability — firewall rules, logging configurations, monitoring setups. The temptation to keep optimising produces drift; the drift produces incidents.
For anyone running a long-running security system: a quarterly review with explicit decisions about what to change (and what not to change) is, in my experience, the right cadence. Not too frequent; not too infrequent.
More as the year develops.