### Honeynet Definitions, Requirements, and Standards ###
ver 1.6.0
Updated: 14 October, 2004
PURPOSE:
--------
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
http://www.honeynet.org/papers/honeynet/
DEFINITIONS:
------------
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
archiving.
REQUIREMENTS:
-------------
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
connections.
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
honeynet.
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
template.
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
data.
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.
STANDARDS:
----------
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.
YEARMONTHDAY-IDENTIFIER-pcap.log
20041014-roo-001a-pcap.log
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
convention.
YEARMONTHDAY-IDENTIFIER-fwlogs.txt
20041014-roo-001a-fwlogs.txt
All comments, suggestions, or corrections should be sent to
project@honeynet.org.
--- The Honeynet Project