Ce mardi 24 août 2021 a eu lieu la seconde édition du AWS re:Inforce, l’événement AWS dédié à la sécurité, l’identité et la conformité. Après son instauration en 2019 et son annulation en 2020 en raison de la pandémie, la conférence s’est déroulée cette année de manière virtuelle depuis Houston. La keynote a été donnée par Steve Schmidt, VP & CISO AWS pour présenter les updates en termes de sécurité, les bonnes pratiques et celles à éviter dans le cloud AWS. A la suite de celle-ci, des clients et d’autres cadres d’AWS ont partagé des retours d’expérience au cours des leadership sessions. 

Globalement, on retiendra que le COVID-19 et ses conséquences ont créé un environnement challengeant pour la sécurité, que cette dernière n’est pas uniquement l’affaire de l’équipe consacrée, qu’il faut prévenir plutôt que guérir et qu’il existe des outils et méthodes simples à appréhender pour réduire les risques. Rien de bien révolutionnaire, mais comme on va le voir, la sécurité est souvent drastiquement améliorée par des pratiques simples et connues, qui ne tiennent qu’à chacun de respecter méthodiquement.

Spoiler alert : AWS Backup Audit Manager est désormais en disponibilité générale. Ce service permet aux utilisateurs d’auditer et de générer des rapports sur la conformité des politiques de protection des données. Il vise ainsi à faciliter la réponse des besoins business et de réglementation.

Adam Selipsky, CEO AWS, introduit la conférence en expliquant que chez AWS, rien n’est plus important, fondamental ou critique que la sécurité. Si celle-ci n’est pas mise en place, il n’y a pas d’expérience client satisfaisante, il n’y aura pas de business, ni pour les clients, ni pour AWS.

L’emphase est comme souvent mise dès le début sur « l’obsession client » d’AWS, et l’importance de la sécurité à ce dessein. A. Selipsky vient renforcer cette idée en rappelant que AWS possède l’infrastructure globale la plus sécurisée au monde pour les clients, en garantissant que ceux-ci restent propriétaires de leurs données, conservent leur habilité à les chiffrer, à les déplacer et à gérer leur rétention.

Il évoque que toutes les données qui passent par le réseau global d’AWS qui relie les data centers et les régions sont automatiquement chiffrées avant qu’elles ne quittent les installations sécurisées. Cette introduction n’est clairement pas sans rappeler le modèle de responsabilité partagée d’AWS : AWS est responsable de la sécurité du cloud, des infrastructures, et le client est responsable de la sécurité dans le cloud.

A la suite de l’introduction du CEO d’AWS, Stephen Schmidt débute avec cette citation de Warren Buffet, que le risque arrive lorsque l’on ne parvient pas à définir, apprendre et itérer. La connaissance de l’état normal fonctionnel permet de réagir aux anomalies rapidement, et ainsi, de détecter les menaces efficacement et d’adopter une réponse appropriée.

Effectivement : à partir de quand peut-on considérer que le comportement observé est une anomalie, un écart significatif à la norme attendue ?

Cette réflexion autour du risque est d’autant plus intéressante si l’on observe cette citation dans un contexte nouveau : le covid a généré beaucoup de changements opérationnels au sein des équipes, et l’on est passé de la relation de proximité autour de la machine à café à la relation à distance, virtuelle, que cela soit pour les meetings ou les opérations. La limite entre la vie personnelle et professionnelle s’est également amincie, avec un accroissement de 114% du télétravail, accompagné d’une augmentation de l’utilisation du matériel personnel de 59%. Plus d’appareils connectés et d’applications tierces, qui augmentent la surface d’exposition, et par ce biais-là, la menace d’exploitation de vulnérabilités. Verizon, entreprise américaine dans les services mobiles, a ainsi constaté une augmentation de 364% en 2020 des tentatives de phishing par smartphone : cette méthode peut être considérée comme l’une des voies les plus rapides pour accéder à un réseau d’entreprise, indépendamment de la bonne volonté de l’utilisateur, qui peut commettre une erreur critique. Errare humanum est.

Comment faire pour réduire les risques ? Commencer par la sensibilisation et l’éducation. La sécurité est avant tout un problème humain : ce sont des attaquants humains qui visent d’autres humains. Et pour répondre à ce problème, il faut développer une bonne hygiène autour de la sécurité, ce qui sous-tend une discipline simple, quotidienne et efficace. S. Schmidt mentionne que la plupart des exploits proviennent d’erreurs basiques, et non pas de hacks issus de l’activité de super méchants ou de ninjas faisant du rappel depuis le toit ! Il affirme que si l’on peut réduire significativement les erreurs humaines, on aura fait la moitié du chemin vers un monde plus sécurisé.

Nouveaux process, nouveaux challenges, d’autant plus pour les professionnels de la sécurité. Pour S. Schmidt, c’est devenu une absolue priorité à gérer en l’espace de quelques semaines au cours de la pandémie.

Comment faire alors, pour nous, les clients et partenaires AWS ?

Le Machine Learning au secours de la sécurité

On peut commencer par l’utilisation de l’intelligence artificielle et du machine learning : non pas pour faire complexe et techos, mais avec l’utilisation d’outils basés sur des modèles de ML. Par exemple, AWS Guard Duty, qui permet notamment de détecter la manipulation d’EC2 qui tenteraient de communiquer avec des domaines prédits comme malicieux. Grâce au ML de AWS Guard Duty, et à l’analyse des domaines dits « normaux » à l’échelle, ce service d’AWS peut générer une alerte lorsqu’il détecte un comportement considéré anormal. Le responsable sécurité peut ainsi prendre une décision informée, et dans le cas d’un faux positif, cette alerte viendra enrichir le modèle de ML de AWS Guard Duty. Pour information, il est estimé d’après S. Schmidt que l’utilisation de ce service peut donner une avance de 4 à 6 semaines sur la gestion d’un événement malicieux par rapport à une détection sans l’utilisation de AWS Guard Duty.

Le conseil du jour ? Anticiper, et ne pas attendre le moment critique. L’image utilisée par le VP d’AWS a été la suivante : on ne souhaite pas que l’airbag d’une voiture se déclenche après le crash, mais pendant l’accident. Makes sense…

Il conseille donc de démarrer AWS Guard Duty maintenant, et d’apprendre à réduire son temps de remédiation et de reprise d’activité. Avec un peu de maturité, il est même conseillé d’aller exploiter les opportunités offertes par l’automatisation et les services AWS. Par exemple, l’utilisation conjointe d’AWS Guard Duty, d’AWS Cloudwatch Events (ou AWS Eventbridge) et d’AWS Lambda peut permettre de détecter automatiquement une EC2 qui ferait du crypto-minage, d’arrêter la ressource et de générer un rapport au responsable sécurité.

Il est donc recommandé, comme pour la plupart des activités, de se préparer pour être performant le jour J. On peut faire une analogie avec le sport : on ne devient pas un champion le jour de la compétition. On le devient à la suite de nombreuses répétitions, expérimentations et apprentissages au cours de séances d’entraînement.

Les ransomwares

S. Schmidt a mentionné qu’il existe des pratiques simples, mais qui se doivent d’être rigoureuses pour être efficaces pour éviter certaines déconvenues liées à la prise de pouvoir malveillante d’un système par un attaquant. Dans le cas des ransomwares, ce qui est nouveau, ce n’est pas de rentrer dans un réseau et de réaliser un exploit, c’est le fait qu’il n’y ait pas besoin d’avoir accès aux données pour faire du mal à l’entreprise. Les données peuvent être chiffrées, verrouillées… tout peut-être parfait, sauf que si l’attaquant empêche les accès légitimes au système, la protection des données n’est plus le problème. Chaque seconde qui passe, c’est le business qui s’écroule.

Comment réduire les risques ? Ici aussi mieux vaut prévenir que guérir, et cela peut débuter par la séparation des responsabilités. Si l’on évite d’avoir un responsable qui a le droit d’empêcher complètement l’accès au système, il sera plus difficile d’en exclure les utilisateurs authentiques. Les comptes opérationnels et de backup doivent appartenir à des propriétaires distincts. Evidemment, les credentials devront être différents. On peut aussi utiliser des outils AWS pour vérifier, par exemple, qu’il n’y a pas de bucket S3 publics, sans versionning ou encore d’EBS sans snapshots. Ici aussi, c’est de l’hygiène, ou le « Hello World » de la sécurité dans le cloud d’AWS.

 AWS Backup Audit Manager Now GA

Ce service peut rajouter un niveau de protection contre les ransomwares, parce qu’il devient plus facile de gérer les backups. L’outil va tracer les activités de backup et détecter les dérives basées sur des paramètres préétablis, facilitant la mise en place d’actions correctives rapidement. Néanmoins, avoir un backup plan est une chose, le tester en est une deuxième. Il est recommandé de jouer préalablement son backup plan, pour s’entraîner à sauvegarder et restaurer ses systèmes. Cette démarche d’entraînement peut être initialisée de manière ludique, par exemple, au cours de Gameday, avec des mises en situation.

IAM

S. Schmidt a rappelé l’importance de respecter les bonnes pratiques de least privilege et de donner des permissions granulaires aux utilisateurs. On observe trop souvent des clients prenant des raccourcis et qui finissent par donner des droits administrateurs non nécessaires pour aller plus vite, avec le risque que ces droits admins donnent des droits admins, et ainsi de suite. Rapidement, la gestion des accès et de la sécurité devient problématique.

Quelques statistiques : 4/5 des incidents arrivent à cause de credentials faibles, 1/3 des employés ont le même mot de passe sur tous leurs appareils, et plus d’un employé sur deux utilisent leurs appareils personnels pour travailler, même pour utiliser leur calendrier, tchatter ou répondre à leurs emails.

Il apparaît nécessaire de rappeler de diversifier et de changer les mots de passe régulièrement, et que ceux-ci ne se limitent pas à « password123 ». L’utilisation d’un gestionnaire de mot de passe (KeePass, Bitwarden, etc.) peut être une première étape vers cette démarche, au moins à titre personnel.

42% des entreprises n’ont pas sécurisé les appareils personnels de leurs employés. Si l’on couple cette donnée avec une gestion IAM bancale et des mots de passe partagés et faibles, cela crée un environnement idéal pour un attaquant qui souhaiterait pénétrer un système.

Des astuces pour prendre des actions ? S. Schmidt propose de définir des horaires de travail dans les permissions : il n’y pas de besoin de se connecter à 2h du mat’ en Australie si le business est en Amérique du Nord. Instaurer l’authentification à plusieurs facteurs (MFA), utiliser des groupes pour gérer les accès, réviser régulièrement qui a accès à quoi, voire mieux : automatiser la vérification. Ce rôle n’a pas été utilisé depuis 60 jours ? On peut automatiser la révocation des accès, enlever les permissions et la suppression des rôles ou des utilisateurs. Il vaut parfois mieux que l’on vienne redemander des accès plutôt que de laisser des portes ouvertes sans contrôle.

Néanmoins, dans certains contextes, il peut aussi être intéressant de considérer que la voie du least privilege est une finalité sur le long terme, et que trop restreindre les accès peut freiner l’innovation, comme cela est évoqué dans une des leadership sessions. Alors comment faire ? On peut donner initialement des droits permissifs pendant quelques semaines, puis, utiliser AWS Access Analyzer pour générer une policy aux petits oignons qui se base sur l’utilisation concrète des accès de l’utilisateur.

Les Security Guardians

Enfin, S. Schmidt a évoqué les résultats d’un programme interne AWS qui seront approfondis au cours du Re:Invent 2021. Il recommande d’avoir des security guardians (ou champions sécurité) dans les équipes autres que celles de sécurité, mais qui sont volontaires pour maintenir les best practices, notamment lors des opérations dans le cloud. C’est une manière de faire qui est souvent partagée : la transformation passe par l’humain et l’adoption du changement.

Pour finir, je partagerai l’une des interventions de Brian Lozada, la CISO de HBO Max. Elle a affirmé qu’elle ne veut pas que la peur des incidents vienne freiner l’innovation et dicter le rythme dans ses équipes, mais que cela soit les clients qui inspirent le tempo. Si je partage ce point de vue, j’y verrais aussi un axe d’amélioration : plutôt que d’opposer les deux approches, est-il possible de faire les deux : être créatif et innover à la fois à travers les incidents et les besoins clients ?

Et pour aller plus loin sur le rôle du Champion Sécurité :