| Internet-Draft | IDMEFv2 - HTTPS Transport | October 2022 |
| Poirotte, et al. | Expires 18 April 2023 | [Page] |
The Incident Detection Message Exchange Format version 2 (IDMEFv2) provides a way to describe any incidents detected on cyber and/or physical infrastructures.¶
The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to describe cyber and physical potential threats (CTI/PTI).¶
IDMEF improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks on critical infrastructures.¶
If approved this document would obsolete RFC4767.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC-DEV-IDMEFv2] defines a model for the purpose of describing security alerts and incidents as IDMEF version 2 (IDMEFv2) messages. It also defines serialization methods so that IDMEFv2 messages can be exchanged between Computer Security Incident Response Teams (CSIRTs) or those responsible for security incident handling for service providers (SPs). The defined serializations make it easy for CSIRTs to exchange data in a way that is both easy and secure for machines to parse.¶
IDMEFv2 defines a message format, not a protocol, as the sharing of messages is assumed to be out of scope in order to allow CSIRTs to exchange and store messages in a way most suited to their established incident-handling processes. However, a protocol specification is required so that actual exchanges can take place between the involved entities. Defining a common protocol also ensures interoperability between otherwise concurrent implementations.¶
This document specifies the transport of IDMEFv2 messages within [RFC9112] or [RFC9113] Request and Response messages over Transport Layer Security, a.k.a. [RFC9110].¶
Although the IDMEF data model strives to be independent from any particular representation, such a serialization is necessary if IDMEF is to be used as an exchange format. Moreover, an interoperable serialization scheme is required for compatibility reasons.¶
This document describes a serialization method for IDMEF messages based on the [RFC8259].¶
This choice is motivated by the following factors:¶
The JSON format is already largely used inside the cybersecurity community, e.g. to replace the syslog format for log shopping. It thus lowers the barrier to entry for implementors.¶
JSON is often seen as a simpler format compared to XML, from both an implementor's and user's point of view. Because of the way XML works, XML documents are usually larger than JSON ones when representing the same content, due for example to the use of namespaces and the repetition of the elements' tag name inside the markup.¶
An effort has been made to make IDMEF useable from end to end, i.e. from the incident detectors to the operator. IDMEF messages must therefore be easy to store in a database, especially NoSQL databases which are often used to store very large amounts of data. JSON is a good format for native NoSQL storage.¶
In contrast, the authors acknowledge that:¶
JSON may suffer from issues of its own. For instance, string processing may require additional normalization steps (e.g. when comparing two JSON strings). and two JSON parsers may handle duplicate members inside a JSON object differently. These concerns are largely covered in [RFC8259] and in this document's Security Considerations (Section 6).¶
Other formats similar to JSON could also fit this role (e.g. YAML, TOML). Those formats are less widely used by incident management tools and operators. They may also introduce vulnerabilities and incompatibilities of their own (e.g. there are multiple versions of YAML, a YAML document may rely on implementation-specific features using so-called "tags", etc.). In addition, most of those formats focus on human-readability, while this document focuses mainly on performance and security.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
Implementations of IDMEFv2 willing to exchange messages with other implementations are REQUIRED to fully implement:¶
This section specifies the details of the transport of IDMEFv2 messages [RFC-DEV-IDMEFv2] over HTTPS.¶
[BCP56] contains a number of important considerations when using HTTP for application protocols. These include the size of the payload for the application, whether the application will use a web browser, whether the protocol should be defined on a port other than the well-known port for HTTP/HTTPS, and if the security provided through HTTPS suits the needs of the new application.¶
It is acknowledged within the scope of these concerns that HTTPS is not ideally suited for IDMEFv2 transport, as the former is a client-server protocol and the latter a message-exchange protocol; however, the ease of implementation over HTTPS outweighs these concerns.¶
In the context of this document, it is expected that IDMEFv2 Analyzers will act as HTTP clients, while IDMEFv2 Managers act as HTTP servers.¶
However, due to external constraints, implementation-specific design decisions, etc. these roles may sometimes be switched around. This can be especially true when dealing with segmented networks such as demilitarized zones, where the Analyzer may be unable to contact its Manager, or for communications which do not rely on an Analyzer sending IDMEFv2 messages to a Manager (e.g. for Manager-to-Manager communications). Such specific cases are outside the scope of this specification.¶
Consistent with [BCP56], compatible system participating in a consortium and hosting a server for the purpose of receiving IDMEFv2 message using this specification SHOULD listen for TCP connections on port 12345 (see in Section 7 for more information).¶
The systems MAY be configurable so as to allow listening on ports other than the well-known port; this configuration is out of scope for this specification.¶
The implementations MUST implement all REQUIRED functionality for [RFC9112]. The implementations SHOULD implement all REQUIRED functionality for [RFC9113] in a TLS context. In particular, the implementations SHOULD support HTTP/2 protocol negociation using the [RFC7301] as defined in [RFC9113] ch 3.3. The "h2c" protocol (HTTP/2.0 over cleartext) MUST NOT be used. HTTP over TLS (also known as HTTPS) is specified in [RFC9110] ch 2.¶
Each IDMEFv2 message MUST be sent as a separate HTTP Request. However, an implementation MAY send multiple HTTP Requests in parallel to achieve higher message throughput. This can be done by creating a separate connection to the HTTP server for each request, or by using any multiplexing mechanism provided by the underlying protocol (see for example [RFC9113] ch 5).¶
All IDMEFv2 messages sent in HTTP Requests MUST be sent using the POST method. In addition, the Request-URI of such requests SHOULD be set to '/' for interoperability, but an implementation MUST also be able to handle alternative paths to cope with situations where URI rewriting may be used (e.g. by a reverse proxy server).¶
As IDMEFv2 messages MUST be sent using the POST method, a compatible implementation SHOULD answer with an appropriate HTTP code (405 Method Not Allowed) to requests made using any other method.¶
If a request is made to a Request-URI other than the one dedicated to the processing of IDMEFv2 messages, the server SHOULD return an appropriate HTTP code (e.g. 404 Not Found).¶
The HTTP Request's body MUST be set to the serialized form of the IDMEFv2 message. Since an IDMEFv2 message can be serialized in a variety of ways, the 'Content-Type' Request header [RFC2045] MUST be set to a media type [RFC2046] that reflects the mechanism used to perform the serialization. If the server does not support the media type sent by the client, it SHOULD respond with an appropriate HTTP code (415 Unsupported Media Type).¶
A conforming IDMEFv2 system acting as an HTTP server MUST support content negotiation based on the value of the 'Accept' Request header sent by the client. If the client does not advertise supported media types (i.e. omits the 'Accept' header), the server MUST default to 'application/json' and use the format defined in [RFC8259] to build the HTTP response. If the server does not support any of the media types advertised by the client, it SHOULD respond with an appropriate HTTP code (406 Not Acceptable).¶
If the Response does not contain a body, the appropriate HTTP code SHOULD be returned to the client (204 No Content). In this case, the 'Content-Type' header can be omitted from the HTTP Response entirely.¶
To improve compatibility between implementations, it is RECOMMENDED that all IDMEFv2 systems conforming to this document support the JSON serialization format defined in [RFC-DEV-IDMEFv2], with a media type set to 'application/json'.¶
If an IDMEFv2 system receives an improper IDMEFv2 message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting system (e.g. 400 Bad Request).¶
The HTTP code serves as an acknowledgment of the message. The receiving IDMEFv2 system SHOULD NOT confirm acceptance of a message (2xx) unless it managed to safely deal with it, e.g. by saving the message to disk / in a database, or by relaying it to another system that successfully acknowledged it for further processing.¶
If an IDMEFv2 implementation cannot process an IDMEFv2 message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting system.¶
Note that HTTP provides no mechanism for signaling to a server that a Response body is not a valid IDMEFv2 response. If an IDMEFv2 system receives an improper HTTP Response, or cannot process an HTTP Response due to an error on its own side, it MUST log the error and present it to the IDMEFv2 system administrator for handling; the error logging format is considered an implementation detail and is out of scope for this specification.¶
Appendix B provides informative guidance on how to map various error conditions to an appropriate HTTP result code.¶
IDMEFv2 systems relying on HTTP/1.1 MUST support and SHOULD use HTTP/1.1 persistent connections as described in [RFC9112]. IDMEFv2 systems MUST support chunked transfer encoding on the HTTP server side to allow the implementation of clients that do not need to pre-calculate message sizes before constructing HTTP headers.¶
The use of stable DNS names to address IDMEFv2 systems is RECOMMENDED; this facilitates connection to IDMEFv2 systems within a consortium. The protocol provides no in-band method for handling a change of address of an IDMEFv2 system.¶
IDMEFv2 systems SHOULD use TLS version 1.3 [RFC8446] or higher for confidentiality, identification, and authentication, when sending IDMEFv2 messages over HTTPS.¶
IDMEFv2 systems MUST NOT request, offer, or use any version of SSL, or any version of TLS prior to 1.3, due to known weaknesses in these protocols; see [RFC8446] ch E for more information.¶
The TLS session MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality. IDMEFv2 systems MUST NOT use ciphersuites with known vulnerabilities and MUST use ciphersuites that provide Perfect Forward Secrecy to protect the messages' confidentiality in case a vulnerability is later discovered in the ciphersuites.¶
Administrators can find guidance regarding the selection of acceptable ciphersuites for TLS version 1.2 in [BCP195].¶
IDMEFv2 systems MUST use mutual authentication; that is, both IDMEFv2 systems acting as HTTPS clients and IDMEFv2 systems acting as HTTPS servers MUST be identified by an X.509 certificate [RFC5280]. Mutual authentication requires full path validation on each certificate, as defined in [RFC5280].¶
All IDMEFv2 systems SHOULD be identified by a certificate containing a DNS-ID identifier as in [RFC6125] ch 6.4; Common Names (CN-IDs) MUST NOT be included in certificates identifying IDMEFv2 systems.¶
IDMEFv2 systems MUST verify the reference identifiers of their peers against those stored in the certificates presented using the methods defined in [RFC6125]. In addition, the following IDMEFv2-specific considerations apply:¶
Wildcards MUST NOT appear in the DNS-ID of a certificate identifying an IDMEFv2 system. If such a certificate is received by an IDMEFv2 system, the verification MUST fail and the receiving IDMEFv2 system MUST close the connection.¶
An IDMEFv2 system MAY match the DNS-ID with a reverse DNS lookup of the connecting IDMEFv2 peer; this support SHOULD allow the lookup to be cached and/or done in advance in order to ensure verifiability during instability or compromise of DNS itself.¶
IDMEFv2 systems MUST support the verification of certificates against an explicit list of approved peer certificates.¶
IDMEFv2 systems MAY apply additional security measures such as IP filtering to further restrict the list of authorized peers. Such additional defenses are outside of the scope of this specification.¶
This document makes no provision on whether the security consortium implementing IDMEFv2 is responsible or not for issuing the certificates used by the systems.¶
In a PKIX certificate to be presented by an IDMEFv2 system, the certificate MUST include one or more identifiers associated with the IDMEFv2 system.¶
The following IDMEFv2-specific considerations apply:¶
Support for the DNS-ID identifier type [RFC5280] is REQUIRED in both IDMEFv2 Analyzers and Managers. Certification authorities that issue IDMEFv2-specific certificates MUST support the DNS-ID identifier type. IDMEFv2 service providers SHOULD include the DNS-ID identifier type in certificate requests.¶
Support for the SRV-ID identifier type [RFC4985] is REQUIRED in both IDMEFv2 Analyzers and Managers implementations using the "_idmef" application service type. Certificate authorities that issue IDMEFv2-specific certificates SHOULD support the SRV-ID identifier type. IDMEFv2 service providers SHOULD include the SRV-ID identifier type in certificate requests.¶
Support for the URI-ID identifier type ([RFC5280] and [RFC3986]) is OPTIONAL for both IDMEFv2 Analyzers and Managers. Certification authorities that issue IDMEFv2-specific certificates SHOULD support the URI-ID identifier type. IDMEFv2 service providers MAY include the URI-ID identifier type in certificate requests.¶
Support for the CN-ID identifier type [RFC5280] is discouraged. Certification authorities that issue IDMEFv2-specific certificates SHOULD NOT support the CN-ID identifier type. IDMEFv2 service providers MUST NOT include the CN-ID identifier type in certificate requests.¶
DNS domain names in IDMEFv2-specific certificates MUST NOT contain the wildcard character '*'. Certification authorities that issue IDMEFv2-specific certificates MUST refuse to issue certificates containing a wildcard character.¶
Great care must be taken by administrators when selecting the PKI to use, as trusting a rogue PKI could have dramatic results on the integrity, confidentiality and authentication mechanisms provided by TLS; and hence, result in the compromise of the protocol defined in this specification.¶
Information about an organization's IDMEFv2 over HTTPS endpoint's location may be stored using DNS Service Location Records (SRV) [RFC2782]. The data in a SRV record contains the DNS name of the server that provides the IDMEFv2 over HTTPS server, the corresponding Port number, and parameters that enable the client to choose an appropriate server from multiple servers according to the algorithm described in [RFC2782]. The name of this record has the following format:¶
_<Service>._<Proto>.<Domain>¶
where <Service> is always "idmef", and <Proto> is always "tcp". <Domain> is the domain name of the entity exposing the endpoint. Note that "idmef" is the symbolic name for the IDMEFv2 over HTTPS service in Assigned Numbers [RFC3232], as required by [RFC2782].¶
Presence of such records enables clients to find the IDMEFv2 over HTTPS endpoints using standard DNS query. An IDMEFv2 system seeking the endpoint for a particular entity, does a SRV record query using the DNS name formed as described in the preceding paragraph, and interprets the response as described in [RFC2782] to determine a host (or set of hosts) to contact. As an example, a client that searches for the IDMEFv2 over HTTPS endpoint for "example.net" will submit a DNS query for a set of SRV records with owner name:¶
_idmef._tcp.example.net.¶
The requesting system will receive the list of SRV records published in DNS that satisfy the requested criteria. The following is an example of such a record:¶
_idmef._tcp.example.net. IN SRV 0 0 12345 soc.example.net.¶
The set of returned records may contain multiple records in the case where multiple servers can act as endpoints for the same domain. If there are no matching SRV records available for the domain name, the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name.¶
This serialization method aims to convert IDMEFv2 messages to a format that is easy to parse and process, both by software/hardware processors, as well as humans.¶
It relies on the the JavaScript Object Notation (JSON) Data Interchange Format defined in [RFC8259].¶
Conforming implementations MUST implement all the requirements specified in [RFC8259].¶
In addition, the following rules MUST be observed when serializing an IDMEFv2 message:¶
The top-level Alert class ([RFC-DEV-IDMEFv2] ch 4.2) is represented as a JSON object ([RFC8259] ch 4). This JSON object is returned to the calling process at the end of the serialization process.¶
Aggregate classes are represented as JSON objects and stored as members of the top-level JSON object, using the same name as in the IDMEF data model. E.g. the Analyzer aggregate class ([RFC-DEV-IDMEFv2] ch 4.3) appears under the name "Analyzer" inside the top-level JSON object.¶
Attributes are stored as members of the JSON object representing the class they belong to, using the same name as in the IDMEF data model. E.g. the "Version" attribute of the Alert class is stored under the name "Version" inside the top-level JSON object.¶
Lists from the IDMEF data model are represented as JSON arrays ([RFC8259] ch 5). This also applies to aggregate classes where a list is expected. E.g. the "Sensor" member inside the top-level JSON object contains a list of objects, where each object represents an instance of the Sensor aggregate class ([RFC-DEV-IDMEFv2] ch 4.4).¶
The various string-based data types listed in [RFC-DEV-IDMEFv2] ch 3.3 are represented as JSON strings ([RFC8259] ch 7). Please note that the issues outlined in [RFC8259] ch 8 regarding strings processing also apply here.¶
Since JSON does not provide a way to distinguish between an integer value and a floating-point (decimal) value, IDMEF attributes with the "INT" and "FLOAT" type annotations are both represented as JSON numbers ([RFC8259] ch 6).¶
Most of the content in Section 4 deals with security considerations. Great care has been taken to protect the confidentiality, authentification and integrity of IDMEFv2 messages while in transit.¶
In addition, to the requirements set in Section 4, all security considerations of related documents apply, especially the Incident Detection Message Exchange Format version 2 [RFC-DEV-IDMEFv2]. Implementations should also be aware of known attacks against Transport Layer Security (TLS) and Datagram TLS (DTLS), and how to mitigate them [RFC7457].¶
Specific considerations have been taken into account regarding certificates usage:¶
Use of the wildcard character inside certificates lacks clear specifications and consistency across application technologies. Considering the issues outlined in [RFC6125] ch 7.2 regarding such certificates, the use of wildcard characters inside certificates is explicitly prohibited in this document.¶
Use of the Common Name field (CN-ID) has been deprecated for a long time ([RFC9110] ch 3.1). Moreover, this field does not cope well with multiple identifiers ([RFC6125] ch 7.4). As such, this document explicitly prohibits the use of CN-IDs altogether.¶
IDMEFv2 systems MAY implement additional security measures (e.g. confidentiality and integrity of specific data inside the message at the field's level). Such additions SHOULD be designed with interoperability in mind, so that implementations that do not recognize these extensions can still process IDMEFv2 messages in a reasonable manner without degrading the security provided by these additions (e.g. by omitting the additions entirely when passing the message to another system, or by handling them as opaque data). The design of such measures is outside the scope of this document.¶
Consistent with [BCP56], since IDMEFv2 over HTTP/TLS is a substantially new service, and should be controlled at the consortium member network's border differently than HTTP/TLS, it requires a new port number.¶
IANA has assigned port 12345/tcp to IDMEFv2 over HTTP/TLS with service name "IDMEFv2 over HTTP/TLS".¶
This section contains several examples of events/incidents described using the IDMEF Data Model.¶
For each example, the serialization method listed in Section 5 was used on the original IDMEF message to produce a JSON representation.¶
Appendix A.1 describes an incident where an unidentified man was detected on company premises near the building where server room A is located.¶
{
"Version": "2.0",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b1",
"Description": "Potential intruder detected",
"Severity": "Low",
"Status": "Incident",
"Cause": "Malicious",
"CreateTime": "2021-05-10T16:52:13.075994+00:00",
"StartTime": "2021-05-10T16:52:13+00:00",
"Category": [
"Intrusion.Burglary"
],
"Analyzer": {
"Name": "BigBrother",
"Hostname": "bb.example.com",
"Type": "Physical",
"Model": "Big Brother v42",
"Category": [
"HAR",
"FRC"
],
"Data": [
"Images"
],
"Method": [
"Movement",
"Biometric",
"AI"
],
"IP": "192.0.2.3"
},
"Sensor": [
{
"IP": "192.0.2.4",
"Name": "Camera #23",
"Model": "SuperDuper Camera v1",
"Location": "Hallway to server room A1"
}
],
"Source": [
{
"Note": "Black Organization, aka. APT 4869"
}
],
"Vector": [
{
"Category": ["Man"],
"TI": ["Name:FBI-Wanted"],
"Name": "John Doe",
"Note": "Codename Vodka, known henchman for APT 4869",
"Size": "Medium",
"Location": "Hallway to server room A1",
"Attachment": ["pic01", "wanted"]
}
],
"Attachment": [
{
"Name": "wanted",
"FileName": "fbi-wanted-poster.jpg",
"Size": 1234567,
"Ref": ["https://www.fbi.gov/wanted/topten"],
"ContentType": "image/jpg",
"ContentEncoding": "base64",
"Content": "VC4gQW5kcmVqYWssIEcuIExlaG1hbm4sIEYuIFBvaXJvdHRl"
},
{
"Name": "pic01",
"Note": "Hi-res picture showing John Doe near server room A1",
"ExternalURI": ["ftps://192.0.2.3/cam23/20210510165211.jpg"],
"ContentType": "image/jpg"
}
]
}
¶
Appendix A.2 describes an incident related to a potential bruteforce attack against the "root" user account of the server at 192.0.2.2 and at 2001:db8::/32.¶
{
"Version": "2.0",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b2",
"Description": "Potential bruteforce attack on root user account",
"Severity": "Medium",
"CreateTime": "2021-05-10T16:55:29.196408+00:00",
"StartTime": "2021-05-10T16:55:29+00:00",
"Category": [
"Attempt.Login"
],
"Analyzer": {
"Name": "SIEM",
"Hostname": "siem.example.com",
"Type": "Cyber",
"Model": "Prelude SIEM 5.2",
"Category": [
"SIEM",
"LOG"
],
"Data": [
"Log"
],
"Method": [
"Monitor",
"Signature"
],
"IP": "192.0.2.2"
},
"Sensor": [
{
"IP": "192.0.2.3",
"Name": "syslog",
"Hostname": "www.example.com",
"Model": "rsyslog 8.2110",
"Location": "Server room A1, rack 10"
}
],
"Target": [
{
"IP": "192.0.2.3",
"Hostname": "www.example.com",
"Location": "Server room A1, rack 10",
"User": "root"
}
]
}
¶
Appendix A.3 describes an incident where the webserver at "www.example.com" encountered some kind of failure condition resulting in an outage.¶
{
"Version": "2.0",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b3",
"Description": "A server did not reply to an ICMP ping request",
"Severity": "Medium",
"Status": "Incident",
"Cause": "Unknown",
"CreateTime": "2021-05-10T16:59:11.875209+00:00",
"StartTime": "2021-05-10T16:59:11.875209+00:00",
"Category": [
"Availability.Outage"
],
"Analyzer": {
"Name": "NMS",
"Hostname": "nms.example.com",
"Type": "Availability",
"Model": "Vigilo NMS 5.2",
"Category": [
"NMS"
],
"Data": [
"Network"
],
"Method": [
"Monitor"
],
"IP": "192.0.2.1"
},
"Target": [
{
"IP": "192.0.2.2",
"Hostname": "www.example.com",
"Service": "website",
"Location": "Server room A1, rack 10"
}
]
}
¶
Appendix A.4 describes a combined incident resulting from the correlation of the previous physical, cyber and availability incidents.¶
{
"Version": "2.0",
"ID": "819df7bc-35ef-40d8-bbee-1901117370b4",
"Description": "Intrusion and Sabotage detected",
"Severity": "High",
"Status": "Incident",
"Cause": "Malicious",
"CreateTime": "2021-05-10T16:59:15.075994+00:00",
"StartTime": "2021-05-10T16:52:11+00:00",
"Category": [
"Intrusion.Burglary",
"Attempt.Login",
"Intrusion.SysCompromise",
"Availability.Outage",
"Availability.Sabotage",
"Availability.Failure"
],
"CorrelID": [
"819df7bc-35ef-40d8-bbee-1901117370b1",
"819df7bc-35ef-40d8-bbee-1901117370b2",
"819df7bc-35ef-40d8-bbee-1901117370b3"
],
"Analyzer": {
"Name": "Correlator",
"Hostname": "correlator.example.com",
"Type": "Combined",
"Model": "Unity 360 Hybrid Correlator v5.2",
"Category": [
],
"Data": [
"Alert"
],
"Method": [
"Correlation"
],
"IP": "192.0.2.4"
},
"Source": [
{
"Note": "Black Organization, aka. APT 4869"
}
],
"Vector": [
{
"Category": ["Man"],
"TI": ["Name:FBI-Wanted"],
"Name": "John Doe",
"Note": "Codename Vodka, known henchman for APT 4869",
"Size": "Medium"
}
],
"Target": [
{
"Location": "Server room A1"
},
{
"IP": "192.0.2.2",
"Hostname": "www.example.com",
"User": "root"
},
{
"IP": "192.0.2.2",
"Hostname": "www.example.com",
"Service": "website"
}
]
}
¶
The following table MAY be used as general guidance by IDMEFv2 systems acting as HTTP servers when mapping various error conditions to an appropriate HTTP result code.¶
Result codes other than the ones listed below MAY still be used, so long as their semantics match the requirements set in Section 4.¶
|
Error condition¶ |
HTTP result code¶ |
|---|---|
|
No error¶ |
2xx, usually 200 (OK) or 204 (No content)¶ |
|
Malformed HTTP request (e.g. the HTTP request's body is not a valid IDMEFv2 message)¶ |
400 (Bad request)¶ |
|
Unauthorized request (e.g. a request from an unauthorized IP address)¶ |
403 (Forbidden)¶ |
|
The HTTP request uses a method other than 'POST'¶ |
405 (Method Not Allowed). In addition, the "Allow" HTTP response header MUST be set accordingly when this code is used.¶ |
|
Failure to negotiate the response's media type based on the "Accept" HTTP request header.¶ |
406 (Not Acceptable)¶ |
|
Missing "Content-Length" request header in case the implementation does not support the chunked transfer encoding¶ |
411 (Length required), but please note that conforming implementations are REQUIRED to support the chunked transfer encoding¶ |
|
Exceedingly long IDMEFv2 message (e.g. the message is considered to be too big due to size restrictions applied by an administrator)¶ |
413 (Request entity too large)¶ |
|
Unsupported serialization format¶ |
415 (Unsupported media type)¶ |
|
Internal server error¶ |
500 (Internal server error)¶ |
|
Unavailable service (e.g. the IDMEFv2 system is overloaded or the next processing service is unavailable)¶ |
503 (Service unavailable)¶ |
In the examples below, ">" denotes a request sent by the IDMEFv2 system acting as an HTTP client to an IDMEFv2 system acting as an HTTP server, while "<" denotes a response to such requests.¶
In this example, the IDMEFv2 system acting as an HTTP server acknowledges the message sent by an IDMEFv2 system acting as an HTTP client. Because the HTTP server does not wish to send any content back to the client, it replies with HTTP result code 204 (No content), and both the "Content-Type" and "Content-Length" headers are omitted from the response.¶
> POST / HTTP/1.1\r\n
> Host: idmefv2.example.com:12345\r\n
> Content-Type: application/json\r\n
> Content-Length: 1234\r\n
> Accept: application/json
> \r\n
> {"Version": "..."}
< 204 No content\r\n
< Connection: close\r\n
< \r\n¶
The following example illustrates the situation where an IDMEFv2 system acting as an HTTP client tries to send a message using a serialization format (media type) that is either not recognized or not supported by the IDMEFv2 system acting as an HTTP server.¶
> POST / HTTP/1.1\r\n
> Host: idmefv2.example.com:12345\r\n
> Content-Type: application/x-idmefv2\r\n
> Content-Length: 1234\r\n
> Accept: application/json
> \r\n
> ...
< 415 Unsupported media type\r\n
< Connection: close\r\n
< Content-Type: application/json\r\n
< Content-Length: 61\r\n
< \r\n
< {"error": "Unsupported or unrecognized serialization format"}¶
In this example, the IDMEFv2 system acting as an HTTP client sends an IDMEFv2 message and requests that the server reponds using the "application/x-example-type" media type.¶
Since the server wishes to include details in the HTTP response but does not know how to generate a response using that media type, it sends back a page using HTTP result code 406 (Not acceptable).¶
The response's body may contain additional information about the media types the server is willing to use and the client may try to resend the request using one of the alternative media types presented inside the new HTTP request's "Accept" header.¶
> POST / HTTP/1.1\r\n
> Host: idmefv2.example.com:12345\r\n
> Content-Type: application/json\r\n
> Content-Length: 1234\r\n
> Accept: application/x-example-type
> \r\n
> ...
< 406 Not Acceptable\r\n
< Connection: close\r\n
< Content-Type: application/json\r\n
< Content-Length: 111\r\n
< \r\n
< {"error": "Cannot reply using 'application/x-example-type'
media type",\n"alternatives": ["application/json"]}\n¶