Project

General

Profile

IDMEFV2 » History » Version 10

Version 9 (Anonymous, 10/27/2015 10:52 AM) → Version 10/22 (Anonymous, 10/27/2015 10:55 AM)

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 détecter à 10h30 et être créée créer à 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, 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, 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|