IDMEFV2 » History » Version 13
« Previous -
Version 13/24
(diff) -
Next » -
Current version
Guillaume Hiet, 10/30/2015 12:35 PM
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 |
|---|---|---|---|
| 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 ^^) 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). |
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. GH: On avait évoqué l'idée d'augmenter le dictionnaire associé à address.category plutôt que d'ajouter un champs dédié... |
Address | translation | no_translation pre_trabslation post_translation |
| Attachement du log originel (plus specifique que Additional Data) | 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 |
| 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 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... |
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 ?... 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?) |
OverflowAlerts | ||
| Ajouter un champs pour identifier la catégorie d'un hôte | Node | type | Enum à travailler |
| Gestion explicite des données de géolocalisation (longitude, lattitude, ville pays) | Node->Location | latitude | float |
| longitude | float | ||
| city | String | ||
| country | String | ||
| state | String | ||
| Node | Location | ||
| Compléter la classe WebService | WebService->WebServiceHeaderParams | parameter | host referer user-agent server cookie http-method other |
| value | String | ||
| 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 | ||
| Ajouter des sous-classes à la classe Service | 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 | ||
| LDAPService->LDAPServiceParams | parameter | scope filter deref_aliases attribute sizelimit timelimit sizeonly ext-type |
|
| ext-type | String | ||
| 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 | ||
| SIPService->HeaderSIPService | parameter | Enum | |
| value | String | ||
| Service->SMTPService | messsageid | String | |
| user-agent | String | ||
| subject | String | ||
| references | String | ||
