 |
|||||
|
|
|
|||
|
|
 |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
 |
|
|
|
|
|
|
|||
|
|||||
|
|||||
|
|||||
|
|
|
|||
|
|
|
|
||
|
|
|
|||
|
|||||
Article rédigé le 01 avril 2011
La 10ème édition de la conférence JSSI (Journée de la Sécurité des Systèmes d'Information), organisée par l’OSSIR (Observatoire de la Sécurité des Systèmes d'Information), s’est déroulée à Paris le 22/03/2011. Elle a réuni une centaine de participants. Nous faisons ici un compte-rendu des différentes présentations. Le programme complet est disponible sur le site de la conférence (les supports de présentation seront publiés prochainement sur ce site).
La condensation de la sécurité, ou comment traiter la sécurité dans le nuage ? - Devoteam
Cette présentation fait un bilan sur la sécurité des offres SaaS telle que vue au travers d’une dizaine d’audits réalisés au cours de 2010 sur des solutions de ce type. Les audits ont été réalisés en évaluant chacun des domaines de la sécurité identifiés par la norme 27002. Ils ont été complétés par un audit technique (un test d’intrusion). Bien que ces résultats ne puissent pas être généralisés, ils font un certain nombre de constats intéressants.
En préambule, les orateurs montrent que le "cloud" change la façon dont le RSSI est impliqué dans les projets :
- Les projets SaaS sont souvent courts et les déploiements rapides. Le RSSI doit donc définir à l’avance les exigences qui seront applicables à ce type de projet.
- Le projet est souvent vu comme l’achat d’une solution (par opposition à un développement) avec une intervention forte des services achats de l’entreprise. Le RSSI doit cependant impérativement être impliqué, en particulier pour évaluer les implications sécurité des clauses du contrat d’achat.
- Les besoins techniques de sécurité (typiquement les critères DIC : Disponibilité, Intégrité et Confidentialité) doivent être traduits par des contrôles spécifiquement adaptés au contexte du "cloud" et des prestations externalisées. Par exemple, la traçabilité (4ème critère souvent ajouté aux critères DIC) est souvent difficile à obtenir dans un contexte "cloud" (peut-on consulter les traces d’accès ?).
Le constat le plus fort réalisé à l’occasion de ces audits est que souvent l’entreprise qui souscrit un service SaaS n’a pas conscience que cette solution repose sur une chaine d’acteurs (plutôt que sur un acteur unique). Au-delà de l’éditeur de la solution SaaS (le concepteur), les acteurs sont typiquement l’exploitant (qui fait fonctionner la solution) et l’hébergeur (qui fournit l’infrastructure sur laquelle la solution fonctionne). Il est impératif lors d’un audit d’identifier ces acteurs et de vérifier que les besoins de sécurité sont pris en compte de façon cohérente par toute la chaine d’acteurs :
- Dans 40 % des audits, certains acteurs n’avaient pas été déclarés au client.
- Dans 60 % des audits, les moyens mis en œuvre par les différents acteurs n’étaient pas cohérents. Par exemple, l’exploitant garantit une gestion des alertes en 24/7, mais il n’a souscrit qu’un support jours ouvrés auprès de l’hébergeur.
Les autres constats notables pour ces audits sont les suivants :
- La culture sécurité des développeurs d’offres SaaS est trop faible. Il s’agit souvent de petites équipes ne disposant pas d’une expertise avancée en sécurité.
- 100% des audits ont identifié des défaillances dans les plans de reprise en cas de sinistre de type « salle machine ». L’exploitant est souvent prêt à faire face à une panne simple (un client tombe en panne), mais pas à des pannes multiples (le centre informatique est hors service).
En conclusion, les orateurs indiquent qu’il est possible de trouver des offres SaaS réellement sécurisées. Il s’agit en général de solutions conçues explicitement pour gérer des données à fort besoin de sécurité. Très souvent également le niveau de sécurité physique est très bon dans le cas d’une solution "cloud" (parce que l’hébergeur a des locaux sécurisés). Ils attirent l’attention sur le fait qu’il ne faut pas négliger de prendre en compte le coût d’encadrement de la prestation "cloud" (par exemple le suivi des contrôles de sécurité) et conserver le contrôle complet sur la gestion des accès (qui a accès, avec quels droits) en évitant absolument dans ce domaine toute approche de type « self-provisioning ».
Anonymisation de données en masse - Bouygues Telecom
Dans certains contextes, le test des applications nécessite des jeux de données qu’il peut être difficile de générer et il est alors plus facile de construire ces données de test à partir de données de production. C’est par exemple le cas si l’on a besoin d’un fichier client de grande taille ou de données cohérentes complexes. Pour faire face à ce besoin Bouygues Telecom a mis en place une équipe spécialisée dans la génération de jeux de données. Cette équipe propose :
- une aide à l’extraction des données opérationnelles,
- l’anonymisation de ces données,
- le transfert et l’installation de ces données dans les environnements de test.
Cette équipe propose ce service « d’ingénierie des données de test » aux différents projets de Bouygues Telecom. Le fait d’isoler cette fonction, outre qu’elle garantit la bonne anonymisation des données extraites de la production (qui sont souvent des données client, à caractère personnel, ou des données sensibles), a également pour effet de renforcer la sécurité des données de production puisque l’équipe « d’ingénierie des données de test » devient l’interface systématique en cas d’utilisation de données de production.
La responsabilité juridique du RSSI - François Herpe (avocat)
Cette présentation, qui est faite par un avocat, propose d’explorer d’un point de vue légal une série de questions type très souvent mises en avant lorsque l’on parle de sécurité informatique. La synthèse que nous en donnons ici est simplifiée et traduit uniquement notre compréhension des réponses apportées par l’orateur à ces questions.
Le RSSI a-t-il une responsabilité financière, civile ou pénale du fait de sa fonction ?
La réponse générale est « non », sauf si le RSSI a reçu du chef d’entreprise une délégation de pouvoir, ou s’il a intentionnellement commis une infraction.
Nota : L’orateur indique qu’en terme de sécurité, une entreprise a l’obligation légale de mettre en place des moyens de sécurité informatique (obligation de moyen) et qu’il s’agit ici d’une obligation renforcée. Cela veut dire que l’entreprise devra être capable de démontrer qu’elle a effectivement mis en place ces moyens (dans le cas d’une obligation simple, ce serait à la partie adverse de démontrer le manque manifeste de moyens mis en œuvre).
Que faut-il faire dans le domaine des données personnelles ?
L’entreprise a des obligations légales fortes pour ce qui concerne les données personnelles. Ces obligations ont été largement documentées par la CNIL. L’orateur recommande donc de se reporter aux documents CNIL. Il cite en particulier la fiche 10 conseils pour la sécurité de votre système d’information.
Sécurité vs cyber-surveillance des salariés
Il faut trouver un équilibre entre les besoins légitimes de surveillance (afin d’assurer la sécurité) et le droit à la vie privée. La recommandation de l’orateur dans ce domaine est de définir au sein de l’entreprise une charte qui décrit les usages qui sont autorisés et les moyens de surveillance mis en place.
Les systèmes mobiles sont-ils plus sûrs ? - EADS
Cette présentation s’intéresse essentiellement à la sécurité des smartphones Android. L’orateur identifie trois niveaux de risque :
- Les risques liés aux opérateurs du marché (constructeurs, opérateurs, développeurs de logiciels). Contrairement à un PC, un smartphone reste fortement dépendant d’une chaine de fournisseurs (l’opérateur télécom, le « market place » Android, etc…) ce qui induit des risques spécifiques. Par exemple, on peut imaginer que des vulnérabilités existent dans l'infrastructure opérateur, ou que des attaques de type « Man In The Middle » puissent survenir lors des échanges avec le « market place ».
- Les risques liés aux logiciels de base (système d’exploitation ou applications standard). Les failles de sécurité potentielles sont nombreuses à ce niveau. Par exemple, le modèle de sécurité d’Android (basé sur une centaine de permissions) n’est pas un modèle robuste, et de nombreuses vulnérabilités ont déjà été trouvées dans des composants centraux comme par exemple le « Webkit ».
- Les risques liés aux applications tierces. Ces applications peuvent être malveillantes, ou insuffisamment sécurisées (et donc vulnérables). L’analyse réalisée par l’orateur sur certaines applications montre que le niveau de sécurité est insuffisant, par manque de connaissance des mécanismes de sécurité fiable (les mécanismes rencontrés ressemblent à ceux qui étaient utilisés il y 10 ans dans le monde PC et qui ont été abandonnés car non robustes) ou par manque de temps.
L’orateur a poursuivi sa présentation en montrant comment une application Android pouvait être analysée (reverse engineering).
En conclusion, l’orateur indique que les risques de sécurité pour Android (et pour les smartphones en général) sont multiples et que l’utilisateur dispose de peu de moyens pour se protéger efficacement. Nous ne serions donc qu’à l’an 1 de la sécurité des mobiles et dans ce domaine tout reste à faire.
Activisme, attaques réputationnelles, rumeurs et guerre économique sur Internet - Emmanuel Lehmann (Consultant)
Cette présentation explique comment une campagne de « guerre de l’information » bien organisée peut permettre d’attaquer un adversaire de façon très efficace. Il illustre son propos en détaillant l’action menée par GreenPeace pour attaquer Nestlé sur le sujet de l’utilisation de l’huile de palme dans ses produits.
De l'utilisation de la supervision sécurité en cyber-défense - Orange Business Services
Orange Business Services a présenté le service de SOC (Security Operation Center) qui a été mis en place en interne à Orange pour superviser la sécurité de ses offres. Le SOC est une structure dédiée, et opérationnelle en 24/7.
La prise en compte d’un nouveau projet (son intégration dans le SOC) se déroule en 3 étapes :
- Définition d’un cahier des charges basé sur les objectifs de sécurité du projet
- Conception et déploiement d’une solution technique (mise en place de capteurs, tuning de la supervision et fonctionnement en mode « pilote »)
- Exploitation de la solution
Le SOC d’Orange Business Service est un projet initialisé en 2005. En termes d’outils, il utilise en particulier des IDS (sondes de détection), des outils de SIM/SIEM pour l’analyse et la corrélation d’événements, et des techniques de « blackholing » (redirection de flux) et de « cleanpipe » (suppression des flux parasites) en réaction à des situations d’attaques.
L’orateur indique en conclusion que le travail avec les spécialistes métier du projet intégré (en phase de définition du cahier des charges) est fondamental pour la réussite du projet de supervision. Il conseille également de résister à la tentation qui consiste à déployer trop rapidement un grand nombre de sondes sur un périmètre large. L’intégration doit être progressive et maîtrisée.
Fingerprinting des frameworks de Web Applications - Toucan System
Cette présentation explique quels sont les techniques et les outils disponibles pour deviner à distance les logiciels utilisés par un site web donné. Il s’agit par exemple de reconnaitre à distance qu’un serveur web utilise Apache, PHP et Joomla et si possible de trouver la version de chacun de ces composants. Si un des composants utilisés n’est pas dans la version la plus récente, il sera ensuite possible de tenter des attaques en utilisant les vulnérabilités connues de ce composant.
Les techniques pour effectuer le « fingerprinting » sont :
- les bannières retournées par les serveurs web,
- les scanners de vulnérabilités (Nessus, etc…),
- les outils spécialement conçus pour le "fingerprinting " (par exemple, le module Sedusa pour Nmap)
L’orateur s’intéresse plus particulièrement à une sous-catégorie de cette dernière approche : la recherche de fichiers statiques spécifiques dans l’arborescence du serveur web analysé. Cette technique a été présentée en 2010 à la conférence DefCon par l’auteur de l’outil BlindElephant (les supports sont disponibles sur le site de la conférence). Le principe est que chaque environnement web (WordPress, Joomla, Drupal, …) installe une série de fichiers spécifiques. Il suffit donc de chercher ces fichiers pour reconnaitre l’environnement utilisé.
BlindElephant est un outil difficile à enrichir et l’orateur s’est finalement orienté sur un autre outil (moins performant mais plus ouvert) : WAFP (Web Application Finger Printing). Il a enrichi WAFP de façon à reconnaitre de nouveaux environnements web tels que : Symfony, Cakephp et Struts.
En conclusion, l’orateur indique que ses travaux sont toujours en cours et qu’ils seront envoyés à l’auteur de WAFP pour une éventuelle intégration. Cette technique de "fingerprinting " n’est cependant pas universelle (l’environnement Zend par exemple n’a aucun fichier statique et ne peut donc pas être "fingerprinté" de cette façon) ni infaillible (il suffit de changer les fichiers standard de l’environnement utilisé pour empêcher la détection).
Conclusions
Cette édition 2011 de la JSSI a été une fois de plus très intéressante.
- D’une part, les sujets abordés (cloud, smartphone, juridique) correspondent bien aux préoccupations actuelles en matière de sécurité.
- D’autre part, il y a eu au cours de la journée un bon équilibre entre les retours d’expériences (cloud, Anonymisation, SOC) et les présentations axées sur l’expertise, qu’elle soit technique (smartphone, fingerprinting), organisationnelle (cloud) ou juridique.
Cette 10ème édition confirme donc que cet événement organisé annuellement par l’OSSIR est un des rendez-vous francophones majeurs de l’année dans le domaine SSI. Nous y serons donc à nouveau l’année prochaine !