feat(ml): replace logistic regression with MLP fusion and KS drift with ADWIN online learning
Replace the LogisticRegression meta-learner with a PyTorch MetaFusionMLP (Linear(3,16)->BN->ReLU->Dropout->Linear(16,1)->Sigmoid) for non-linear fusion of EIF, NF, and XGBoost scores. Replace KS-test + quantile digest drift detection with ADWIN (adaptive sliding window, Hoeffding bound). Replace weekly XGBoost batch retraining with River HoeffdingAdaptiveTree for incremental online learning (learn_one per cycle). Update all thesis documentation sections (2.4.2c, 2.4.3, 3.8, discussion, conclusion). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Jacquin Antoine
@ -11,7 +11,7 @@
|
||||
|
||||
## Résumé
|
||||
|
||||
Ce document présente une architecture opérationnelle de détection et classification du trafic HTTP malveillant, s'inscrivant dans la continuité des approches de génération 3 (fingerprinting multi-protocole et ML comportemental). Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un autoencodeur (AE) et XGBoost, fusionnés par une régression logistique calibrée activée à partir de 1 000 étiquettes accumulées. L'explicabilité est assurée par l'importance des features par profondeur d'isolation (EIF) et SHAP TreeExplainer (XGBoost). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent 16 dimensions de l'autoencodeur, et la détection de flottes coordonnées par graphes bipartis via NetworkX. Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — exploite un signal déjà utilisé par des solutions industrielles (Akamai, Cloudflare, F5), ici implémenté via eBPF. L'infrastructure repose sur 16 modules Python (4 800 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 % — chiffre opérationnel brut, non validé comme taux de détection). Le système intègre un moteur de profiling dynamique automatique des navigateurs (HDBSCAN sur les vecteurs H2 observés, centroïdes auto-appris, scoring temps réel par distance normalisée) qui s'adapte aux évolutions des piles HTTP/2 sans intervention manuelle.
|
||||
Ce document présente une architecture opérationnelle de détection et classification du trafic HTTP malveillant, s'inscrivant dans la continuité des approches de génération 3 (fingerprinting multi-protocole et ML comportemental). Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un Normalizing Flow (NF) et XGBoost, fusionnés par un méta-modèle MLP (Multi-Layer Perceptron) non-linéaire calibré sur les étiquettes accumulées. L'explicabilité est assurée par l'importance des features par profondeur d'isolation (EIF) et SHAP TreeExplainer (XGBoost). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent 16 dimensions de l'autoencodeur, et la détection de flottes coordonnées par graphes bipartis via NetworkX. Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — exploite un signal déjà utilisé par des solutions industrielles (Akamai, Cloudflare, F5), ici implémenté via eBPF. L'infrastructure repose sur 16 modules Python (4 800 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 % — chiffre opérationnel brut, non validé comme taux de détection). Le système intègre un moteur de profiling dynamique automatique des navigateurs (HDBSCAN sur les vecteurs H2 observés, centroïdes auto-appris, scoring temps réel par distance normalisée) qui s'adapte aux évolutions des piles HTTP/2 sans intervention manuelle.
|
||||
|
||||
**Mots-clés** : fingerprinting réseau, JA4+, HTTP/2 fingerprinting, détection de bots, Extended Isolation Forest, autoencodeurs, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ Ce document décrit une architecture opérationnelle s'inscrivant dans la contin
|
||||
1. **Corrélation TCP/TLS/HTTP** en temps réel via ja4ebpf (clé : `src_ip:src_port`, 256 shards, timeout orphelin 500 ms)
|
||||
2. **Fingerprinting HTTP/2 passif** : extraction des trames SETTINGS, WINDOW_UPDATE, PRIORITY et de l'ordre des pseudo-headers directement depuis le stream TCP — approche déjà exploitée par des solutions industrielles (Akamai, Cloudflare, F5), ici implémentée via eBPF
|
||||
3. **Architecture EIF bifurquée** : modèle complet (≈ 45 features L3→L7) et modèle applicatif (≈ 35 features L7 uniquement), évitant le biais de zérotage sur le trafic non corrélé — choix pragmatique de gestion des données manquantes
|
||||
4. **Ensemble triple-voix avec fusion par régression logistique** : combinaison EIF + AE + XGBoost avec régression logistique apprise sur étiquettes accumulées
|
||||
4. **Ensemble triple-voix avec fusion par MLP non-linéaire** : combinaison EIF + NF + XGBoost avec méta-modèle MLP apprenant les interactions non-linéaires entre les trois voix
|
||||
5. **HDBSCAN dans l'espace latent AE** : clustering de campagnes par similarité de comportement compressé en 16 dimensions
|
||||
6. **Détection de dérive adversariale** : distinction entre dérive organique (mises à jour navigateur) et manipulation directionnelle coordonnée
|
||||
7. **8 features comportementales avancées** : application de statistiques standard (déviation de Benford, entropie de transition markovienne, autocorrélation lag-1, délai root-to-first-asset, diversité de hosts, uniformité de couverture cross-host) au domaine de la détection de bots
|
||||
|
||||
@ -413,20 +413,20 @@ Le système de détection combine trois « voix » complémentaires :
|
||||
┌──────────────┼──────────────┐
|
||||
│ │ │
|
||||
┌─────▼─────┐ ┌─────▼─────┐ ┌────▼──────┐
|
||||
│ EIF │ │ AE │ │ XGBoost │
|
||||
│ (semi- │ │ (semi- │ │(supervisé)│
|
||||
│supervisé) │ │supervisé) │ │ │
|
||||
│ EIF │ │ NF │ │ XGBoost │
|
||||
│ (semi- │ │ (Normal- │ │(supervisé)│
|
||||
│supervisé) │ │ izing │ │ │
|
||||
│ │ │ Flow) │ │ │
|
||||
└─────┬─────┘ └─────┬─────┘ └────┬──────┘
|
||||
│ │ │
|
||||
eif_norm ae_norm xgb_prob
|
||||
eif_norm nf_norm xgb_prob
|
||||
│ │ │
|
||||
└──────────────┼──────────────┘
|
||||
│
|
||||
┌────────▼────────┐
|
||||
│ Fusion LR │
|
||||
│ (régression │
|
||||
│ logistique, │
|
||||
│ ≥1000 labels) │
|
||||
│ Meta-Model │
|
||||
│ Stacking MLP │
|
||||
│ (non-linéaire) │
|
||||
└────────┬────────┘
|
||||
│
|
||||
┌────────▼────────┐
|
||||
@ -435,33 +435,47 @@ Le système de détection combine trois « voix » complémentaires :
|
||||
└─────────────────┘
|
||||
```
|
||||
|
||||
**Formule de combinaison** :
|
||||
**Limites de la fusion linéaire**
|
||||
|
||||
```python
|
||||
final = (1 - XGB_WEIGHT) × ((1 - AE_WEIGHT) × eif_norm + AE_WEIGHT × ae_norm) \
|
||||
+ XGB_WEIGHT × xgb_prob
|
||||
```
|
||||
|
||||
Valeurs par défaut : `AE_WEIGHT=0.30`, `XGB_WEIGHT=0.20`. Configurable via variables d'environnement pour ajustement en production sans modification du code.
|
||||
|
||||
**Fusion LR**
|
||||
|
||||
Le Fusion LR est une régression logistique activée lorsqu'au moins 1 000 étiquettes ont été accumulées (sessions DENY Anubis + annotations manuelles + seuillage de confiance).
|
||||
|
||||
Régression logistique : modèle linéaire probabiliste qui apprend des poids w pour chaque signal intermédiaire en minimisant l'entropie croisée binaire sur les étiquettes accumulées :
|
||||
Une fusion linéaire — combinaison convexe pondérée ou régression logistique — ne peut capturer que des frontières de décision linéaires dans l'espace des scores intermédiaires. Or les signaux EIF, NF et XGBoost peuvent exhiber des interactions non-linéaires impossibles à modéliser par une combinaison linéaire :
|
||||
|
||||
```
|
||||
P(bot) = σ(w1×eif + w2×ae + w3×xgb + w4×volume + bias)
|
||||
Problème XOR des scores :
|
||||
NF élevé
|
||||
┌────────┐
|
||||
EIF bas │ BOT ✓ │ ← combinaison inhabituelle = bot confirmé
|
||||
├────────┤
|
||||
EIF haut │normal ✗│ ← faux positif fréquent de l'EIF seul
|
||||
└────────┘
|
||||
NF bas
|
||||
```
|
||||
|
||||
où σ est la fonction sigmoïde : σ(z) = 1 / (1 + e^{-z})
|
||||
Exemple concret : un bot utilisant un outilHeadless avec un JA4 fingerprint légitime (NF bas) mais un comportement de navigation atypique (EIF élevé). Le XGBoost peut compenser, mais la fusion linéaire ne peut apprendre la relation *« EIF élevé ET XGB élevé MAIS NF bas = bot »* — elle ne fait que sommer les contributions indépendantes.
|
||||
|
||||
Les poids w1–w4 sont appris, permettant au système de calibrer automatiquement l'importance relative de chaque voix en fonction du type de trafic en production. En dessous de 1 000 étiquettes, le système revient aux poids fixes : `(eif: 0.50, ae: 0.30, xgb: 0.20)`.
|
||||
**Stacking OOF (Out-of-Fold) et MLP méta-modèle**
|
||||
|
||||
Pour résoudre cette limitation, le système utilise un méta-modèle non-linéaire de type MLP (*Multi-Layer Perceptron*) entraîné via stacking Out-of-Fold :
|
||||
|
||||
1. **Prédictions OOF** : les modèles de base (EIF, NF, XGBoost) produisent des prédictions sur des plis de validation croisée temporelle, garantissant que le méta-modèle n'a jamais vu les données d'entraînement des modèles de base — évitant le surapprentissage (*information leakage*).
|
||||
|
||||
2. **Méta-modèle MLP** : un réseau de neurones à 2 couches apprend la fonction de fusion optimale :
|
||||
|
||||
```
|
||||
MetaFusionMLP : [eif, nf, xgb] → Linear(3,16) → BatchNorm → ReLU → Dropout(0.2)
|
||||
→ Linear(16,1) → Sigmoid → P(bot)
|
||||
```
|
||||
|
||||
- **BatchNorm** : normalise les activations intermédiaires, stabilise l'apprentissage et régularise implicitement — crucial avec peu de données labellisées.
|
||||
- **Dropout(0.2)** : désactive aléatoirement 20% des neurones pendant l'entraînement, prévenant la co-adaptation des poids.
|
||||
- **Early stopping** (patience = 5 epochs) : arrête l'entraînement dès que la loss de validation ne s'améliore plus, évitant le surapprentissage.
|
||||
- **Weight decay** ($\lambda = 10^{-4}$) : pénalité L2 sur les poids du MLP pour une régularisation supplémentaire.
|
||||
|
||||
Le MLP apprend des frontières de décision non-linéaires dans l'espace 3D `[eif_norm, nf_norm, xgb_prob]`, capable de résoudre les patterns XOR et les interactions conditionnelles entre les trois voix. Le système de détection peut ainsi combiner automatiquement les signaux de manière optimale en fonction du type de trafic observé en production.
|
||||
|
||||
**Calendrier de retraining** :
|
||||
- XGBoost : hebdomadaire sur les étiquettes accumulées, après filtrage Cleanlab des labels SOC bruyants (voir ci-dessous)
|
||||
- EIF : toutes les 24 heures
|
||||
- AE : continu avec arrêt précoce sur la loss de validation
|
||||
- HAT (supervisé) : apprentissage incrémental à chaque cycle (300s) sur les étiquettes accumulées, après filtrage Cleanlab des labels SOC bruyants (voir ci-dessous)
|
||||
- EIF : toutes les 24 heures ou sur détection ADWIN
|
||||
- NF : continu avec arrêt précoce sur la loss de validation
|
||||
|
||||
**Filtrage des labels SOC bruyants (Cleanlab)** :
|
||||
|
||||
@ -481,7 +495,7 @@ X_clean, y_clean = X[~noisy_mask], y[~noisy_mask]
|
||||
|
||||
Ce mécanisme protège le modèle contre l'empoisonnement par des faux positifs mal corrigés ou des biais de confirmation des analystes. Le taux de labels filtrés est loggé pour surveillance. En cas d'échec de Cleanlab (erreur mémoire, dépendance manquante), le pipeline revient aux données brutes sans interruption.
|
||||
|
||||
#### 2.4.3 Concept Drift et retraining adaptatif
|
||||
#### 2.4.3 Concept Drift : ADWIN et Online Learning
|
||||
|
||||
**Définition du concept drift**
|
||||
|
||||
@ -494,28 +508,74 @@ En apprentissage automatique, le concept drift désigne le changement des propri
|
||||
|
||||
En détection de bots, le drift adversarial est particulièrement critique : les attaquants adaptent délibérément leurs outils pour contourner les modèles déployés.
|
||||
|
||||
**Test de Kolmogorov-Smirnov**
|
||||
**Limites de l'approche KS + quantile digest**
|
||||
|
||||
Le test KS (Kolmogorov-Smirnov) mesure la différence maximale entre deux fonctions de distribution empiriques cumulées (ECDF) :
|
||||
L'approche précédente détectait la dérive en sauvegardant 5 quantiles (p10, p25, p50, p75, p90) par feature à l'entraînement, puis en reconstruisant une distribution synthétique par interpolation de la CDF inverse et en appliquant un test de Kolmogorov-Smirnov entre cette distribution et la distribution courante. Cette méthode souffre de trois lacunes fondamentales :
|
||||
|
||||
1. **5 quantiles ne captent pas les distributions bimodales** : les features de trafic web comme `asset_ratio`, `post_ratio` et `orphan_ratio` ont souvent des distributions bimodales (deux populations de trafic distinctes). Cinq points ne suffisent pas à reconstruire fidèlement ces distributions — une dérive dans un mode peut être masquée par la stabilité de l'autre mode.
|
||||
|
||||
2. **Reconstruction par interpolation linéaire** : interpoler entre 5 quantiles suppose une distribution unimodale et lisse. Pour les distributions skewed à queue lourde (timing inter-requêtes, taille des payloads), l'interpolation sous-estime systématiquement les valeurs extrêmes, rendant le test KS peu fiable.
|
||||
|
||||
3. **Seuil de 30% arbitraire** : le seuil `DRIFT_THRESHOLD = 0.30` (30% de features en dérive) est un hyperparamètre non fondé statistiquement. Il est trop sensible pour les périodes de forte activité (faux positifs) et trop conservateur pour les attaques furtives ne touchant que quelques features.
|
||||
|
||||
**ADWIN : fenêtre glissante adaptative**
|
||||
|
||||
[ADWIN (ADaptive WINdowing, Bifet & Gavalda, 2007)](https://dl.acm.org/doi/10.1145/1242572.1242660) résout ces problèmes en maintenant une fenêtre de longueur variable sur le flux de données. Le principe :
|
||||
|
||||
1. **Fenêtre adaptative** : ADWIN maintient une fenêtre $W$ de valeurs récentes. La taille de $W$ s'ajuste automatiquement — elle grandit quand la distribution est stable et rétrécit quand un changement est détecté.
|
||||
|
||||
2. **Test de Hoeffding** : pour chaque coupe possible $W = W_0 \cup W_1$, ADWIN compare les moyennes $\hat{\mu}_0$ et $\hat{\mu}_1$ des deux sous-fenêtres. Si la différence dépasse la borne de Hoeffding :
|
||||
|
||||
$$|\hat{\mu}_0 - \hat{\mu}_1| \geq \sqrt{\frac{1}{2m} \ln\frac{4}{\delta}}$$
|
||||
|
||||
où $m = \frac{1}{1/|W_0| + 1/|W_1|}$ et $\delta$ est le paramètre de confiance, alors un changement est détecté et la sous-fenêtre la plus ancienne est supprimée.
|
||||
|
||||
3. **Pas de seuil arbitraire** : la détection repose uniquement sur la borne de Hoeffding (garantie probabiliste), paramétrée par $\delta$ (défaut : 0.002). Aucun seuil de « 30% de features en dérive » n'est nécessaire au niveau de chaque feature — seul le nombre de features driftant simultanément déclenche le retraining global.
|
||||
|
||||
**Architecture de monitoring ADWIN** :
|
||||
|
||||
```
|
||||
D = max|F1(x) - F2(x)|
|
||||
Cycle n (300s)
|
||||
│
|
||||
├── Calculer μ_f pour chaque feature f sur le trafic baseline
|
||||
│
|
||||
├── ADWIN_f.update(μ_f) pour chaque feature
|
||||
│ └── Fenêtre interne W_f ajustée automatiquement
|
||||
│
|
||||
├── ADWIN_f.detected_change() ?
|
||||
│ └── Si oui → feature f marquée « en dérive » ce cycle
|
||||
│
|
||||
└── Si > 30% features en dérive → flag retraining EIF/NF
|
||||
Si > 50% features en dérive → alerte ADVERSARIAL_DRIFT
|
||||
```
|
||||
|
||||
où F1 et F2 sont les ECDFs de la distribution courante et de la distribution de référence (baseline). Si D dépasse la valeur critique (déterminée par les tables de la distribution KS pour un niveau de confiance α), les deux échantillons sont considérés comme provenant de distributions différentes. Avantage : test non-paramétrique, aucune hypothèse sur la forme de la distribution.
|
||||
**Online Learning : Hoeffding Adaptive Tree**
|
||||
|
||||
**Méthode de détection de dérive** :
|
||||
Le retraining hebdomadaire par batch (`XGBClassifier.fit()` sur l'ensemble des labels accumulés) est remplacé par un apprentissage incrémental via [River](https://riverml.xyz/), une bibliothèque spécialisée en stream mining. Le modèle utilisé est le `HoeffdingAdaptiveTreeClassifier` (HAT) :
|
||||
|
||||
1. Sauvegarde avec chaque modèle sérialisé de l'approximation 5-quantiles par feature : (p10, p25, p50, p75, p90)
|
||||
2. Génération d'échantillons synthétiques par interpolation de la CDF inverse (quantile function)
|
||||
3. Test KS + divergence KL sur chaque feature entre la distribution courante et la baseline
|
||||
4. Feature marquée comme « en dérive » si le test KS OU la divergence KL dépasse le seuil configuré
|
||||
5. Retraining forcé si > 30 % des features dérivent simultanément
|
||||
6. **Détection de dérive adversariale** : si de nombreuses features dérivent simultanément dans la même direction (score de corrélation directionnelle élevé), génération d'une alerte spécifique distinguant la manipulation intentionnelle (dérive adversariale coordonnée) de l'évolution organique (mises à jour navigateur ou changements de comportement naturels)
|
||||
- **Arbre de décision incrémental** : construit l'arbre de décision progressivement, un exemple à la fois via `learn_one(x, y)`. À chaque split, le test de Hoeffding garantit que le split choisi est (probablement) le même que celui qu'un arbre batch aurait choisi avec les mêmes données.
|
||||
- **Adaptatif** : utilise des estimateurs de fenêtre ADWIN à chaque nœud pour remplacer les statistiques obsolètes — le modèle s'adapte automatiquement au concept drift sans retraining explicite.
|
||||
- **Apprentissage par cycle** : à chaque cycle de 300s, les nouveaux labels accumulés sont injectés un par un via `learn_one()`. Le modèle s'améliore continuellement, rendant le lourd retraining hebdomadaire obsolète.
|
||||
|
||||
**Validation gate** : si le taux d'anomalie sur le jeu de validation dépasse 20 % après retraining, le nouveau modèle est rejeté et le modèle précédent est conservé, avec génération d'une alerte (baseline contaminée).
|
||||
```
|
||||
Cycle 300s
|
||||
│
|
||||
├── Charger HAT sérialisé (pickle)
|
||||
│
|
||||
├── Pour chaque label accumulé ce cycle :
|
||||
│ model.learn_one({feature: value, ...}, label)
|
||||
│
|
||||
├── Persister HAT mis à jour
|
||||
│
|
||||
└── Prédiction : model.predict_proba_many(df) → P(bot)
|
||||
```
|
||||
|
||||
**Limites de l'approximation 5-quantiles** : adéquate pour les distributions unimodales, mais peut manquer les dérives bimodales dans `asset_ratio`, `post_ratio`, `orphan_ratio`. Extension à p5/p95 ou à t-digest identifiée comme travail futur.
|
||||
Le passage au stream mining élimine trois problématiques majeures du batch training :
|
||||
- **Latence de mise à jour** : de hebdomadaire à chaque cycle (300s)
|
||||
- **Coût mémoire** : plus besoin de charger 50 000 labels en RAM
|
||||
- **Stale model** : le modèle est toujours à jour par rapport au concept courant
|
||||
|
||||
**Validation gate** : conservée — si le taux d'anomalie sur le jeu de validation dépasse 20% après retraining EIF/NF, le nouveau modèle est rejeté et le modèle précédent conservé.
|
||||
|
||||
#### 2.4.4 Modélisation des phases d'attaque
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@
|
||||
│ │ 4. EIF bifurqué (complet/appli) │ │
|
||||
│ │ 5. NF log-likelihood scoring │ │
|
||||
│ │ 6. XGBoost probabilité │ │
|
||||
│ │ 7. Fusion LR fusion │ │
|
||||
│ │ 7. Meta-Model MLP fusion │ │
|
||||
│ │ 8. HDBSCAN clustering (NF latent) │ │
|
||||
│ │ 9. Écriture résultats ClickHouse │ │
|
||||
│ └──────────────────────────────────┘ │
|
||||
@ -240,7 +240,7 @@ Session entrante
|
||||
├── asn_label == 'human' ?
|
||||
│ ── OUI → baseline EIF training (sans étiquette bot)
|
||||
│
|
||||
└── Sinon → Triple-voix : EIF + NF + XGBoost + Fusion LR
|
||||
└── Sinon → Triple-voix : EIF + NF + XGBoost + Meta-Model Stacking (MLP non-linéaire)
|
||||
```
|
||||
|
||||
#### Seuil adaptatif
|
||||
|
||||
@ -115,7 +115,7 @@ Le fingerprinting réseau opère sans déchiffrement TLS (les métadonnées TLS
|
||||
| HDBSCAN (profiling) | ~2–5 s | Quotidien, ~200k sessions H2 dédupliquées, min_cluster=1000 |
|
||||
| Dynamic matcher scoring | < 1 ms | Par session, lookup en mémoire contre ~5–10 profils |
|
||||
| GraphSAGE (fleet.py) | ~80 ms | Graphe d'IPs, 2 couches SAGEConv, GPU/CPU |
|
||||
| Fusion LR LR | < 10 ms | Régression logistique, négligeable |
|
||||
| Fusion MLP | < 10 ms | MLP 2 couches, négligeable |
|
||||
| **Cycle complet** | **~300 secondes** | EIF + AE + XGBoost + HDBSCAN + GraphSAGE |
|
||||
|
||||
La durée du cycle (300 s = 5 minutes) est contrainte principalement par la **fenêtre d'agrégation ClickHouse** (1 heure glissante avec recalcul toutes les 5 minutes), non par les temps d'exécution ML.
|
||||
@ -133,9 +133,9 @@ La durée du cycle (300 s = 5 minutes) est contrainte principalement par la **fe
|
||||
- À 34 000 sessions/cycle : ~100 ms — acceptable
|
||||
- À 500 000 sessions/cycle (scaling ×15) : ~2 s — encore tolérable
|
||||
|
||||
**Fusion LR logistic regression** : O(n × d) entraînement, d = 3 features d'entrée (scores EIF, AE, XGBoost). Temps négligeable quelle que soit la taille.
|
||||
**Fusion MLP** : O(n × d) inférence avec d = 3 features d'entrée (scores EIF, NF, XGBoost), MLP 2 couches (16 neurones). Temps négligeable quelle que soit la taille.
|
||||
|
||||
**Limite architecturale principale** : le modèle XGBoost hebdomadaire nécessite un jeu de labels accumulés via le feedback SOC. À faible volume de labels (< 500 sessions étiquetées par semaine), XGBoost ne converge pas correctement. Ce problème est partiellement atténué par le filtrage Cleanlab qui élimine les labels douteux (détail §3.8), mais reste identifié comme axe d'amélioration futur (§6.6 — online learning).
|
||||
**Limite architecturale principale** : le modèle supervisé (Hoeffding Adaptive Tree) s'améliore incrémentalement à chaque cycle via `learn_one()`, mais nécessite un flux continu de labels fiables. À faible volume de labels (< 500 sessions étiquetées), le HAT converge lentement. Ce problème est partiellement atténué par le filtrage Cleanlab qui élimine les labels douteux (détail §3.8), mais la qualité du feedback SOC reste le goulot d'étranglement principal.
|
||||
|
||||
**Overhead de l'uprobe SSL_read** : un uprobe attaché à `SSL_read` se déclenche à *chaque* appel de lecture TLS, y compris pour les gros transferts de fichiers (images, vidéos, scripts JS volumineux), où une seule requête peut générer des dizaines d'appels `SSL_read` successifs transportant des frames HTTP/2 DATA sans intérêt pour le fingerprinting. Sous forte charge (> 10 000 connexions TLS actives simultanées), cet overhead peut dégrader les performances du serveur web de manière mesurable. Les mitigations recommandées sont : (1) filtrer côté eBPF les invocations dont le buffer ne contient pas les magic bytes HTTP/2 ou HTTP/1.x (`GET `, `POST `, etc.) avant de soumettre au ring buffer ; (2) ignorer les frames HTTP/2 de type DATA de grande taille (longueur payload > 16 384 octets) qui ne contiennent pas d'en-têtes de requête ; (3) appliquer du sampling probabiliste (ex. 1 appel sur 10) pour les connexions déjà identifiées par leur JA4 comme des navigateurs légitimes connus.
|
||||
|
||||
@ -208,10 +208,10 @@ Un Variational Autoencoder bêta ([β-VAE, Higgins et al., 2017](https://openrev
|
||||
Des modèles d'état-espace pour la modélisation des phases d'attaque — permet de détecter explicitement les transitions de phase (reconnaissance → exploitation) au lieu de seulement scorer chaque session isolément. Complémentaire au signal JA4 Drift (§5.5).
|
||||
|
||||
**t-digest pour la dérive conceptuelle** :
|
||||
Remplacement de l'approximation à 5 quantiles actuellement utilisée pour la détection de drift ([quantile_drift_score]) par la structure **t-digest** , qui supporte les distributions bimodales et les queues longues avec précision adaptative. Critique pour les features à distribution bimodale comme `hit_velocity` (distribution séparée bots/humains).
|
||||
Remplacement effectué — ADWIN (fenêtre glissante adaptative avec borne de Hoeffding) remplace l'approximation à 5 quantiles + KS. ADWIN gère nativement les distributions bimodales et les queues longues sans reconstruction de CDF.
|
||||
|
||||
**XGBoost → online learning** :
|
||||
Remplacement du ré-entraînement hebdomadaire XGBoost par un apprentissage incrémental (gradient boosting online, par exemple [XGBoost Federated](https://xgboost.readthedocs.io/en/stable/tutorials/federated_learning.html) ou RIVER framework) permettant des mises à jour par cycle au lieu d'attendre l'accumulation d'une semaine de labels.
|
||||
**Supervisé → online learning** :
|
||||
Remplacement effectué — le `HoeffdingAdaptiveTreeClassifier` de River remplace le XGBoost batch hebdomadaire. Le modèle s'améliore incrémentalement à chaque cycle (300s) via `learn_one()`, éliminant la latence de mise à jour hebdomadaire.
|
||||
|
||||
#### Priorité 3 — Infrastructure et protocoles émergents
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Un pipeline ML combinant :
|
||||
- **Isolation Forest Étendu (EIF)** ([Hariri et al., 2021](https://ieeexplore.ieee.org/document/8888179)) : modèle non-supervisé fondé sur l'isolation aléatoire d'instances anormales dans des espaces de features basse-dimension
|
||||
- **Autoencodeur variationnel (AE)** ([Mirsky et al., NDSS 2018](https://www.ndss-symposium.org/ndss-paper/kitsune-an-ensemble-of-autoencoders-for-online-network-intrusion-detection/)) : détection d'anomalies par reconstruction, capturant les corrélations entre features
|
||||
- **XGBoost supervisé** : correction des erreurs systématiques des modèles non-supervisés via labels SOC accumulés
|
||||
- **Fusion par régression logistique** : fusion des trois scores en un score final calibré
|
||||
- **Fusion par MLP méta-modèle** : fusion non-linéaire des trois scores en un score final calibré
|
||||
|
||||
Le pipeline intègre un mécanisme de **détection de dérive conceptuelle** (basé sur le percentile 5 des scores négatifs) distinguant la dérive organique (évolution naturelle du trafic) de la dérive adversariale (manipulation intentionnelle de la distribution).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user