IDMEFV2 » History » Version 17
Anonymous, 11/04/2015 05:08 PM
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 | 17 | Anonymous | |_.Evolution|_.Impacted Class|_.Proposed Field|_.Type | |
12 | 17 | Anonymous | |/2. [[Start time end time|Indicate start time and end time or a duration for an event such as worm propagation or scan]] |
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 | 17 | Anonymous | |[[Identify transport protocol|Identify transport protocol (TCP, UDP, etc.) regardless of the applicative protocol]] |
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 | 15 | Yoann Vandoorselaere | *YV: TCP et UDP font partis des protocols IANA, leur place naturelle est donc iana_protocol_number et iana_protocol_name. Voir http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml* |
23 | 9 | Anonymous | | Service | transport_protocol |ATP |
24 | 2 | Anonymous | CUDP |
25 | 2 | Anonymous | DCCP |
26 | 2 | Anonymous | FCP |
27 | 2 | Anonymous | IL |
28 | 2 | Anonymous | MPTCP |
29 | 2 | Anonymous | RDP |
30 | 2 | Anonymous | RUDP |
31 | 2 | Anonymous | SCTP |
32 | 2 | Anonymous | SPX |
33 | 2 | Anonymous | SST |
34 | 2 | Anonymous | TCP |
35 | 2 | Anonymous | UDP |
36 | 2 | Anonymous | UDP Lite |
37 | 2 | Anonymous | µTP| |
38 | 17 | Anonymous | |[[Translated addresses and ports|Handle translated addresses and ports]] |
39 | 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é...* |
40 | 13 | Guillaume Hiet | | Address | translation |no_translation |
41 | 2 | Anonymous | pre_trabslation |
42 | 2 | Anonymous | post_translation| |
43 | 17 | Anonymous | |/3.[[Original log|Add original log attachment]]|/3.Classification->Origin|origin|log_analysis |
44 | 2 | Anonymous | sensor| |
45 | 2 | Anonymous | |signature|String| |
46 | 5 | Yoann Vandoorselaere | |log|String| |
47 | 17 | Anonymous | |[[Counters|Occurrence counter of aggregated events]]|Origin|counter|Integer| |
48 | 17 | Anonymous | |[[Thread ID|Add Thread ID]] *YV: intérêt très limité IMHO* |Process| TID|Integer| |
49 | 17 | Anonymous | |/2.[[Specify the attack severity, the target supposed vulnerability, the target criticity and the final priority of the alert]] |
50 | 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...* |
51 | 16 | Yoann Vandoorselaere | *YV: je ne vois pas pourquoi une sonde ne pourrait pas spécifier la criticité a son niveau. Cette criticité pourra ensuite être prise en compte lors de la correlation* |
52 | 13 | Guillaume Hiet | |/2.Impact|target_vulnerability|Enum| |
53 | 1 | Gilles Lehmann | |target_criticity|Enum| |
54 | 17 | Anonymous | |[[Remove OverflowAlerts]] |
55 | 1 | Gilles Lehmann | *YV: ça semble être une mauvaise idée. Pourquoi ?* |
56 | 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 ?...* |
57 | 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?)* |
58 | 16 | Yoann Vandoorselaere | *YV: dans ce cas, il me semblerait plus pertinent d'ajouter de nouvelle sous-classe* |
59 | 9 | Anonymous | |\3{background:#e99b9b}.OverflowAlerts| |
60 | 17 | Anonymous | |[[host category|Specify host category]]|Node|type|Enum à travailler| |
61 | 17 | Anonymous | |/6.[[Location data|Add More explicit location data (latitude, longitude, country, city, etc.)]]|/5.Node->Location|latitude|float| |
62 | 2 | Anonymous | |longitude|float| |
63 | 1 | Gilles Lehmann | |city|String| |
64 | 2 | Anonymous | |country|String| |
65 | 2 | Anonymous | |state|String| |
66 | 2 | Anonymous | |{background:#e99b9b}.Node|\2{background:#e99b9b}.Location| |
67 | 17 | Anonymous | |/4.[[Expand WebService class]]|/2.WebService->WebServiceHeaderParams|parameter|host |
68 | 2 | Anonymous | referer |
69 | 2 | Anonymous | user-agent |
70 | 1 | Gilles Lehmann | server |
71 | 1 | Gilles Lehmann | cookie |
72 | 1 | Gilles Lehmann | http-method |
73 | 1 | Gilles Lehmann | other| |
74 | 2 | Anonymous | |value|String| |
75 | 9 | Anonymous | |/2.WebService->WebServiceParams |
76 | 9 | Anonymous | *YV: WebService->arg ?* |
77 | 10 | Anonymous | *SM: Les paramètres HTTP sont sous formes de clé/valeur on ne peut pas les mettre non dans arg, si ?* |
78 | 16 | Yoann Vandoorselaere | *YV: Et pourquoi pas ? C'est surtout le wording utilisé par la RFC qui est incorrecte (CGI devrait être URL)* **http-method: The HTTP method (PUT, GET) used in the request.** **arg:The arguments to the CGI script.** |
79 | 9 | Anonymous | |parameter|String| |
80 | 2 | Anonymous | |value|String| |
81 | 17 | Anonymous | |/16.[[Expand Service class|Add subclasses to Service class]]|/4.Service->LDAPService|url|String| |
82 | 2 | Anonymous | |operation|start_tls |
83 | 2 | Anonymous | bind |
84 | 2 | Anonymous | search |
85 | 2 | Anonymous | compare |
86 | 2 | Anonymous | add |
87 | 2 | Anonymous | delete |
88 | 2 | Anonymous | modify |
89 | 2 | Anonymous | modify_dn |
90 | 2 | Anonymous | abandon |
91 | 2 | Anonymous | extended-operation |
92 | 2 | Anonymous | unbind |
93 | 2 | Anonymous | other| |
94 | 2 | Anonymous | |ext-operation|String| |
95 | 2 | Anonymous | |dn|String| |
96 | 2 | Anonymous | |/2.LDAPService->LDAPServiceParams|parameter|scope |
97 | 2 | Anonymous | filter |
98 | 2 | Anonymous | deref_aliases |
99 | 2 | Anonymous | attribute |
100 | 2 | Anonymous | sizelimit |
101 | 2 | Anonymous | timelimit |
102 | 2 | Anonymous | sizeonly |
103 | 2 | Anonymous | ext-type| |
104 | 2 | Anonymous | |ext-type|String| |
105 | 2 | Anonymous | |/4.Service->SIPService|uri|String| |
106 | 2 | Anonymous | |request|INVITE |
107 | 2 | Anonymous | ACK |
108 | 2 | Anonymous | BYE |
109 | 2 | Anonymous | CANCEL |
110 | 2 | Anonymous | OPTIONS |
111 | 2 | Anonymous | REGISTER |
112 | 2 | Anonymous | PRACK |
113 | 2 | Anonymous | SUBSCRIBE |
114 | 2 | Anonymous | NOTIFY |
115 | 2 | Anonymous | PUBLISH |
116 | 2 | Anonymous | INFO |
117 | 2 | Anonymous | referer |
118 | 2 | Anonymous | MESSAGE |
119 | 2 | Anonymous | UPDATE |
120 | 2 | Anonymous | other| |
121 | 2 | Anonymous | |ext-request|String| |
122 | 2 | Anonymous | |response|integer| |
123 | 2 | Anonymous | |/2.SIPService->HeaderSIPService|parameter|Enum| |
124 | 2 | Anonymous | |value|String| |
125 | 2 | Anonymous | |/4.Service->SMTPService|messsageid|String| |
126 | 2 | Anonymous | |user-agent|String| |
127 | 2 | Anonymous | |subject|String| |
128 | 2 | Anonymous | |references|String| |