### Honeynet Definitions, Requirements, and Standards ###
                             ver 1.6.0
                    Updated: 14 October, 2004

The purpose of this document is to state the definitions, requirements
and standards for a honeynet.  This will allow various organizations to
independently research, develop, and deploy their own honeynets using 
the same guidelines. For more information on what a honeynet is, an
overview of how it works, and risks refer to

The goal of a honeynet is to create an environment where the tools and 
behavior of threats can be captured and analyzed in the wild.  Based 
on this information, we can gain intelligence on threats faced by the 
Internet community.  A honeynet works by creating a highly controlled 
environment that is probed, attacked, and compromised by blackhats.  To 
create this highly controlled environment, two requirements must be met.

I.   Data Control:
     Once a honeypot within the honeynet is compromised, we have 
     to contain the activity and ensure the honeypots are not used 
     to harm non honeynet systems.  There must be some means of 
     controlling how traffic can flow in and out of the honeynet, 
     without attackers detecting control activities.  Data Control
     always takes priority over Data Capture.

II.  Data Capture:
     Capture all activity within the honeynet and the information 
     that enters and leaves the honeynet, without attackers knowing 
     they are being watched.  

III. Data Collection
     If the honeynet is part of a distributed environment, then
     that Honeynet must meet the third requirement of Data Collection.
     Once data is captured, it is securely forwarded to a centralized
     data collection point.  This allows data captured from numerous
     honeynet sensors to be centrally collected for analysis and

I.  Data Control
This defines the specific requirements for data control.

  a. Must have both automated and manual Data Control.  In other 
     words, Data Control can be implemented via an automated response 
     or manual intervention.
  b. At least two layers of data control to protect against failure.
  c. Data Control failures should not leave the system in an open 
     state. In case all layers of Data Control fail, the system should 
     automatically prevent all accesses to and from the honeypot.
  d. Be able to maintain state of all inbound and outbound
  e. Data Control enforcement must be must be configurable by the
     administrator at any time, including remote adminstration.  
  f. Control connections in a manner as difficult as possible to
     be detected by attackers.
  g. Automated alerting of when honeypots are compromised.

II. Data Capture
This defines the specific requirements for data capture.

 a. No honeynet captured data will be stored locally on the
    honeypot. Honeynet captured data is any logging or information 
    capture that is not standard to the honeypots within the
 b. Data pollution can contaminate the Honeynet, invalidating
    data capture. Data pollution is any activity that is non-standard
    to the environment.  An example would be an admin  testing a tool
    by attacking a honeypot. 
 c. The following activity must be captured and archived for one year.
     - Inbound/Outbound connections (firewall logs)
     - Network activity (full packet captures)
     - System activity
 d. The ability to remotely view this activity in real time.
 e. The automated archiving of this data for future analysis.
 f. Maintain a standardized log of every honeypot deployed. 
    Refer to Appendix A (Honeypot Deployment) for template.
 g. Maintain a standardized, detailed write-up of every honeypot 
    compromised. Refer to Appendix B (Honeypot Compromise) for
 h. Honeynet gateways' data capture must use the UCT time zone.  
    Individual honeypots may use local time zones, but data will have to 
    be later converted to UCT for analysis purposes.
 i. Resources used to capture data must be secured against compromise
    to protect the integrity of the data.

III.  Data Collection
If the Honeynet is to be part of a distributed network, then the
following requirements must be met.

 a. Honeynet naming convention and mapping so that the type of site and 
    a unique identifier is maintained for each honeynet.  
 b. A means for transmitting this captured data from sensors
    to the collector in a secure fashion, ensuring the 
    confidentiality, integrity, and authenticity of the
 c. Organizations have the option of anonymizing the data.
    This does not mean to anonymize the data of the attacker,
    rather it gives the source organization the option of
    anonymizing their source IP addresses or other information
    they feel is confidential to their organization.
 d. Distributed honeynets are expected to standardize on NTP,
    ensuring all honeynet data capture is properly synched.

The following standards apply to Data Capture and Data Collection.  All
documentation will be done in either .txt or .html format.

I. Data Capture Standards
The following are minimum standards for data capture.  This is what data
and in what format should be captured at each honeynet.  It is expected 
that more forms of data then discussed below can and will be captured. 

 a. All network activity (packets and full packet payload) must be captured 
    in pcap binary format (OpenBSD libpcap standards) and rotated
    on a daily basis.

 b. Firewall logs must be converted to IPTables ASCII format. 

 c. System activity using the format provided by Sebek.

II. Data Collection Standards
The following are standards for data collection.  This is what data
and in what format data should be sent to a central collection point.  
These standards define what format or naming convention will be used for 
data when sent to the central collection site.  

Every organization and their honeynets will be given a unique identifier.  
This identifier will be used to identify all data sent to a central data.  
For the purposes of this document, we will call this ID (identifier). 
There are currently four types of Honeynet data that can be 
automatically forwarded to central point.

 a.  Pcap binary logs 
     Each honeynet will upload daily pcap binary log captures with the 
     following naming convention.


 b.  Firewall logs, ASCII format
     Every inbound and outbound connection logged by the firewall can be 
     sent in ASCII text format on a daily basis.  Use the following naming 


All comments, suggestions, or corrections should be sent to
[email protected].

                             --- The Honeynet Project