Bonjour à tous les ninjas de la sécurité,
Le monde informatique d’aujourd’hui est complexe et source de défis pour les équipes des opérations de sécurité. Aujourd’hui, le nombre d’applications intégrées et interconnectées est plus élevé que jamais. Les services cloud et les solutions SaaS achetés dans toute l’entreprise, en-dehors du service informatique, ajoutent une complexité supplémentaire.
La grande question du SOC : que faut-il impérativement superviser en priorité, et pourquoi ?
Communiquer aux responsables d’applications et de services les catégories d’activités à consigner et à transmettre au SOC n’a rien d’une tâche facile. Il est également difficile de déterminer quelles alertes méritent d’être examinées manuellement par le SOC.
Aujourd’hui, l’office du commissaire à l’information (ICO) démontre que cette mission doit être abordée avec le plus grand sérieux et de façon stratégique !
J’ai rédigé un article de blog il y a quelque temps à propos du processus SIEM et des étapes à suivre en priorité lors de l’élaboration d’une feuille de route réussie. Dans cet article, j’ai opté pour une approche verticale, de haut en bas. Selon moi, cela reste une méthodologie parfaitement valide, que vous l’appliquiez à la gouvernance des informations ou à vos scénarios d’utilisation SIEM. Une alternative à cette approche serait l’adoption de MITRE ATT&CK et l’utilisation de tactiques et techniques connues pour déterminer ce qu’il faut superviser. Un inconvénient de cette approche est que MITRE ATT&CK ne nous dit pas ce qu’il faut superviser en premier ! Vous devez prendre la décision vous-même, et vous ne pourrez pas superviser l’ensemble du champ couvert par MITRE ATT&CK.
Dans cet article, je voudrais aborder les enseignements clés que l’on peut tirer d’une faille récente. British Airways a fait les gros titres des journaux, à la suite d’un piratage et du vol des données de ses clients. Des rumeurs ont couru sur le déroulement et la cause de cet événement.
Pourquoi les professionnels de la sécurité IT doivent comprendre l’amende imposée par l’ICO britannique
Le procès-verbal de l’amende imposée par l’ICO britannique à British Airways vient d’être publié. Ce rapport communique un grand nombre d’informations utiles à la communauté de la sécurité informatique.
Le procès-verbal ne concerne pas seulement les professionnels
Cette description brute, faite par une source indépendante, d’un scénario d’attaque et de violation n’est pas seulement bénéfique pour les professionnels, mais aussi pour la gestion de la sécurité des informations. Le procès-verbal permet de comprendre pourquoi certains contrôles de sécurité sont considérés comme appropriés et pourquoi il est indispensable de mettre en place un plan et des procédures de réponse aux incidents adaptés, incluant des signalements aux équipes juridiques et de communication de crise. Nous avons également abordé ces étapes dans notre webinaire « Le cycle de vie d’une violation du RGPD ». En me préparant à ce webinaire, j’ai beaucoup appris en tant que professionnel de la sécurité informatique. Mon travail avec le Directeur de la confidentialité des données de Splunk m’a appris qu’une violation du RGPD dépasse largement le cadre de l’IT.
À partir de la page 17, le document de l’ICO ressemble à une démonstration montée de toutes pièces, alors qu’il s’agit d’un cas réel, étudié et confirmé par l’ICO.
LES FAITS : l’attaque
Étape 1 : accès initial
Le pirate a compromis 5 comptes utilisateurs affectés au prestataire externe « Swissport ». Le compte utilisateur clé exploité était celui d’un employé basé à Trinité-et-Tobago. Grâce à ces identifiants, le pirate a pu se connecter à une session Citrix.
Étape 2 : sortie de Citrix
Le pirate est parvenu à mobiliser des outils extérieurs afin d’effectuer une opération de reconnaissance réseau dans la session Citrix, et il est parvenu à les lancer en utilisant les identifiants et certaines techniques qui n’ont pas été publiées.
Étape 3 : acquisition de privilèges
Au cours de la reconnaissance, le pirate a obtenu l’accès à un fichier contenant le nom d’utilisateur et le mot de passe d’un compte d’administrateur de domaine privilégié. Il était stocké en texte brut sur un serveur.
Les étapes 4 à 6 sont masquées
Même si ces étapes ont été masquées dans le rapport, nous les qualifierions de « Mouvement latéral et collecte » dans le monde traditionnel de la sécurité. Le pirate a fini par obtenir le nom d’utilisateur et le mot de passe d’un administrateur de base de données.
Étape 7 : violation de données personnelles ; fichier XML
Au cours de la phase de mouvement latéral/collecte, le pirate a trouvé un serveur contenant les fichiers de log d’une application utilisée pour les transactions d’échange de British Airways. Malheureusement, en raison d’une erreur humaine, une fonctionnalité qui ne devait pas être utilisée en production avait été activée. Cette erreur a permis à l’application d’écrire des informations de carte de paiement dans le log de débogage en texte brut, pendant une période de conservation de 95 jours. Cette journalisation inutile était active, à l’insu de tous, depuis décembre 2015. Le pirate a eu potentiellement accès aux informations d’environ 108 000 cartes de paiement.
Étape 8 : violation de données personnelles ; données de cartes de paiement
En poursuivant son opération de mouvement latéral/collecte, le pirate a identifié des fichiers contenant du code du site web de BA. Il a ensuite redirigé les informations de carte de paiement des clients vers un autre site web pendant 15 jours, à l’aide de techniques qui n’ont pas été divulguées.
Découverte et signalement de la violation
- 90 minutes après avoir été notifié par un tiers, BA a modifié le code malveillant et contenu la vulnérabilité. Après 20 minutes supplémentaires, toutes les URL menant à la page de redirection malveillante à partir des réseaux de BA avaient été bloquées.
- Le jour suivant, le commissaire, les banques et les programmes de paiement ainsi que près d’un demi-million de clients touchés ont été informés de la violation.
Les échecs : mesures préventives
Si l’authentification multifacteurs aurait, selon l’ICO, relevé le niveau de sécurité face à une appropriation de compte utilisateur, le commissaire ajoute quelques suggestions et références intéressantes. Plusieurs guides de renforcement de Citrix sont référencés, mais aussi des guides de sécurité de l’ICO ainsi que des rapports de menaces sur les techniques employées par les pirates, publiés par Mandiant et Citrix, ayant trait à l’effraction et à la virtualisation des problématiques de sécurité. Cela démontre que, dans le monde d’aujourd’hui, les responsables et les professionnels de la sécurité doivent impérativement suivre et lire les études de sécurité systématiques, car cela fait partie de leur mission.
Les échecs : mesures de détection
Après une analyse du récit de l’attaque, les points à superviser doivent apparaître clairement. L’ICO met en évidence plusieurs énoncés de bonnes pratiques de journalisation, tels que cet article du centre national pour la cybersécurité (NCSC) : Introduction à la journalisation à des fins de sécurité. BA aurait pu superviser et générer des alertes sur plusieurs points clés pour détecter la violation de façon précoce :
- la supervision des utilisations non autorisées ou nouvelles des applications au sein d’un environnement Citrix ;
- la supervision et la journalisation des accès aux fichiers concernés incluant des identifiants inscrits en dur ;
- la supervision de la création et de l’activation de comptes invités ;
- la supervision des actions administratives en cas d’ajout d’un compte utilisateur à un groupe d’administration local ;
- la supervision des tentatives de connexion non abouties à l’aide du compte d’administration système ;
- l’utilisation des comptes privilégiés doit être supervisée et auditée ;
- la supervision des modifications non autorisées au code du site web sur les systèmes de production.
Pour chaque dispositif réseau, système d’exploitation, base de données, application métier et application de bureau, pouvez-vous cocher les points suivants de la liste ?
- ces types d’événement sont inscrits dans le log (niveau de journalisation correctement configuré)
- stockés de façon centralisée
- génèrent une alerte ou font partie de votre pipeline ou chaîne de hiérarchisation des alertes en vue d’être examinés en temps utile
Découvrez notre application sur les fondamentaux de la sécurité : elle contient tous ces scénarios d’utilisation, prêts à être adoptés ! Splunk Enterprise Security sera votre meilleur allié si vous prévoyez d’opérationnaliser ces cas d’usage, de hiérarchiser les alertes et de créer des workflows.
Remarque sur le cloud
Vous pensez que rien de tout cela ne vous concerne parce que vous avez tout migré dans le cloud ? Ou bien vous utilisez Kubernetes et des microservices gérés ? Remplacez simplement « comptes utilisateur » par « clés d’API ». Exploitation de clés, création de nouvelles clés, ajout de nouvelles permissions à des clés existantes, etc.
Aujourd’hui, la gestion de la sécurité des informations n’est ni de la magie, ni une science de haute volée. Et j’espère que ces conseils et ces éclairages vous aideront à renforcer et à optimiser votre programme de sécurité !
Bonne journée,
Matthias
P.-S. :J’ai dressé une liste pour que vous sachiez quoi chercher lorsque vous faites de la supervision proactive. Vous la trouverez ici.
*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.
