Rehausser les exigences de sécurité chez AWS et au-delà

Clarke (10:27) :
J'imagine que tous les développeurs qui travaillent sur la sécurité d'AWS ne commencent pas nécessairement avec une solide expérience en ingénierie de la sécurité. Quel type de mécanismes avez-vous mis en place pour amener ces développeurs au niveau que vous avez défini pour la sécurité AWS ? En particulier dans les outils de développement et même peut-être dans les produits de sécurité destinés aux clients ? 

Eric (10:50) :
Il y a plusieurs façons d'aborder cette question. D'une part, la sécurité chez Amazon est une discipline de développeur. Nous ne pouvons pas faire tout ce que nous devrions faire. Nous ne pouvons pas évoluer avec l'entreprise si nous le faisons uniquement en ajoutant des ingénieurs à l'équipe. Et donc, une grande partie de ce que nous faisons consiste à créer des outils. Il s'agit de développement logiciel direct, comme vous le feriez dans n'importe quelle autre équipe au sein d'Amazon, sauf que vous développez des outils de sécurité. Beaucoup de nos ingénieurs ne sont pas des ingénieurs en sécurité, ils n'ont pas de formation en sécurité. Ils n'ont pas besoin d'avoir une expertise particulière en matière de sécurité pour rejoindre l'équipe. Certains d'entre eux ont une passion pour la sécurité, d'autres aiment simplement le travail et l'équipe dans laquelle ils travaillent et ils sont très heureux de faire ce qu'ils font, mais ils n'ont pas un intérêt particulier pour la sécurité, et c'est bien comme ça.

Eric (11:37) :
Tout le domaine de la sécurité consiste à déterminer les hypothèses formulées par un développeur, puis à déterminer comment enfreindre ces hypothèses pour pousser le système dans un état inattendu. Que se passe-t-il lorsque j'injecte les données d'un disque dur entier dans ce champ ? Que se passe-t-il lorsque je tourne la molette jusqu'à 11 ? Que se passe-t-il lorsque je mets un nombre négatif dans ce champ ? Et les gens qui pensent comme ça ont tendance, d'après mon expérience, à le faire de façon naturelle et spontanée – c'est une mentalité très difficile à enseigner. 

Eric (12:18) :
Donc, quand nous trouvons quelqu'un qui a cette mentalité, toutes les connaissances spécifiques en matière de sécurité peuvent être enseignées. Nous pouvons le faire progresser facilement dans toutes les technologies quotidiennes. Rien de ce je fais au quotidien n'existait lorsque j'étais à l'université : les principes fondamentaux que j'ai appris à l'université s'appliquent toujours, mais ce n'est le cas d'aucune des technologies spécifiques. Nous avons donc mis en place un programme très robuste pour mettre au niveau les personnes qui ont cette tournure d'esprit particulière pour la sécurité.

Eric (12:46) :
Donc la réponse à votre question est double. Il y a des personnes que nous n'avons pas besoin de former à la sécurité. Elles font un travail de développement standard. C'est un rôle de création normal. Et elles excellent. Et certaines d'entre elles expriment un intérêt pour la sécurité, et c'est très bien, nous encourageons cela. Mais ce n'est pas nécessaire. Et puis de l'autre côté, nous avons des gens qui aiment comprendre comment casser des choses. Et quand on se demande comment casser les choses, on est naturellement amené à se demander comment les réparer pour qu'on ne puisse plus les casser. Et toutes les compétences qui sont spécifiques à l'emploi peuvent être enseignées.

Clarke (14:03) :
À ce sujet, ou plutôt à rebours de ce que vous venez de dire, nous voyons beaucoup de nos clients essayer de mettre en place une pratique de sécurité au sein de leurs communautés de développement. Et l'une des pistes qu'ils choisissent consiste à mettre un expert de la sécurité à la tête d'une « équipe de développement ordinaire » pour relever le niveau de la sécurité dans l'équipe en s'en faisant le champion. L'idée est que nous avons un nombre limité de professionnels de la sécurité, et qu'il faut donc les répartir dans les équipes de développement jusqu'à ce que tout le monde ait le même niveau. Est-ce que nous avons une approche similaire chez AWS et Amazon, est-ce la façon dont nous voyons les choses ? Ou bien, puisque la sécurité est intégrée à notre philosophie, est-ce que tout le monde se dit : « J'ai une certaine responsabilité dans la sécurité de mon application, donc je vais suivre le processus » ? Pourriez-vous nous dire un peu comment cela fonctionne ?

Eric (14:58) :
Bien sûr. La sécurité est un « job zero », un prérequis absolu. Nous croyons fondamentalement que, tout comme l'évolutivité, la disponibilité, la faible latence et la faible variation, la sécurité fait partie de l'expérience client. Elle fait partie de tout ce que nous développons. Cela dit, l'expertise en sécurité est rare. Nous n'avons pas autant d'ingénieurs en sécurité que nous aimerions. J'adorerais que chacun de nos développeurs soit aussi un expert en sécurité. Mais je ne vais pas attendre que ça arrive. Donc je trouve qu'il est intéressant que vous utilisiez le terme de champion de la sécurité, parce que c'est littéralement le nom du programme que nous avons en interne : nous identifions des personnes axées sur la sécurité au sein des équipes de service, nous les formons, nous les soutenons et nous leur permettons d'améliorer leurs compétences en matière de sécurité afin qu'elles puissent contribuer à influencer l'ensemble de leur équipe de service.

Eric (16:38) :
Et quand le moment de prendre une grande décision arrive, elles ne sont pas seules pour annoncer : « En tant que seul champion de la sécurité ici, je pense que ce n'est pas prêt pour le lancement, ou que nous devons travailler davantage. » Elles peuvent s'appuyer sur toute cette organisation de sécurité, nous pouvons travailler ensemble sous l'angle de l'obsession client pour déterminer ce qui est bon pour les clients. Si nous livrons un service non sécurisé, nous ne donnons pas le résultat attendu aux clients. Mais si nous ne livrons pas le service... Un service qui n'existe pas ne satisfait aucun client – il faut donc trouver le juste équilibre. Et en intégrant une expertise en sécurité au sein de l'équipe de service, en empathie totale avec elle, puis en intégrant une expertise en sécurité au sein de l'équipe de sécurité AWS, toujours en empathie avec l'équipe de service, mais agissant davantage comme un auditeur, nous prenons de bien meilleures décisions, beaucoup plus rapidement.

Clarke (17:28) :
Et j'imagine que ça apaise... Encore une fois, dans de nombreux échanges avec les clients, le service de sécurité est considéré comme le service du « non », ou comme le service à éviter si l'on veut lancer une application. Avec le modèle dont vous venez de parler, il me semble qu'on jette un pont de confiance et que tout le monde prenne conscience que la sécurité fait simplement partie du travail et que c'est ainsi que nous faisons les choses chez Amazon. Et puis le résultat final est un produit plus sûr.
 
Eric (18:00) :
Il y a quelque temps, nous essayions de proposer un énoncé de mission. Nous essayions de dire ce que fait la sécurité AWS. Et le meilleur résumé que nous ayons trouvé était « livrer en toute sécurité ». C'est une formule très courte mais je pense qu'elle capture parfaitement notre raison d'être. L'entreprise n'existe pas pour faire de la sécurité. Elle s'appelle Amazon Web Services, pas Amazon Security. Nous sommes là pour livrer ces services aux clients. Si nous ne livrons pas, nous n'exécutons pas. Nous ne faisons pas ce pour quoi l'entreprise existe. Nous sommes ici pour être un moteur pour l'entreprise. Nous ne sommes pas la raison d'être de l'entreprise. Certes, vous ne pouvez pas avoir cette entreprise sans une sécurité exemplaire, mais nous ne sommes qu'une facette.
 
Eric (18:44) :
Et la chose la plus importante pour nous est l'appui que nous avons de la direction. De toute évidence, la sécurité est extrêmement importante et cela vient d'en haut. Nous n'avons pas besoin de dire « Nous sommes l'équipe de sécurité, vous devez nous écouter. S'il vous plaît, écoutez-nous... » Je n'ai pas ce problème. Depuis le PDG jusqu'en bas de l'échelle, le ton est donné. Tout le monde sait que la sécurité est importante.
 
Clarke (20:04) :
Merci. Maintenant, parlons de mesurer un programme de sécurité, en particulier avec les développeurs et tous ceux qui écrivent du code au sein d'AWS. Quelles sont les métriques clés que vous utilisez pour mesurer l'efficacité du programme de sécurité dans l'ensemble de la communauté de développement d'AWS ?
 
Eric (20:57) :
Nous utilisons des métriques pour deux aspects.
 
Eric (21:43) :
Il ne sert à rien de mesurer le temps de résolution d'un ticket. Le ticket met le temps qu'il faut à se fermer. Par contre, nous mesurons notre réactivité. Nous avons donc des SLA sur le premier échange. Par exemple, si vous envoyez un e-mail à AWS-security, nous avons déclaré publiquement que vous obtiendrez une réponse d'un humain dans les 24 heures. Et nous mesurons cela. Nous avons même des graphiques et des tableaux que je regarde chaque semaine et qui me disent : « Voilà le temps qu'il nous a fallu pour répondre aux personnes qui nous envoient des e-mails. » La réactivité est vraiment décisive. Premièrement, parce que si vous n'êtes pas réactif, vous perdez la confiance des gens. Et deuxièmement, parce que si vous êtes réactif, c'est généralement le point de départ d'autres bonnes choses.
 
Eric (22:25) :
Nous appliquons la même approche à l'âge des tickets.
…
Tout est un ticket. Donc nous avons quantité d'automatisations intégrées au système de tickets pour détecter si un ticket devient obsolète. Nous mesurons les délais entre les différents échanges avec l'équipe de service et avec l'équipe de sécurité, donc si des tickets traînent en longueur, nous savons si le blocage est à notre niveau ou à celui de l'équipe de service, et nous pouvons très rapidement faire remonter les tickets qui nécessitent une attention immédiate. Mais grâce à cela nous obtenons aussi des données nécessaires à l'introspection et la rétrospection pour identifier les processus qui ne fonctionnent pas, comment réaffecter le personnel et comment investir dans de meilleurs outils. Nous mesurons les processus qui entourent la sécurité et nous avons constaté que cela produisait réellement de bons résultats en matière de sécurité.
 
Eric (23:20) :
Et s'il y a une autre chose que nous mesurons de manière agressive, c'est qu'il ne s'agit pas de faire les choses bien. Nous passons énormément de temps, dans la sécurité des applications, à concevoir un bon service, mais il n'arrive jamais qu'Amazon lance quelque chose puis cesse d'y toucher. Nous ajoutons constamment des fonctionnalités, nous répondons constamment aux commentaires des clients et nos services changent rapidement en fonction de ce feedback. Donc notre objectif n'est pas de lancer en toute sécurité, c'est de maintenir la sécurité tout au long de la vie du service : cela signifie que les choses que vous faites lors de l'évaluation initiale de la sécurité de l'application vieillissent rapidement et perdent leur valeur. Ainsi, une partie du processus de sécurité des applications consiste à déterminer les invariants, les déclarations qui doivent toujours être vraies à propos du service, puis à déterminer comment nous allons vérifier ces invariants dans le code.
 
Eric (24:10) :
Par exemple, si un service doit toujours refuser une demande formatée d'une certaine façon, il faut mettre en place un test canary qui appelle ce service en production en formulant la requête dans ce format, pour vérifier qu'elle est bien refusée. Ensuite, nous mesurons nos canaris. Quelle part de la surface du service couvrent-ils ? À quelle fréquence sont-ils exécutés ? À quelle fréquence échouent-ils ? À quelle fréquence produisent-ils des résultats anormaux ? Et nous mesurons ces processus, pour valider notre position de sécurité. Il ne s'agit pas de mesurer la sécurité fournie. C'est difficile à faire. Nous mesurons plutôt les régressions par rapport au niveau de sécurité que nous avons établi. C'est extrêmement important parce qu'il y aura toujours un nouveau problème de sécurité. Nos équipes sont innovantes, elles ne cessent de proposer de nouveaux services passionnants que nous n'avons jamais eu à sécuriser auparavant. C'est une autre des choses qui me poussent à venir travailler tous les jours.
 
Clarke (26:00) :
C'est formidable. Donc, pour poser une question connexe, mais du point de vue du client cette fois, nous avons des clients qui sont très, très avancés, ils font de l'infrastructure en tant que code, via un pipeline CICD en production. À l'autre extrémité du spectre, nous avons des clients qui restent dans la console et font tout en pointer-cliquer. D'après mon expérience, la majorité de nos clients se situent quelque part au milieu et s'efforcent d'accéder au nirvana de l'infrastructure en tant que code. Quels conseils donneriez-vous à la direction de ces clients pour les encourager à se concentrer davantage sur l'ingénierie plutôt que sur les aspects opérationnels « pointer-cliquer » de la gestion d'une infrastructure ?
 
Eric (26:42) :
Vous savez, je n'ai jamais rien développé de beau. J'ai développé des choses dont je suis incroyablement fier, des choses qui ont très bien fonctionné sur le marché, que ce soit le marché public des services AWS ou le marché interne, où nos clients sont les équipes de service et d'autres Amazoniens. Mais tous ces systèmes ont commencé par une graine d'idée : nous avons développé ce que nous pensions être la plus petite chose susceptible de ravir les clients, puis nous l'avons itérée aussi rapidement que possible. Et elle a grandi au fil du temps. C'est cette itération qui vous donne les magnifiques outils. Les personnes qui leur sont proches les voient comme le monstre de Frankenstein. Ce sont des tas de ferraille qui tiennent avec du ruban adhésif, on dirait un bricolage de MacGyver. Mais en réalité, ce sont de magnifiques outils. Ils sont d'une efficacité redoutable. Et parce qu'ils ont été développés spécialement pour leur mission, étape par étape, ils font réellement le travail qu'on attend d'eux.
 
Eric (27:42) :
Donc quand quelqu'un arrive, que ce soit un nouveau dans l'équipe ou un client à qui nous expliquons comment nous faisons les choses en interne, il voit tout cet éventail d'outils, ces mécanismes que nous avons construits, et il se sent dépassé. « Jamais je ne pourrais reproduire ça. » Premièrement, vous n'avez pas besoin de le reproduire. C'est fait pour gérer nos problèmes de sécurité spécifiques. Mais deuxièmement, nous n'avons pas construit ces choses, nous les avons cultivées au fil du temps, et toutes ont commencé petit. C'est une approche progressive. Lorsque nous parlions de métriques, j'ai parlé du refus des régressions, du fait qu'il ne faut pas résoudre deux fois le même problème. Améliorez-vous chaque jour. Chaque jour, vous relevez progressivement le niveau de la sécurité, c'est une croissance exponentielle.
 
Clarke (29:34) :
Donc si je résume pour les clients qui nous regardent : l'idée est, essentiellement, de commencer petit en termes d'efforts d'ingénierie, puis simplement de grandir au fil du temps pour améliorer au fur et à mesure, plutôt que de changer l'intégralité de son approche en une fois ?
 
Eric (29:48) :
Tout à fait. Cet état d'esprit progressif porte toujours ses fruits. Et de l'autre côté il doit s'appuyer sur des professionnels de la sécurité qui n'ont pas froid aux yeux. Nous sommes tous entourés de risques chaque jour. Traverser la rue est un risque, conduire sa voiture est un risque, brancher son ordinateur portable sur le réseau est un risque. Nous devons être à l'aise avec un niveau de risque approprié. Et donc la sécurité est l'art – et j'aimerais que ce soit plus une science, mais je pense que c'est un art – de gérer ces risques, de comprendre quels risques sont acceptables, quels risques peuvent être atténués et quels risques sont absolument inacceptables. Et donc, en tant que professionnel de la sécurité, dans n'importe quel rôle, n'importe où dans la sécurité, vous devez pouvoir parler de la gravité de ce risque.
 
Eric (30:38) :
Dans notre organisation, quand nous parlons de sécurité, une expression que nous utilisons tout le temps est « clinique et précis ». Si vous dites : « C'est la pire faille de sécurité que nous n'ayons jamais vue, et nous ne pouvons rien faire pour la corriger », vous venez de perdre énormément de crédibilité. Vous avez fermé la porte à toutes les discussions. Nous ne négocions plus sur la voie à suivre. Vous venez de la fermer. Par contre, si vous dites : « C'est un problème vraiment préoccupant. Je m'inquiète de cet impact en particulier, et trois pistes sont possibles. J'aime bien la première. Elle coûte plus cher, mais elle apporte tel et tel avantages. Parlons de ce que nous devons faire maintenant ». C'est clinique, c'est précis, et ça ouvre la conversation. Je vous apporte mon expertise afin que nous puissions avoir une conversation sur l'entreprise. Et l'ingénieur qui construit cet outil de sécurité doit avoir cela à l'esprit. Il doit se demander : « Comment puis-je améliorer la situation de l'entreprise ? » et non pas, « Oh mon Dieu, tout est en feu, c'est terrible. »