Project

General

Profile

IDMEFV2 » History » Version 11

« Previous - Version 11/24 (diff) - Next » - Current version
Guillaume Hiet, 10/30/2015 10:49 AM


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. 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 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 ?...
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

Alert.png View (634 KB) Anonymous, 05/26/2016 10:15 AM

Alert.png View (656 KB) Anonymous, 05/26/2016 12:03 PM