Protocol Documentation

IP address (either version 4 or version 6)

Name of the analyzer, which must be reasonably unique, however still bear some meaningful sense. Usually denotes hierarchy of organizational units which detector belongs to and its own name or it can distinguish multiple analyzers running with the same IP

Hostname of this analyzer. SHOULD be a fully-qualified domain name

Analyzer type

Generic name, brand, version

Analyzer categories

Data analyzed for detection

Detection method

GPS coordinates for the sensor

Standard UN/LOCODE location

Internal location of the agent/sensor

Unique identifier among attachments that can be used to reference this attachment from other classes using the "Attachment" attribute

Attachment filename

Checksum of the attachment's content. The use of a hash function from the SHA-2 or SHA-3 family is recommended

Length of the content (Bytes)

References to known sources, related to the attack and/or vulnerability, and specific to this attachment. This MAY be a URL to additional info, or a URN (according to RFC 2141) in a registered (IANA) or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as "urn:clamav:Win.Trojan.Banker-14334"

If the attachment's content is available and/or recognizable from an external resource, this is the URI (usually a URL) to that resource. This MAY also be a URN (according to RFC 2141) in a registered (IANA) or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as "urn:mhr:55eaf7effadc07f866d1eaed9c64e7ee49fe081a", "magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C"

Free text human-readable additional note

Internet Media Type of the attachment, according to RFC 2046 and related. Along with types standardized by IANA also non standard but widely used media types can be used (for examples see MIME types list at freeformatter.com)

Content encoding. The following encodings are defined in this version of the specification: "json" - Content refers to a JSON object which has been serialized to a string using the serialization procedure defined in RFC 7159. "base64" - The Content has been serialized using the Base64 encoding defined in RFC 4648. This encoding SHOULD be used when the content contains binary data. If omitted, the "json" encoding should be assumed

The attachment's content if the content is included inside the message

Version of the IDMEFv2 Format

128-bit Universally Unique IDentifier (UUID) either UUID version 4 (random) or 5 (SHA-1)

Tenant ID to support multi-tenancy (e.g. decentralized infrastructure, local agency, subsidiary company, etc.). Should be used when there are multiple sites/locations or multiple tenants (e.g. MSSPs)

The ENISA:RIST incident category & subcategory

Alert cause's origin, if known at the time of detection. If unknown, this key should not be defined and may be filled later on by a manager or a human operator

Short free text human-readable description

Alert state in the overall alert lifecycle

Severity of the alert

Confidence of detector in its own reliability of this particular detection. (0 – surely false, 1 – no doubts)s

Free text human-readable additional note, possibly longer description of incident if not obvious

Message creation timestamp. May point out delay between detection and processing of data

Deduced start of the event, or just time of the event if it is solitary

Deduced end of the event

Message deletion timestamp. MUST be specified if the message has to be deleted after this date for technical, organizational or ethical reasons

Alternative identifiers; strings which help pair the event to internal systems' information (for example tickets in request tracking systems)

Alternate category from another reference than RIST (e.g. MISP, MITRE ATT@CK or another proprietary internal reference)

References to known sources, related to the alert and/or vulnerability, and specific to this alert. This MAY be a URL to additional info, or a URN (according to RFC 2141) in a registered (IANA) or unregistered ad-hoc namespace bearing reasonable information value and uniqueness, such as "urn:cve:CVE-2013-2266

Identifiers for the messages which were used as information sources to create this message, in case the message has been created based on correlation/analysis/deduction from other messages

List of IDMEF fields that are shared (with the same value) by all aggregated events. Should be sent mostly by intermediary nodes, which detect duplicates, or aggregate events, spanning multiple detection windows, into a longer one. IDMEF fields syntax: <field> for top-level fields. E.g. "CeaseTime" <class>.<field> for subfields. E.g. "Source.IP" <field>(<N>) to reference the Nth element (0-based) inside a list. N defaults to 0 if omitted. E.g. "Source.IP(0)" refers to the first IP of the first source. The "StartTime" and "CeaseTime" fields are used to describe the aggregation timeframe, in conjunction with this field

Identifiers of previous messages which are obsoleted by this message. The obsoleted alert should no longer be used. This field can be used to "update" an alert

Other messages related to this message

The Analyzer class identifies the analyzer from which the message originates

The Sensor class identifies the sensor used by the analyzer for its analysis

The Source class contains information about the possible source(s) of the event(s) that generated this message

The Target class contains information about the possible target(s) of the event(s) that generated this message

The Vector class contains information about the vector(s) of the event(s) that generated this message

The Attachment class contains information about data linked to a source, target or vector

The Observable class contains information about metadata linked to a source, target or vector

Unique identifier among observables that can be used to reference this observable from other classes using the "Observable" attribute

Name of the reference from where the observable is specified

Observable content

The sensor's IP address (either version 4 or version 6)

Name of the sensor, which must be reasonably unique, however still bear some meaningful sense. Usually denotes the hierarchy of organizational units the detector belongs to and its own name. May also be used to help distinguish sensors running with the same IP address

Hostname of this sensor. 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 can be used to explicitly state that this value was inquired but not found (missing DNS name)

Generic name, brand, version

Standard UN/LOCODE location

Internal location of the sensor

String that describes the capture zone of the sensor in a serialized JSON string

Standard UN/LOCODE location for this source

Internal location description (for internal sources)

GPS coordinates for the source

Free text human-readable additional note

Threat intelligence information about the source

Source IP address (either version 4 or version 6)

Hostname of this source. 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 can be used to explicitly state that this value was inquired but not found (missing DNS name)

User ID or login responsible for the alert

Email address (e.g. the value of the "Reply-To" or "From" header inside a phishing e-mail)

Protocols related to connections from/to this source/target. If several protocols are stacked, they must be ordered from the lowest (the closest to the medium) to the highest (the closest to the application) according to the ISO/OSI model

Source ports involved

Identifiers for attachments related to this source. Each identifier listed here MUST match the "Name" attribute for one of the attachments described using the "Attachment" class

Identifiers for observables related to this source. Each identifier listed here MUST match the "Name" attribute for one of the observables described using the "Observable" class

Standard UN/LOCODE location for this target

Internal location description (for internal target)

GPS coordinates for the target

Free text human-readable additional note

Target IP address (either version 4 or version 6)

Hostname of this target. 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 can be used to explicitly state that this value was inquired but not found (missing DNS name)

Service(s)/process(es) impacted by the event/alert

User ID or login responsible for the alert

Email address (e.g. the value of the "To" header inside a phishing e-mail)

Target ports affected

Identifiers for attachments related to this target. Each identifier listed here MUST match the "Name" attribute for one of the attachments described using the "Attachment" class

Identifiers for observables related to this target. Each identifier listed here MUST match the "Name" attribute for one of the observables described using the "Observable" class

Category for the detected "vector"

Threat intelligence information about the vector

Name of the detected vector or "Unknown"

Average size of the detected vector

UN Location of the vector (e.g. Storm detected on Athens)

GPS coordinates for the vector, providing event geolocation (i.e. where a man/car/animal was detected, a storm/drought/fire risk was predicted, etc.)

Estimated radius around the provided geolocation (error margin) in meters. The value can be very precise or approximated (e.g. 100 m)

Internal location

Free text human-readable additional note

Identifiers for attachments related to this vector. Each identifier listed here MUST match the "Name" attribute for one of the attachments described using the "Attachment" class

Identifiers for observables related to this vector. Each identifier listed here MUST match the "Name" attribute for one of the observables described using the "Observable" class