Project

General

Profile

IDMEFV2 » History » Version 14

Yoann Vandoorselaere, 11/03/2015 08:28 AM

1 1 Gilles Lehmann
h1. IDMEFV2
2 2 Anonymous
3 2 Anonymous
One of SECEF's projects was to build a new IDMEF structure, that referred to as IDMEF V2.
4 2 Anonymous
5 8 Anonymous
Here are listed the changes that we think could be insteresting to include in the V2.
6 2 Anonymous
7 8 Anonymous
All of these changes were discussed during meetings or on the forum.
8 2 Anonymous
9 8 Anonymous
In red are the fields or class to be suppressed, the others are to be added.
10 2 Anonymous
11 2 Anonymous
|_.Evolution|_.Class|_.Field|_. Type   |
12 9 Anonymous
|/2. Identifier la date de début et de fin d'un événement (scan, propagation de vers, etc.) ou une durée
13 9 Anonymous
*YV: Rôle déjà rempli par CreateTime / detectTime*
14 10 Anonymous
*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)*
15 14 Yoann Vandoorselaere
*YV: ça fait a mon avis parti des Best Practices : IE une sonde devrait toujours positionner l'élément DetectTime à l'heure du premier évènement détecté (quel qu'il soit : un paquet, une première alerte corrélée, etc* 
16 9 Anonymous
| StartTime     |   Date | Date|
17 1 Gilles Lehmann
                                                                                                         | EndTime       |   Date | Date|
18 9 Anonymous
|Champs pour identifer le protocole de transport (TCP, UDP) indépendamment du protocole applicatif 
19 9 Anonymous
*YV: déjà sur-présent, iana_protocol_number, iana_protocol_name, name, port*      
20 9 Anonymous
*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 ^^)*
21 12 Guillaume Hiet
*GH : DNS est un meilleur exemple. Je crois me souvenir qu'Hervé avait évoqué la possibilité de préciser le port sous la forme TCP:53 ou UDP:53. Cela éviterait l'ajout d'un champs dédié mais il faudrait vérifier que la V1 d'IDMEF le permet effectivement et surtout faire un tuto à ce sujet. Je préfère la solution d'un champs dédié (je préfère des champs les plus "atomiques" et homogène possibles).*
22 9 Anonymous
| Service       | transport_protocol |ATP
23 2 Anonymous
CUDP
24 2 Anonymous
DCCP
25 2 Anonymous
FCP
26 2 Anonymous
IL
27 2 Anonymous
MPTCP
28 2 Anonymous
RDP
29 2 Anonymous
RUDP
30 2 Anonymous
SCTP
31 2 Anonymous
SPX
32 2 Anonymous
SST
33 2 Anonymous
TCP
34 2 Anonymous
UDP
35 2 Anonymous
UDP Lite
36 2 Anonymous
µTP|
37 13 Guillaume Hiet
|Gérer les adresses et les ports translatés.
38 13 Guillaume Hiet
*GH: On avait évoqué l'idée d'augmenter le dictionnaire associé à address.category plutôt que d'ajouter un champs dédié...*
39 13 Guillaume Hiet
| Address | translation |no_translation
40 2 Anonymous
pre_trabslation
41 2 Anonymous
post_translation|
42 2 Anonymous
|/3.Attachement du log originel (plus specifique que Additional Data)|/3.Classification->Origin|origin|log_analysis
43 2 Anonymous
sensor|
44 2 Anonymous
|signature|String|
45 5 Yoann Vandoorselaere
|log|String|
46 1 Gilles Lehmann
|Compteur d'occurrence des événements qui sont agrégés dans une alerte|Origin|counter|Integer|
47 1 Gilles Lehmann
|Champs pour identifier le thread *YV: intérêt très limité IMHO* |Process| TID|Integer|
48 13 Guillaume Hiet
|/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
49 13 Guillaume Hiet
*GH: tant qu'à faire, je rajouterais alert_priority. Remarque au passage, cela pose le problème de la portée du format. Si c'est juste un format sonde->SIEM, ces champs sont peu pertinents (ce n'est pas le rôle d'une sonde de juger la criticité. Par contre, si IDMEF est un format d'import/exeport entre sonde, SIEM et autres outils, çà a du sens...*
50 13 Guillaume Hiet
|/2.Impact|target_vulnerability|Enum|
51 1 Gilles Lehmann
|target_criticity|Enum|
52 9 Anonymous
|Supprimer les OverflowAlerts
53 1 Gilles Lehmann
*YV: ça semble être une mauvaise idée. Pourquoi ?*
54 9 Anonymous
*SM: Pourquoi faire la distinction entre les Alertes Overflow et pas les autres ? Dans ce cas on pourrait mettre les injections SQL, non ?...*
55 13 Guillaume Hiet
*GH: OverFlow alert pose le problème de l'homogénéité du format. Soit on propose différents sous-type pour couvrir les différents types d'attaques les plus courant. On court le risque de l'inflation du format (qui est déjà assez verbeux. Se pose aussi la question de la maintenabilité. Typiquement, ce type d'information nécessite de fréquentes mises à jour vu la fréquance d'apparition des nouveaux types d'attaques. La seconde option consiste à supprimer cette classe en considérant que le niveau de détail est trop important et inutilisé en pratique (est-ce vrai?)*
56 9 Anonymous
|\3{background:#e99b9b}.OverflowAlerts|
57 2 Anonymous
|Ajouter un champs pour identifier la catégorie d'un hôte|Node|type|Enum à travailler|
58 2 Anonymous
|/6.Gestion explicite des données de géolocalisation (longitude, lattitude, ville pays)|/5.Node->Location|latitude|float|
59 2 Anonymous
|longitude|float|
60 1 Gilles Lehmann
|city|String|
61 2 Anonymous
|country|String|
62 2 Anonymous
|state|String|
63 2 Anonymous
|{background:#e99b9b}.Node|\2{background:#e99b9b}.Location|
64 9 Anonymous
|/4.Compléter la classe WebService|/2.WebService->WebServiceHeaderParams|parameter|host
65 2 Anonymous
referer
66 2 Anonymous
user-agent
67 1 Gilles Lehmann
server
68 1 Gilles Lehmann
cookie
69 1 Gilles Lehmann
http-method
70 1 Gilles Lehmann
other|
71 2 Anonymous
|value|String|
72 9 Anonymous
|/2.WebService->WebServiceParams
73 9 Anonymous
*YV: WebService->arg ?*
74 10 Anonymous
*SM: Les paramètres HTTP sont sous formes de clé/valeur on ne peut pas les mettre non dans arg, si ?*
75 9 Anonymous
|parameter|String|
76 2 Anonymous
|value|String|
77 2 Anonymous
|/16.Ajouter des sous-classes à la classe Service|/4.Service->LDAPService|url|String|
78 2 Anonymous
|operation|start_tls
79 2 Anonymous
bind
80 2 Anonymous
search
81 2 Anonymous
compare
82 2 Anonymous
add
83 2 Anonymous
delete
84 2 Anonymous
modify
85 2 Anonymous
modify_dn
86 2 Anonymous
abandon
87 2 Anonymous
extended-operation
88 2 Anonymous
unbind
89 2 Anonymous
other|
90 2 Anonymous
|ext-operation|String|
91 2 Anonymous
|dn|String|
92 2 Anonymous
|/2.LDAPService->LDAPServiceParams|parameter|scope
93 2 Anonymous
filter
94 2 Anonymous
deref_aliases
95 2 Anonymous
attribute
96 2 Anonymous
sizelimit
97 2 Anonymous
timelimit
98 2 Anonymous
sizeonly
99 2 Anonymous
ext-type|
100 2 Anonymous
|ext-type|String|
101 2 Anonymous
|/4.Service->SIPService|uri|String|
102 2 Anonymous
|request|INVITE
103 2 Anonymous
ACK
104 2 Anonymous
BYE
105 2 Anonymous
CANCEL
106 2 Anonymous
OPTIONS
107 2 Anonymous
REGISTER
108 2 Anonymous
PRACK
109 2 Anonymous
SUBSCRIBE
110 2 Anonymous
NOTIFY
111 2 Anonymous
PUBLISH
112 2 Anonymous
INFO
113 2 Anonymous
referer
114 2 Anonymous
MESSAGE
115 2 Anonymous
UPDATE
116 2 Anonymous
other|
117 2 Anonymous
|ext-request|String|
118 2 Anonymous
|response|integer|
119 2 Anonymous
|/2.SIPService->HeaderSIPService|parameter|Enum|
120 2 Anonymous
|value|String|
121 2 Anonymous
|/4.Service->SMTPService|messsageid|String|
122 2 Anonymous
|user-agent|String|
123 2 Anonymous
|subject|String|
124 2 Anonymous
|references|String|