Surveillance des menaces et alerte SOC

Résumé succinct

Un SOC efficace repose sur trois baleines : l'exhaustivité de la télémétrie, les détections de qualité et la discipline opérationnelle (hiérarchisation, escalade, post-incident et améliorations). Objectif : identifier rapidement les intrus par des indicateurs de comportement et de signature, réagir à l'intérieur du SLO et minimiser les faux positifs sans perte de couverture.

Architecture de surveillance SOC

SIEM - Réception, normalisation et corrélation d'événements ; Dashboards, recherche, alerting.
L'UEBA est l'analyse du comportement des utilisateurs/hôtes, des profils de base et des anomalies.
SOAR - automatisation de la réponse : enrichissement des alertes (TI, CMDB), orchestration des activités de containment.
TI (Threat Intelligence) - Fides IOC/TTP/vulnérabilités critiques ; le contexte de la réglementation et de l'enrichissement.
L'entrepôt est « chaud » 7-30 jours pour les enquêtes, « froid » 90-365 + pour les comparaisons/rétrospectives.

Sources de logs (minimum suffisant)

• IdP/SSO (OIDC/SAML), MFA, PAM, VPN/ZTNA, annuaires (AD/AAD).

• EDR/AV, Sysmon/ETW (Windows), auditd/eBPF (Linux), MDM (mobiles).

• Firvol (L3/L7), WAF/WAAP, équilibreurs (NGINX/Envoy), DNS, proxy, NetFlow/sFlow/Zeek.

• CloudTrail/Activity Logs, KMS/Key Vault, événements IAM, Kubernetes (audit, API server), sécurité des conteneurs.

• Vérification des amiraux, accès aux IPI/paiements, DDL/droits, événements commerciaux critiques (withdraw, bonus, payout).

• Phishing/spam detect, DLP, URL clics, pièces jointes.

Normalisation : format unique (par exemple ECS/CEF), champs obligatoires : 'timestamp', 'src/dst ip', 'user', 'action', 'resource', 'result', 'request _ id/trace _ id'.

Taxonomie des menaces et cartographie ATT&CK

Construisez des règles et des dashboards en coupe MITRE ATT&CK : Accès initial, Exécution, Persistance, Isolement, Évolution de la Défense, Accès Crédentiel, Découverte, Mouvement Latéral, C2, Collège sélection/Extraction/Impact.
Pour chaque tactique, les détections minimales et les panneaux de contrôle « coverage vs. fidelity ».

Politique d'alerte et hiérarchisation

• P1 (Critique) : C2 actif, ATF/enlèvement de token réussi, cryptage, exfiltration de paiement/PII.
• P2 (High) : implémentation dans l'infrastructure/cloud, escalade des privilèges, contournement de MFA.
• P3 (Médium) : anomalie suspecte, tentatives infructueuses répétées, comportement rare.
• P4 (Low) : bruit, hypothèses, coïncidences TI sans confirmation.
• Escalade : P1 est immédiatement sur appel (24 × 7), P2 est pendant les heures de travail ≤ 1 h, les autres sont par file d'attente.
• Déduplication : agrégez les alertes par objet/session pour éviter la « tempête ».

SLI/SLO/SLA SOC

SLI : temps de détection (MTD), temps de confirmation (MTTA), temps de contention (MTTC), proportion de faux positifs (FP) et de faux positifs (FN) sur les grappes de scénarios.

• MTTD P1 ≤ 5 min ; MTTC P1 ≤ 30 min
• FP-rate selon les règles de severity élevée ≤ 2 %/jour.
• Couverture des techniques clés ATT&CK ≥ 90 % (présence d'au moins une détection).
• SLA (externe) : s'entendre avec l'entreprise (p. ex., avis P1 aux propriétaires ≤ 15 min).

Règles de détection : signatures, heuristique, comportement

Sigma (exemple : accès suspect à un administrateur hors du pays)

yaml title: Admin Panel Access Outside Allowed Country id: 5c6c9c1d-8f85-4a0e-8c3a-1b7cabc0b001 status: stable logsource:
product: webserver detection:
selection:
http. request. uri: /admin http. response. status: 200 filter_country:
geoip. country: /^(?!UA    PL    GE)$/
condition: selection and filter_country level: high fields: [user, ip, geoip. country, user_agent, trace_id]
falsepositives:
- Service connections from SOC/VPN (add allow-list)

KQL (exemple : sursaut de logins échoués + comptes différents à partir d'une même IP)

kusto
SigninLogs where ResultType!= 0 summarize fails=count(), users=dcount(UserPrincipalName) by bin(TimeGenerated, 10m), IPAddress where fails > 50 and users > 5

Application (SQL, accès PII hors graphique)

sql
SELECT user_id, count() AS reads
FROM audit_pii
WHERE ts > now() - interval '1 hour'
AND user_id NOT IN (SELECT user_id FROM roster WHERE role IN ('DPO','Support'))
AND extract(hour from ts) NOT BETWEEN 8 AND 21
GROUP BY 1 HAVING count() > 5;

UEBA et contexte

Profils d'activité de base par utilisateur/rôle/service (horloge, ASN, appareils).
Anomalies : rare IP/ASN, nouveau device, séquences API inhabituelles, changement brusque de temps d'activité.
Score de risque de l'événement = signaux (TI, anomalie, sensibilité de la ressource) de poids ×.

SOAR et automatisation des réponses

Enrichissement : TI-réputation IP/domaine/hachage, CMDB (qui est le propriétaire de l'hôte/service), RH (statut d'employé), rôle IAM.
Actions : Isolation d'hôte (EDR), blocage des IP/ASN/JA3, révocation temporaire des tokens/sessions, rotation forcée des secrets, interdiction de retrait/gel des bonus.
Garde : pour les actions critiques, un appel à deux facteurs ; TTL sur les verrous.

Processus SOC

1. Triage : vérification du contexte, déduplication, rapprochement avec TI, classification primaire par ATT&CK.
2. Enquête : collecte d'artefacts (PCAP/EDR/logs), hypothèses, temporisation, évaluation des dommages.
3. Containment/Eradiation : isolation, rappel de clés/tokens, patch, verrous.
4. Récupération : contrôle de la pureté, rotation, surveillance de la répétition.
5. RCA/Leçons : post-incident, mise à jour des règles/dashboards, ajout de cas de test.

Tuning et qualité des détections

Mode shadow pour les nouvelles règles : compter, mais ne pas bloquer.
Paquet de région : bibliothèque d'événements « bons/mauvais » pour les tests de règles CI.
FP-remediation : exceptions par voie/rôle/ASN ; la règle du « méchant par défaut » n'est qu'après les canaries.
Drift-monitoring : modification de l'activité sous-jacente → adaptation des seuils/modèles.

Dashboards et critiques

Opérationnel : alertes actives, P1/P2, carte d'attaque (geo/ASN), « top talkers », bande de coïncidences TI.
Tactique : couverture ATT&CK, tendances FP/FN, MTTD/MTTC, sources « bruyantes ».
Business : incidents par produit/région, impact sur les KPI (conversion, Time-to-Wallet, refus de paiement).

Stockage, confidentialité et conformité

Ретеншн : le minimum de 90 jours des tanières "chaudes", ≥ de 1 an les archives là, où il faut de (celui-ci financier/régulateurs).
PII/secrets : Tokenization/masquage, accès par rôle, cryptage.
Exigences légales : signalement des incidents, stockage des chaînes décisionnelles, cohérence des montres (NTP).

Purple Team et vérification de la couverture

Threat hunting : hypothèses TTP (par exemple, T1059 PowerShell), demandes ad hoc au SIEM.
Purple Team : sprints collaboratifs Red + Blue - lancement TTP, vérification des déclencheurs, mise au point des règles.
Autotests de détails : récurrents re-play d'événements de référence (essais atomiques) en non-prod et « shadow » prod.

Spécificités iGaming/fintech

Domaines critiques : login/enregistrement, dépôts/conclusions, promo, accès PII/fin. aux rapports.
Scénarios : ATO/credential stuffing, card testing, bonus-abyse, accès initié aux paiements.
Règles : velocity sur '/login ', '/withdraw', idempotence et webhooks HMAC, mTLS à PSP, détections d'accès aux tables avec PAN/PII.
Déclencheurs d'affaires : forte augmentation des refus de paiement/chargeback, anomalies dans les conversions, sursaut des dépôts « zéro ».

Exemples de runbook-ov (abrégé)

P1 : ATO confirmé et retrait

1. SOAR bloque la session, retire les tokens refresh, gèle les conclusions (TTL 24 h).
2. Aviser le propriétaire du produit/financier ; lancez password reset/2FA-rebind.
3. Vérifier les comptes voisins sur la colonne device/IP/ASN ; étendre le bloc par clusters.
4. RCA : ajouter des détections de répétition, renforcer le seuil velocity sur '/withdraw '.

P2 : Exécution sur le serveur (T1059)

1. Isolation EDR, retrait de mémoire/artefacts.
2. Inventaire des derniers déployages/secrets ; rotation des clés.
3. Chasse à la flûte IOC ; Vérification de C2 dans DNS/Proxy.
4. Post-incident : Rule « Parent = nginx → bash » + Sigma pour Sysmon/Linux-audit.

Erreurs fréquentes

Surcharge SIEM de bruit sans normalisation et TTL.
Détections sans mappage sur ATT&CK → « zones aveugles ».
Pas de SOAR/enrichissement - long MTTA, routines manuelles.
Ignorer l'UEBA/comportement est passer les initiés « lents ».
Les blocs TI mondiaux rigides sans TTL → coupent le trafic d'affaires.
Absence de tests de régression des règles.

Feuille de route pour la mise en œuvre

1. Inventaire des loges et normalisation (ECS/CEF), « ensemble minimum ».
2. Matrice de revêtement ATT&CK et détections de base à risque élevé.
3. SLO et files d'attente : P1-P4, on-call et escalade.
4. SOAR-playbooks : enrichissement, containment-action, blocs TTL.
5. UEBA et risque-scoring : profils, anomalies, surveillance de la dérive.
6. Purple Team/tests de détails : mode shadow, canaris, pack de région.
7. Reporting et conformité : Retensh, vie privée, dashboards d'affaires.

Total

Le SOC mature est une discipline de télémétrie complète + de détection de qualité + de réponse. Liez les règles à MITRE ATT&CK, automatisez l'enrichissement et le containment dans SOAR, mesurez les résultats de SLO, vérifiez régulièrement la couverture dans Purple Team - et votre surveillance sera résistante au bruit, répondra rapidement aux menaces réelles et maintiendra les mesures commerciales.