SMART-IDS FRAMEWORK V5

Rapport Technique — Partie 2

Threat Intelligence · MITRE ATT&CK

Champ Détail

Sections couvertes Threat Intelligence (Score Composite) + MITRE ATT&CK (Mapping

+ T0000)
Auteur achrefmansouri600
Infrastructure Google Cloud Platform — europe-west1
Stack IA XGBoost V3 + Autoencoder + LSTM V4 PRO + Gemini 2.5 Flash
Date Avril 2026

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 1

PARTIE A — Threat Intelligence

La Threat Intelligence (TI) désigne l'ensemble des informations collectées sur les menaces
connues pour aider à prendre de meilleures décisions de sécurité. Dans Smart-IDS, la TI
s'articule autour de deux APIs externes qui enrichissent chaque alerte avec la réputation de l'IP
source, et d'un algorithme de score composite qui fusionne ces informations avec la décision du
modèle ML.

A.1 Pourquoi la Threat Intelligence est-elle Nécessaire ?

Une alerte Suricata brute dit : « ET SCAN Potential SSH Scan detected ». Elle donne une IP
source, un port, une signature. Elle ne dit pas :
▸ Est-ce que cette IP a déjà attaqué d'autres systèmes dans le monde ?
▸ Combien de moteurs antivirus la considèrent comme malveillante ?
▸ Est-ce une IP de Tor, de VPN commercial, d'un botnet connu ?
▸ Est-ce que le comportement réseau observé est cohérent avec la réputation de l'IP ?

Sans TI, un analyste SOC doit investiguer manuellement chaque alerte pour répondre à ces
questions. Avec TI intégrée, le système répond automatiquement en quelques secondes.

💡 Analogie Pratique

Imaginez que vous êtes agent de sécurité à l'entrée d'un bâtiment.

Une alerte Suricata seule, c'est comme si quelqu'un tente d'ouvrir une porte fermée à clé.
La Threat Intelligence, c'est comme avoir accès à la base de données des personnes
recherchées : vous savez immédiatement si cette personne a déjà été arrêtée ailleurs,
si son visage correspond à un criminel connu, et combien de pays la recherchent.

Dans Smart-IDS : une IP qui déclenche une alerte SSH ET qui est connue sur 24 moteurs
VirusTotal avec AbuseIPDB à 100% → réponse immédiate sans investigation manuelle.

A.2 Les Deux APIs de Threat Intelligence

A.2.1 VirusTotal — Le Méta-Moteur Antivirus
VirusTotal est un service de Google qui agrège les résultats de plus de 90 moteurs antivirus et
outils d'analyse. Quand on soumet une adresse IP, VirusTotal interroge en parallèle tous ces
moteurs et retourne un rapport consolidé.

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 2

Ce que VirusTotal retourne pour une IP
Champ VirusTotal Type Signification dans Smart-IDS

malicious Entier (0-90+) Nombre de moteurs qui considèrent l'IP comme

malveillante — c'est notre vt_score
suspicious Entier Nombre de moteurs qui la considèrent comme
suspecte (moins grave que malveillante)
harmless Entier Nombre de moteurs qui la considèrent comme
inoffensive
undetected Entier Nombre de moteurs qui n'ont pas de données sur
cette IP
community_score Flottant Score de la communauté VirusTotal (-100 à +100)
last_analysis_date Timestamp Date de la dernière analyse — important pour la
fraîcheur des données

Interprétation du vt_score
vt_score Interprétation Action SOC recommandée
(malicious)

0 IP propre selon tous les Basse probabilité d'attaque — surveiller

moteurs
1-5 Quelques moteurs la flagguent Signal faible — à surveiller, contexte
important
6-15 Nombre significatif de IP probablement malveillante —
détections investigation prioritaire
16-30 Détection massive IP clairement malveillante — blocage
recommandé
30+ Quasi-unanimité IP activement utilisée par des attaquants —
blocage immédiat

Exemple Réel Observé dans notre SOC

📋 Cas Réel : IP [Link]

Alerte Suricata : ET COMPROMISED Known Compromised or Hostile Host T

IP Source : [Link]

Résultat VirusTotal API :

malicious : 15 (15 moteurs AV la flagguent comme malveillante)
suspicious : 3
harmless : 12
undetected : 60

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 3

 Notre vt_score = 15 → contribution dans le score composite = min(15 × 5, 30) = 30 points
(maximum)
→ Cette IP atteint immédiatement le maximum de la contribution VirusTotal

Interprétation : IP connue comme hostile sur 15 moteurs — cohérent avec la signature

Suricata
'COMPROMISED'. L'alerte est confirmée par deux sources indépendantes.

A.2.2 AbuseIPDB — La Base de Données des Signalements

AbuseIPDB est une base de données communautaire où des administrateurs systèmes du
monde entier signalent des IPs qui ont tenté de les attaquer. Contrairement à VirusTotal qui
agrège des moteurs antivirus, AbuseIPDB se base sur des signalements humains réels.

Ce que AbuseIPDB retourne

Champ AbuseIPDB Type Signification

abuseConfidenceScore Entier (0-100) Score de confiance en pourcentage que l'IP

est malveillante — c'est notre abuse_score
totalReports Entier Nombre total de signalements reçus pour cette
IP
numDistinctUsers Entier Nombre d'utilisateurs différents qui ont signalé
cette IP
lastReportedAt Timestamp Date du dernier signalement — fraîcheur des
données
usageType String Type d'usage déclaré : 'Data Center/Web
Hosting', 'ISP', 'Residential'...
isp String Fournisseur d'accès Internet de l'IP
countryCode String Pays d'origine de l'IP
isWhitelisted Booléen Si l'IP est sur la whitelist AbuseIPDB (Google,
Cloudflare...)

Interprétation de l'abuse_score
abuse_score (0- Signification Action
100)

0 Aucun signalement — IP Basse priorité

inconnue ou propre
1-25 Quelques signalements — IP Surveiller
suspecte
26-50 Signalements modérés — IP Investigation recommandée
souvent signalée
51-75 Signalements importants — IP Blocage préventif

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 4

 abuse_score (0- Signification Action
100)

activement malveillante
76-99 Très nombreux signalements Blocage immédiat
— IP hautement malveillante
100 Score maximal — IP Blocage + rapport incident
unanimement reconnue
comme malveillante

Différence Clé entre VirusTotal et AbuseIPDB

Cette distinction est importante à comprendre pour la soutenance :

Critère VirusTotal AbuseIPDB

Source des Moteurs antivirus automatiques Signalements humains d'admins

données (analyse de malwares, URLs, systèmes après une vraie attaque
fichiers)
Type d'information Réputation statique basée sur Réputation dynamique basée sur
analyse technique comportement observé
Fraîcheur Analyse automatique régulière Mise à jour en temps réel par la
communauté
Avantage Exhaustif — 90+ moteurs agrégés Contextuel — vraies attaques
observées in vivo
Limitation Peut rater les IPs nouvellement Dépend de la participation de la
utilisées pour attaquer communauté

🧠 Pourquoi Utiliser les Deux ?

Une IP peut être inconnue de VirusTotal (jamais analysée par les moteurs AV) mais avoir
un AbuseIPDB score élevé (déjà utilisée pour attaquer des systèmes réels).

Inversement, une IP peut être flagguée par quelques moteurs AV (VT score > 0) sans avoir
encore été utilisée dans une attaque concrète signalée sur AbuseIPDB.

En combinant les deux, nous couvrons ces deux cas complémentaires : réputation
technique ET réputation comportementale opérationnelle.

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 5

A.3 L'Architecture du Cache — Optimisation des Quotas API
A.3.1 Pourquoi un Cache est Indispensable
Les deux APIs fonctionnent en mode freemium avec des quotas limités :

API Plan Gratuit Limite Conséquence sans

cache

VirusTotal Free 4 requêtes par 1000 requêtes par jour Épuisé en 4 minutes si
minute 100 alertes/min
AbuseIPDB Free 1000 requêtes par 60 requêtes par minute Épuisé si > 1000 IPs
jour uniques par jour

Dans notre environnement, un seul scan Nmap agressif peut générer plusieurs centaines
d'alertes en quelques minutes — toutes depuis la même IP attaquante. Sans cache, on ferait
plusieurs centaines de requêtes API pour la même IP en quelques secondes.

A.3.2 Implémentation du Cache en Python

Le cache est implémenté comme un dictionnaire Python en mémoire avec une durée de vie de
1 heure :

# Cache global en mémoire — persiste pendant toute la durée d'exécution

d'[Link]
ip_reputation_cache = {}
# Durée de vie du cache : 1 heure (3600 secondes)
CACHE_TTL = 3600

# Fonction principale d'interrogation des APIs de réputation

def get_ip_reputation(ip: str) -> tuple:
# Retourne (vt_score, abuse_score)

# Étape 1 : Ignorer les IPs privées / RFC1918

if ip in ('', None): return 0, 0
private_ranges = ('10.', '192.168.', '172.16.', '127.', '169.254.')
if any([Link](r) for r in private_ranges):
return 0, 0 # Pas de réputation externe pour IPs privées

# Étape 2 : Vérifier le cache

now = [Link]()
if ip in ip_reputation_cache:
entry = ip_reputation_cache[ip]
if now - entry['timestamp'] < CACHE_TTL:
# Cache valide — retourner sans appel API
return entry['vt_score'], entry['abuse_score']

# Étape 3 : Appeler VirusTotal

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 6

 vt_score = 0
try:
url = f'[Link]
headers = {'x-apikey': VT_KEY}
resp = [Link](url, headers=headers, timeout=5)
if resp.status_code == 200:
data = [Link]()
stats = data['data']['attributes']['last_analysis_stats']
vt_score = [Link]('malicious', 0)
except Exception as e:
pass # Timeout ou erreur réseau — score reste à 0

# Étape 4 : Appeler AbuseIPDB

abuse_score = 0
try:
url = '[Link]
headers = {'Key': ABUSE_KEY, 'Accept': 'application/json'}
params = {'ipAddress': ip, 'maxAgeInDays': 90}
resp = [Link](url, headers=headers, params=params, timeout=5)
if resp.status_code == 200:
data = [Link]()
abuse_score = data['data']['abuseConfidenceScore']
except Exception as e:
pass

# Étape 5 : Stocker dans le cache avec timestamp

ip_reputation_cache[ip] = {
'vt_score' : vt_score,
'abuse_score': abuse_score,
'timestamp' : now
}
return vt_score, abuse_score

A.3.3 Impact du Cache sur les Performances

Scénario Sans cache Avec cache TTL 1h Économie

100 alertes depuis la 100 appels VT + 1 appel VT + 1 appel 99% d'économie

même IP en 1 min 100 appels AIPDB AIPDB = 2 req
= 200 req
10 IPs différentes, 50 500 appels VT + 10 appels VT + 10 98% d'économie
alertes chacune 500 AIPDB = 1000 AIPDB = 20 req
req
Quota VirusTotal Free (4 Épuisé en 1 minute 1 req/IP unique → Protection complète
req/min) d'attaque jamais épuisé du quota

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 7

A.4 Le Score Composite de Menace — Le Cœur de l'Innovation
A.4.1 Pourquoi Fusionner Trois Sources ?
Chacune des trois sources d'information (ML, VirusTotal, AbuseIPDB) est imparfaite seule :

Source Force Faiblesse Taux d'erreur

seule

XGBoost ML Détecte les patterns Peut se tromper sur des FP 6% (avant

comportementaux trafics atypiques optimisation)
réseau légitimes
VirusTotal Réputation technique Ne couvre pas les IPs Faux négatifs sur
vérifiée par 90+ moteurs nouvellement déployées nouvelles IPs
pour attaquer
AbuseIPDB Basé sur vraies attaques Dépend des Faux négatifs si IP
observées signalements non signalée
communautaires — peut
être incomplet

En fusionnant les trois, on crée un système de validation croisée : si le ML dit 'attaque' ET

VirusTotal confirme ET AbuseIPDB confirme, la probabilité d'erreur devient infime.

A.4.2 La Formule du Score Composite — Analyse Détaillée

La formule est conçue pour maximiser la contribution du ML (source principale) tout en
pondérant les deux sources TI comme des confirmateurs :

# Calcul du score composite de menace (0 à 100 points)

def compute_threat_level(ml_pred, ml_confidence, vt_score, abuse_score):
threat_score = 0

# Contribution 1 : Machine Learning (poids 50%)

# Si le ML prédit une attaque, sa confiance contribue jusqu'à 50 points
# Formule : (confiance ML en %) / 100 × 50
# Ex: confiance 80% → 80/100 × 50 = 40 points
if ml_pred == 1:
threat_score += ml_confidence / 100 * 50

# Contribution 2 : VirusTotal (poids 30%)

# Chaque moteur AV qui flaggue l'IP vaut 5 points, plafonné à 30
# Formule : min(vt_score × 5, 30)
# Ex: vt_score=6 → min(6×5, 30) = 30 points (maximum atteint dès 6 moteurs)
if vt_score > 0:
threat_score += min(vt_score * 5, 30)

# Contribution 3 : AbuseIPDB (poids 20%)

# Le score AbuseIPDB (0-100%) vaut jusqu'à 20 points
# Formule : min(abuse_score / 5, 20)

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 8

# Ex: abuse_score=100 → min(100/5, 20) = 20 points (maximum)
if abuse_score > 0:
threat_score += min(abuse_score / 5, 20)

# Décision finale basée sur le score total

if threat_score >= 70: return 'CRITICAL'
elif threat_score >= 40: return 'HIGH'
elif threat_score >= 20: return 'MEDIUM'
else: return 'LOW'

A.4.3 Analyse de la Formule — Pourquoi Ces Coefficients ?

Les poids (50%, 30%, 20%) ne sont pas arbitraires. Voici la justification de chaque choix :

ML à 50% — Source Principale

▸ Le ML est la seule source qui analyse le COMPORTEMENT réseau, pas juste la
réputation. Un attaquant peut changer d'IP rapidement (IP rotation), mais le
comportement de ses scans reste similaire. VirusTotal et AbuseIPDB ne peuvent pas
détecter une IP neuve — le ML si.
▸ Le ML a été validé avec AUC-ROC 0.9995 — une performance exceptionnelle. Il mérite
la contribution la plus importante.
▸ Asymétrie volontaire : si le ML prédit NORMAL (ml_pred=0), la contribution ML est 0
même si confiance=99%. Cela évite qu'un trafic normal soit classifié CRITICAL
uniquement parce que l'IP a une mauvaise réputation historique (ex: IP d'un fournisseur
cloud partagé).

VirusTotal à 30% — Confirmateur Principal

▸ Le plafond à 30 points (atteint dès vt_score=6) est intentionnel. Au-delà de 6
moteurs qui flagguent une IP, l'information est déjà clairement établie — pas besoin de
pondérer davantage la quantité.
▸ La multiplication par 5 donne du poids aux IP avec peu de détections mais
significatives. Une IP flagguée par 2 moteurs spécialisés vaut déjà 10 points.

AbuseIPDB à 20% — Validateur Comportemental

▸ AbuseIPDB est moins pondéré car dépend de la communauté. Une IP peut être très
malveillante sans jamais avoir été signalée sur AbuseIPDB. Il vient confirmer, pas
décider.
▸ La division par 5 permet au score AbuseIPDB (0-100) de contribuer progressivement :
25% abuse = 5 points, 50% = 10 points, 100% = 20 points (max).

A.4.4 Les Quatre Niveaux de Menace — Logique des Seuils

Niveau Seuil Logique Opérationnelle Exemple

🔴 CRITICAL >= 70 pts ML confirme (>40pts) + VT confirme ML 80% = 40pts +

(30pts max) = 70+. UNIQUEMENT VT:6 = 30pts =

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 9

Niveau Seuil Logique Opérationnelle Exemple

possible si ML prédit attaque ET VT 70pts → CRITICAL

confirme. Deux sources indépendantes
en accord.
🟠 HIGH 40-69 pts ML très confiant seul (ex: 90% = 45pts), ML 90% = 45pts +
OU ML modéré + confirmation partielle TI. VT:0 + Abuse:0 =
Attaque probable mais moins certaine. 45pts → HIGH
🟡 MEDIUM 20-39 pts ML modéré sans confirmation TI, OU ML 40% = 20pts =
signature Suricata avec peu de confiance MEDIUM
ML. Investiguer.
🟢 LOW < 20 pts Alerte Suricata mais ML peu convaincu ML 20% = 10pts +
ET aucune réputation négative. VT:0 + Abuse:0 =
Probablement faux positif. 10pts → LOW

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 10

A.5 Simulation Complète — Calcul Pas à Pas
A.5.1 Cas 1 : IP Réellement Malveillante — CRITICAL
Alerte réelle observée dans notre SOC :

# Entrée brute depuis Elasticsearch (filebeat-*)

signature : ET COMPROMISED Known Compromised or Hostile Host T
src_ip : [Link]
dst_ip : [Link]
dst_port : 22
event_type : alert

# Étape 1 : XGBoost prédit

ml_pred : 1 (ATTACK)
ml_confidence : 69.4%
contribution : 69.4 / 100 × 50 = 34.7 points

# Étape 2 : VirusTotal API

vt_score : 12 (12 moteurs AV la flagguent)
contribution : min(12 × 5, 30) = 30 points (plafonné)

# Étape 3 : AbuseIPDB API

abuse_score : 100 (score maximal — nombreux signalements)
contribution : min(100 / 5, 20) = 20 points (plafonné)

# Étape 4 : Score Total

threat_score : 34.7 + 30 + 20 = 84.7 points → 🔴 CRITICAL

# Étape 5 : Mapping MITRE

mitre_technique : T1071 (Application Layer Protocol — C2)

# Super-alerte injectée dans smart-ids-alerts-v5

{
'@timestamp' : '2026-03-29T20:29:11.545Z'
'src_ip' : '[Link]'
'signature' : 'ET COMPROMISED Known Hostile...'
'threat_level' : 'CRITICAL'
'threat_score' : 84.7
'xgb_confidence' : 69.4
'vt_score' : 12
'abuse_score' : 100
'mitre_technique' : 'T1071'
'mitre_tactic' : 'Command and Control'
'lstm_killchain' : True
}

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 11

 ✅ Analyse Gemini Générée Automatiquement

DIAGNOSTIC : Une attaque critique et active est en cours depuis [Link],

IP répertoriée comme hostile sur 12 moteurs VirusTotal et avec un score AbuseIPDB de
100%.
L'attaquant cible le port SSH 22 (T1071 — Application Layer Protocol).
La séquence kill chain confirmée par LSTM indique une progression tactique en cours.

ACTIONS RECOMMANDÉES :
1. Bloquer immédiatement [Link] sur le firewall périmétrique
2. Analyse forensique de [Link] (logs SSH, processus suspects, connexions établies)
3. Vérifier si d'autres hôtes ont communiqué avec cette IP dans les 24 dernières heures
4. Imposer authentification par clé SSH, désactiver accès root direct

A.5.2 Cas 2 : Scan SSH Externe — HIGH

# Alerte courante — scan SSH depuis IP externe
signature : ET SCAN Potential SSH Scan detected
src_ip : [Link]
dst_port : 22

ml_pred : 1 | ml_confidence : 99.5%

contribution : 99.5 / 100 × 50 = 49.75 points

vt_score : 0 (IP propre selon VT — IP Google Cloud interne)

abuse_score : 0

threat_score : 49.75 + 0 + 0 = 49.75 → 🟠 HIGH

Note : Cette IP ([Link]) appartient à Google Cloud Platform. Le ML est très confiant
(99.5%) car le comportement réseau ressemble à un scan SSH, mais VT et AbuseIPDB
retournent 0 car c'est une IP GCP légitime. Résultat HIGH mais pas CRITICAL — correspond à
du trafic de health check ou de monitoring GCP qui déclenche Suricata.

A.5.3 Cas 3 : Alerte Informelle — LOW

# Alerte informative — pas une vraie attaque
signature : ET INFO SSH-2.0-Go version string Observed
src_ip : [Link]

ml_pred : 0 (NORMAL — XGBoost ne considère pas ça comme une attaque)

ml_confidence : 15% → contribution : 0 (ml_pred=0, pas de contribution)

vt_score : 2 → contribution : min(2×5, 30) = 10 points

abuse_score : 8 → contribution : min(8/5, 20) = 1.6 points

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 12

threat_score : 0 + 10 + 1.6 = 11.6 → 🟢 LOW

Le ML décide que ce n'est pas une attaque comportementalement. Même si l'IP a quelques
signalements TI, le score final reste LOW — l'alerte est probablement un faux positif Suricata.

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 13

A.6 Intégration dans [Link] — Le Flux Complet
Voici comment la Threat Intelligence s'intègre dans la boucle principale du script [Link],
qui tourne toutes les 15 secondes :

# Boucle principale d'enrichissement — exécutée toutes les 15 secondes

def enrichment_loop():
while True:
# Étape 1 : Récupérer les dernières alertes Suricata depuis Elasticsearch
alerts = get_recent_alerts(index='filebeat-*', last_seconds=15)
network_alerts = [a for a in alerts if [Link]('event_type') == 'alert']

for alert_raw in network_alerts:

# Étape 2 : Extraire les champs de base
src_ip = alert_raw.get('src_ip', '')
signature = alert_raw.get('signature', '')
timestamp = alert_raw.get('@timestamp', '')

# Étape 3 : Construire le vecteur de features (18 features)

features = build_features(alert_raw, timestamp)

# Étape 4 : Triple prédiction IA

xgb_pred, xgb_conf = predict_xgb(features)
ae_anomaly, ae_score = predict_autoencoder(features)
lstm_kc, lstm_score = predict_lstm(features)

# Étape 5 : Mapping MITRE ATT&CK

mitre = get_mitre_tag(signature)
# Filtrer les signatures sans mapping (bruit)
if mitre is None: continue

# Étape 6 : THREAT INTELLIGENCE — avec cache automatique

vt_score, abuse_score = get_ip_reputation(src_ip)

# Étape 7 : Score composite

threat_level = compute_threat_level(
xgb_pred, xgb_conf, vt_score, abuse_score
)

# Étape 8 : Construire et injecter la super-alerte

super_alert = {
'@timestamp' : timestamp,
'src_ip' : src_ip,
'signature' : signature,
'threat_level' : threat_level,
'xgb_confidence' : xgb_conf,
'xgb_prediction' : xgb_pred,
'ae_score' : ae_score,
'ae_anomaly' : ae_anomaly,

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 14

 'lstm_killchain' : lstm_kc,
'vt_score' : vt_score,
'abuse_score' : abuse_score,
'mitre_technique' : mitre['technique'],
'mitre_tactic' : mitre['tactic'],
'event_type' : 'network_alert'
}
[Link](index='smart-ids-alerts-v5', body=super_alert)

[Link](15) # Attendre 15 secondes avant le prochain cycle

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 15

PARTIE B — Framework MITRE ATT&CK

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) est un framework
mondial qui documente les comportements des attaquants réels, organisés en tactiques (le
POURQUOI) et techniques (le COMMENT). Smart-IDS utilise ce framework pour contextualiser
automatiquement chaque alerte Suricata.

B.1 Qu'est-ce que MITRE ATT&CK ?

B.1.1 La Structure du Framework
MITRE ATT&CK est organisé en 14 tactiques qui représentent les grandes phases d'une
cyberattaque, chacune contenant plusieurs techniques et sous-techniques :

ID Tactique Nom de la Tactique Description Techniques

notables

TA0001 Initial Access Comment l'attaquant pénètre T1190 (Exploit),

initialement le réseau T1133 (External
Remote Services)
TA0002 Execution Comment l'attaquant exécute T1059
du code malveillant (Command/Script
Interpreter), T1203
(Client Exec)
TA0003 Persistence Comment l'attaquant maintient T1078 (Valid
sa présence Accounts), T1547
(Boot Autostart)
TA0004 Privilege Escalation Comment l'attaquant gagne T1068 (Exploit
des droits élevés Vulnerability), T1078
TA0005 Defense Evasion Comment l'attaquant évite la T1027 (Obfuscation),
détection T1070 (Indicator
Removal)
TA0006 Credential Access Comment l'attaquant vole des T1110 (Brute Force),
credentials T1003 (OS Credential
Dump)
TA0007 Discovery Comment l'attaquant explore T1046 (Network
le réseau Scan), T1082
(System Info)
TA0008 Lateral Movement Comment l'attaquant se T1021 (Remote
déplace dans le réseau Services), T1091
(USB)
TA0009 Collection Comment l'attaquant collecte T1560 (Archive Data),
des données T1074 (Data Staged)

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 16

 ID Tactique Nom de la Tactique Description Techniques
notables

TA0010 Exfiltration Comment l'attaquant exfiltre T1041 (Exfil over C2),

les données T1048 (Exfil Alt
Protocol)
TA0011 Command and Comment l'attaquant T1071 (App Layer
Control communique avec sa cible Protocol), T1095
(Non-App Layer)
TA0040 Impact Comment l'attaquant cause T1499 (Endpoint
des dommages DoS), T1486 (Data
Encrypted)
TA0042 Resource Comment l'attaquant prépare T1583 (Acquire
Development ses ressources Infrastructure), T1588
(Obtain Caps)
TA0043 Reconnaissance Comment l'attaquant collecte T1046, T1590,
des informations T1595, T1596

B.1.2 Pourquoi MITRE ATT&CK dans Smart-IDS ?

Sans MITRE ATT&CK, les alertes restent cryptiques pour un analyste humain :

Sans MITRE ATT&CK Avec MITRE ATT&CK Impact

"Alerte ID 2009358 — ET T1046 — Network Service L'analyste comprend

SCAN Nmap..." Discovery (Discovery) immédiatement que c'est une
phase de reconnaissance
"Alerte ID 2001219 — ET T1071 — Application Layer L'analyste sait qu'il y a une
COMPROMISED..." Protocol (C2) communication C2 active —
urgence maximale
"Alerte ID 2001334 — ET T1110 — Brute Force L'analyste sait que quelqu'un
SCAN SSH..." (Credential Access) tente de voler des credentials
SSH

📊 Impact Mesuré

Selon les études MITRE (citées dans le cahier des charges initial) :
L'utilisation de MITRE ATT&CK réduit le temps de prise de décision de l'analyste de 60%.
Au lieu de dire 'Alerte ID 2001843', l'IDS dit 'Tentative de Brute Force SSH (T1110)'.
L'analyste comprend immédiatement le contexte sans avoir à investiguer manuellement.

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 17

B.2 Le Mapping Signatures Suricata → MITRE ATT&CK
B.2.1 La Fonction get_mitre_tag() — Code Complet
Cette fonction est le cœur du mapping MITRE dans Smart-IDS. Elle prend la signature Suricata
d'une alerte et retourne la technique MITRE correspondante, ou None si c'est du bruit à filtrer :

# Dictionnaire de mapping : pattern de signature → technique MITRE

MITRE_MAPPING = {

# ══ TACTIQUE : RECONNAISSANCE (TA0043) ══

'SCAN Nmap' : {'technique': 'T1046', 'tactic': 'Discovery',
'name': 'Network Service Discovery'},
'nmap' : {'technique': 'T1046', 'tactic': 'Discovery',
'name': 'Network Service Discovery'},
'masscan' : {'technique': 'T1046', 'tactic': 'Discovery',
'name': 'Network Service Discovery'},
'SCAN Potential SSH' : {'technique': 'T1046', 'tactic': 'Discovery',
'name': 'Network Service Discovery'},
'SSH version string' : {'technique': 'T1046', 'tactic': 'Discovery',
'name': 'Network Service Discovery'},

# ══ TACTIQUE : RECONNAISSANCE ACTIVE (TA0043) ══

'Active_Scanning' : {'technique': 'T1595', 'tactic': 'Reconnaissance',
'name': 'Active Scanning'},
'Aggressive Scan' : {'technique': 'T1595', 'tactic': 'Reconnaissance',
'name': 'Active Scanning'},
'Gather Victim' : {'technique': 'T1590', 'tactic': 'Reconnaissance',
'name': 'Gather Victim Network Info'},

# ══ TACTIQUE : COMMAND AND CONTROL (TA0011) ══

'COMPROMISED' : {'technique': 'T1071', 'tactic': 'Command and Control',
'name': 'Application Layer Protocol'},
'Known Hostile' : {'technique': 'T1071', 'tactic': 'Command and Control',
'name': 'Application Layer Protocol'},
'CNC' : {'technique': 'T1071', 'tactic': 'Command and Control',
'name': 'Application Layer Protocol'},
'Dshield' : {'technique': 'T1071', 'tactic': 'Command and Control',
'name': 'Application Layer Protocol'},

# ══ TACTIQUE : INITIAL ACCESS / EXPLOIT (TA0001) ══

'Exploit_Public_App' : {'technique': 'T1190', 'tactic': 'Initial Access',
'name': 'Exploit Public-Facing Application'},
'SQLi' : {'technique': 'T1190', 'tactic': 'Initial Access',
'name': 'Exploit Public-Facing Application'},
'nikto' : {'technique': 'T1190', 'tactic': 'Initial Access',
'name': 'Exploit Public-Facing Application'},
'Web Attack' : {'technique': 'T1190', 'tactic': 'Initial Access',
'name': 'Exploit Public-Facing Application'},
'XSS' : {'technique': 'T1190', 'tactic': 'Initial Access',

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 18

 'name': 'Exploit Public-Facing Application'},

# ══ TACTIQUE : CREDENTIAL ACCESS (TA0006) ══

'Brute_Force' : {'technique': 'T1110', 'tactic': 'Credential Access',
'name': 'Brute Force'},
'hydra' : {'technique': 'T1110', 'tactic': 'Credential Access',
'name': 'Brute Force'},
'brute' : {'technique': 'T1110', 'tactic': 'Credential Access',
'name': 'Brute Force'},
'Password' : {'technique': 'T1110', 'tactic': 'Credential Access',
'name': 'Brute Force'},

# ══ TACTIQUE : IMPACT — DENIAL OF SERVICE (TA0040) ══

'Endpoint_DoS' : {'technique': 'T1499', 'tactic': 'Impact',
'name': 'Endpoint Denial of Service'},
'hping3' : {'technique': 'T1499', 'tactic': 'Impact',
'name': 'Endpoint Denial of Service'},
'ICMP flood' : {'technique': 'T1499', 'tactic': 'Impact',
'name': 'Endpoint Denial of Service'},
'SYN flood' : {'technique': 'T1499', 'tactic': 'Impact',
'name': 'Endpoint Denial of Service'},

# ══ TACTIQUE : DISCOVERY — SYSTEM INFO (TA0007) ══

'System_Info_Disc' : {'technique': 'T1082', 'tactic': 'Discovery',
'name': 'System Information Discovery'},
'enum4linux' : {'technique': 'T1082', 'tactic': 'Discovery',
'name': 'System Information Discovery'},
'SMB' : {'technique': 'T1082', 'tactic': 'Discovery',
'name': 'System Information Discovery'},

# ══ TACTIQUE : LATERAL MOVEMENT — REMOTE SERVICES (TA0008) ══

'Remote Services' : {'technique': 'T1021', 'tactic': 'Lateral Movement',
'name': 'Remote Services'},
'SSH-2.0-Go' : {'technique': 'T1021', 'tactic': 'Lateral Movement',
'name': 'Remote Services'},

# ══ SIGNATURES À FILTRER — Retournent None (bruit à exclure) ══

# Ces signatures ne correspondent pas à des attaques réelles
# 'STREAM' → anomalies TCP normales (retransmissions, etc.)
# 'INVALID' → paquets mal formés côté réseau
# 'ET INFO' → informations réseau neutres (version SSH, DNS, etc.)
# 'DHCP' → découverte d'adresse — trafic système
}

# Implémentation de la fonction de mapping

def get_mitre_tag(signature: str):
# Retourne le dict MITRE ou None si bruit à filtrer

# Patterns qui doivent être filtrés (retournent None)

NOISE_PATTERNS = ['STREAM', 'INVALID', 'ET INFO', 'DHCP', 'STATS']
sig_upper = [Link]()

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 19

 for noise in NOISE_PATTERNS:
if noise in sig_upper:
return None # Ce pattern est du bruit — filtrer

# Chercher dans le dictionnaire de mapping

for pattern, mitre_info in MITRE_MAPPING.items():
if [Link]() in [Link]():
return mitre_info # Match trouvé

# Aucun match — technique inconnue

return {'technique': 'T0000', 'tactic': 'Unknown', 'name': 'Unclassified'}

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 20

B.3 Le Problème T0000 — Diagnostic et Correction
B.3.1 Découverte du Problème
Lors de l'analyse du dashboard React, une anomalie a été détectée : un grand nombre d'alertes
étaient classifiées sous la technique T0000 (Unknown). Cette découverte a nécessité un
diagnostic approfondi.

🔍 Problème Identifié : T0000 pollue les statistiques MITRE

Symptôme : Dans le dashboard React, 71 alertes sur 100 affichaient 'T0000 — Unknown'
Conséquence : La heatmap MITRE ATT&CK dans Kibana ne reflétait pas la réalité des
attaques

Investigation :
curl -s 'localhost:9200/smart-ids-alerts-v5/_search' | grep mitre_technique | sort | uniq -c
→ T1499 : 883 occurrences
→ T0000 : 71 occurrences ← PROBLÈME
→ T1190 : 20 occurrences
→ T1046 : 16 occurrences

Signatures T0000 identifiées :

- 'SURICATA STREAM Packet with invalid ack' → STREAM = bruit TCP
- 'ET INFO SSH-2.0-Go version string Observed' → INFO = informatif neutre
- 'SURICATA STREAM excessive retransmissions' → STREAM = anomalie réseau
- 'ET INFO DNS Non-Recursive Query' → INFO = requête DNS normale
- 'GPL ICMP PING *NIX' → Ping = peut être bruit ou attaque

B.3.2 Analyse des Causes — Trois Catégories de T0000

En analysant toutes les signatures qui se retrouvaient avec T0000, nous avons identifié trois
catégories distinctes qui nécessitaient des traitements différents :

Catégorie Exemples de signatures Nature Traitement

Bruit réseau pur SURICATA STREAM Packet Anomalies TCP Filtrer complètement
(STREAM, invalid ack SURICATA normales générées par (return None) — ne pas
INVALID) STREAM excessive le réseau GCP. Ces injecter dans smart-ids-
retransmissions SURICATA alertes n'ont AUCUNE alerts-v5
STREAM out of window signification malveillante
— elles sont du bruit de
fond.
Informatif neutre ET INFO SSH-2.0-Go version Suricata log des Filtrer ou mapper vers
(ET INFO) string ET INFO DNS Non- informations sur le trafic T1590 (Gather Info)

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 21

 Catégorie Exemples de signatures Nature Traitement

Recursive Query ET INFO observé sans que ce soit selon le contexte

TLS SNI observed une alerte de sécurité.
Ce sont des
observations, pas des
détections.
Attaque réelle non GPL ICMP PING *NIX ET De vraies règles de Ajouter le mapping
mappée DROP Dshield Block Listed sécurité qui n'avaient correct dans le
Some-Vendor-Rule-Not-in-Dict pas encore de dictionnaire
correspondance dans
notre dictionnaire
MITRE_MAPPING.

B.3.3 La Solution en Deux Étapes

Étape 1 : Enrichir le dictionnaire de mapping
Pour les signatures qui représentent de vraies attaques mais n'avaient pas de mapping, nous
avons ajouté des règles :

# Ajouts au dictionnaire MITRE_MAPPING pour couvrir les signatures orphelines

'USER-AGENT' : {'technique': 'T1590', 'tactic': 'Reconnaissance', 'name': 'Gather
Victim Network Info'},
'DNS' : {'technique': 'T1596', 'tactic': 'Reconnaissance', 'name': 'Search
Open Technical Databases'},
'SSH' : {'technique': 'T1021', 'tactic': 'Lateral Movement', 'name':
'Remote Services'},
'RDP' : {'technique': 'T1021', 'tactic': 'Lateral Movement', 'name':
'Remote Services'},
'ICMP PING' : {'technique': 'T1046', 'tactic': 'Discovery', 'name': 'Network
Service Discovery'},
'DROP' : {'technique': 'T1071', 'tactic': 'Command and Control', 'name':
'Application Layer Protocol'},

Étape 2 : Filtrer le bruit à la source

Pour les signatures de bruit pur (STREAM, INVALID, ET INFO générique), nous avons modifié
la logique de la boucle principale pour ne pas injecter ces alertes dans Elasticsearch :

# AVANT la correction — les alertes STREAM/INFO passaient avec T0000

# mitre = get_mitre_tag(signature)
# super_alert['mitre_technique'] = [Link]('technique', 'T0000')
# [Link](index='smart-ids-alerts-v5', body=super_alert) # ← T0000 injecté

# APRÈS la correction — les alertes sans MITRE sont filtrées

mitre = get_mitre_tag(signature)

# Si get_mitre_tag() retourne None → bruit → ne pas injecter dans ES

if mitre is None:
continue # Passer à l'alerte suivante sans injection

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 22

# Sinon, injecter avec le bon mapping MITRE
super_alert['mitre_technique'] = mitre['technique']
super_alert['mitre_tactic'] = mitre['tactic']
super_alert['mitre_name'] = mitre['name']
[Link](index='smart-ids-alerts-v5', body=super_alert)

B.3.4 T0000 Résiduel — Problème Non Complètement Résolu

Après la correction, un T0000 résiduel a été détecté lors de l'inspection des données :

⚠️T0000 Résiduel Identifié

Signature : 'ET INFO SSH-2.0-Go version string Observed'

La correction initiale ciblait le pattern 'STREAM' et 'ET INFO' générique,

mais pas spécifiquement les strings de version SSH ('SSH-2.0-Go', 'SSH-2.0-OpenSSH'...).

Ce cas particulier représente des sondes de version SSH — borderline entre :

- Informatif neutre (quelqu'un vérifie la version SSH exposée)
- Reconnaissance active (T1046 ou T1021)

Décision prise : mapper ces signatures vers T1021 (Remote Services) car
observer intentionnellement une version SSH fait partie d'une phase de reconnaissance.

Fix additionnel dans MITRE_MAPPING :

'SSH-2.0' : {'technique': 'T1021', 'tactic': 'Lateral Movement', ...}

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 23

B.4 Résultats MITRE Observés en Production
B.4.1 Distribution des Techniques MITRE dans Smart-IDS
Après correction du T0000, voici la distribution réelle des techniques MITRE observées dans
notre SOC sur 24 heures :

Technique Nom Occurrences % du total Origine

MITRE

T1499 Endpoint Denial of 883 83.3% Ping flood / ICMP massif

Service depuis attacker-vm Kali
T1190 Exploit Public-Facing 20 1.9% Tentatives exploitation
App web (HTTP anomalies)
T1046 Network Service 16 1.5% Scans Nmap depuis
Discovery attacker-vm
T1071 Application Layer 10 0.9% Communications C2 —
Protocol IPs compromises connues
T1021 Remote Services 8 0.8% Sondes SSH — version
string observed
T1110 Brute Force 6 0.6% Tentatives Hydra SSH
T1082 System Information 4 0.4% enum4linux / SMB
Discovery enumeration
T1595 Active Scanning 3 0.3% Nmap scripts vuln,
Masscan
T0000 Unclassified (résiduel) 0 0% Corrigé à 0 après le fix

B.4.2 Analyse des Résultats

Pourquoi T1499 domine à 83% ?
▸ hping3 SYN flood (30 secondes) génère des centaines de milliers de paquets —
chaque paquet peut déclencher une alerte Suricata. Une seule attaque hping3 peut
produire 800+ alertes.
▸ C'est représentatif d'un SOC réel : les attaques de déni de service (DoS) génèrent
toujours un volume d'alertes disproportionné par rapport aux autres types.
▸ Solution pour un vrai SOC : agréger les alertes T1499 par IP source sur une fenêtre
de 60 secondes et les présenter comme une seule alerte consolidée.

Pourquoi T1071 — C2 apparaît-il ?

Ces alertes correspondent aux IPs externees malveillantes ([Link], [Link]) qui
tentent de scanner nos ports. Suricata les identifie via ses règles COMPROMISED et DROP
Dshield, qui signalent des IPs connues pour héberger des serveurs C2 (Command and Control).

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 24

B.4.3 Tableau Récapitulatif des Mappings Clés
Signature Suricata Pattern détecté Technique Tactique Niveau mena
MITRE typique

ET SCAN Potential SSH Scan 'SCAN' T1046 Discovery MEDIUM à

detected HIGH
ET SCAN Nmap OS fingerprint 'Nmap' T1046 Discovery HIGH
ET COMPROMISED Known Hostile 'COMPROMISED' T1071 Command and CRITICAL
Host T Control
ET DROP Dshield Block Listed 'DROP' T1071 Command and CRITICAL
Source Control
GPL ICMP PING *NIX 'ICMP PING' T1046 Discovery MEDIUM
ET SCAN Masscan User-Agent 'masscan' T1046 Discovery HIGH
SURICATA HTTP gzip 'HTTP' T1190 Initial Access HIGH
decompression failed
ET EXPLOIT SSH Brute Force 'Brute_Force' T1110 Credential Access HIGH
ET INFO SSH-2.0-Go version string 'SSH-2.0' T1021 Lateral Movement LOW à
MEDIUM
SURICATA STREAM Packet invalid 'STREAM' None → FILTRÉ — Non injecté
ack
ET INFO DNS Non-Recursive 'ET INFO' None → FILTRÉ — Non injecté
Query
SURICATA STREAM excessive 'STREAM' None → FILTRÉ — Non injecté
retransmissions

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 25

B.5 Utilisation de MITRE dans le Dashboard
B.5.1 Dans le Dashboard React
Chaque alerte affichée dans l'onglet 'Alertes' du dashboard React inclut la technique MITRE :

# Structure d'une AlertRow dans [Link]

function AlertRow({ alert, onAnalyze }) {
return (
<div>
{/* Niveau de menace : CRITICAL / HIGH / MEDIUM / LOW */}
<span>{[Link]}</span>

{/* Technique MITRE — source de la technique */}

<span style={{ color: [Link] }}>
{alert.mitre_technique || 'T0000'} {/* Ex: T1046 */}
</span>

{/* Signature Suricata tronquée à 55 caractères */}

<span>{([Link] || '').substring(0, 55)}</span>

{/* Scores ML et TI */}

<span>XGB:{alert.xgb_confidence?.toFixed(0)}%</span>
{alert.vt_score > 0 && <span>VT:{alert.vt_score}</span>}
{alert.lstm_killchain && <span>⚡KC</span>}
</div>
)
}

B.5.2 Dans Kibana — Top MITRE ATT&CK Widget

Le dashboard Kibana V4 inclut un widget 'Top MITRE ATT&CK' qui montre les techniques les
plus utilisées contre notre infrastructure. Configuration du widget :

Paramètre Valeur Justification

Type de visualisation Bar Chart Horizontal Comparaison facile des occurrences

par technique
Axe X (valeur) Count des documents Nombre d'alertes par technique
Axe Y (catégorie) mitre_technique.keyword Le champ keyword permet le tri et
l'agrégation
Index Pattern smart-ids-alerts-v5* Uniquement les super-alertes
enrichies — pas les alertes brutes
Filtre mitre_technique != 'T0000' Exclure les non-classifiés du widget
— depuis la correction T0000, ce
filtre est redondant
Période par défaut 24 heures Vue SOC quotidienne standard

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 26

 Paramètre Valeur Justification

Nombre de résultats Top 10 Afficher uniquement les 10

techniques les plus actives

B.5.3 Dans le Rapport Gemini

Gemini utilise les informations MITRE pour générer des rapports SOC contextualisés. Exemple
de prompt structuré envoyé à Gemini :

# Prompt structuré pour le rapport de sécurité 8h

prompt = f'''
Tu es un analyste SOC senior. Analyse ces alertes des 8 dernières heures.

ALERTES DÉTECTÉES (résumé) :

- T1499 (DoS) : 883 alertes depuis [Link]
- T1071 (C2) : 10 alertes depuis IPs COMPROMISED
- T1046 (Scan): 16 alertes depuis diverses IPs

Pour chaque technique MITRE :

1. Explique ce que cette technique signifie concrètement
2. Évalue le risque pour notre infrastructure
3. Donne des recommandations actionnables

Format : Rapport exécutif en français, clair et professionnel.

'''

B.5.4 Dans la Détection LSTM — Kill Chains

Le LSTM utilise les techniques MITRE pour définir ce qu'est une kill chain réelle. Une séquence
d'alertes est considérée comme une kill chain si elle contient des techniques de 2+ étapes
tactiques MITRE distinctes :

# Définition d'une kill chain basée sur les tactiques MITRE

def is_kill_chain(seq_mitres: list) -> int:
# Retourne 1 si la séquence représente une kill chain, 0 sinon

unique_techniques = set(seq_mitres)

# Étape 1 : Reconnaissance (T1046, T1590, T1595, T1596)

recon = any(m in unique_techniques for m in ['T1046', 'T1590', 'T1595',
'T1596'])

# Étape 2 : Exploitation (T1190, T1059, T1110)

exploit = any(m in unique_techniques for m in ['T1190', 'T1059', 'T1110'])

# Étape 3 : C&C (T1071, T1557, T1021)

c2 = any(m in unique_techniques for m in ['T1071', 'T1557', 'T1021'])

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 27

# Étape 4 : Impact (T1499, T1486)
impact = any(m in unique_techniques for m in ['T1499', 'T1486'])

# Kill chain = 2+ étapes distinctes présentes dans la séquence

stages = sum([recon, exploit, c2, impact])
return 1 if (stages >= 2 or len(unique_techniques) >= 2) else 0

💡 Exemple de Kill Chain Détectée

Séquence d'alertes depuis [Link] sur 15 minutes :

Alert 1 (18:06:01) : T1046 — Network Scan (nmap_syn)
Alert 2 (18:06:09) : T1046 — Network Scan (nmap_version_os)
Alert 3 (18:06:29) : T1595 — Active Scanning (masscan)
Alert 4 (18:06:58) : T1595 — Active Scanning (nmap_scripts)
Alert 5 (18:07:06) : T1110 — Brute Force (hydra_ssh)
Alert 6 (18:07:15) : T1499 — Endpoint DoS (hping3_syn)

Techniques uniques : {T1046, T1595, T1110, T1499}

Étapes présentes : Reconnaissance ✓ + Credential Access ✓ + Impact ✓ = 3 étapes
→ is_kill_chain = 1 → ⚡ Kill Chain détectée → alerte dans le dashboard

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 28

B.6 Synthèse Complète — MITRE dans Smart-IDS
Composant Utilisation de MITRE Implémentation

[Link] Mapping signature → Dictionnaire Python avec 25+

technique via get_mitre_tag() patterns, filtre None pour le bruit
smart-ids-alerts-v5 Stockage des champs Index Elasticsearch — disponible
mitre_technique, mitre_tactic, pour tous les composants
mitre_name
Dashboard React Affichage de la technique AlertRow component — champ
MITRE sur chaque ligne mitre_technique.keyword
d'alerte
Kibana Widget 'Top MITRE ATT&CK' Agrégation terms sur
— bar chart horizontal mitre_technique.keyword
LSTM V4 PRO Définition d'une kill chain via 2+ étapes tactiques distinctes dans
is_kill_chain() la séquence
Gemini Rapport Contextualisation narrative Techniques MITRE injectées dans le
des techniques détectées prompt structuré
Score Composite Non utilisé directement — Le ML apprend les patterns
mais influence via comportementaux liés à chaque
xgb_confidence technique

— Fin de la Partie 2 (Threat Intelligence & MITRE ATT&CK) —

Smart-IDS Framework V5 | Avril 2026 | Note Globale : 8.7/10

Smart-IDS Framework V5 | Threat Intelligence & MITRE ATT&CK | Page 29