Hone Sensor Requirements Tiers

Hone sensor development begins by implementing the functionality in Tier 1 and progresses through Tiers 2, 3, and 4 as defined below. The Hone Linux sensor is believed to be at Tier 4; however, please be sure to read the disclaimer.

Tier 1 - Basic Correlation

Tier 1 requirements are targets for new sensors that perform the most basic packet-process correlation for version 4 of the Internet protocol (IP).

1. When a process starts, the process identifier (PID), start time, and executable path must be logged. a. The PID shall be an identifier that is unique over the lifetime of the process. On platforms that make available a system PID, the system PID shall be used.
2. When a process exits, the PID and exit time must be logged.
3. IPv4 packets originating from or destined to the host system must be logged as follows, along with the PID of the sending/receiving process and the time of the send or receive event. a. Sufficient packet data must be logged to determine the protocol, and source and destination IP addresses. b. If the protocol is TCP or UDP, sufficient packet data must be logged to determine the source and destination ports.
4. The log must be written in either plain text or Hone-augmented PCAP-NG format.

Tier 2 - Advanced Correlation

Sensors must complete tier 2 requirements to be considered complete in the area of packet-process correlation. Users of Tier 2 sensors should be aware that sensor security is not implemented until Tier 3.

1. Logging for new process events must additionally include the arguments and process owner information such as user and group or security ID (SID).
2. Logging for new connection events (socket creation) must include the connection identifier, unique over the lifetime of the socket, along with the identifier of the creating process and the time of the event.
3. Logging for connection termination events (socket release) must include the connection identifier and the time of the termination event.
4. Logging for a packet event must include the connection identifier and optionally the process identifier.
5. IPv6 must be supported at the same level as IPv4 in Tier 1.
6. Logging for ICMP packets must include information that correlates the packet to the associated process, kernel thread, or the system process.
7. Logging for RAW socket packets must include information that correlates the packet to the associated process, kernel thread, or the system process.
8. A method for determining the version of the sensor driver must be provided.

Tier 3 - Basic User-Space Reader Support

Tier 3 requirements focus on how Hone events are delivered to user-space. As of Tier 3, the sensor uses a publish-subscribe paradigm; therefore, in Tiers 3 and 4, references to the sensor logging data should be construed to mean that the sensor is publishing the data.

1. The sensor must provide a method whereby it can be assigned a host identifier.
2. The sensor must provide a mechanism whereby user-space readers can read Hone output in Hone-augmented PCAP-NG format. a. The host identifier, if provided, must be written in the section header block (shb_host_id option). Rationale: Enable user-space applications to aggregate captures for a host from multiple files.
3. Already-running processes and already-open sockets (connections) must be logged at reader connect (when a reader connects to the sensor).
4. The sensor shall provide a mechanism by which the user-space reader can specify the packet capture length (aka snap length or snaplen).
5. The sensor must be loadable and runnable (i.e., able to create logs) without requiring a system reboot. Rationale: This lets the sensor log processes that would otherwise be terminated by a reboot.
6. Access to Hone sensor interfaces must be controlled by system security policies. Rationale: Prevent an attacker from figuring out what Hone is seeing. Rationale: Prevent an unprivileged user from manipulating the sensor's behavior.

Tier 4 - Advanced User-Space Reader Support

Tier 4 requirements focus on optimizing the transfer of data between the sensor and user-space readers. PCAP-NG captures consist of a stream of records or blocks, each of which starts with the overall length and type of the block.
Valid captures start with a section header block. There may be multiple section header blocks in a single capture, but each section header block must be followed by one or more interface description blocks, after which any other block type may occur, including additional interface description blocks.
Valid captures must also start and end on a block boundary. During a log rotation, the logger must request for the sensor to restart the output with the section header block, interface description block(s), and current processes and connections.

A simple method to ensure that a capture ends on a block boundary is for the logger to read the block length and then read that number of bytes from the sensor and write it to the log. However, during a log rotation, the logger would need to watch for a section header block to know when to start the new log file. A simple optimization allows the logger to read and write without tracking block boundaries and types but requires coordination with the sensor.
When a reader is ready to disconnect or rotate a file, it notifies the sensor of this intention and waits for a read from the sensor to indicate an end-of- file or end-of-record condition (preferably by returning 0 bytes from the read() function), after which the next read will start with a new section header block, followed by one or more interface description blocks and current process and connection events, just as if the reader had just attached.
During this transition, new events should continue to be queued up so that no events are lost, assuming sufficient buffer space.

1. The sensor must provide a per-reader mechanism, preferably using the ioctl or comparable interface, by which a reader can notify it that the reader intends to end a capture.
2. When the sensor is notified that a reader intends to end a capture, subsequent reads from the sensor should behave as follows: a. If the last read did not conclude on a block boundary, a read shall only return data from the remainder of the partially read PCAP-NG block until the boundary of that block is reached. b. Once a read concludes on a block boundary, the next read shall return an end-of-file or end-of-record condition. c. After the end-of-file or end-of-record condition has been returned, a subsequent read shall cause PCAP-NG blocks, as required by the specification, to be prepended to the stream of records returned to the reader, just as if the reader had initially attached to the sensor.
3. No events shall be lost by the sensor upon restart (described in the previous point), assuming sufficient memory and buffer space.
4. The sensor must provide a per-reader mechanism by which a reader can request that the sensor filter out (or not produce) packet records for a given socket owned by the reader process.
5. The sensor may provide a mechanism for readers to set the size of the internal buffers used by the sensor.
6. The sensor should provide a mechanism to notify readers when data is available without requiring the reader to poll the sensor.
7. The sensor must not lose events between boot up and the time a logger can connect and read the events.