Automatisez vos audits de securite avec Amazon Inspector

Transcript

Bonjour à toutes et à tous, merci de nous rejoindre pour cette dernière journée des webinaires de la Security Week. Bravo de ne pas être en congé. On va essayer de finir à l'heure pour que tout le monde puisse aller faire ces dernières courses de Noël. Un salut amical à tous nos amis francophones qui sont encore nombreux aujourd'hui, canadiens et autres. Merci beaucoup, on est très content de pouvoir vous parler aujourd'hui. On va commencer l'après-midi par un premier webinaire sur Amazon Inspector avec pas mal de démos. On enchaînera ensuite sur un récapitulatif des bonnes pratiques de sécurité sur AWS en rebalayant la plupart des services dont on a parlé cette semaine, avec beaucoup de conseils très concrets, beaucoup d'infos, beaucoup de liens, pour essayer de faire une petite synthèse et de vous permettre d'attaquer la sécurisation de vos plateformes de manière très pragmatique. Et puis bien sûr, on aura du temps pour les questions, n'hésitez pas à les envoyer. Hugo est évidemment toujours avec moi, il note vos questions et me les fait passer en fin de session. Alors c'est parti. L'agenda de cette session : une rapide présentation d'Inspector et du rôle qu'il peut jouer pour sécuriser votre infrastructure. Un petit mot sur sa disponibilité et sa tarification. Ensuite, comment l'installer. Vous verrez que c'est plutôt simple. Et puis ensuite on enchaînera sur une démonstration. J'ai déjà préparé pas mal de choses, mais on va continuer à jouer, je vais vous montrer toute la console en détail, on va regarder les résultats d'audit sur des instances, Linux, Windows, etc. On va vraiment rentrer dans les détails. Quelques ressources supplémentaires comme d'habitude pour aller plus loin et puis bien sûr questions et réponses. À quoi sert Amazon Inspector ? Amazon Inspector est un produit simple qui fait une chose et une seule : analyser, scanner vos instances EC2, Linux et Windows, on verra les OS précis tout à l'heure, afin d'y identifier des failles de sécurité. Le rôle d'Inspector est de faire un scan à l'intérieur de l'instance, donc de scanner la configuration de l'OS, la configuration des packages qui sont installés, etc. Ce n'est pas un scan réseau, c'est vraiment un scan à l'intérieur de l'instance. Le fonctionnement d'Inspector est très simple, la mise en œuvre est assez aisée. On va taguer un ensemble d'instances EC2 de manière à les identifier, à les désigner. On va installer l'agent Inspector sur ces instances et puis ensuite on va lancer une évaluation de cette liste d'instances sur la base de règles préétablies. Vous verrez qu'on a différents packages de règles de sécurité que vous pourrez vérifier sur vos instances. Vous allez lancer cette évaluation pendant un certain temps, qui peut varier de 15 minutes à 24 heures. Et puis à la fin de l'évaluation, vous aurez les résultats, la liste des vulnérabilités triées par niveau de sévérité, avec, et c'est là que c'est important, un détail précis de la vulnérabilité et surtout comment la corriger. C'est bien de savoir qu'on a un problème de sécurité, mais ce qu'on veut vraiment, c'est comment le corriger. Donc, Inspector a cette double dimension : l'analyse et le conseil pour la correction. Un point important que j'ai mentionné ici, c'est qu'on a beaucoup parlé du modèle de sécurité partagé, et on va en redire deux mots pour être très clair. Inspector ne change rien au modèle. Ce n'est pas parce que vous utilisez Inspector que vous êtes déchargé de votre responsabilité dans le cadre du modèle de sécurité. Le modèle de sécurité que j'ai déjà montré plusieurs fois cette semaine, le socle d'Inspector et de services qui est sécurisé par AWS, donc la sécurité du cloud, et puis au-dessus, la plateforme client, la sécurité dans le cloud, avec le chiffrement, l'OS, les applis, les plateformes, les applis, le contenu, etc. Donc, Inspector va vous aider sur cette partie-là. Inspector va vous aider à sécuriser l'OS, à sécuriser les protocoles réseau, à sécuriser vos plateformes applicatives, vos environnements, PHP, Java, etc. Bref, l'ensemble du socle logiciel que vous installez et que vous devez maintenir sur votre instance. À l'inverse, Inspector ne scannera pas votre code applicatif. La sécurité de votre propre code ne fait pas partie d'Inspector. C'est vraiment l'OS, les packages, etc. Un tout petit peu de terminologie, je me permets de passer 30 secondes là-dessus parce qu'on va les retrouver dans la console et c'est toujours important de savoir de quoi on parle. Ce qu'Inspector appelle une évaluation, en anglais, si vous utilisez la console en anglais, vous verrez que ça s'appelle un assessment, c'est l'analyse d'une application afin d'y détecter des failles de sécurité. Une application étant un ensemble d'instances. On va choisir les instances et on va lancer une évaluation. La cible de l'évaluation, c'est la liste des instances que vous voulez évaluer. Donc la liste des instances que vous aurez taguées. Assessment target en anglais. Cette cible d'évaluation sera évaluée contre un ensemble de règles. Donc rule package en anglais. Ces règles, ces ensembles de règles, on va voir qu'aujourd'hui on en supporte quatre. Ce sont un ensemble de vérifications de sécurité unitaires qui vont être déroulées sur chacune de vos instances. Ensuite, on créera un modèle d'évaluation. Un modèle d'évaluation, c'est une cible, l'ensemble d'instances, un groupe de règles, les règles de sécurité qu'on veut vérifier sur ces instances, et puis une durée. Et puis enfin, une fois que l'évaluation basée sur ce modèle d'évaluation sera terminée, on aura des résultats, findings, qui vous listeront des problèmes de sécurité priorisés par niveau de sévérité, et puis une description et comment les régler. On va revoir ces différentes étapes et comment les dérouler, mais voilà un petit peu le vocabulaire d'Inspector. Quelles règles sont disponibles aujourd'hui ? Aujourd'hui on a 4 groupes de règles que vous pouvez choisir même de cumuler, vous pouvez choisir l'un ou l'autre de ces groupes, ou 2 ou 3 ou même les 4, afin de les confronter à vos instances. Le premier, sans doute le plus connu, c'est l'ensemble des vulnérabilités dites CVE, qui est une base de données gérée par le MITRE qui va lister littéralement des milliers de CVE vérifiées par Inspector. À l'URL que j'ai indiqué sur le slide, au moment où j'ai vérifié, il y en avait 43 819. Je suis prêt à parier que ce chiffre a déjà bougé. Si vous faites un petit coup de double VEGAD sur ce fichier et que vous comptez les lignes, je suis sûr qu'il a bougé. J'ai dû faire ça il y a quelques jours et on sait très bien que les CVE, malheureusement, apparaissent tous les jours. Donc, c'est vraiment la plus grosse base de données de vulnérabilité et à mon sens, elle doit faire partie de vos évaluations. Il y a un deuxième package qui s'appelle le package CIS, qui sont un ensemble de vulnérabilités définies par un organisme qui s'appelle le Center for Internet Security. Vous trouvez la liste détaillée des checks, des vérifications sur leur site à l'URL indiquée. Ce sont des standards de l'industrie, des vulnérabilités standards identifiés par l'industrie informatique. Elles méritent d'être appliquées. Les deux autres packages sont plutôt des bonnes pratiques qui ont été définies par AWS, donc le Security Best Practices, qui va vérifier des règles sur votre configuration SSH, sur votre politique de mot de passe, etc. Je précise que ces règles-là, à l'heure actuelle, ne sont valables que pour des instances Linux. Et puis un quatrième package qui s'appelle Runtime Behavior Analysis, qui est un peu différent des précédents puisque celui-là va définir des règles de comportement des instances pendant l'évaluation. On va regarder les protocoles réseau, on va regarder si les ports ouverts sur votre instance correspondent réellement à des protocoles utilisés ou alors est-ce que c'est juste des ports ouverts par inadvertance sans qu'il y ait le moindre trafic dessus, ce qui peut toujours être un risque. Donc, on est plutôt sur du comportement dynamique, ce qui veut dire que lorsque vous utilisez ce groupe de règles, il est extrêmement utile que votre application fonctionne, c'est-à-dire qu'il y ait du trafic sur vos instances. Une bonne façon d'utiliser ce package, par exemple, ça serait de lancer vos tests unitaires et en parallèle, simultanément, de déclencher une évaluation sur le comportement à l'exécution avec ce package. Si vous utilisez ce package sans aucun trafic sur vos instances, il sera beaucoup moins pertinent puisqu'il ne se passera rien. Les trois premiers sont vraiment des règles qu'on va qualifier de statiques, qu'on peut vérifier de manière unitaire sur vos instances. Le dernier package, le Runtime Behavior Analysis, c'est vraiment ce qui se passe à l'exécution. Donc, il faut que votre application tourne pour que les règles vérifiées aient du sens. Inspector est disponible dans plusieurs régions, pour l'Europe en particulier, il est disponible dans la région irlandaise. Je crois savoir que l'expansion géographique devrait se poursuivre en début d'année. On devrait avoir un peu plus de régions au cours du premier trimestre. Combien coûte ce service ? Le service, comme tous les services AWS, est facturé à l'usage. Le tarif est un tarif par évaluation par instance. Il est dégressif, donc il commence à 30 cents par évaluation par instance. Et puis si vous faites beaucoup d'audits, le tarif diminue jusqu'à 5 cents par évaluation. Vous voyez finalement un tarif relativement faible pour un service qui peut s'avérer assez profond. Vous disposez d'un niveau d'usage gratuit dans le cadre du free tier que vous connaissez. Vous avez le droit de faire 250 évaluations gratuites pendant 90 jours. Ça vous permet de tester le service et de vérifier s'il répond à vos attentes. S'il ne répond pas à vos attentes, surtout dites-nous pourquoi. Ça nous intéresse beaucoup. N'hésitez pas à m'envoyer du feedback par mail sur les services. Je suis très friand. Je le relaie très rapidement aux équipes produits qui, elles aussi, sont très preneuses de feedback. De manière générale, Inspector est disponible à la fois sur Linux et sur Windows. Rentrons un peu dans les détails. Sur Linux, vous pourrez l'utiliser sur Amazon Linux à partir de la version de mars 2015. Vous pouvez l'utiliser sur Ubuntu 14.04, vous pouvez l'utiliser sur Red Hat et CentOS 7.2. Je crois savoir que ces versions, des versions ultérieures vont être supportées en début d'année. De manière générale, je pense pouvoir vous dire qu'au cours du premier trimestre, il y aura beaucoup de nouveautés sur Inspector en termes de fonctionnalités, de régions supportées, etc. Pas de détails supplémentaires à vous communiquer, mais c'est un produit qui va être rafraîchi, mis à jour de manière assez importante en début d'année. Comment est-ce qu'on installe l'agent ? Tout simplement en le téléchargeant en Wget, en l'installant, et puis en le démarrant ou en l'arrêtant au fil des besoins avec les commandes standards, etc. Une petite astuce qui pourra vous être utile et que j'ai redécouverte en faisant des tests, l'agent est dépendant du noyau. Par conséquent, lorsque vous mettez à jour vos instances Linux, si le noyau est mis à jour, il est extrêmement probable que vous deviez également remettre à jour l'agent. Sinon, l'agent démarrera, détectera qu'il est configuré pour la mauvaise version du noyau et puis s'arrêtera, ne démarrera pas. Donc, votre instance ne sera plus accessible par Inspector. Pensez dans vos scripts de mise à jour à re-télécharger et à réinstaller l'agent pour qu'il redétecte le nouveau noyau et qu'il se configure correctement après les mises à jour. Sur Windows, on supporte aujourd'hui Windows Server 2008 R2 et 2012 et 2012 R2. Et là aussi, il faut télécharger l'agent, l'installer, c'est tout simple. Et puis vous pouvez, comme les agents Windows le supportent habituellement, le démarrer, l'arrêter via la console de service, on la regardera tout à l'heure. Comment utiliser Inspector ? Dans la console, qui pour l'instant est uniquement en anglais, c'est pour ça que je vous ai aussi donné la terminologie anglaise, la console Inspector n'a pas été traduite en français pour l'instant. Bien sûr, vous pouvez l'utiliser en ligne de commande ou avec les SDK de manière traditionnelle, je vous ai mis à titre d'exemple les URL des SDK Java et Python, mais ça marche évidemment avec les autres langages. Et toute l'API d'Inspector est bien sûr décrite dans la documentation. Alors, on va passer à la démonstration. Qu'est-ce que j'ai fait pour jouer avec Inspector ? J'ai créé trois instances Linux, une Ubuntu 14.4, relativement ancienne maintenant, une Amazon Linux 2015.03 et une Amazon Linux 2016-09, donc la plus récente, et j'y ai installé mes packages préférés, donc les packages par défaut qui étaient présents dans les dépôts de ces différentes distributions, PHP, MySQL, Java, le JDK, Apache, Bind, j'ai dû mettre SendMail aussi, je me demande si je n'ai pas mis mon GoDB au passage, enfin bref, j'ai mis mes packages favoris en me disant qu'il y aurait bien quelques vulnérabilités à y trouver. Et puis j'ai créé aussi une instance Windows Server 2012 juste pour vous montrer comment ça peut fonctionner. J'ai passé un certain nombre de tests, un certain nombre d'évaluations sur ces instances dont on va regarder les résultats et je vais d'abord vous montrer la console. Le premier truc à faire quand vous allez dans la console, moi je l'ai déjà fait, c'est pour ça que je vous montre le slide, donc ça c'est ce que vous verrez je pense la première fois que vous vous connectez à l'Inspector. Il faut créer un rôle pour que l'Inspector ait le droit d'accéder aux instances, donc vous créez ce rôle. Il faut que vous taguiez vos instances, je vais vous montrer comment je l'ai fait, et puis bien sûr il faut que vous installiez l'agent sur les instances. Voilà les prérequis. Un rôle d'exécution pour Inspector, les tags sur les instances EC2 et l'agent installé sur les instances EC2. On va basculer sur la console. Voilà mes petites instances. On est en US West 2. Donc, mes quatre instances, vous voyez mon instance Ubuntu, mon instance Amazon Linux 2015, Amazon Linux 2016 et Windows. Donc, première étape, mettre des tags sur ces instances. On va prendre celle-ci par exemple. Et je vais dans l'onglet balise, donc je vois, alors elle a un tag name, qui est toujours une bonne idée, et puis j'ai créé un tag que j'ai appelé inspector tag, avec la valeur assessment 001. Vous êtes totalement libre, vous pouvez définir le nom de vos propres tags, ainsi que la valeur, c'est complètement ouvert, l'essentiel, c'est simplement que vous sachiez et que vous indiquiez ensuite à Inspector que c'est bien ce tag là qui désigne cette instance et cette valeur. Donc voilà, j'ai dû mettre ce tag sur les autres également, voilà vous voyez inspector tag assessment 01, ici j'ai fait inspector tag assessment 01, inspector tag 2 assessment 02 puisque j'ai fait un assessment spécifiquement sur cette instance. Et sur Windows, voilà, j'ai mis mon assessment 0.0. Donc voilà, vous démarrez vos instances comme vous le faites d'habitude. Simplement, vous pensez à définir un tag qui est commun au groupe d'instances que vous voulez évaluer avec Inspector. Une fois de plus, vous mettez le nom que vous voulez pour la clé et le nom que vous voulez pour la valeur. Aucune complication. Si vous voulez taguer massivement des groupes d'instances, vous pouvez le faire. Vous pouvez sélectionner un grand nombre d'instances ici et leur appliquer un tag, donc si vous voulez taguer d'un coup 20 instances, ne faites pas ce que je vous ai montré à l'instant, vous venez ici dans balise, vous cochez les instances dont vous avez besoin et puis paf, vous collez ici le tag directement. Ça c'est bien pratique, ça fait gagner du temps. Ok, donc voilà pour mes petites instances. Alors on va regarder Inspector maintenant. La première étape, c'est de définir la cible. C'est ce que j'ai fait ici. Vous voyez, j'ai défini une cible qui s'appelle « Webinar 001 » et qui est quoi ? La liste des instances qui comporte le tag inspector tag avec la valeur assessment 001. Donc créer la cible d'évaluation, ça revient juste à dire voilà le nom du tag et la valeur du tag qui décrit les instances. Si on fait preview, c'est évidemment une mise en page un peu désagréable, ça c'est quelque chose qui devrait être amélioré de mon point de vue, là on voit la liste imparfaite et incomplète des instances concernées, mais si vous cliquez là, vous n'allez pouvoir la télécharger. Ce n'est pas extrêmement ergonomique. Bref, voilà comment on définit une cible, on ferait create ici tout simplement, on donne un nom d'évaluation, on donne le nom de la clé, la valeur de la clé, et c'est tout. Très très simple. Ensuite, on va définir un template, donc un modèle d'évaluation. On va prendre celui-ci pour commencer. Celui-ci me dit quoi ? Il me dit que ma cible c'est Webinar 001, c'est ce que je viens de vous montrer à l'instant, ce sont les instances qui ont un tag, un inspector tag qui contient Assessment 001. Et qu'est-ce que je vais faire sur ces instances-là ? Je vais appliquer le package de règles, le groupe de règles CVE et je vais le faire pendant une heure. Deuxième exemple, prenons celui-ci dont on verra le résultat tout à l'heure. Là, j'ai défini un autre modèle où toujours sur les mêmes instances désignées par la même cible, je vais cette fois passer les quatre packages de règles et je vais le faire pendant 24 heures. Donc c'est ce que je vous disais tout à l'heure. Un modèle d'évaluation c'est une cible, une liste de packages et une durée. Alors j'en profite pour parler un peu de la durée, on pourrait faire create ici, on donnerait un nom, la cible, on sélectionne les packages de règles qu'on a envie d'ajouter, etc. et la fameuse durée. Vous voyez vous avez le choix entre 15 minutes, 1h, 8h, 12h, 24h. J'anticipe la question, qu'est-ce qu'on met comme durée ? La doc est assez peu prolixe à ce sujet, elle dit que plus vous laissez de temps à un Inspector, plus il va scanner profondément les instances. Sans donner beaucoup plus de détails. Je suis comme vous, j'aimerais bien en savoir plus. Ça va dépendre du contexte dans lequel vous auditez. Si par exemple vous avez intégré un Inspector à votre pipeline de déploiement continu, il est évident que vous n'allez pas scanner pendant 24 heures. 15 minutes est peut-être pas mal dans un cadre comme ça, voire une heure. Donc si c'est des scans intégrés dans des processus de déploiement, on va plutôt rester sur des durées courtes. Et donc on va laisser un Inspector choisir, j'imagine qu'il doit y avoir une priorisation des vulnérabilités par niveau de sévérité, etc. Mais voilà, je ne peux que deviner à l'instant T. Et puis j'imagine de temps en temps, on va avoir envie de faire des scans beaucoup plus exhaustifs, et c'est ce que j'ai fait, vous verrez les résultats, où là, effectivement, peut-être une fois par semaine, une fois par mois, à vous d'apprécier, vous de définir ce qui est pertinent pour votre plateforme, on va effectivement faire un scan complet avec toutes les règles et on veut avoir une vision la plus précise possible des vulnérabilités qui existent. Petite précision, vous pouvez taguer les résultats, les fameux findings, les résultats d'audit, vous pouvez leur appliquer également un tag, ce qui va vous permettre de les rechercher, de les filtrer, voire de créer des tickets automatiquement sur la base de ces résultats, etc. Voilà pour les templates. On va revenir sur ma liste. Il faut que je fasse cancel. Une fois que vous avez fait ça, vous en choisissez un. On va prendre par exemple celui-là. Je vérifie mon instance Windows contre les règles CVE et je le fais pendant une heure. Vous sélectionnez tout simplement le modèle d'évaluation et puis vous faites run. Voilà c'est parti. Et dans l'assessment runs, on devrait voir, voilà, donc on voit la liste des assessments qui ont déjà été exécutés et puis on voit celui que je viens de lancer. Et pour vérifier que tout fonctionne bien, vous pouvez regarder le statut de l'agent puisqu'ici il n'y a qu'une instance. Si vous rafraîchissez, vous voyez que le nombre de messages reçus par l'agent Inspector au back-end augmente. Les vérifications sont en cours. Évidemment il n'augmente plus. Classique. Voilà. Et là vous voyez le statut et vous vérifiez que l'audit a commencé. Vous voyez la durée, voilà ça augmente. Vous voyez depuis combien de temps l'audit a démarré. On va laisser tourner ça à une heure, on n'en verra pas à la fin, mais rassurez-vous j'en ai exécuté d'autres. Et puis ensuite on a donc les findings, toutes les vulnérabilités qui ont été trouvées. Et là, le vrai travail commence. Alors, j'ai une vision un peu plus synthétique de ces résultats. Je vais retourner sur mes slides et puis on reviendra en console tout à l'heure si nécessaire. Donc, on a défini la cible, on a défini le modèle, on a le récap, on lance l'évaluation. Pendant l'évaluation on voit les compteurs qui augmentent, etc. Voilà et puis ensuite on va voir les résultats dans la console. Alors j'aurais pu en ouvrir un c'est vrai quand même pour vous montrer, c'est plus intéressant. Donc on va prendre celui-là, on va prendre le premier de la liste. Donc je vois la sévérité, je vois à quelle date il est arrivé. Ouvrons-le. Voilà je vois quoi ? Donc je vois l'instance qui a été impactée par ce problème. Et je vois donc la description. Cette instance, elle est vulnérable au CVE 2016-7202. Ce qui m'inquiète, c'est qu'elle est effectivement en sévérité élevée, qui est un vrai problème. Je vois la description du CVE. J'ai le lien vers la base CVE de Mitre. Si je veux vraiment voir l'intégralité des détails. Là, je vais avoir les liens. Ici, c'est une vulnérabilité Microsoft. J'ai les liens vers les bulletins TechNet Microsoft. Et je peux avoir toute une liste supplémentaire d'informations et j'imagine si je clique sur ces liens Microsoft, je vais voir la solution pour corriger ce problème. Là, manifestement, je pense qu'un coup de Windows Update devrait régler le problème. On va regarder d'autres. Petite vulnérabilité Java. Alors ça c'est une instance Linux. Voilà donc là j'ai un problème dans Java, un grand classique. Et donc là on me dit très spécifiquement de mettre à jour mes packages OpenJDK, etc. Petit troisième, là encore du Java, encore du Java. Décidément. Encore du Java. J'adore Java. Encore du Java. Bon, ok, c'est la fête de Java aujourd'hui. Bon, il n'y a pas que des problèmes dans Java, je vous rassure. Il y en a partout. Mais vous voyez, bon, on peut... Alors, vous pouvez les filtrer. Vous pouvez évidemment les filtrer. On va essayer d'aller... Voilà, on pourrait les filtrer par instance. Donc, si je voulais tous les problèmes... On va essayer de prendre peut-être celle-là, on va chercher son nom. Si je voulais uniquement les problèmes de cette instance, les voici. Je peux les filtrer par sévérité, je pourrais les filtrer, etc. Je vous laisserai regarder ça, c'est très simple à faire. On peut évidemment accéder à tout ça aussi en ligne de commande et l'automatiser. Gardez bien à l'esprit que surtout ce qui est intéressant pour vous c'est de savoir comment corriger ces problèmes. Voilà les quelques appels de ligne de commande qui sont intéressants. Vous pouvez faire list assessment runs pour avoir la liste des exécutions. Ça va vous donner l'ARN du run, à partir duquel vous pourrez faire un list findings pour avoir la liste, hop hop hop, on a avancé trop vite, la liste des findings de ce run là, et à partir, donc là vous en aurez sans doute une quantité importante, et donc à l'intérieur de cette réponse-là, vous avez les ARN de toutes les trouvailles que vous pouvez décrire et là vous les décrivez une par une et vous voyez l'équivalent de ce que je vous ai montré, c'est-à-dire c'est un problème Java, c'est un problème Windows, c'est un problème PHP, etc. Donc vous pouvez les automatiser assez facilement. Alors quand même, qu'est-ce que ça donne ? Parce qu'on va essayer d'en tirer quelques leçons. Donc sur mes trois instances Linux, alors j'ai oublié de préciser que je les ai démarrées sans les mettre à jour. Je voulais voir quel était le point de départ en réalité. Et donc là vous voyez que sur mon instance Ubuntu, Vanilla si j'ose dire, donc non mise à jour, juste démarrée à partir de l'AMI, j'ai trouvé 242 vulnérabilités élémentaires. 242 sur la base d'une installation PHP MySQL etc. Java qui a l'air d'être un bon contributeur. Sur l'Amazon Linux de 2015 j'en ai trouvé 69 et sur l'Amazon Linux de 2016 j'en ai trouvé 4. Alors qu'est-ce qu'on peut en conclure ? On peut en conclure plusieurs choses. Démarrer des AMI même à jour, sans avoir mis à jour les packages, c'est toujours dangereux. Et que plus elles sont anciennes, plus c'est dangereux. Donc quand vous démarrez des AMI Linux, et je pense qu'on peut généraliser ça à Windows aussi, pensez immédiatement à mettre à jour les instances. Le conseil que je peux donner, c'est sûrement pour la partie EC2 dans le user data dans le script d'initialisation de l'instance, je pense que c'est une bonne idée de faire un coup selon les cas de yum update ou de apt-get update pour garantir que quand l'instance démarre, quand elle est créée plus exactement puisque user data n'est exécutée qu'à la création, elle est mise à jour avec les packages les plus récents. Ça vous protégera déjà contre ce genre de soucis. Vous voyez qu'un Ubuntu 14.4 aujourd'hui, il est malheureusement relativement vulnérable et d'autant plus si vous ajoutez beaucoup de packages. Et puis on voit que même un Amazon Linux à jour, il a quand même quelques vulnérabilités. Alors j'ai regardé en détail quelles étaient ces quatre vulnérabilités. Il y en a une qui est OpenSSH, qui est là aussi un grand classique, et trois qui étaient liées à des risques d'overflow dans la stack IP du noyau Linux. Donc des problèmes relativement sérieux. Voilà, donc la conclusion. J'adore Ubuntu 14 et je l'utilise encore beaucoup mais 242 problèmes c'est beaucoup. Comment corriger les problèmes ? On l'a dit, faites en sorte à la création de l'instance de mettre à jour les packages. User data est sans doute le bon endroit pour le faire. Et puis ensuite, faites-le régulièrement. Je me suis reconnecté sur mes instances, celle-ci en particulier, c'est l'Amazon Linux 2016-9, là on voit la version. Et effectivement, quand je regarde le message of the day, à la connexion, on me dit, ah oui, il y avait 6 mises à jour de sécurité sur 11 mises à jour total. Je ne l'avais pas fait. Donc, j'ai fait un petit coup de YUM Update. Sans surprise, je vois qu'effectivement, je mets à jour le kernel et que je mets à jour Open SSH. Je pense que ces mises à jour de sécurité, les voilà. Les corrections de mes CVE, les voilà. Si vous êtes un peu réticent à l'idée de faire du YUM Update systématique si vous ne voulez pas que d'autres packages non liés à la sécurité soient mis à jour, ce que je peux comprendre. Vous savez peut-être qu'avec YUM en l'occurrence, vous pouvez demander que les mises à jour de sécurité avec moins moins security. Vous pouvez même demander à corriger une liste de CVE précise. On aurait pu ici faire un sudo YUM update, moins moins, civis avec les numéros de CVE remontés par un Inspector et il ne m'aurait mis à jour que les trois packages Open SSH et le kernel. Si fonctionnellement ça vous gêne de changer potentiellement des packages comme ça périodiquement, vous pouvez ne corriger que les trucs de sécurité. Et donc j'ai refait la manip, j'ai rescanné cette fois mon instance Amazon Linux 2016, une fois les patches appliqués, et je l'ai rescanné, je crois que j'ai refait 24 heures il me semble, non j'ai fait une heure peut-être, je ne sais plus, je crois que j'ai fait les deux, peu importe. Et donc cette fois je n'ai plus aucun problème de sécurité. Alors il vous met quand même un finding, alors j'étais déçu parce que quand j'ai vu arriver le résultat du run et que je voyais un, je me suis dit non c'est pas vrai, il a encore trouvé un problème. En fait non, c'était uniquement ce finding de sévérité information pour me dire pas de problème. Donc effectivement si on met à jour son instance, on arrive à avoir zéro vulnérabilité sur l'instance. Alors comme j'avais envie de pousser un peu le bouchon, je me suis dit, je ne voudrais pas qu'on m'accuse de favoriser Amazon Linux, donc j'ai fait cette manip sur les trois instances à nouveau, donc j'ai fait une update complète d'Ubuntu, une update complète d'Amazon Linux 2015, une update complète de 2016 et j'ai refait un scan de 24 heures. Voilà les résultats, donc sur Ubuntu je tombe encore sur 52 problèmes, donc ça c'est vraiment vraiment mauvais et c'est pas un jugement de valeur sur Ubuntu, une fois de plus, j'ai beaucoup de respect pour cette distribution que j'utilise depuis des années, mais ça montre quoi ? Ça montre que sur des AMI anciennes, puisque Ubuntu, beaucoup doit avoir plus de deux ans maintenant, deux ans et demi, on voit qu'il y a une série de problèmes qui ne sont pas corrigés. Et ça, c'est uniquement les problèmes en sévérité élevée. Donc il reste encore 52 vulnérabilités élevées sur une instance complètement patchée, à jour. Voilà, donc il faut en être conscient. Après, à chacun d'en tirer les conséquences. Je pense que si j'avais fait le test avec des vieilles AMI d'autres distributions Linux, j'aurais probablement trouvé des choses similaires qui sont liées au fait que vous n'avez pas le dernier noyau Linux, vous n'avez peut-être pas le dernier JDK, vous n'avez peut-être pas les derniers packages applicatifs, etc. Ce qui est intéressant, si on passe à Amazon Linux, c'est qu'on voit que la version d'Amazon Linux 2015 à jour n'a plus aucun problème. Et donc, ce qui se comporte en termes de sécurité, et je dirais même, se comporte tout court, comme une Amazon Linux à jour. Puisqu'on fait sur Amazon Linux, on fait vraiment des mises à jour systématiques. Donc, on peut considérer qu'une AMI Amazon Linux 2015 à jour et identique à une Amazon Linux 2016-09. Alors, est-ce que pour autant, il faut ne pas migrer sur 2016-09 ? Je dirais non. Je dirais qu'en termes de sécurité, vous êtes dans une meilleure situation qu'avec sans doute d'autres distributions Linux, comme le démontre cet exemple. Mais en tout cas, la bonne nouvelle, c'est qu'en termes de sécurité, les paliers sont vraiment franchis, même par les vieilles versions d'Amazon Linux, qui manifestement n'est pas le cas pour Ubuntu. Alors, quelques petits conseils. On va regarder Windows quand même. Avant de conclure. Mon audit tourne toujours. Il n'a rien trouvé. Voilà. Donc pour l'instant, on est toujours à zéro finding, donc tout va bien. Donc j'ai créé une instance. La voilà. Donc l'installation de l'agent sur Windows, qu'est-ce que j'ai fait ? Je suis allé sur la page de documentation. Inspecteur et tout simplement il y a le lien qui doit être un peu plus bas, le voilà donc j'ai téléchargé ce fichier là tout simplement ici qui s'est retrouvé je ne sais où dans le téléchargement sans doute, le voilà donc j'ai exécuté ce fichier il a démarré. Donc clic, clic, clic, il n'y a rien de spécial à faire à part l'installer. Et puis dans la console des services, vous la voyez là, on voit qu'il y a deux agents, enfin deux services qui tournent. Il y a le service lui-même qui s'appelle AWS Agent Service. On aurait peut-être pu l'appeler Inspecteur, mais ce n'est pas le cas. Ne cherchez pas un truc qui s'appelle Inspecteur. Et puis, il y a l'updater service qui va s'assurer que l'agent est à jour. Donc là, lorsque vous l'installez, il démarre. Si pour des raisons qui vous sont propres et qui sont tout à fait compréhensibles, ça vous gêne d'avoir des agents allumés en permanence sur vos instances, il n'y a rien qui vous empêche de l'arrêter. Là, je ne vais pas le faire parce que j'ai un assessment en cours, mais voilà, vous pouvez arrêter l'agent et puis le démarrer au moment, enfin avant de lancer des évaluations. Je pense que personne n'aime avoir des agents qui tournent sur les machines sans qu'on sache très bien pourquoi, donc aucun souci, vous pouvez faire start et stop. Et voilà, ok, et puis pour le reste, à vous de gérer votre politique de patch, ici j'ai activé Windows Update automatiquement, de manière inconditionnelle, là c'est une instance de test sur des instances de production, vous avez peut-être envie de contrôler plus finement ce qui se passe en termes d'installation de patch, et ça ça peut se comprendre, on a déjà eu des patchs, quels que soient les systèmes d'ailleurs, qui provoquaient quelques désagréments, donc installer tout aveuglément parfois, c'est une mauvaise idée. Bon, ici je l'ai fait, mais une fois de plus c'est sans conséquence. Voilà ce que je peux dire sur Windows, on va dire au revoir à cette instance. Voilà. Et on va voir un petit peu quelques conseils maintenant pour piloter au mieux la mise à jour de vos instances. Donc vous l'avez vu, faites attention via ISAMI. Alors vieux package, je pense que je n'ai pas fait une analyse hyper précise des 52 vulnérabilités qui restaient sur l'Ubuntu à jour, mais je suspecte qu'une bonne partie vient de packages applicatifs qui ne sont pas à jour. On a des versions de retard et je pense qu'il y a beaucoup de Java, de vieux JDK 6 ou 7 là-dedans. Sur Amazon Linux, la situation semble meilleure. On voit qu'on arrive à un niveau de sécurité identique, y compris sur des Amazon Linux anciens. Maintenant, mon conseil, c'est quand même, peut-être de temps en temps, une fois par an, à vous de voir ce qui convient dans vos process. Je vous conseille quand même de passer sur les dernières AMI. Ça vous redonnera une baseline très propre. Et d'ailleurs, j'ai vu que ce matin, où cette nuit on a mis à jour d'ailleurs 2016-09 avec encore des nouvelles fonctionnalités noyaux etc. Il y a pas mal de choses qui se passent sur Amazon Linux et c'est dommage de ne pas en profiter. Le deuxième point c'est de penser à faire régulièrement ces scans parce que vous voyez même le temps de construire cette démo il y a de nouvelles CVE qui sont sorties donc le 0% le zéro vulnérabilité élevé sur l'Amazon Linux, je suis à peu près sûr que si je repasse un scan dans une semaine, sans avoir patché mon instance, je vais retrouver encore des vulnérabilités. Donc faites-le régulièrement, l'impact performance est totalement négligeable, le coût des évaluations est faible, il est dégressif, donc plus vous en faites, moins ça vous coûte cher unitairement. Si vous avez 50 serveurs web qui ont tous exactement la même configuration parce que vous avez une AMI que vous construisez vous-même, que vous déployez, etc. et que vous avez une infrastructure immutable, etc. Évidemment, ce n'est pas la peine de scanner les 50. Vous en scannez une sur les 50 et puis vous aurez un état des vulnérabilités qui représentera ce qui se passe sur cette ferme-là. Donc vraiment à coût extrêmement faible, il y a vraiment peu de... Enfin je vois peu de raisons de ne pas utiliser ce service, peut-être pas quotidiennement, mais en tout cas au moins toutes les semaines. Pensez à appliquer régulièrement et je dirais même systématiquement les mises à jour de sécurité, et là aussi... mais littéralement tous les jours vous en aurez sur Amazon Linux. Donc attention, pensez peut-être à le faire une fois à la création de l'instance avec UserData, mais UserData n'étant exécutée qu'à la création, ça ne fonctionnera pas pour les reboots. Donc pensez à intégrer vos mises à jour, vos yum update ou apt-get update, etc., dans les scripts d'init de l'instance ça prend quelques secondes et ça peut vous sauver la vie si vous ne voulez pas le faire comme ça vous pouvez toujours définir des tâches cron pourquoi pas, vous pouvez utiliser CloudWatch Events pour programmer des événements et déclencher pourquoi pas des fonctions lambda qui vont exécuter des commandes de mise à jour sur les instances et puis vous pouvez depuis peu utiliser un système qui s'appelle EC2 Systems Manager qui a été annoncé à Rainvent, qui est intégré dans la console EC2 et qui est une extension d'EC2 pour justement gérer des flottes d'instances. Et je crois hier ou avant-hier, on a annoncé dans Systems Manager la capacité justement à gérer les patchs pour Windows, donc à piloter la des patches, Windows Update, etc. directement à partir de la console EC2. Je crois que j'ai mis le lien sur la page de Recap. Il y a plein de façons de le faire, je n'en préfère aucune, à vous de jouer, mais faites-le s'il vous plaît, dans votre intérêt. N'oubliez pas que l'agent est dépendant de la version du noyau, et par je pense qu'il est là aussi utile au redémarrage de l'instance, peut-être de réinstaller l'agent, ou en tout cas à chaque fois que vous voulez lancer des évaluations, de vérifier que l'agent a été bien mis à jour, pour éviter que vos instances sortent du périmètre de scan. Et puis je l'ai mentionné tout à l'heure, on a aussi des clients qui intègrent un spectre dans le pipeline de déploiement, qui lancent des scans sur des pré-prod ou des prods et ça peut se faire sans trop de difficultés avec CodePipeline par exemple. On aura peut-être l'occasion de le montrer dans un webinaire ultérieur. Voilà quelques ressources complémentaires. Trois livres blancs. Le premier, je crois que je les ai déjà mentionnés pendant la présentation CloudTrail hier, mais je les redonne parce qu'ils sont vraiment importants. Donc la checklist pour l'auditing de vos plateformes, le white paper sur comment loguer tout ce qui se passe dans vos plateformes et puis un en général sur la compliance dans AWS. Je vous ai mis la vidéo qui date de l'année dernière sur le lancement d'un Si vous voulez revoir une vidéo qui vous explique un peu les fonctionnalités. Un post de blog beaucoup plus récent sur l'utilisation d'Inspector et son intégration avec des fonctions lambda. Et puis le fameux post sur Systems Manager qui est vraiment très récent. et qui explique comment utiliser Systems Manager pour appliquer les patchs Windows. Pour l'instant, on n'a pas de support pour les patchs Linux. Je ne doute pas que ça arrive. Et puis, il y a d'autres façons d'appliquer ces patchs. Vous pouvez utiliser la commande EC2 run, vous pouvez scripter. Je pense que le besoin était sans doute plus pressant sur Windows. Voilà, j'en ai terminé, je voulais vous remercier d'avoir participé à cet avant-dernier webinaire de la Security Week. On va répondre à vos questions et puis on parlera ensuite tout à l'heure des bonnes pratiques de sécurité. On a déjà mis en ligne le lien d'inscription pour les webinaires 2017 ainsi que la description des webinaires des mois de janvier, février et mars. Voilà donc janvier beaucoup de serverless, février beaucoup de C2 et mars j'ai oublié. Ah non pardon, serverless en janvier, donc deux webinaires serverless en janvier, deux webinaires DevOps en février et deux webinaires EC2 en mars, y compris un deep dive EC2 qui s'annonce d'anthologie. Si vous avez assisté à la session VPC que j'ai faite cette semaine et que vous l'avez trouvée dense, je pense que là on va battre un nouveau record de densité avec le deep dive EC2. Mais bon, on est là pour s'amuser et donc profitons-en. Je pense que Hugo va vous afficher le traditionnel sondage. Donc vous votez de 1 à 5, je vous rappelle, 5 très contents, 1 pas content du tout, donc 5 est la meilleure note. Je vous laisse quelques secondes pour voter. Et puis si vous avez des questions, n'hésitez pas. Même des questions sur d'autres sujets qu'Inspector ont pour Pour une fois, on a encore un petit peu de temps. J'ai été plus court sur ce webinaire. Si vous avez des questions générales sur AWS, la sécurité, n'hésitez pas, on a du temps pour y répondre. Je vous laisse quelques minutes et on commence à répondre aux questions. Merci beaucoup pour le vote. On va attaquer les questions. Alors il y a deux questions sur le pricing, enfin la tarification, je vais répondre tout de suite, ça c'est assez facile. Comment fonctionne le pricing d'inspecteur en détail ? Désolé si ça a été abordé pendant que j'ai été distrait. Bon, c'est pas grave, vous avez été distrait, mais on vous pardonne. Donc le pricing c'est simplement à l'évaluation. C'est une évaluation d'une instance, ça commence comme je dis tout à l'heure à 30 cents, c'est dégressif au volume et ça descend jusqu'à 5 cents. Pour répondre à une deuxième question qui demande si c'est en fonction du temps, pardon de la durée de l'évaluation, non, c'est vraiment à l'évaluation. Que le scan, quelle que soit la durée du scan. Voilà pour ces deux premiers points. Alors on va remonter dans la liste. Autre question, est-ce que Boris H, j'ai une idée de qui ça peut être. Salut Boris. Est-ce qu'inspecteur peut tester des instances dans une région distante ? C'est un service qui est régional, donc non, inspecteur ne peut tester que les instances EC2 qui sont dans la même région que lui. Il est disponible, qu'est-ce que je vous ai dit tout à l'heure ? Je vais ressortir ma liste. Il est disponible en Irlande, voilà la liste, il est disponible, US East 1, US West 2, Irlande, Corée, Inde, Japon, Australie. Mais une fois de plus, pour ne rien vous cacher, j'ai re-regardé la keynote sécurité de reInvent faite par Stephen Schmitt dont vous aurez les références tout à l'heure, je crois que j'ai mis le lien dans l'autre présentation. Il a annoncé qu'on aurait beaucoup de nouveautés sur Inspector au premier trimestre 2017 dont une expansion géographique. J'espère Boris que tu auras la région de tes rêves. Continuons. Alors, il y a une question intéressante. La comparaison avec Ubuntu 14 et pas fair play, pourquoi ne pas avoir comparé à Ubuntu 16 ? Alors ça c'est vrai, merci Yann. Alors je l'ai fait exprès, parce que je voulais vraiment une vieille distribution. Je suis à peu près convaincu, comme vous, que si j'avais fait sur Ubuntu 16, j'aurais eu de bien meilleurs résultats. Le but, je répète, n'est absolument pas de faire du Ubuntu bashing, qui est une distribution que j'aime beaucoup et que j'utilise à la maison tout le temps. C'était vraiment juste de dire, je prends une distribution Linux d'il y a deux ans et je regarde ce qui se passe en termes de sécurité. Donc oui, je suis à peu près sûr aussi que si j'avais pris un Ubuntu 16, j'aurais eu de bien meilleurs résultats. Mais l'idée était de dire, qu'est-ce qui se passe si je prends quelque chose d'ancien ? Et dans la liste des OS supportées par l'inspector, le choix le plus ancien, c'était Ubuntu 14, tout simplement. Merci. Alors, on a des questions sur Debian. Oui, alors ça c'est aussi une bonne question. Est-ce qu'on aura le support de Debian ? Alors je n'en sais rien. Est-ce que ça fera partie des nouvelles fonctionnalités qui seront annoncées en début d'année ? Je ne sais pas. Je peux faire remonter le point, on va le noter, tu notes dans un coin, tu gardes ça dans ta feuille, feuille Excel. Effectivement, avoir d'autres distributions, je pense que d'autres distributions et d'autres versions de distribution, ça serait effectivement pas mal. Mais je pense que c'est dans les tuyaux, on verra pour des bien. Quoi d'autre ? Alors est-ce qu'Inspector fonctionne avec ECS pour scanner les containers Docker ? Pas pour l'instant. Pour l'instant le scan se fait sur l'instance. Maintenant je n'ai pas essayé, mais est-ce que ça serait une réellement bonne idée ? Je ne sais pas. Je n'ai pas essayé d'installer l'agence à l'intérieur d'un container ? Je ne sais pas ce que ça donnerait. Je pense que ce n'est pas une très bonne idée dans la mesure où… Je pense qu'il y aurait un problème de port. On pourrait peut-être scanner les containers un par un. Je ne suis pas sûr qu'on arriverait à lancer l'agent dans plusieurs containers sur la même instance simultanément. Je pense qu'en termes réseau, je ne sais pas. Je n'ai pas essayé et si quelqu'un a essayé, ça m'intéresse de savoir ce que ça a donné. Je ne sais pas si ça fera partie des nouvelles fonctionnalités. Je sais qu'on a des partenaires qui font ce genre de choses et leur nom m'échappe. Je vous trouve ça à la pause tout à l'heure et je redonnerai le nom du partenaire dans la deuxième session de questions réponses tout à l'heure. Mais oui, on a des partenaires qui sont capables de faire du scan dans Docker, ce qui est un vrai bon sujet parce que j'aime bien Docker mais passer directement du dev à la prod des containers bâtis par des développeurs sans forcément respecter un certain nombre de règles. On voit que installer beaucoup de packages comme ça, ça peut être un risque. effectivement dans les containers aussi. Donc c'est une bonne remarque, je ne sais pas si l'inspecteur supportera ça. Quelle charge CPU RAM l'agent consomme-t-il ? Alors j'ai regardé un peu sur Linux, j'ai regardé, j'ai lancé un assessment, enfin une évaluation sur mes instances qui sont... Je crois du T2 micro, si je ne m'abuse. On va ressortir la console. Oui, c'est du T2 micro. Je me suis connecté sur les instances pendant l'audit avec un top, vraiment pour regarder ce qui se passait. Il ne se passait rien. On restait en chat en load, on était vraiment à zéro. Donc, il il se passe vraiment vraiment rien. Donc je pense qu'il y a, moi j'avais, sur Linux en tout cas, en T2Micro, donc ils ne sont vraiment pas des instances puissantes, je n'ai vraiment vu aucun impact de performance sur l'exécution des audits. A fortiori sur des grosses instances, je pense que c'est encore moins visible. Alors, qu'est-ce qu'on voit ? Bonjour, inspecteur, s'exécute-t-il en tant que route sur les instances Linux ? Comment peut-on faire confiance en ces actions ? Eh bien, on va regarder. Alors, on va récupérer l'IP... de cette instance là on va aller voir ce qui se passe ah là il m'a pas dit j'avais des mises à jour à faire alors je pense que là j'en tourne la question est comment s'appelle-t-il ? alors on va lancer on va faire le test on va relancer le run on va le voir tourner On va lancer celui-là. Run. C'est parti. On est connecté sur l'instance, on va voir ce qui se passe. Ok, c'est parti. Le temps qui démarre. Il s'appelle AWS Agent. Vous voyez le pourcentage CPU ? Et ça, j'insiste, c'est une T2 micro. Donc ça me permet de répondre à deux questions et de le faire en plus avec des éléments factuels. Merci pour la question. On ne peut pas dire que ça pèse lourd. Donc il s'exécute en route ? puisqu'il a besoin d'aller taper un petit peu partout sur l'instance et de voir ce qui se passe. Comment lui faire confiance ? Il est développé par AWS, le service inspecteur fait partie des services qui sont également certifiés, etc. Voilà, au-delà de ça, qu'est-ce que vous voulez que je vous dise ? Je pense qu'il n'y a pas de... cet agent provient de chez nous, vous pouvez lui faire confiance. Vous voyez le CPU et la mémoire, on ne peut pas dire que ce soit violent. Est-ce qu'on a encore d'autres questions ? Non, on n'a plus... On a plus de temps, on a répondu presque à toutes les questions. J'ai oublié de vous dire quoi ? J'ai oublié de vous dire, non je vous ai parlé des webinaires 2017, ça c'est fait. Et puis à cette URL vous retrouverez dans un premier temps les slides de tous les webinaires qui ont eu lieu cette semaine. semaine et puis le temps de travailler un petit peu les vidéos. Je pense que d'ici, dans le courant du mois de janvier, on commencera à poster les vidéos et vous pourrez toutes les revoir. En tout cas, tout sera à cette URL. Voilà, merci beaucoup de nous avoir suivis pour ce neuvième et avant-dernier webinar. On va faire une pause de 5 minutes, un petit café et puis on continue. conclura en beauté, j'espère, avec les bonnes pratiques de sécurité et une nouvelle session de questions-réponses. Merci beaucoup et j'espère à dans cinq minutes. Merci.