Skip to content

IDMEFv2 : Sensor Class Comments

Jump to bottom
Gilles Lehmann edited this page Jan 17, 2023 · 5 revisions

The Sensor class describes the module that captured the data before sending it to an analyser. The Sensor may be a subpart of the Analyser.

+----------------------+
| Sensor |
+----------------------+
| IP IP |
| STRING Name |
| STRING Hostname |
| STRING Model |
| UNLOCODE UnLocation |
| STRING Location |
| STRING CaptureZone |
+----------------------+

IP

Mandatory. The sensor's IP address.

TBM: In physical environment there might still be a lot of sensors communicating without IP, this attribute should probably be "recommended"

Name

Mandatory. Name of the sensor, which must be reasonably unique, however still bear some meaningful sense. This attribute usually denotes the hierarchy of organizational units the sensor belongs to and its own name. It MAY also be used to distinguish multiple sensors running with the same IP address.

Hostname

Optional. The sensor's hostname. This SHOULD be a fully qualified domain name, but may not conform exactly because values extracted from logs, messages, DNS, etc. may themselves be malformed.An empty string MAY be used to explicitly state that this value was inquired but not found (missing DNS entry).

Model

Mandatory. The sensor model's description (usually its generic name, brand and version).

See Analyser Model for comments on this attribute

TBA : GeoLocation

Comments : Typo error, GeoLocation has been forgotten in Draft V00.

UnLocation

Optional. Standard UN/Locode for the sensor.

Location

Optional. Internal name for the location of the sensor.

CaptureZone

Optional. A string that describes the "capture zone" of the sensor, as a JSON-serialized string. Depending on the type of sensor, the capture zone may for instance refer to:
A JSON object describing a camera's settings (elevation, horizontal and vertical field of view, azimuth, etc.)
A description of the IP network where packet capture is taking place.

Comments :

  • There is a question about keeping this attribute.
  • The capture zone is necessary to identify what zone is covered by the different sensors, and what zone is not covered. But in theory it could be available elsewhere as it is a configuration value. So the manager could get the capture zone from the IP or the name of the sensor. But the capture zone might also have been modified and the centralized value not uptodate
  • IDMEFv2 could also be used for analyser and sensor to send their presence and configuration to the manager and any change of configuration. In this case, a "Configuration" and possibly a "Registration" type of message should be added to the Alert class category attribute enumeration.
  • If the CaptureZone attribute is kept we have to define its syntax.
  • Are physical sensors able to calculate/measure there captureZone ?

Example of a physical conic capture zone : "CaptureZone": "{\"type\":\"conic-zone\",\"Azimuth\":34.00,\"Elevation\":-30.00,\"Range\":600.00,\"HFOV\":200.00,\"VFOV\":20.00}"

Clone this wiki locally