Une question ? Contactez notre standard : 01 41 91 58 61 - Un incident de sécurité ? Faites-vous assister : 01 47 28 38 39

Journée de la Sécurité des Systèmes d'Information 2017 de l'OSSIR

par | Mar 20, 2017 | SOC Sécurité Opérationnelle, Veille Sécurité, Evaluation Sécurité | 0 commentaires

L’édition 2017 de la Journée de la Sécurité des Systèmes d’Information (JSSI, marque déposée par l’OSSIR !) s’est déroulée le mardi 14 mars 2017 à Paris. Le thème cette année était « Fuites de données : s’en protéger, les détecter, les gérer ».

Intrinsec avait le plaisir d’être présent et vous partage son compte-rendu, en remerciant au passage les organisateurs et présentateurs.

Les diapositives sont disponibles sur la page de la JSSI 2017.

Introduction : information/fuites d’information – Jean-Philippe Gaulier

Jean-Philippe Gaulier est président de l’OSSIR et RSSI au sein de la DSI chez Orange. Après ses propos introductifs en tant que président de l’OSSIR, il a endossé le rôle de premier conférencier. Il a introduit le thème de cette JSSI17 qui s’est articulée autour de la fuite de données.

 

JP Gaulier a insisté sur la circulation généralisée de l’information, qui est le résultat de notre présence sur les réseaux sociaux (exemple des plus importants réseaux sociaux tels que LinkedIn, Twitter ou Facebook), et de la connectivité (multiplication des supports d’accès à Internet).  Avec cet enrichissement de données permanent, les infrastructures et/ou les utilisateurs deviennent des cibles.

Pour illustrer son propos, Jean-Philippe a cité les exemples de fuites de données les plus marquants :

  • Sony, Facebook, Twitter, Ashley Madison
  • Cas de Julien Assange, Edward Snowden ou Kim Dotcom (Megaupload)

Le point commun à ces fuites de données d’après Jean-Philippe ? L’humain au cœur de la fuite de données (qu’il en soit à l’origine, qu’il doive la gérer ou lorsqu’il en est victime). On parle d’ailleurs de donnée personnelle : il est possible d’identifier une personne physique à partir de ses données personnelles (référence à la définition de la CNIL).

 

Jean-Philippe a finalement dressé un bilan mitigé sur les fuites de données : il y en a de plus en plus et malgré quelques systèmes de protection (formation, authentification, détection, prévision d’intrusion, chiffrement, anti-virus, anti-spam, anonymisation, veille, SOC, antimalware, etc.), il n’y a pour l’instant pas de solution miracle.

La face cachée de la XXE (XML eXternal Entity) – Charles Fol

Charles Fol, de la société Ambionics Security, nous a présenté les attaques de type XXE (XML External Entity).

Ces attaques, relativement récentes, exploitent la richesse fonctionnelle et l’omniprésence de XML : un langage de plus en plus utilisé pas seulement pour les protocoles applicatifs (SOAP, XMLRPC etc.), mais aussi dans les documents bureautiques comme ceux d’Office, etc.

Il est possible de définir des entités dans la DTD (la grammaire associée à l’XML) qui agissent en tant que variables, permettant de substituer un élément à forte récurrence par un autre dans le document XML. Ces entités peuvent aussi faire référence à des ressources du système.

Parmi les actions possibles : lecture de fichiers locaux, reconnaissance d’ordinateurs internes, rebond HTTP…

Plusieurs techniques peuvent être combinées pour obtenir des attaques de plus en plus puissantes. En contrepartie, il n’est pas possible d’exécuter facilement des requêtes complexes.

Suite à une question du public, l’orateur nous fait remarquer que la seule façon de se protéger contre ce genre d’attaque est d’interdire toute entité externe dans la configuration du parseur XML.

Règlementation RGPD/GDPR : quel impact sur la sécurité ? – Eric Barbry

Eric Barbry est avocat et directeur du pôle « Droit du numérique » au sein du cabinet « Alain Bensoussan Avocats ». Il a orienté sa conférence en questionnant l’impact de la future réglementation GDPR sur la sécurité des systèmes d’information.

Pour cette réglementation qui sera mise en application le 25 mai 2018, l’impact principal réside dans les amendes qui sanctionneront les sociétés qui auront mal géré les fuites de données : entre 10 millions d’euros d’amende ou 2% du chiffre d’affaires et 20 millions d’euros ou 4% du CA. La manière de traiter les problématiques liées à l’informatique et aux libertés sera donc cruciale pour les DSI/RSSI. Pour Eric Barbry, il y a plusieurs chantiers sur lesquels les sociétés devront œuvrer afin de respecter la loi :

    • Sécuriser les données
      • Il faut protéger les données dès la conception (« protection by design »), c’est-à-dire mettre en place des mécanismes techniques et organisationnels au sein de la société
      • Se protéger par défaut (« protection by default ») : dès le départ, se mettre en situation de surprotection des données (définir en interne un schéma d’accès aux données, une politique d’habilitation, un monitoring des accès, etc.)
      • Sécuriser les données dans toute la chaîne : du RSSI au sous-traitant via un code de conduite (des mesures de type chiffrement, pseudonymisation, intégrité, etc.)
    • Définir un plan de réaction à la fuite de données
      • C’est un élément attendu par la nouvelle loi européenne : chaque entreprise devra notifier à l’autorité compétente s’il y a risque ou non. C’est au DSI que revient la responsabilité de dire s’il est nécessaire de notifier (cela implique une analyse de risque)
      • Communiquer au moment de la crise sur la fuite des données
    • Effectuer une analyse d’impact de la fuite, que la CNIL sera en droit d’exiger
    • Faire en sorte que le sous-traitant soit un allié dans la réglementation (ce qui implique pour la société d’aller évaluer ce qu’il se passe chez le sous-traitant et d’établir en amont des règles communes de sécurité)
  • Enfin, un système de gouvernance des données, autrement dit, définir qui est responsable du traitement de l’information : un DSI, un RSSI, un DPO.

Retour d’expérience sur la gestion d’une fuite de données majeure – Stéphane Py

Stéphane Py occupe la fonction de RSSI au sein de la DSI d’Orange France. Lors de son exposé, il a dévoilé son retour d’expérience, en tant que RSSI, sur la fuite de données qui a eu lieu en 2014.

Il a d’abord contextualisé la crise en précisant qu’il s’agissait d’un vol de données depuis l’espace client grand public d’Orange en janvier 2014 et à l’issue duquel 800 000 données ont fuité dans la nature.

Tout au long de son témoignage, Stéphane a ensuite souligné les étapes importantes qui ont marqué la gestion de cette fuite, de l’entrée en crise jusqu’à sa sortie.

    • Deux attaques ont eu lieu sur l’espace client public, une première le 12 janvier 2014, une seconde le 15. Le 16 janvier, les équipes techniques ont découvert le vol de données. L’analyse d’impact a poussé le personnel à passer en mode crise. Fermeture de la rubrique espace client et mise en place d’une organisation spécifique, de modalités de travail et d’une hiérarchie de pilotage de la crise dont Stéphane faisait partie. Des réunions quotidiennes ont été organisées, une logistique a été mise en place (salle de crise, repas, etc.), un pilotage des actions a été lancé.
  • Une déclaration à la CNIL a été effectuée rapidement.
  • Côté technique, Stéphane a lancé une analyse de l’attaque et des conséquences dans la perspective de pouvoir communiquer sur plusieurs niveaux :
    • prévenir individuellement les clients concernés mais également l’ensemble de la clientèle Orange en sachant que dès lors que cette communication est établie, la fuite devient publique ;
    • en interne, communiquer les informations nécessaires à l’ensemble du personnel qui est en contact direct avec les clients.
  • Cette communication a été lancée le 29 et le 30 janvier. Une dépêche AFP est sortie le 2 février.
  • Le 6 février les équipes sont sorties du mode crise. Un retour d’expérience est initié afin d’élaborer un bilan, identifier des axes d’amélioration.
  • Passage en mode post-crise et traitement des sujets connexes (effectuer une veille car la fuite peut inciter à d’autres attaques, traiter des cas clients qui pourraient être liés, déposer plainte, etc.)

Pour Stéphane, finalement trois éléments sont cruciaux lors de la gestion de crise liée à une fuite de données importante : la préparation (l’aspect organisationnel, logistique), la mutualisation de l’effort (toute l’entreprise est touchée, des équipes techniques aux relations presse/communication), et la contrainte des délais qui peut être respectée si les deux éléments précédents sont soignés.

Détection d’une fuite de données, Gestion de crise, et Plan d’action pour revenir à une situation normale – Marc-Frédéric Gomez

Conformément à la demande de l’orateur : cette conférence reste sous diffusion restreinte.

Conférence sur le Bug Bounty – Guillaume Vassault-Houlière

Guillaume Vassault-Houlière, aka Freeman, nous a présenté le principe de bug bounty et la plateforme de sa société Bounty Factory.

Historiquement, seules deux solutions se présentaient pour les experts en sécurité qui décelaient des vulnérabilités : contacter de façon privée les entreprises concernées ou bien rendre publique la vulnérabilité.

La première solution exposait directement le chercheur à la réaction de l’entreprise (qui était souvent de porter plainte). La deuxième solution pouvait porter atteinte à l’entreprise même, en l’exposant à la possibilité d’exploitation de la faille avant correction.

Le concept de Bug Bounty se base sur un échange gagnant-gagnant (win-win) : les entreprises décident des règles et du périmètre de la recherche et les white hats peuvent mettre leurs compétences au profit des organismes et être récompensés pour chaque anomalie découverte.

Bounty Factory, présentée par Guillaume, a le rôle d’intermédiaire entre chasseurs de failles et entreprises.

Ce modèle fonctionne bien : les règles sont bien établies et les récompenses basées sur les résultats.

Suite à une question concernant la possibilité qu’un chercher s’arrange avec un employé d’une entreprise pour être prévenu à l’avance d’une faille et partager la récompense, Guillaume souligne que la confiance reste la base de cette démarche.

Extraction hors-ligne des secrets protégés par la DPAPI – Jean-Christophe Delaunay

Jean-Christophe, expert en sécurité chez Synacktiv, a présenté DPAPI dont le rôle est de protéger des données sensibles en environnement Windows. Elle est massivement utilisée (gestionnaire d’identification Windows, gestionnaires de mots de passe d’Internet Explorer et Google Chrome, Skype). Sa présence et son utilisation sont transparentes pour l’utilisateur.

Cette bibliothèque est présente depuis longtemps (Windows 2000), et n’a pas subi d’évolutions importantes sur sa structure. Sa démocratisation est surtout due à la facilité d’implémentation pour les développeurs (principalement deux fonctions : CryptProtectData, CryptUnprotectData) et la rétrocompatibilité typique de la stratégie Microsoft.

L’intervenant a expliqué les détails techniques et les interrogations liées à l’utilisation de DPAPI : un secret est créé à partir du mot de passe utilisateur ; que se passe-t-il lors du changement du mot de passe ? Est-il possible d’effectuer des attaques par raimbow tables ?

Des outils existent pour les tests d’intrusion et le forensic : Passcape, impacket de CoreSecurity, mimikatz, DPAPIck, dpapilab, dpapeace. Ce dernier se base sur les travaux effectués autour de DPAPIck et dpapilab et permet, entre autres, de déchiffrer hors ligne les données protégées par la DPAPI.

 

Big data : sécurité des environnements Hadoop – Mahdi Braik

L’objectif de l’intervenant de la société Wavestone était de donner un aperçu le plus épuré et pertinent possible du travail qui reste à faire concernant les écosystèmes Hadoop en matière de sécurité.

Hadoop est un framework open-source permettant le traitement distribué de jeux de données volumineux au sein d’un cluster de serveurs en utilisant des modèles de programmation simples. Des sociétés de la taille de Facebook, Yahoo et Microsoft ont massivement investi dans ce projet dont la complexité représente un vrai défi pour la sécurité.

En analysant chaque couche du framework, Mahdi montre, par exemple qu’aucun mécanisme d’authentification n’est mis en place par défaut sur un cluster Hadoop. Le mode authentification « simple » est utilisé tout comme le fait que les données ne sont pas chiffrées (ni sur le serveur ni dans les échanges).

En conclusion, il s’agit d’un projet en pleine ébullition, mais qui manque encore de maturité au niveau de la sécurité.

Poster le commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Verified by MonsterInsights