no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | en:other_formats [02.12.2014 10:19] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Other formats ====== | ||
+ | |||
+ | This page describes our review of existing formats and tries to explain, why we are not using one of them. It works as summarization of benefits and drawbacks of each of them, together with our subjective remarks. | ||
+ | |||
+ | ===== IDMEF ===== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | It is based on and very tightly coupled with XML and its structure makes heavy use of its paradigms. | ||
+ | |||
+ | It has rigid structure and some fields are dynamic (it is for example able to represent more sources or destinations of the attack). Structure is also very deep and wordy, for example to address attack source IP address, we have to use locator “Alert.Source.Node.Address.address”. Some fields are also recursive, so depth of its structure is not limited and can be arbitrary. | ||
+ | |||
+ | IDMEF has limited means to allow extensibility: | ||
+ | |||
+ | * by global key/value pairs, which are however tied to message, not to specific source, target or other key | ||
+ | * by own XML namespace in specific place of the structure (which brings in need for full fledged XML parser and higher complexity in IDMEF tools) | ||
+ | |||
+ | Specification often mentions subclassing and aggregation, | ||
+ | |||
+ | Format is often redundant – timestamps are represented both in machine readable format and human representation, | ||
+ | |||
+ | Also it is sometimes inconsistent – it supports long list of historic (or even obsolete) network protocols in one field, however URL and SNMP are classes on its own. | ||
+ | |||
+ | Incident type is free text, but there exist specific classes for buffer overflow, correlation, | ||
+ | |||
+ | Format can be validated against the thoroughly defined schema (which is a good thing), however schema itself is not enough – some cases must be validated specifically (for example timestamps, IP addresses). | ||
+ | |||
+ | IDMEF is in fact the basis for our design, it is format which is able to describe the widest number of incident types. The basic problems are its verbosity, depth and attempts to describe “everything”. According to our experiences, | ||
+ | |||
+ | See also: | ||
+ | * Demchenko, Y., //IODEF Design principles and relation to IDMEF//, TERENA: [[http:// | ||
+ | * Demchenko, Y., //Relations between IODEF and IDMEF//, TERENA: [[http:// | ||
+ | |||
+ | ===== X-ARF ===== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | The basis of the event description is set of keys and values, which is enclosed in MIME/DSN encoded container along with human readable description, | ||
+ | |||
+ | Different types of events | ||
+ | |||
+ | Also this format has some reusable ideas: | ||
+ | * TLP field explains to receiver what level of privacy it expects by Traffic Light Protocol1. | ||
+ | * Antivirus-Result and Antivirus-Vendor keys can be used to enrich security event by automated analysis | ||
+ | * DNSBL – name of blacklist, where (possibly) malicious IP address appeared | ||
+ | |||
+ | ===== IODEF ===== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | IODEF is able to describe the whole case and its timeframe, not only one event – each decisive or communication action can be documented. | ||
+ | |||
+ | Like IDMEF, it has limited means for extending, but usable only on several explicitly defined places. | ||
+ | |||
+ | Specification also suggests, that some kind of interoperability with IDMEF is possible. According to our observation, | ||
+ | |||
+ | There is much of freedom in representation of Assessment field, types and semantics are dependent on attributes. Sender can choose one representation, | ||
+ | |||
+ | Interesting ideas to reuse: | ||
+ | * AlternativeID – bears the incident tracking numbers used by other teams/nodes to locally refer to the same incident. Good for backwards pairing of incident. | ||
+ | * IncidentID.name – an identifier describing the security team that created the document. | ||
+ | |||
+ | See also: | ||
+ | * Demchenko, Y., //IODEF Design principles and relation to IDMEF//, TERENA: [[http:// | ||
+ | * Demchenko, Y., //Relations between IODEF and IDMEF//, TERENA: [[http:// | ||
+ | |||
+ | ===== Warden ===== | ||
+ | |||
+ | Format, used by [[http:// | ||
+ | |||
+ | It could be explained as an analogy of netflow for security incidents. Warden messages are rigid static messages, which (similarly to X-ARF) cannot describe more sources and/or more destinations. Also, information about target of attack is by design incomplete (users usually do not want to spoil addresses of their honeypot systems), however that complicates more general usage, because in incidents against production infrastructure this information may be vital for analysis. | ||
+ | |||
+ | There is no extensibility – just free text field for additional data, mostly meant for human inspection. | ||
+ | |||
+ | Format is used as SOAP serialized HTTP/RPC call – advantage is simple implementation, | ||
+ | |||
+ | Incident timeframe information is incomplete – bulk incidents can get aggregated, but format does not specify, whether timestamp describes start of aggregation window, its end or moment of aggregation. | ||
+ | |||
+ | The specific of this format is tagged description of detection probes – receiver can deduce probe capabilities without exact knowledge of detection software. However, reader must explicitly request this information via another RPC call. | ||
+ | The code is under open-source/ | ||
+ | |||
+ | ===== AbuseHelper ===== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | The messages are free sets of keys and values, which do not specify any semantics. On key can contain one value, or set of unique values (so it has limited support for more than one source or destination). | ||
+ | |||
+ | The code is under open-source/ | ||
+ | |||
+ | By inspection of code in “contrib” directory we can obtain a (fundamentally incomplete) list of keys: | ||
+ | |||
+ | // | ||
+ | |||
+ | This freedom in key assignment can cause inconsistencies in processing, semantics must get guessed from the code of generating agents or by best effort heuristics. | ||
+ | |||
+ | Important note to make is that none of mentioned formats directly supports anonymization. | ||