Retour sur une faille majeure découverte, il y a quelques mois
Le rappel peut être important car c’est le temps nécessaire au pirate pour se faire oublier
Durant les premiers temps, les pirates vont utiliser les failles pour collecter l’ensemble des informations possibles afin de pouvoir les exploiter plus tard :
Certificat, Clefs, log,….
#Bonne pratique de compromission potentielle :
- En cas de doute : changer l’ensemble des informations de connexion (travail long et complexe)
La détection des applications installées ne permet pas de définir si l’application est réellement utilisée.
Impact : cela va rendre plus complexe la mise à niveau nécessaire des serveurs et donner du travail inutile.
#Bonne pratique d’exploitation :
- n’installer que les applications nécessaires
La cartographie est un outil indispensable pour mener des actions vite et bien, et non dans l’urgence et sans vision
# bonne pratique d’exploitation :
- cartographie à jour
Lorsqu’il faut pouvoir scanner le code source avant de vérifier l’usage d’un composant, un référentiel du code unique est gain de temps.
De même, l’utilisation des éléments d’identification dans le code est à proscrire
# bonne pratique de développement:
- Référentiel unique du code
- Pas d’éléments d’identification dans le code
Une fois le vecteur d’attaque et les méthodes utilisées identifiés, la lecture des logs du systèmes d’information doit permettre d’identifier la date, l’heure et les machines qui ont été compromises
Cette collecte de log est indispensable et doit être réalisée au plus vite, afin de pouvoir remonter le plus loin possible en cas de besoin
Rappel : après analyse d’une compromission, on découvre souvent que les pirates sont déjà présents depuis plusieurs mois.
De même, la vision de l’ensemble du flux internet est facilitée par l’usage d’un proxy. La lecture des logs est donc simplifiée
Pour les serveurs, l’accès à internet pour les mises à jour est un risque.
Si vous n’avez pas la possibilité d’installer un service de mise à jour en interne, pour couper les liens avec l’externe, l’usage d’un proxy est une aide pour le contrôle et la sécurisation d’un seul point
D’autre part, les effets d’une compromission ne seront visibles que dans le temps. Il est donc nécessaire de maintenir les analyses des logs jusqu’à ce que l’ensemble de l’infrastructure soit mis à jour. Le processus de contrôle quotidien est aussi important que le contrôle de la sauvegarde. Bien sûr, il ne faut pas oublier le sujet lorsqu’un nouveau service (application/machine) arrive sur le réseau. La mise en place d’une base de connaissance est nécessaire.
# bonne pratique d’exploitation :
- centraliser les logs
- Pas d’accès à internet en direct (uniquement proxy) pour les serveurs
- Service de mise à jour en interne (cycle de vie de la machine)
- Contrôle quotidien des incidents de sécurité (aide possible via Console,EDR, XDR, SIEM,…)
- Base de connaissance sur les points de contrôle
La compromission d’un composant se traduit par la mise à jour le plus vite possible vers la nouvelle version
Malheureusement, plus le composant sera vieux, plus la mise à jour sera complexe et longue.
Dans le cas extrême, la mise en place d’un WAF permet de réduire le risque d’attaque externe. Cela ne doit pas être la solution
# bonne pratique d’exploitation :
- Mise à jour régulière des composants
- Usage d’un waf
# bonne pratique de développement :
- Mise à jour régulière des outils de développement
La faille vient aussi d’une fonctionnalité de prise en compte de chaine de traitement dans un outil de lecture de log.
Un moyen de rendre inactive la faille sera de pouvoir mettre en place un paramétrage pour arrêter la fonctionnalité. La bonne méthode est d’activer une fonctionnalité de traitement ou de communication à la demande uniquement. Les applications doivent être Secure by default.
L’ajout d’une fonctionnalité, par un développeur, qui peut introduire un risque doit être communiqué de manière explicite aux équipes d’exploitation pour une analyse de risque et un traitement particulier.
L’équipe d’exploitation devra ensuite identifier les paramètres utilisés pour une réaction rapide en cas de failles
# bonne pratique d’exploitation :
- Mise en place d’une cartographie
- Mise en place d’une CMDB (suivi des configurations)
- Processus d’analyse de risque
# bonne pratique de développement :
- Fonctionnalité à risque activée à la demande uniquement
- Travail sur le Secure by default
- Note de version avec la description des fonctionnalités (pas uniquement dans le code, uniquement accessible par les développeurs)
#Bonne pratique de compromission réelle :
- savoir tenir dans la durée
