L’innovation dans le cloud au service de la sécurité d’Internet

Clarke Rodgers (00:10) :
Il est difficile de croire qu’avant Internet, les problèmes de sécurité étaient plus simples et plus clairs. Le monde a radicalement changé au cours des 40 dernières années, et la connexion en ligne est désormais au cœur de nos vies et de nos activités. Cette évolution draine davantage d’opportunités, mais aussi des risques bien plus importants.

Je suis Clarke Rodgers, directeur de la stratégie d’entreprise AWS et votre guide pour une série de conversations avec les responsables de la sécurité d’AWS ici, sur Executive Insights.

Aujourd’hui, nous recevons Paul Vixie, responsable adjoint de la sécurité des systèmes d’information, vice-président et ingénieur émérite chez AWS. En tant que pionnier de l’évolution d’Internet, Paul apporte une perspective unique à l’organisation de sécurité AWS. Rejoignez notre conversation sur le rôle joué par les responsables de la sécurité pour faire d’Internet un lieu de communication plus sûr. Nous espérons que vous apprécierez notre compagnie.

Clarke Rodgers (00:57) :
Paul, merci beaucoup d’être ici aujourd’hui. Vous êtes dans le milieu d’Internet depuis un certain temps. Pouvez-vous nous dire comment tout a commencé et comment nous en sommes arrivés à ce stade aujourd’hui, notamment pour ce qui est de la sécurité ?

Paul Vixie (01:11) :
La sécurité était une préoccupation secondaire. Elle n’a commencé à être sérieusement prise en compte que bien plus tard. Internet a vu le jour sous la forme d’un réseau du gouvernement américain. Il n’a jamais été utilisé par les militaires, du moins au début. Selon un mythe, les protocoles sont conçus pour renforcer la sécurité contre les cyberattaques ou d’autres formes d’attaques. Or, ce n’est pas vrai. Il a toujours été question du système de meilleur effort. Quand il fonctionne, il fonctionne vraiment bien pour beaucoup de gens. Son dysfonctionnement peut entraîner des pannes catastrophiques qu’un réseau plus sécurisé ne connaîtrait pas.

Clarke Rodgers (01:48) :
À quel moment avez-vous réalisé que la sécurité n’était pas prise en compte ? Et à votre avis, quelles devaient en être les conséquences ?

Paul Vixie (01:56) :
J’ai commencé à tirer la sonnette d’alarme assez tôt, et ma première préoccupation était le spam. Nous n’avions aucun mécanisme d’authentification, rien qui puisse empêcher les gens d’envoyer du trafic indésirable, car l’envoi de trafic indésirable ne profiterait à personne dans un réseau purement gouvernemental.

J’ai commencé à tirer la sonnette d’alarme dès 1992. Dans le cadre de mes activités de conseil, entre autres, j’ai également lancé le premier projet antispam, qui est devenu la première entreprise antispam. Notre système de réputation distribuée était le premier du genre. J’aurais aimé le breveter. Ce système est toujours largement utilisé aujourd’hui, bien que l’entreprise que j’ai créée pour lutter contre le spam ait été poursuivie en justice pour faillite. Elle a fermé. Mais l’idée et les technologies demeurent d’actualité et me donnent raison.

Clarke Rodgers (02:57) :
Maintenant que la sécurité est prise plus au sérieux, non seulement chez les grands fournisseurs de services cloud, mais également auprès des entreprises clientes, qu’est-ce qui vous motive éventuellement ? Est-ce que cela vous donne de l’espoir ?

Paul Vixie (03:13) :
J’éprouve un sentiment d’espoir et de déception, car notre action est trop limitée ou trop tardive. Mais il faut en quelque sorte attendre que l’ensemble des acteurs du marché se réveillent et cernent le problème. Vous ne pouvez pas simplement tirer la sonnette d’alarme en tant qu’entreprise ou personne.

L’espoir réside dans l’ensemble des technologies que j’ai découvertes chez Amazon. À grande échelle, certains problèmes peuvent être généralisés et des solutions être ensuite déployées, ce qui n’est pas possible pour les plus petites entreprises qui fonctionnent à des échelles modestes. Par exemple, ce que nous avons fait avec les processeurs Graviton pour renforcer la sécurité de nos machines virtuelles par rapport aux autres machines virtuelles est inédit.

Considérez le jeu de puces Nitro et l’hyperviseur Nitro. Nous sommes les seuls à les avoir développés. À la sortie de Log4j, par exemple, nous n’étions pas épargnés, mais nous avons mis en place un correctif pour tous nos clients en quelques dizaines d’heures, car notre entreprise est assez grande pour le mettre au point et le déployer rapidement à l’échelle mondiale. Or, dans un système moins centralisé où chacun assume ses responsabilités, vous devez vous en remettre à la chaîne d’approvisionnement.

« J’ai bon espoir simplement parce qu’Internet connaît un regain d’importance à mesure qu’il devient une infrastructure critique et en quelque sorte le système nerveux numérique international ainsi que la source de l’économie mondiale. »

Beaucoup de choses que nous faisions auparavant avec peu de moyens lorsque les transistors coûtaient un dollar la pièce, disparaissent progressivement. Outre le fait qu’éviter les erreurs de départ nous a permis de mettre nos produits sur le marché plus rapidement que les protocoles OSI, le seul et unique moyen de résoudre ce problème consiste à utiliser des clouds comme le nôtre.

Clarke Rodgers (05:09) :
Au cours des deux prochaines années, quelles sont les technologies ou les méthodologies auxquelles vous vous intéresserez particulièrement et qui, selon vous, aideront non seulement les entreprises comme la nôtre, mais également nos clients à améliorer leurs charges de travail en matière de sécurité et de conformité ?

Paul Vixie (05:31) :
Les conteneurs constituent assurément une source d’encouragement en interne. C’est encourageant de pouvoir en faire fonctionner 10 000 sur une seule puce et d’en démarrer des milliers par seconde en cas de pic de charge, et ce, sans avoir besoin d’une intervention humaine pour modifier complètement la conception des logiciels. En effet, à mesure du passage des utilisateurs à ce modèle, nous éviterons le problème que nous rencontrons actuellement, par exemple en matière d’application de correctifs.

Chaque jour, un correctif doit être appliqué. Et à moins d’avoir une équipe dédiée à cette tâche, vous remettrez l’opération à plus tard ou le ferez à une fréquence d’une fois par semaine ou par mois. Lors de l’opération, vous pourriez également être tenu de mettre à niveau d’autres éléments pour adapter le correctif au système, ce qui vous pousserait à tout soumettre à des tests. Des mois peuvent s’écouler entre le moment où vous établissez la nécessité d’appliquer un correctif et sa mise en place effective dans votre système.

►  Écoutez le podcast : Gestion des vulnérabilités dans un scénario de sécurité du « jour zéro »

Je ne pense pas que nous puissions avoir un monde parfait où tout fonctionne si nous continuons à répéter cette opération. Ainsi, avec des conteneurs tels que Lambda, Kubernetes ou Firecracker, vous pouvez faire en sorte que votre pipeline de génération (appelé CI/CD) crée une image et l’exécute au travers de tests. En cas de réussite, vous pouvez simplement la mettre en service.

Vous n’avez pas besoin d’une machine virtuelle dotée de suffisamment d’outils et de logique intégrés pour pouvoir accéder à l’application et l’utiliser comme correctif en propre. C’est ce que nous faisons aujourd’hui : il ne faut en attendre aucune mise à l’échelle. Cela montre déjà quelques problèmes. Même si je procède toujours de cette façon parce que c’est le monde dans lequel j’ai grandi, je ne vous le recommande pas. Il n’y a aucune raison de le faire et il y aurait beaucoup d’avantages à pouvoir créer des éléments immuables.

L’idée d’éliminer les interventions humaines dans la boucle est également encourageante. Je suis triste de le dire parce que les humains ont inventé et construit le système, mais nous devons réduire leur intervention dès maintenant si nous voulons mettre en place une sécurité à l’épreuve du temps.

La quantité de logiciels et de matériel utilisés par l’humain pour apporter de la valeur à un client n’a jamais été aussi importante. Et notre compréhension est restée relativement fixe, c’est-à-dire que plus cette complexité augmente, plus notre niveau de compréhension s’amenuise. Cela ne marchera pas. Nous devons trouver un moyen de faire en sorte que cette complexité n’entraîne pas de résultats indésirables. Encore une fois, cela repose sur une plus grande discipline et l’élimination de toute intervention humaine.

« Je suis triste de le dire parce que les humains ont inventé et construit le système, mais nous devons réduire leur intervention dès maintenant si nous voulons mettre en place une sécurité à l’épreuve du temps. »

Clarke Rodgers (08:18) :
Face à l’accès des humains et aux réseaux, le concept de Zero Trust a évolué au fil des années. Que pensez-vous du Zero Trust, à la fois du point de vue d’AWS, par exemple de la façon dont nous envisageons les systèmes et les mettons en œuvre en interne ? Comment les clients devraient-ils envisager le Zero Trust ?

Paul Vixie (08:39) :
L’élément irréductible clé du Zero Trust est mal compris. Par exemple, des gens disent qu’il suffit de tout mettre en ligne, de tout rendre accessible et de sécuriser les services et les serveurs eux-mêmes. Sécuriser le réseau sans disposer d’un périmètre de sécurité. » Ce n’est pas l’objectif du Zero Trust ni un modèle fonctionnel. Vous avez toujours besoin d’un pare-feu, mais une fois à l’intérieur, vous n’aurez pas une confiance particulière simplement parce que vous êtes à l’intérieur du périmètre.

Cela élimine l’hypothèse selon laquelle accessibilité rime avec fiabilité. Ce modèle consistait autrefois en un périmètre de sécurité renforcé enveloppant un système à faibles protections. Nous ne voulons pas avoir un système perméable bien que le périmètre de sécurité demeure robuste. Vous avez besoin d’un système qui mécanise la gestion des identités, l’authentification et les autorisations à grande échelle. À titre d’exemple, pendant que vous et moi discutons, des milliards d’événements d’authentification se produisent chaque seconde sur le cloud Amazon.

Nous n’avons pas utilisé d’astuces peu coûteuses, comme mettre en cache les résultats récents et considérer que les autorisations sont probablement permanentes. Au contraire, nous vérifions à chaque fois, et à un moment donné, nous avons résolu que c’était la solution pour faire de la sécurité la priorité absolue. »

Mais encore une fois, la plupart des systèmes ont été conçus avec l’idée que l’accès vous y donnait simplement libre cours en raison de l’absence d’un contrôle d’accès précis qui fonctionnerait à grande échelle. C’est le modèle que nous sommes en train de changer. Différentes normes d’authentification sont en place. La nôtre est relativement pionnière et très rigoureuse, mais n’a jamais visé à être une norme sectorielle. D’autres clouds travaillent sur des sujets similaires et certaines normes sectorielles essaient de voir le jour.

Pour autant que je sache et sans en avoir parlé à l’équipe de services, nous allons faire en sorte que chaque client soit libre d’adopter ce mode de fonctionnement.

Clarke Rodgers (10:49) :
Au cours de la dernière année environ, l’IA générative a fait la une des journaux et apparaît presque quotidiennement dans mon fil d’actualité. Qu’en pensez-vous en tant que professionnel de la sécurité ? Comment pensez-vous que les professionnels de la sécurité l’utiliseront à des fins de sécurité, d’investigation, etc. ?

Paul Vixie (11:10) :
Vous devez regarder au-delà du battage médiatique et vous demander ce qu’il restera à l’issue de cet emballement. Dans certains cas, nous ne le savons pas. Il s’agit d’une technologie relativement nouvelle, et de nombreux matériels et logiciels sont conçus pour elle. Il est difficile de prédire l’impact d’un outil tant qu’il n’a pas été utilisé par quelqu’un d’autre que son fabricant. Le fabricant de clés n’a probablement pas prévu qu’elles pouvaient être utilisées comme marteau, mais cela est possible dans certains cas.

Nous ne voyons pas clairement les possibilités réelles qu’offrira l’IA générative au-delà de ce battage médiatique, qui en cèdera la place à un autre. Cela dit, Amazon mène des activités de recherche, de développement et de déploiement de solutions basées sur l’IA depuis plus d’une dizaine d’années. L’IA générative n’était donc pas complètement une surprise pour nous.

CodeWhisperer est un exemple de système à technologie d’IA générative qui n’a rien a voir avec ce qui fait l’actualité. Je constate que cela se produit sur toutes sortes de systèmes. Par exemple, lorsque vous détectez des anomalies, vous examinez les flux de télémétrie de votre système, notamment les événements qui indiquent un potentiel problème ou une potentielle attaque. Forts de cette technologie, nous pourrons désormais mieux les corréler. Encore une fois, j’ai l’impression que nous explorons à peine 1 % des possibilités qu’offre cette technologie.

►  Regardez la vidéo : L’état de l’IA générative

Même si je déteste le battage médiatique en cours et que j’en appelle à plus de sérieux dès le départ, je comprends également que cela présente un réel mérite. Je travaille avec certaines équipes de la sécurité AWS qui essaient de répondre exactement à la question suivante : « Que pouvons-nous faire pour mieux servir nos clients maintenant face à la démocratisation de l’IA générative ? »

Clarke Rodgers (13:14) :
Nous souhaitons également savoir comment aider sur le plan technologique les professionnels de la sécurité humaine qui ont beaucoup de travail en leur fournissant des outils d’IA générative.

Paul Vixie (13:25) :
Il ne s’agit pas d’un produit, mais le plus grand succès d’Amazon avec notre cloud a toujours été les flux de travail que nous permettons à nos clients d’adopter et de développer. Ainsi, Bedrock est l’un des premiers produits que nous avons mis au point dans le domaine des grands modèles de langage. En matière d’utilisation des grands modèles de langage, l’idée est de savoir si vous souhaitez payer les frais relatifs à leur entraînement ou si vous désirez les créer vous-même.

En effet, la création d’un modèle peut prendre des milliers, voire des dizaines de milliers d’heures de temps de calcul très coûteux. S’il existe différents modèles prédéfinis avec un menu qui vous permet de sélectionner ceux de votre choix et de les copier gratuitement sur votre propre système, vous pouvez simplement insérer de la logique dans votre VPC ou tout autre système de notre environnement cloud disposant d’un accès direct aux API qui savent qu’elles ont accès à ces modèles d’abonnement.

Notre croissance repose sur le principe initial du cloud, à savoir une quantité élastique de calcul et de stockage aussi élevée que possible et sans pénalité d’accès. Or, je ne connaissais pas ce principe auparavant et j’ai dû l’apprendre après avoir rejoint AWS. Et maintenant, nous venons de reproduire cela dans le domaine de l’IA générative afin de permettre aux utilisateurs éventuellement très ambitieux dans leur propre segment de marché d’utiliser notre cloud et nos LLM pour réaliser ce qu’ils ont toujours fait avec notre cloud, mais sans les LLM. C’est fantastique, car la véritable puissance de cette technologie réside dans l’usage qu’en font nos clients.

Clarke Rodgers (15:13) :
C’est également fantastique que les clients acquièrent cette confiance grâce à tous les outils de sécurité qu’ils utilisent depuis des années et à d’autres aspects qui peuvent désormais s’appliquer à Bedrock et à tout autre outil.

Paul, merci beaucoup d’avoir été en notre compagnie aujourd’hui.

Paul Vixie (15:26) :
C’était super. Merci encore de m'avoir invité.