Fuzzing intelligent de XSS type 2 filtrés selon Darwin : KameleonFuzz
Fabien Duchène, Sanjay Rawat, Jean-Luc Richier, Roland Groz
Seul Fabien Duchène a présenté l’outil d’analyse de vulnérabilités d’applications Web de type XSS.
Il est composé de deux parties : l’inférence de modèle et la génération automatique d’entrées malveillantes (appelé « fuzzing évolutionniste »).
Conscient de la difficulté des outils disponibles sur le marché à détecter efficacement des vulnérabilités XSS de type 2 (persistant), les auteurs se sont appliqués à développer un outil plus performant. En effet, selon les auteurs, les meilleurs outils détectent 40% des XSS de type 2, la plupart des autres outils, 20% et un tiers n’en détecte aucune. L’outil analyse et détecte également les XSS de type 1 (réfléchi).
La première partie de l’outil apprend de manière automatique un modèle formel du système audité en produisant un automate à état fini étendu. Ce modèle est appris par des envois successifs d’entrées (requêtes HTTP) et analyse des sorties correspondantes, repérées par d’inférence de teinte.
La deuxième partie de l’outil prend en entrée l’automate généré précédemment par la première partie de l’outil sur lequel les réflexions (retours) potentielles sont annotées. Les valeurs des paramètres fuzzés sont générées grâce à une grammaire d’attaques puis elles évoluent grâce à un algorithme génétique. De multiples traitements sont effectués sur ces entrées pour leur donner des scores. Les entrées ayant les meilleurs scores seront recombinées par des opérations de mutation et de recombinaison par croisement respectant la grammaire d’attaques. Ce processus prend fin quand les conditions d’arrêt imposées par l’utilisateur sont atteintes (exemple : 4 XSS découverts).
L’outil a été testé sur cinq applications Web et comparé à quatre scanners XSS du marché. Il se révèle plus performant dans la découverte de XSS que tous les autres outils testés.
Une fois la présentation terminée, l’orateur poursuit par une démonstration de son outil.
Finger printing de navigateurs
Alain Ribault, Erwan Abgrall, Mario Heiderich, Martin Monperrus, Sylvain Gombault, Yves Le Traon
Erwan Abgrall , doctorant à Telecom Bretagne, aborde le finger printing de navigateurs par l’approche des attaques XSS.
Ce finger printing du navigateur présente deux usages :
- Accès à des informations privées (identifier un utilisateur, collecter des informations sur ses paramètres de configuration…). Cette approche est déjà suivie par le programme Panopticlick de l’EFF, des études sont en cours à l’INRIA. De plus, compte tenu de la faible valeur accordée par les utilisateurs à leurs informations privées, cette piste a été volontairement mise de côté par Erwan Abgrall pour se concentrer uniquement sur la seconde ;
- Identification du navigateur afin de lancer des attaques ciblées. De fait, le lancement d’une attaque ciblée, par l’esquive des machines d’audit ou antivirales, permet de limiter les capacités de détection de la victime.
Quelques techniques spécifiques à certains navigateurs sont présentées, telles que la détection d’un plugin Fiddler installé dans Google Chrome (fréquemment utilisé par certains analystes pour visualiser la sortie du navigateur), les tests de user-agents en JavaScript ou la compilation conditionnelle sous Internet Explorer via des astuces bien connues des développeurs Web.
Cette revue des techniques utilisées permet de constater que les techniques académiques restent aujourd’hui en avance sur celles effectivement exploitées dans des exploit kits.
On entre dans le vif du sujet après une présentation de quelques techniques académiques.
L’approche retenue pour la méthode de finger printing présentée repose sur des vecteurs XSS dont l’exécution est conditionnée par la capacité du navigateur à comprendre une portion de HTML donnée. Elle présente l’avantage d’être aisément testable depuis un serveur et automatisable, tout en se basant sur des vecteurs XSS disponibles en grandes quantités.
L’exécution de ces vecteurs XSS dans divers contextes, influençant le comportement du navigateur, permet de construire une signature pour chaque navigateur.
L’identification des signatures par arbre de décision a rapidement été abandonnée au profit d’une mesure de distances de Hamming afin de rendre le framework plus résilient face aux mises à jour fréquentes des navigateurs.
Ce framework permet, dans certains cas, de disposer d’un niveau de détail de l’ordre de la sous-version.
Le code est disponible et hébergé sur GitHub.
Duqu contre Duqu
Aurélien Thierry
Aurélien Thierry effectue actuellement une thèse en sécurité informatique à l’INRIA (Institut National de Recherche en Informatique et en Automatique).
Duqu est un ver informatique découvert en 2011 par CrySyS Lab. Il est présumé lié à Stuxnet car il possède des fonctionnalités et du code partagés.
Il fonctionne de la manière suivante : un dropper (ici, un fichier Word) est téléchargé sur la machine cible (par mail le plus souvent), une fois celui-ci lancé il exploite une faille noyau en rapport avec les polices TrueType dans win32K.sys. Cela lui permet d’écrire des fichiers chiffrés sur le disque et d’installer un pilote. Seul le pilote est présent déchiffré sur le disque. Ce pilote vérifie quels modules sont exécutés et déchiffre les DLL correspondantes pour lancer les charges.
Aurélien Thierry développe un outil de détection de malwares, celui-ci serait-t-il capable de détecter la DLL principale de Duqu ou même de déjouer une attaque en temps réel ?
Pour cela, il faudrait surveiller les processus lancés et intercepter la DLL déchiffrée au moment de l’injection. Or il existe un programme qui réalise ce genre d’opérations et c’est précisément le pilote Duqu. L’idée lui est donc venue de réutiliser le pilote à des vues défensives.
Pour cela, il a utilisé IDA et son module de décompilation, effectué l’identification des constantes, des structures Windows et des structures propres au pilote (PEData). Il ne restait plus qu’à trouver les conventions d’appel manquantes et les diverses options de compilation. Une fois le code récupéré, le C++ et l’ASM sont à analyser.
Ce code lui a appris beaucoup d’informations intéressantes: ce pilote est de type réseau, il est lancé avant la HAL (couche d’abstraction matérielle), puis le pilote détecte si l’OS est en mode debug, et une fois actif, il met en place des fonctionnalités de type rootkit en injectant la DLL dans services.exe. Une notification est émise lorsqu’un module est chargé en mémoire.
C’est cette fonctionnalité de notification qui a été réutilisée. Ainsi, une notification sera émise dans le pilote défensif lorsque l’injection aura lieu dans services.exe par le pilote Duqu.
Une démonstration a été faite, les deux pilotes étaient présents sur la machine : le pilote défensif intervient avant le pilote Duqu pour détecter les notifications d’injection et ainsi empêcher l’attaque.
Le TEE, nouvelle ligne de défense dans les mobiles (conférence invitée)
Hervé Sibert
L’orateur est responsable sécurité produits chez ST-Ericsson.
Le Trusted Execution Environment est un environnement de sécurité qui commence à être déployé sur les smartphones, particulièrement sur les processeurs ARM.
Entre 1990 et 2007, les fonctions de sécurité étaient implémentées dans la couche software du téléphone. Depuis 2007, certaines fonctions sensibles font appel à une implémentation hardware de composantes de sécurité (« trusted root », générations de clés cryptographiques…).
Les OS mobiles étant de plus en plus ouverts (sic), les fonctionnalités sensibles sont déportées dans le TEE, bien que leur gestion demeure externe. Le TEE est donc le seul à avoir accès aux fonctionnalités de sécurité de la plateforme.
Le séquencement des fonctions sensibles reste en environnement d’exécution standard alors que les fonctions en elles-mêmes sont déportées vers le TEE.
Les fonctionnalités du TEE sont dédiées à la gestion des fonctions sensibles du code dont l’exécution dans l’OS standard exposerait le système à des attaques. Il gère aussi le contrôle de la sécurité du boot (stockage et canaux sécurisés).
La fonctionnalité principale du TEE correspond à l’isolation du code et des données, la protection des clés sur lesquelles reposent les fonctions de sécurité et l’isolation entre les différentes applications du TEE.
L’initiative Global Platform est à l’origine d’un ensemble de spécifications d’interfaces standards afin d’encourager le développement logiciel en TEE et simplifier la migration.
Le TEE est supporté depuis ARM76 et permet de disposer de deux processeurs virtuels sur un même cœur (un état normal et un mode sécurisé). Un bit NS permet d’identifier et propager la TrustZone vers la cible des accès afin de s’assurer qu’une donnée sécurisée ne soit accessible par un composant REE et inversement.
Un mode moniteur peut être invoqué via Secure Monitor Call afin d’héberger le code nécessaire à la transition d’un mode à l’autre, chaque mode disposant de ses propres instances MMU.
Le TEE nécessite une racine de confiance matérielle. Pour cela, un ROM boot est chargé de faire une initialisation de la plateforme en mode sécurisé en s’exécutant sur la « RAM-on-chip ».
Les méthodes de signature et l’implémentation des fonctionnalités de sécurité dans un environnement isolé et sécurisé sont des fonctionnalités disponibles sur la quasi-totalité des smartphones, mais restent assez peu déployées sur le marché.
Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/conf_invit1_j3_2013/.
La réponse aux incidents ou quelques recommandations pratiques pour les auteurs de malwares (conférence invitée)
Alexandre Dulaunoy
La dernière conférence du vendredi matin est réalisée par Alexandre Dulaunoy, chercheur sécurité au CIRCL (Computer Incident Response Center Luxembourg), le CERT National du Luxembourg. Sur 2012, ce CERT a traité plus de 10 000 événements de sécurité et réalisé plus de 400 investigations techniques.
La conférence s’articule autour des auteurs de malwares et des bonnes pratiques de développement qu’ils devraient adopter. En effet, comme le signale Alexandre, dans un CERT, on voit de tout : des malwares amusants, originaux ou parfois ennuyeux à analyser. À force, on les compare et l’envie vient d’effectuer des recommandations pour les auteurs de malwares.
Un logiciel malveillant reste un logiciel, il y a tout naturellement une tendance qui se dessine pour leurs auteurs : créer de nouvelles fonctionnalités.
La première préconisation est donc « Keep it Simple ! ». Comme dans tout, les premières réalisations ressemblent à du bricolage puis on avance, on épure afin de rendre l’outil plus propre. C’est aussi valable pour les produits de piratage, les skimmers en sont de parfaits exemples.
Pour commencer, Alexandre présente les différentes méthodes pour signer son code. Il existe plus de 600 autorités et plusieurs méthodes sont à la disposition des auteurs de malwares pour signer leur code :
- Voler la partie privée du certificat et émettre de faux certificats valables ;
- Acheter un certificat volé ;
- Faire une demande de signature.
Par ailleurs, le dernier cas est possible si la création de votre logiciel malveillant à des intérêts économiques ou politiques, ou encore si l’autorité ne fait pas de vérifications poussées.
Une autre option consiste à utiliser des failles dans des binaires déjà signés : une application signée charge un programme normal qui charge ensuite le malware. Il existe environ 900 DLL permettant cela sous Windows.
Plusieurs préconisations au niveau des usages du réseau par un malware :
- Évitez de mettre des mots de passe et des clés par défaut, cela compliquera la tâche des équipes de recherche ;
- Utilisez le port 53 (DNS) pour exfiltrer de l’information. C’est une bonne idée, cependant, si les paquets émis ne ressemblent pas à du DNS, ils sont visibles dans les logs (cas de sshd library rootkit) ;
- Si vous utilisez HTTP, évitez que ce soit le client qui envoie une page HTML au serveur (Fakem RAT) ;
- Ajoutez de la latence entre les requêtes afin que ce soit crédible ;
- Comme il a été signalé par Nicolas Brulez lors de son retour sur Red October, évitez de faire une faute de frappe lors de l’enregistrement du nom de domaine de votre botnet ;
- Lorsque vous enregistrez le domaine, préférez une adresse email anonyme plutôt que votre adresse personnelle ;
- Utilisez des user-agents crédibles ;
- N’utilisez pas l’adresse IP de votre connexion personnelle (cas d’URL utilisée pour exfiltrer de l’information : http://<IP>:1001/c.php?botnet=<victim_name>).
Au niveau de l’utilisation sur le système, il est judicieux de préférer un stockage en mémoire plutôt que sur le disque. L’utilisation de logins par défaut est bien évidemment à bannir.
Il peut aussi être intéressant de détecter si le malware se lance au sein d’une machine virtuelle, comme par exemple en regardant s’il y a des actions de la souris, du clavier, en tentant d’imprimer une page de test ou en analysant le nombre d’événements dans Word.
Le conférencier termine par un peu de publicité pour la conférence Hack.lu, vous trouverez plus d’informations sur cette conférence sur ce site : http://2013.hack.lu.
Présentation courtes
Détection comportementale de malwares P2P par analyse réseau
Xiao Han
Cette présentation de Xiao Han d’Orange Labs, traite de la détection comportementale des malwares peer-to-peer par analyse réseau.
Plusieurs malwares récents basent leurs communications sur des protocoles peer-to-peer. On notera entre autres ZeroAccess sur Kademlia ou Storm sur Overnet.
Ces communications sont difficiles à détecter puisqu’elles dépendent d’une architecture décentralisée (il est donc impossible de bloquer un nom de domaine de C&C). De plus, le trafic étant souvent chiffré, il est impossible d’établir des signatures de détection.
Ces constatations mènent à une approche comportementale de la détection.
Ainsi, une méthode automatisée est utilisée pour générer les footprints des communications sur un ensemble d’éléments caractérisant le trafic P2P (nombreux échecs de connexion vers des nœuds non connectés, absence de requête DNS avant l’établissement de la connexion…).
Cette méthode a permis, sur divers échantillons de malwares P2P, de les détecter avec un taux de faux positifs de 0.14%.
L’apprentissage automatique des profils à détecter est une implémentation du modèle Support Vector Machine qui a permis, via l’analyse de la périodicité des flux, du nombre de paquets envoyés et d’autres composantes, d’aboutir à un taux de détection de 97.2% sur les échantillons de malwares étudiés.
Le point de blocage majeur semble résider dans la capacité de séparer les flux P2P licites et illicites. Ceux-ci faisant partie des flux à risque devant être identifiés et monitorés en entreprise, la viabilité de l’approche ne semble pas remise en cause.
Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/2013_short_han/.
Attestation distante d’intégrité sous Android
Dimitri Kirchner
Pour cette deuxième présentation courte, Dimitri Kirchner aborde le sujet de l’informatique de confiance par l’attestation distante d’intégrité sous Android.
Après avoir laissé son ordinateur dans sa chambre d’hôtel lors d’un séjour et suite au passage d’une « Evil Maid », Dimitri d’interroge sur la possibilité d’utiliser son smartphone, toujours dans sa poche, comme racine de confiance lui permettant de savoir si des actions malveillantes ont été commises sur sa machine.
Le processus se déroule en trois étapes :
- L’utilisateur connecte son smartphone à l’ordinateur ;
- Le smartphone vérifie l’intégrité de l’ordinateur ;
- L’utilisateur décide de poursuivre ou pas, le démarrage de sa machine.
Cette vérification repose sur l’utilisation de la puce TPM de sa machine qui sert à certaines fonctions cryptographiques, au stockage sécurisé ainsi qu’à la vérification de la chaîne de démarrage de la machine.
L’analyse de conformité se déroule en deux phases :
- Phase amont, au déploiement, obtention de la signature de la chaine de démarrage considérée comme intègre et récupération de la clé publique de la puce TPM permettant de s’assurer que les données transmises ne soient pas forgées ;
- Phase de vérification, à l’utilisation, le téléphone demande à vérifier l’intégrité de l’ordinateur, l’ordinateur renvoie la valeur de sa chaîne PCR chiffrée vers le téléphone.
L’implémentation retenue se base sur OpenPTS, fondée sur un vérifieur en Java, aisément portable vers Android, et un transfert des données via SSH, utilisable via la connexion USB entre le téléphone et l’ordinateur.
Le code de ce PoC devrait être bientôt disponible sur GitHub.
Le rôle des hébergeurs dans la détection de sites web compromis
Davide Canali
Davide Canali d’Eurecom, conclut ce cycle de présentations courtes en étudiant le rôle des hébergeurs dans la détection de sites Web compromis.
Les hébergements mutualisés servent aujourd’hui majoritairement à des utilisateurs qui ne sont pas sensibilisés aux problématiques de sécurité (particuliers et petites entreprises) ou à des power-users n’ayant de toute façon ni contrôle, ni visibilité sur la configuration. En résulte une grande surface d’attaque potentielle, face à laquelle les hébergeurs devraient jouer un rôle plus important dans l’assistance à leurs clients en cas d’attaques.
Plusieurs abonnements à des fournisseurs d’hébergements mutualisés ont donc été souscrits afin d’étudier leur capacité à détecter et à répondre à une faille de sécurité.
Sur ces hébergements, ont été installées diverses applications volontairement vulnérables afin de réaliser différents scénarios d’intrusion.
La première phase a consisté à compromettre de manière répétée des applications Web hébergées et à attendre une réaction de la part des hébergeurs (soit durant 25 jours).
Une deuxième phase, de 5 jours cette fois-ci, a consisté à déposer des plaintes auprès du fournisseur de service (certaines plaintes valides, d’autres inventées).
Ces tests ont concerné un total de 22 hébergeurs, 12 de niveau mondial, 10 régionaux, répartis dans le monde entier.
Les résultats sont inquiétants puisque si les hébergeurs font leur possible pour dissuader les inscriptions frauduleuses, peu de mesures sont prises pour garantir la sécurité des services hébergés.
De fait, un seul hébergeur sur les 22 a détecté un cas de compromission, 17 jours après sa première occurrence et n’en a informé l’utilisateur que par le biais de son interface d’administration.
La moitié des hébergeurs n’a simplement pas répondu aux plaintes et ceux qui l’ont fait semblent, pour la majorité, l’avoir fait rapidement (en moins d’une journée).
Pire, certaines plaintes ont été traitées sans vérification puisque des plaintes fictives ont par la suite été reprochées au client du service.
Chez les hébergeurs testés dans cette étude, rien ne semble être fait pour détecter des signes évidents de compromission et les plaintes des utilisateurs (du service d’hébergement ou de l’application Web) sont traitées, au mieux, de façon expéditive et inadaptée.
Conférence de clôture : faire face aux cyber-menaces => détecter (les attaques) et former (des experts en SSI) – conférence invitée
Ludovic Mé
Ludovic Mé est enseignant-chercheur à Supélec, il a une expérience de plus de 20 ans de recherche dans le domaine de la sécurité informatique et plus particulièrement dans la détection d’intrusion.
Il se base sur le Livre blanc sur la défense et sécurité nationale 2013 pour introduire son propos.
Le constat est que les cyber-attaques constituent des menaces majeures à forte probabilité. Une fois ce constat posé, il devient évident qu’il faut faire quelque chose. En effet, toutes les organisations, gouvernementales comme privées, subissent des attaques informatiques sur une base quotidienne. Aujourd’hui, ces attaques semblent avoir comme objectif la prise d’empreintes et la récupération d’informations afin de les exploiter ultérieurement. Des attaques de grandes envergures se préparent donc.
Même s’il ne faut pas être alarmiste, il convient tout de même d’être capable de se protéger contre ces attaques, tout comme pour des attaques armées. Cette protection repose sur une forte capacité de détection des attaques et d’identification de leurs auteurs.
Le Livre blanc suggère donc la mise en place d’une « posture robuste et résiliente de détection », ce que l’orateur comprend comme une volonté d’être capable, au niveau national et/ou européen, de produire de manière autonome des dispositifs de détection. À sa connaissance, c’est la première fois que l’on met les systèmes de détection au même niveau que la cryptographie.
Il mentionne également d’autres points importants du Livre blanc tels que la capacité de réponse, la sensibilisation/formation, les moyens opérationnels (standards industriels, audit, réserve opérationnelle spécialisé, etc.), la riposte (point hautement sensible) et la capacité offensive.
Au vu de l’importance de tous ces items, Ludovic Mé souhaite s’attarder sur deux points qu’il connaît très bien : la détection et la formation.
La détection
Aujourd’hui, la détection est réalisée de manière ultra-classique : on capte, on analyse et on envoie des alertes. Certains positionnent éventuellement des mécanismes de corrélations, et enfin essaient de réagir (patchs, corrections, etc.).
Les IDS (Intrusion Detection System) émettent des alertes évaluées suivant deux propriétés :
- Leur fiabilité : pas de faux négatifs ;
- Leur pertinence : pas de faux positifs.
Dans la réalité, l’idéal ne semble pas atteignable. Les faux négatifs et positifs sont incontournables, même dans le cas de systèmes comportementaux. Cependant, comment peut-on faire pour s’en rapprocher ?
L’administrateur de sécurité n’est pas vraiment intéressé par ces taux, ce qu’il veut savoir c’est la probabilité que l’alerte qu’il reçoit soit vraie. Pour ce faire, il faudrait améliorer les taux de faux positifs.
Or malgré les améliorations apportées aux outils de type pattern matching, Snort (http://www.snort.org) par exemple, ceux-ci ne suffisent pas. Ils vont dans le bon sens, mais il n’en reste pas moins que nous n’avons pas vu baisser le nombre de vulnérabilités et que le trafic va être de plus en plus chiffré.
L’orateur met en avant deux manières, non exclusives, d’envisager les choses :
- Soit on considère que l’on a fait ce que l’on pouvait. Ce n’est pas idéal et cela va requérir beaucoup de travail en aval, car malgré la mise en place de systèmes de corrélation :
- Il n’y a pas de base de scénarios commune,
- Il y a une masse énorme de données,
- Il y a peu d’administrateurs,
- Il y a un manque d’outils de visualisation.
Il précise qu’il faut faire de la corrélation mais que cela n’est pas suffisant.
- Soit on produit de meilleures alertes :
- Améliorer l’analyse par les NIDS,
- Développer une offre HIDS, OS et applicatif (il me semblait que certains outils existaient déjà…),
- Prendre en compte la politique de sécurité (HIDS et NIDS)*,
- Apporter des capacités de diagnostic aux IDS comportementaux,
- S’inspirer des techniques de la sûreté de fonctionnement*,
- Offrir un contrôle des taux de faux positifs et négatifs,
- Développer des environnements de tests d’IDS.
*Points les plus importants, selon lui.
Il faut donc qu’un HIDS soit paramétré suivant une politique de flux d’information.
Considérons une entité à surveiller, avec des entrées et des sorties. Il y a des entrées de certains types comme des sorties de certains types. On définit une politique qui établit quels sont les flux autorisés en entrée et en sortie et on surveille le composant en question afin de lever une alerte le cas échéant.
À Supélec, Ludovic Mé travaille autour de l’outil Blare (http://blare-ids.org). Son objectif est d’avoir un IDS au niveau OS qui ne soit pas de type pattern matching et qui connaisse la politique de sécurité (en l’occurrence la politique de flux).
Une autre idée serait d’avoir des logiciels auto-testables. C’est-à-dire qu’un logiciel devrait pouvoir à tout moment s’autotester afin de savoir s’il se comporte et/ou produit ce qu’on attend de lui.
Pour conclure sur les considérations en termes de détection, Ludovic Mé insiste sur le fait que les IDS ne sont pas forcement basés sur des signatures. Il y a une multitude d’autres mécanismes à tester et à explorer.
Enfin, il ajoute qu’il regrette grandement que la communauté sécurité, y compris celle du SSTIC, ne se focalise pas davantage sur la défense plutôt que sur les attaques.
La formation
Il en vient à la deuxième partie de son propos concernant la formation.
Il attire notre attention sur la différence de niveau des connaissances requises. Ainsi, il est nécessaire de sensibiliser le grand public, les professionnels et les ingénieurs de tout type (même les PME ou l’artisanat), alors qu’il s’agit de véritables formations pour les informaticiens et, bien sûr, pour les experts SSI (masters en doctorats). Ces sensibilisations/formations doivent prendre en compte la pluridisciplinarité de la sécurité : logique, physique et organisationnelle.
Il donne des exemples de nombreux pays dans le monde où des cours d’informatique sont donnés dès le plus jeune âge, ce qui est loin d’être le cas en France. Il note cependant que quelques progrès sont faits : une spécialité informatique a été inaugurée pour les terminales S en 2012 et le programme des classes préparatoires scientifiques inclut désormais l’apprentissage du langage Python, mais est-ce assez ?
Enfin, pour les experts, il préconise l’apprentissage d’une base très large et très solide sur l’ensemble des domaines de l’informatique pour la Licence, puis sur tous les aspects de la sécurité (de la cryptographie à la politique de sécurité, mais aussi les métiers) au niveau M1/2.
Il serait également nécessaire d’y inclure les méthodes offensives bien qu’il y ait une organisation à mettre en place à ce sujet (contrôle, audit, éthique, etc.) car ceci est illégal à l’heure actuelle.
Il conclut la partie formation en insistant sur le fait que former les experts SSI, c’est former les informaticiens de manière générale.
Enfin, il rappelle que si ces deux points sont extrêmement importants, il n’en faut pas moins traiter tout le reste.
Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/conf_cloture_2013/.
Propos recueillis par: Geoffrey Bertoli, Antoine Cervoise, Brice Duprieux, Yannick Fournel, Julien Vallet et relu par Isabelle Feetz.