SecurityInsider
Le blog des experts sécurité Wavestone

Compte-rendu de la JSSI 2017



Nous avons assisté à l’édition 2017 de la JSSI (Journée de la Sécurité des Systèmes d’Information), organisée par l’OSSIR (Observatoire de la Sécurité des Système d’Information et des Réseaux), qui s’est tenue le 14 Mars 2017 au FIAP Jean Monet.
Comme les années précédentes, elle était composée de huit présentations articulées autour d’un thème, cette année : « Fuites de données: s’en protéger, les détecter, les gérer ».

Introduction : information/fuites d’information par Jean-Philippe GAULIER (Orange)

Jean-Philippe GAULIER, président de l’OSSIR et RSSI au sein de la DSI d’Orange, a ouvert cette JSSI. Suite à quelques mots en tant que président de l’OSSIR et un rappel des activités de l’association, il a introduit le thème de cette année.
Il nous a invités dans un premier temps à réfléchir autour des données, en insistant sur leur circulation massive aujourd’hui. L’exemple de celles que nous exposons via les réseaux sociaux auxquels nous adhérons a notamment été pris. Ces données, d’une richesse incroyable pour qui les exploite, sont convoitées et deviennent donc des cibles.
L’intervenant a appuyé son propos en citant de grands cas de fuites de données : Sony, Ashley Madison, cas de Julien Assange, Edward Snowden ou Kim Schmitz (fondateur et ancien PDG de Megaupload).
Il a enfin souligné le fait que l’Humain est au cœur de l’ensemble de ses fuites de données, qu’il en soit l’auteur, la victime ou le gestionnaire de sa résolution.


La face cachée de la XXE (XML eXternal Entity) par Charles FOL (Ambionics Security)

L’intervenant nous a présenté ici les attaques de type XXE, XML External Entity.
Ces entités sont définies dans la DTD (DOCTYPE) XML, et agissent comme des variables permettant de faire référence à des contenus locaux ou externes.
Si exploitée à ces fins, elles sont potentiellement sources de différentes attaques (lecture illicite de fichiers locaux, rebond http, déni de service…) avec extraction des données possible in-band (affichage des données) ou out-of-band (sortie en http, ftp…).
L’intervenant a alerté sur le fait que l’utilisation du XML est largement répandue :

  • Dans des protocoles applicatifs : XML, SVG, HTML
  • Mais également dans les documents bureautiques : DOCX (Office), PDF, XMP (Adobe)

Il a également insisté sur le fait que les vulnérabilités liées aux XXE sont bien réelles, en citant quelques exemples de Bug bounties en lien notamment.
Un exemple d’exploitation a été donné, puis l’intervenant a conclu sur les protections possibles :

  • Désactiver les DTD
  • Utiliser d’autres formats de données que XML

Présentation complète

Règlement RGDP, Quel impact sur la « sécurité » des données ? par Eric BARBRY (Alain Bensoussan Avocats - Lexing)


Eric BARBRY fut le troisième intervenant de cette journée, sur le sujet de la réglementation européenne GDPR (General Data Protection Regulation), visant à renforcer et unifier la protection des données à caractère personnel des citoyens européens. Elle sera mise en application le 25 Mai 2018.
Dans les débuts de son intervention, il a notamment insisté sur les impacts qu’auraient un non-respect de la réglementation. Un accent a été mis sur les pénalités financières qui seront mises en place : de 10 à 20 M€ ou 2 à 4% du chiffre d’affaire mondial pour les entreprises, selon les cas de manquement. Il a poursuivi en soulignant le fait que la mise en conformité engendrerait de nombreux chantiers, impactant notamment fortement DSI et RSSI.
C’est l’angle qu'il a choisi pour la suite de l'intervention, donnant son analyse des articles qu’il juge les plus impactants pour ces derniers, déclinés en quatre chantiers :

  • Sécurité des données : 
    • Protection des données by design et by default (article 25) : ce qui implique la mise en place de mécanismes techniques ou organisationnels pour protéger les données dès le départ, et par défaut (schémas d’accès aux données, politiques d’habilitations, supervision des accès…).
    • Obligation de sécurisation (article 32) : cet article s’applique au responsable de traitement et à ses sous-traitants. Ce qui imposera au responsable de traitement de définir précisément ses exigences de sécurité en amont et de regarder ce qui se passe chez ses sous-traitants.
    • Obligation de notification (article 33) : la CNIL devant être notifiée sous 72h en cas de fuite, le processus devra être défini en amont. En particulier avec les sous-traitants qui devront informer le commanditaire en cas de fuite pour que ce dernier porte la notification à la CNIL. 
    • Obligation de communication (article 34) : individuelle notamment, à toutes les personnes impactés. 
  • Analyse d’impact et consultation (article 35 et 36) : une analyse d’impact devra être réalisée systématiquement dans le cadre de certaines activités (profilage, traitement à grande échelle de données sensibles…). Elle permettra entre autres d’identifier les traitements permettant de réduire les risques. Un fois réalisée, une consultation préalable à la mise en place des traitements identifiés peut être demandée à la CNIL. Celle-ci rendrait un avis « préalable » sous huit semaines.
  • Sous-traitance (article 28) : une définition et une maîtrise fine des contrats et activités des sous-traitants seront exigées.
  • Gouvernance des données : non abordé lors de l’intervention faute de temps


Présentation complète

Retour d'expérience sur la gestion d'une fuite de données majeure par Stéphane PY (Orange)


Lors de cette intervention, Stéphane PY, RSSI adjoint à la DSI d’Orange France, nous a présenté un retour d’expérience sur la gestion de la fuite de données personnelles qu’a connu Orange France en janvier 2014.
L’intervenant nous a détaillé la chronologie de la crise, depuis le constat des attaques le 12 janvier à la fin de la crise le 06 février en passant par la déclaration CNIL (25 jours au total). Il a également insisté sur la chronologie du passage en situation de crise, déterminé par l’impact dans le cas présenté, et ses conséquences (organisation, mise à disposition de compétences et moyens).
Stéphane PY a ensuite détaillé les activités traitées lors de cette crise et donné les retours tirés pour chacune :

  • Analyse de l’attaque et conséquences
  • Identification des impacts
  • Gestion de la relation client
  • Communication externe et interne
  • Gestion de la crise
  • Bilan et enseignements
  • Sujets connexes. Sur ce dernier point, l’intervenant a insisté sur le fait que les actions post crise peuvent se prolonger longtemps, parfois plusieurs mois après sa fin

En conclusion, Stéphane PY nous a rappelé l’importance d’une bonne préparation à la gestion de crises, que ces situations touchent toute l’entreprise et qu’elles imposent des contraintes de délais de déclaration et d’informations des clients très lourdes. Enfin, il a conclu en insistant sur l’étape du bilan, primordiale pour tirer des enseignements sur l’ensemble des aspects.

Présentation complète


Détection d'une fuite de données, Gestion de crise, et Plan d'action pour revenir à une situation normale par Marc-Frédéric GOMEZ (CERT-AG)

Conformément à la volonté de l’intervenant, les slides de cette intervention ne sont pas publiés et nous ne résumerons pas son contenu.


Bug Bounty as a Service par Guillaume VASSAULT-HOULIERE (YesWeHack)


Lors de son intervention, Guillaume VASSAULT-HOULIERE a présenté les origines du Bug Bounty et les plateformes existantes dont celle de YesWeHack, dont il est l’un des présidents fondateurs.
Il nous explique qu’à l’origine deux grandes solutions existaient pour remonter des vulnérabilités découvertes : soit directement aux Entreprises (qui pouvait très mal le prendre et attaquer le lanceur d’alerte), soit en rendant la vulnérabilité publique et en publiant l’exploit.
Netscape fut le premier à tenter l’aventure du Bug Bounty, en organisant un challenge en 1995 récompensant (par des T-shirts) les chercheurs remontant des vulnérabilités.
Il faudra attendre que les GAFAM s’y mettent, entre 2010 et 2012, pour voir le concept démocratisé, les chercheurs sont alors récompensés pour la découverte de failles. Depuis, plusieurs entreprises se sont lancées à leur tour dans le concept : Tesla (2015), Uber (2016)…
L’intervenant est ensuite passé à une présentation des plateformes de Bug Bounty as a Service existantes. Celles-ci se placent en intermédiaires entre les « White Hat » et les commanditaires. Il a souligné l’importance de la définition du cadre, et de la gestion et animation de la communauté pour que la plateforme vive. La complémentarité de cette activité par rapport aux audits a également été soulignée.

Présentation complète


Extraction hors-ligne des secrets protégés par la DPAPI par Jean-Christophe DELAUNAY (Synacktiv)


L’avant dernière conférence, animée par Jean-Christophe DELAUNAY, portait sur la DPAPI (Data Protection Application Programming Interface) qui sert à protéger les secrets sous Windows. Apparue avec Windows 2000, la structure de cette Data Protection API n’a pas subi d’évolutions majeures depuis.
Ses actions de protection sont réalisées de manière transparente pour les utilisateurs, et pour un certain nombre de leurs secrets (mots de passe Wifi, gestionnaires de mots de passe Windows, Internet Explorer, Chrome…). Son utilisation massive s’expliquerait par sa facilité d’implémentation pour les développeurs (deux fonctions à connaître pour son utilisation : CryptProtectData et CryptUnprotectData).
L’intervenant a ensuite détaillé le mode de fonctionnement de DPAPI et notamment sa cryptographie, basée entre autres sur le mot de passe de l’utilisateur.
L’intervenant a ensuite présenté les outils existants pour les tests d’intrusion et le forensic (passcape, impacket, mimikatz, dpapick, dpapilab), en faisant un focus sur son propre outil, dpapeace. L'outil présenté n'est actuellement pas publié.

Présentation complète

Big data : sécurité des environnements Hadoop par Mahdi BRAIK (Wavestone)


Mahdi BRAIK fut le dernier intervenant de cette journée, sur le sujet du modèle de sécurité des environnements Hadoop.
Il a commencé par expliquer ce qu’est Hadoop (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) et son principe de fonctionnement.
Il a ensuite pointé le fait que ce framework est massivement utilisé (Adobe, Yahoo!, EBay…) pour poursuivre sur son modèle de sécurité.
Par défaut, aucun mécanisme d’authentification n’est mis en place sur un cluster Hadoop. Plus exactement, le mode d’authentification « simple » qui équivaut à de l’identification est utilisé par défaut. La recommandation serait donc de déployer l’unique mécanisme d’authentification fourni par Hadoop : Kerberos.
Par défaut, les données ne sont également pas chiffrées. Des mécanismes de chiffrement sont néanmoins implémentés nativement et peuvent être activés après « kerberisation » du cluster.
Une démonstration d’attaque d’un cluster Hadoop par exécution de commandes à distance a ensuite été réalisée par Mahdi; de nombreuses infrastructures Hadoop sont exposées sur Internet et pourraient être exploitées massivement, comme ce fut le cas pour les bases MongoDB par exemple.
L’intervenant conclu en soulignant le fait que de nombreux challenges autour de la sécurité d’Hadoop restent à relever, mais que des actions de sécurisation classiques peuvent être mises en œuvre à très court terme : mettre en place Kerberos, cloisonner les flux et durcir les socles et applicatifs.

Présentation complète



Cette édition 2017 de la JSSI a donc permis de donner aux auditeurs une vision à la fois juridique, organisationnelle mais aussi technique des enjeux liés aux fuites de données.

Morgane NICOLAS

Aucun commentaire:

Enregistrer un commentaire