h1. IDMEFV2

One of SECEF's projects was to build a new IDMEF structure, that referred to as IDMEF V2.

Here are listed the changes that we think could be insteresting to include in the V2.

All of these changes were discussed during meetings or on the forum.

In red are the fields or class to be suppressed, the others are to be added.

|_.Evolution|_.Class|_.Field|_. Type   |

|/2. Identifier la date de début et de fin d'un événement (scan, propagation de vers, etc.) ou une durée

*YV: Rôle déjà rempli par CreateTime / detectTime*

*SM: Pas forcément une attaque sur une durée peut commencer à 10h finir à 11h, être détectée à 10h30 et être créée à 11h01 (IODEF fait aussi cette distinction)*

| StartTime     |   Date | Date|

                                                                                                         | EndTime       |   Date | Date|

|Champs pour identifer le protocole de transport (TCP, UDP) indépendamment du protocole applicatif 

*YV: déjà sur-présent, iana_protocol_number, iana_protocol_name, name, port*      

*SM: Je me trompe peut être, mais on peut représenter que le protocol applicatif non ? On peut pas différencier un HTTP over UDP et HTTP over TCP (c'est un mauvais exemple comme c'est forcément TCP, mais j'en avais pas d'autres sous la main ^^)*

| Service       | transport_protocol |ATP

CUDP

DCCP

FCP

IL

MPTCP

RDP

RUDP

SCTP

SPX

SST

TCP

UDP

UDP Lite

µTP|

|Gérer les adresses et les ports translatés.| Address | translation |no_translation

pre_trabslation

post_translation|

|/3.Attachement du log originel (plus specifique que Additional Data)|/3.Classification->Origin|origin|log_analysis

sensor|

|signature|String|

|log|String|

|Compteur d'occurrence des événements qui sont agrégés dans une alerte|Origin|counter|Integer|

|Champs pour identifier le thread *YV: intérêt très limité IMHO* |Process| TID|Integer|

|/2.Distinguer la sévérité d'une attaque, la vulnérabilité probable de la cible, la criticité de la cible et la priorité finale de l'alerte|/2.Impact|target_vulnerability|Enum|

|target_criticity|Enum|

|Supprimer les OverflowAlerts

*YV: ça semble être une mauvaise idée. Pourquoi ?*

*SM: Pourquoi faire la distinction entre les Alertes Overflow et pas les autres ? Dans ce cas on pourrait mettre les injections SQL, non ?...*

|\3{background:#e99b9b}.OverflowAlerts|

|Ajouter un champs pour identifier la catégorie d'un hôte|Node|type|Enum à travailler|

|/6.Gestion explicite des données de géolocalisation (longitude, lattitude, ville pays)|/5.Node->Location|latitude|float|

|longitude|float|

|city|String|

|country|String|

|state|String|

|{background:#e99b9b}.Node|\2{background:#e99b9b}.Location|

|/4.Compléter la classe WebService|/2.WebService->WebServiceHeaderParams|parameter|host

referer

user-agent

server

cookie

http-method

other|

|value|String|

|/2.WebService->WebServiceParams

*YV: WebService->arg ?*

*SM: Les paramètres HTTP sont sous formes de clé/valeur on ne peut pas les mettre non dans arg, si ?*

|parameter|String|

|value|String|

|/16.Ajouter des sous-classes à la classe Service|/4.Service->LDAPService|url|String|

|operation|start_tls

bind

search

compare

add

delete

modify

modify_dn

abandon

extended-operation

unbind

other|

|ext-operation|String|

|dn|String|

|/2.LDAPService->LDAPServiceParams|parameter|scope

filter

deref_aliases

attribute

sizelimit

timelimit

sizeonly

ext-type|

|ext-type|String|

|/4.Service->SIPService|uri|String|

|request|INVITE

ACK

BYE

CANCEL

OPTIONS

REGISTER

PRACK

SUBSCRIBE

NOTIFY

PUBLISH

INFO

referer

MESSAGE

UPDATE

other|

|ext-request|String|

|response|integer|

|/2.SIPService->HeaderSIPService|parameter|Enum|

|value|String|

|/4.Service->SMTPService|messsageid|String|

|user-agent|String|

|subject|String|

|references|String|