Dans le cadre de la veille cybersécurité, telle que réalisée par le CERT Metsys au profit des clients du MSSP, de plus en plus de cas de fuite d’information sont observés. Néanmoins, « l’affaire Free » a incité le CERT à publier le présent article, afin de contribuer à communiquer sur les actions recommandées, pour ce cas spécifique, mais aussi de manière plus globale.
Toutefois, il ne sera pas ici question de « décortiquer » l’incident ayant récemment impacté l’opérateur Free, sachant que l’ANSSI a été notifiée de l’incident, qu’une plainte auprès du Procureur de la République a été déposée, et qu’une notification auprès de la CNIL a été faite, par l’opérateur. Laissons ainsi la Justice faire son travail, en respectant le secret de l’instruction, mais discutons des recommandations voire enseignements à tirer, d’une telle situation.
Méthodologie : application du cycle de vie des incidents de sécurité
Comme à l’habitude, nous allons dérouler le NIST SP800-61 r3 :
en considérant que la phase « Detection & analysis » va alimenter la « containment, eradication & recovery ».
Premier réflexe : rester attentif concernant les publications autour de ce type d’incident
En l’espèce, le CERT Metsys ne peut que recommander à tous de prendre connaissance du très bon article publié par Cybermalveillance.gouv.fr, concernant l’incident de fuite d’information ayant impacté les clients de Free.
Cela permet de rester informé sur le périmètre et les implications de la compromission de données (types de données, nombre de clients, données en clair ou chiffrées, etc.), ce qui servirait de phase « détection » dans notre approche.
Second réflexe : le confinement
Même s’il semble y avoir une ambiguïté concernant le fait que les mots de passe des clients des clients Free aient effectivement été volés, la première réaction recommandée, par précaution, est le changement du mot de passe sur le service concerné, en l’occurrence ici, l’espace abonné opérateur Free.
Rappelons d’ailleurs que les recommandations actuelles pour la sécurisation des mots de passe ne sont plus de mettre en place une rotation régulière, mais plutôt de s’assurer de leur robustesse et de ne les changer qu’en cas de suspicion de compromission (cf. cet article par ex).
Troisième réflexe : l’éradication
Dans le jargon, le mode opératoire d’un cyber-attaquant qui exploiterait les informations client ayant fuité (Free, pour l’exemple), pourrait correspondre au « T1078 valid account ».
La problématique est donc que par défaut, le cyber-attaquant se présente sur un système ou un service, avec un compte et un mot de passe à priori valides. Par conséquent, le système où l’authentification a lieu n’est pas censé lever d’alerte, à partir du simple combo identifiant utilisateur et mot de passe.
D’aucuns seraient alors tentés de parler de confiance zéro (alias « zero trust »), qui peut certes servir de ligne directrice, mais qui demeure avant tout un concept, où la complexité réside bien souvent dans l’implémentation opérationnelle. En soi, implémenter une approche (voire une architecture) confiance zéro, est un projet à part entière, généralement structurant, et il semble donc peu probable de pouvoir le réaliser dans le même temps que la réponse à incident. Toutefois, les principes de « zero trust » peuvent être capitalisés en phase « RETEX / Post-incident activity », pour implémentation progressive.
Malgré tout, à titre de précaution (mais aussi pour bloquer à court terme les sessions suspectes déjà ouvertes), la recommandation est d’activer le MFA, sur le compte concerné par la fuite d’information (ceci contribuant au principe de « vérification explicite » de la confiance zéro).
Par ailleurs, dans ce cas où l’organisation au sein de laquelle l’utilisateur concerné par la fuite d’information dispose d’un SOC, il est attendu que ce dernier renforce sa supervision de sécurité en ce qui concerne l’usurpation d’identité.
Malgré tout, dans le grand public, ou pour la sphère personnelle, trop peu de personnes sont au informées que Google, par exemple, indique en bas de page de Gmail la liste des sessions actives pour le même utilisateur (NB : ici, « l’autre emplacement » correspond à la même session Gmail ouverte sur le téléphone mobile), et cela se retrouve aussi dans le « check-up sécurité » :
Et pour un compte Microsoft, il y a la page « Afficher mon activité de connexion » :
Ceci permet donc de pister les sessions potentiellement suspectes. Cependant, pour le grand public néophyte, la notion même d’adresse IP peut paraître relativement abscons, ce qui réduit malheureusement l’efficacité d’un tel outillage à grande échelle.
Extension du périmètre de réponse
L’activité de réponse à incident amène à faire preuve de pragmatisme, surtout quand il s’agit du niveau d’hygiène informatique des utilisateurs lambdas. Ainsi, il est à craindre que des mots de passe soient communs entre sites/services.
Or, pour rappel, et encore une fois par RETEX de réponse à incident, il apparaît qu’il est relativement facile de trouver le profil « agrégé » d’une personne, avec son profil LinkedIn associé à son adresse électronique professionnelle, ainsi que son adresse email personnelle… L’utilisation de combinaison, avec mot de passe volé sur un compte mais utilisé sur un autre compte victime, par le cyber-attaquant, est donc à craindre.
Aussi, la recommandation est de procéder à une sécurisation des comptes « satellites » de l’incident de sécurité (car associés au même utilisateur), mais bien importants malgré tout. Ce qui est entendu par « sécurisation » ici correspond concrètement à :
- en cas de doute, notamment si mot de passe potentiellement réutilisé entre plusieurs services, alors changer les mots de passe des comptes ;
- NB : un service comme ProtonPass alertera si un mot de passe est réutilisé entre plusieurs services ;
- activer le MFA partout où possible.
Voici une liste non exhaustive de ces comptes « satellites » à sécuriser :
- messageries personnelles (GMail, compte Microsoft, Protonmail, etc.) ;
- moyens et sites de paiement en ligne (Paypal, Amazon, etc.) ;
- sites bancaires ;
- opérateurs et services en ligne (opérateur telecom, fournisseur d’énergie, etc.) ;
- sites et services administratifs (impôts, sécurité sociale, etc.) ;
- réseaux sociaux (LinkedIn, FaceBook, etc.) ;
Dernier réflexe : la Détection
Le cas de la fuite d’informations concernant les clients Free n’étant pas isolé, comme indiqué au début, il apparaît donc nécessaire de mettre en oeuvre une capacité de détection. Plus précisément, la recommandation est d’activer une surveillance « Dark Web », pour 2 grands scénarios communs dans cet Internet souterrain :
- vente/re-vente des identifiants compromis ;
- diffusion « ouverte » des identifiants compromis.
Pour cela, le CERT Metsys recommande aux organisations de se doter d’un service de veille Dark Web, tel que Metsys peut le fournir. Pour le grand public (ou les usages personnels), la recommandation est d’utiliser :
- soit un gestionnaire de mots de passe disposant de cette capacité de surveillance « Dark Web » (ex : LockPass, FSecure Total, ProtonPass) ;
- soit d’utiliser le mécanisme de détection de compromission de mots de passe maintenant intégré en standard dans les navigateurs modernes (Microsoft Edge, Google Chrome, Mozilla Firefox), à l’instar de la posture qu’ont pu déjà adopter différentes organisations françaises notamment dans le monde des urgences médicales.
Enfin, pour le cas spécifique de la fuite d’information ayant impacté les clients de l’opérateur Free, il semble pertinent de prévenir sa banque, pour leur signaler que l’IBAN a visiblement été concerné par le piratage, afin de renforcer la surveillance des activités potentiellement suspectes sur le compte bancaire.
NB : l’opérateur Free est censé prévenir explicitement les clients dont l’IBAN est considéré comme ayant fuité.
RETEX du traitement de l’incident :
Nous avons vu ici un ensemble d’action : des mesures d’endiguement (réinitialisation des mots de passe des comptes concernés), et éradication (fermeture des sessions suspectes), mais aussi des mesures de protection : la généralisation du MFA ! En entreprise, la recommandation est de le faire au strict minimum au niveau Microsoft Entra ID.
Le mot de la fin sera sous un angle métier SOC : tout tourne ici autour de l’identité. Aussi, bien qu’un antivirus et un EDR soient absolument nécessaires de nos jours, il convient de surtout ne pas croire qu’en ayant juste ces deux technologies, un environnement est sécurisé ! La recommandation forte est d’y adjoindre des solutions de sécurité spécialisées sur le volet identité (ex : Microsoft Azure Identity Protection, Semperis Directories Services Protector, etc.)
Les équipes de Metsys sont à votre disposition si vous souhaitez poursuivre plus loin la réflexion, et identifier les solutions ainsi que les services de sécurité correspondant à vos besoins.
Article écrit par la Direction technique du MSSP
