Data Mining et Machine Learning avec Orange

Disclaimer

Au moment où j’ai réalisé le TP, le lien Teams vers le jeu de données KDD CUP 1999 avait déjà expiré. J’ai donc utilisé une autre source (kaggle).

Question 1:

Voici le schéma avec lequel nous allons travailler:

Combien d’instances y a-t-il dans ce jeu de données ? Combien d’attributs y a-t-il ?

Dans Data Table, nous observons :

À votre avis, que signifient le C vert et le N rouge à côté du nom des attributs ?

Dans Distributions, nous observons :

Le C vert et le N rouge correspondent au type de l’attribut :

• C pour categorical (catégorique)
• N pour numerical (numérique)

L’attribut label correspond à la catégorisation d’une attaque.

Que représente l’attribut label ?

En regardant les valeurs possible de label, nottament normal, dos, r2l. On déduit qu’il s’agit de la catégorization de l’attaque

Question 2:

Voici la distribution par label:

Observez la distribution de l’attribut label. Quelle classe est majoritaire ?

La classe majoritaire est smurf. En consultant la page Wikipedia : Attaque Smurf, un type d’attaque par déni de service (DoS) sur les réseaux informatiques.

Regardez les types d’attaques et leur proportion. Pensez-vous que ce dataset soit représentatif des mesures qu’on pourrait réaliser sur un réseau en 2021 ? Pensez-vous qu’il soit représentatif des attaques actuelles ?

Quelques autres attaques prononcées sont neptune (SYN Flood), back (TCP Reset ?). Enfin, il y a aussi la catégorie normal.

Le nombre d’attaques par déni de service semble trop élevé par rapport aux connexions normales. Cela me semble excessif, mais ce n’est pas surprenant vu le coût d’une attaque DoS.

Question 3:

Pouvez-vous identifier des attributs dont certaines valeurs vous paraissent très liées à certaines attaques ?

Après le split, j’ai trouvé le diagramme difficile à lire, donc j’ai regroupé les catégories avec l’outil Edit Domain pour reconstruire les catégories normal, DOS, U2R, R2L et Probe. J’ai utilisé ce document comme support pour cette transformation.

Je vais continuer le TP avec cette transformation appliquée.

Par exemple :

Nous observons qu’un nombre élevé de serror_rate produit une forte probabilité d’une attaque de type DoS.

Un autre exemple :

Nous observons qu’un taux élevé de rerror_rate à partir d’un certain seuil est fortement corrélé à une attaque de type Probe.

Question 4:

Listez les cinq attributs les plus corrélés aux attaques d’après leur Gini coefficient.

Ceci nous permet d’identifier les cinq attributs les plus corrélés aux attaques.

Question 5:

Quelle attaque précisément semble détectable avec cet attribut ? Prenons l’exemple de dst_bytes :

Nous observons qu’un taux très faible de cet attribut est corrélé avec une attaque de type DoS, tandis qu’un taux élevé correspond plutôt à une attaque de type R2L.

De même pour l’attribut count :

À partir d’un certain seuil, c’est probablement une attaque.

Question 6:

Vu que mon jeu de données est différent, je ne peux pas créer un arbre binaire pour l’erreur suivante :

Continuons avec un arbre normal.

Une capture pour la visualisation de l’arbre

L’arbre est gigantesque, voici une image que vous pouvez agrandir pour voir les détails.

Une autre capture pour la visualisation des règles de décisions.

Question 7:

Pourriez-vous, à partir de l’arbre de décision appris, donner un exemple d’instance qui serait prédit comme une attaque Probe

• Si count >= 65 et service = nntp ou vmnet, l’arbre prédit Probe.

Même question avec les règles apprises

Voici quelques règles apprises qui prédisent avec une très forte probabilité une attaque de type Probe :

Question 8:

Pour chaque modèle, Quel est l’accuracy de ce modèle ?

La valeur de l’accuracy est présente sous le champ CA.

Pour chaque modèle, Combien y a-t-il de faux positifs ? (instances normales considérées comme attaques) De faux négatifs ? (attaques considérées comme normales)

Pour cette question, on fixe le target à normal.

Un faux positif fp' dans cette image représente le cas où le trafic est malveillant mais détecté comme normal. Donc fp' = fn.

Un faux négatif fn' dans cette image représente le cas où le trafic est normal, mais détecté comme malveillant. Donc fn' = fp.

On aura aussi besoin du nombre total d’échantillons N = 494021 et normaux Nnorm = 97278.

Faux positifs

La formule du recall s’écrit r' = tp' / (tp' + fn'). On rappelle que tp' + fn' correspond au nombre total des paquets normaux. Donc Nnorm = tp' + fn'.

On peut en déduire le nombre de faux positifs par fp = fn' = (1 - r')*Nnorm.

Faux négatifs

La formule du accuracy s’écrit a' = (tp' + tn') / N, ainsi fp' + fn' = N * (1 - a').

Comme on a calculé fn' dans l’étape précédente, on peut maintenant en déduire le nombre de faux négatifs fn = fp' = N*(1 - a') - fn'.

En supposant dix connexions légitimes par seconde, combien y aurait-il de faux positifs par jour en moyenne ? Trouvez-vous ce résultat satisfaisant pour une utilisation réelle ?

Pour chaque algorithme, on calcule le False Positive Rate (FPR) = FP / P.

Le nombre de faux positifs par jour est ainsi FPR * 10 * 60*60*24.

On obtient les valeurs suivantes :

Sauf pour Random Forest, le nombre de fausses alertes reste un peu élevé mais pas excessif.