Le rôle du PDG dans le leadership en matière de sécurité

Clarke Rodgers (00:05) :
Le leadership en matière de sécurité doit commencer au sommet. Lorsque la haute direction discute de la stratégie commerciale, la sécurité doit non seulement occuper une place de choix, mais aussi être la première priorité de chacun.

Je suis Clarke Rodgers, directeur, AWS Entreprise Strategy, et je serai votre guide durant une série de conversations avec les responsables de la sécurité d’AWS sur Executive Insights.

Mon invité d’aujourd’hui n’a pas besoin d’être présenté : Adam Selipsky, PDG d’AWS. Découvrez comment la culture de sécurité a été établie pour la première fois chez AWS, comment se présente la communication entre le PDG et le CISO, et comment Adam soutient les initiatives de sécurité depuis le sommet. Merci de vous joindre à nous.

Clarke Rodgers (00:46) :
Adam Selipsky, PDG d’Amazon Web Services. Merci beaucoup d’être ici aujourd’hui.

Adam Selipsky (00:50) :
C’est un plaisir d’être ici.

Clarke Rodgers (00:51) :
Alors, revenons un peu en arrière dans l’histoire. Nous sommes maintenant en 2005. Jeff Bezos vous a donné carte blanche pour aller de l’avant avec cette petite expérience appelée « AWS ». Comment avez-vous abordé ces toutes premières conversations sur la sécurité avec ces clients ? Et cela ne m’étonnerait pas qu’à ce moment-là, de nombreux clients se soient demandé : « Qu’est-ce que le cloud ? » « Qu’est-ce que l’informatique distribuée ? » Il se peut qu’ils n’aient jamais eu de conversations de sécurité, mais que se serait-t-il passé s’ils en avaient eu une à ce moment-là ?

Adam Selipsky (01:22) :
Il s’agissait d’un tout nouveau concept et il est vrai que, pour de nombreuses personnes, le fait de confier vos charges de travail pour qu’elles soient traitées « quelque part ailleurs » n’était pas très intuitif. Bien sûr, c’est pour cela qu’on l’appelle le cloud, il se trouve quelque part là-bas. Il est donc compréhensible que cela ait demandé beaucoup de sensibilisation. Mais, après avoir expliqué quelques principes fondamentaux, le plus important étant qu’Amazon avait vraiment dû faire des miracles à cette époque où AWS n’existait pas, cela a commencé à prendre du sens pour eux.

Clarke Rodgers (01:49) :
Bien sûr.

Adam Selipsky (01:50)
Amazon devait donc être vraiment douée pour gérer une infrastructure à grande échelle, hautement disponible, très rentable et, bien sûr, très disponible sur le plan opérationnel et de la sécurité. Et nous avons vraiment tiré parti de toute cette expertise au sein d’Amazon, qui opérait à une échelle à laquelle, franchement, peu d’entreprises opéraient et a développé AWS. Les nombreuses charges lourdes et indifférenciées ont constitué l’un des principaux obstacles initiaux. Nous l’avons parfois qualifiée de « boue » des infrastructures. Pour la plupart des entreprises, il n’était pas nécessaire d’être spécialement douées en termes d’infrastructure.

Si vous vendez des automobiles, si vous diffusez des films en streaming, si vous faites de la recherche de médicaments, pourquoi devriez-vous réussir à gérer une infrastructure massive, à la maintenir disponible, à la sécuriser et à la rendre peu coûteuse, à aller de l’avant et à innover ? Tous ces points relevaient bien entendu d’AWS.

Clarke Rodgers (02:50) :
Exact.

Adam Selipsky (02:51)
Il était donc logique que nous soyons vraiment bons dans tous ces domaines. L’un des principaux éléments de cette initiative est donc d’expliquer notre approche en matière de sécurité, qui était clairement la tâche zéro chez AWS.

Je m’assure de m’exprimer très clairement à ce sujet, car c’est tout simplement plus important que tout le reste de notre travail. De fait, nous avons été très clairs là-dessus dès le début. Nous avions l’habitude de dire qu’il y avait très peu d’événements d’extinction potentiels pour AWS, mais un problème de sécurité grave représentait l’un des rares facteurs susceptibles de constituer un événement d’extinction pour l’entreprise, en particulier au début. Et nous avons pris ça très au sérieux.

Clarke Rodgers (03:44) :
Cela a-t-il donc motivé certains comportements au sein des équipes de produit lors du développement de ces nouveaux services tels que SQS, S3 et EC2 ?

Adam Selipsky (03:54):
Avoir un modèle de propriété très bien défini était la méthode qui nous a permis de bénéficier de la meilleure sécurité possible. C’est vraiment... je suppose qu’on pourrait appeler ça une matrice. Nous avons donc une équipe de sécurité de grande envergure, hautement experte, absolument hors pair et de classe mondiale. Des milliers de personnes qui ne s’inquiètent que pour la sécurité. Peu d’entreprises peuvent dire la même chose... Cela n’aurait aucun sens économique pour la plupart des entreprises.

Notre équipe de sécurité, notre équipe de sécurité centralisée AWS, développe de nombreuses capacités techniques et dispose de nombreux experts pour aider à auditer, à conseiller et à orienter la stratégie. En même temps, nos équipes de service, EC2, S3, DynamoDB, Connect, Amazon Bedrock, quelle qu’elle soit, sont toutes propriétaires à 100 % de leur sécurité. Elle n’est pas sous-traitée à l’équipe de sécurité.

Donc, s’il y a un problème avec l’un de nos services, le GM de ce service s’y intéresse entièrement, se sent pleinement propriétaire, le gère à 100 % et bénéficie bien sûr du partenariat total de notre équipe de sécurité. Et je pense que l’intégration de cette sécurité dans la culture de notre équipe de service garantit son intégration réelle au service. C’est crucial. Nous l’intégrons au service dès le premier jour, pas après. Bien entendu, nous améliorons constamment la sécurité, mais nous intégrons fondamentalement une sécurité à toute épreuve et de niveau professionnel à tout ce que nous faisons, quel que soit le service, dès le moment où nous commençons à le développer.

Clarke Rodgers (05:43):
Et c’est tout à fait logique, car le propriétaire du service est le plus proche de l’objet qu’il construit. Il sait donc à quels risques, et cetera, cette situation particulière est confrontée...

Adam Selipsky (05:52)
Eh bien, aucun problème de sécurité ne sera introduit par une équipe de sécurité centrale. Il serait introduit involontairement par votre propre équipe. Il est donc préférable que votre propre équipe soit chargée en premier lieu de le repérer et de le corriger. Et nous avons vraiment adopté une approche de surprotection grâce à un ensemble de fonctionnalités très robustes de notre équipe de sécurité.

Clarke Rodgers (06:09):
Tout à fait. 17 ans et demi plus tard, après le lancement initial, comment la sécurité a-t-elle évoluée ? Et quand je parle de sécurité, je parle également des conversations sur les risques et la conformité. Comment celles-ci ont-elles évolué dans vos interactions avec les clients ?

Adam Selipsky (06:26)
Je pense que la conversation sur la sécurité a commencé par « Est-il vraiment possible de sécuriser ça ? » Et bien sûr, nous en avons parlé. Nous avons rapidement dépassé ce point, et je pense qu’il y a eu des moments déterminants, notamment lorsque Netflix a annoncé qu’elle optait pour AWS. Elle est très compétente d’ailleurs, elle peut développer n’importe laquelle de ces fonctionnalités, mais elle a choisi de ne pas le faire. Lorsqu’elle a annoncé qu’elle allait foncièrement abandonner le secteur des centres de données et placer l’ensemble de leur infrastructure sur AWS, ce qui impliquait toute la sécurité et la disponibilité, je pense que cela a marqué beaucoup d’esprits. Et cela a changé la teneur des conversations.

Un certain nombre d’agences gouvernementales, y compris des membres éminents de la communauté du renseignement du gouvernement américain, ont déclaré publiquement qu’AWS offrait une meilleure sécurité que celle qu’elles offraient dans leurs propres centres de données. Et encore une fois, de nombreuses personnes, y compris de grandes entreprises, des banques, des sociétés pharmaceutiques, etc., en ont pris note. Donc, comme de gros clients déclaraient vouloir confier ces fonctions à AWS en raison de son excellent modèle de sécurité, Je pense que cela a marqué beaucoup d’autres entreprises.

Clarke Rodgers (07:35):
L’année dernière, lors de la deuxième saison de la série, j’ai eu le privilège d’interviewer le CISO d’AWS et nous avons parlé des mécanismes de sécurité, de ce qui fonctionne dans les grandes organisations, de ce qui ne fonctionne pas très bien. Et l’un des mécanismes les plus efficaces auxquels il a fait référence était la réunion hebdomadaire entre le PDG et le CISO d’AWS. Bien entendu, selon lui, cette réunion donne le ton au reste de l’organisation. Cela permet de tenir le PDG informé de ce qui se passe dans le domaine de la sécurité. Cela permet de tenir le CISO informé de ce qui est important pour le PDG.

J’aimerais donc connaître votre point de vue sur cette réunion. Pas celui d’un professionnel de la sécurité, mais votre point de vue en tant que chef d’entreprise. Comment se déroule cette réunion pour vous ?

Adam Selipsky (08:20):
Dans ce cas précis, l’un de nos nombreux mécanismes de sécurité est cette réunion hebdomadaire que mon directeur de la sécurité informatique, Chris Betz, et moi-même organisons conjointement. Et comme vous l’avez mentionné, cela envoie un signal culturel. C’est donc une réunion hebdomadaire, sans plaisanter, Et elle est prioritaire. Son contenu est incroyablement simple. Nous passons en revue les trois principaux problèmes de sécurité apparus au cours de la semaine passée.

La réunion se maintient toujours, il y en a toujours deux ou trois. Certaines périodes peuvent être plus « intéressantes » que d’autres, mais nous ne la sautons jamais. Nous étudions toujours de manière très approfondie les principaux problèmes de sécurité. Il ne s’agit pas d’une présentation. Tout à fait dans le style d’Amazon, il existe un document écrit, un résumé écrit du problème de sécurité. Il a été soigneusement vérifié avant la réunion. Il est complet et détaille exactement où nous en sommes et les prochaines étapes précises concernant cette question de sécurité. Les membres de l’équipe de service appropriée et, bien sûr, de l’équipe de sécurité, tous ceux qui sont directement impliqués, participent à cette réunion.

Et c’est définitivement éducatif. La réunion est parfois agréable et d’autres fois franchement moins agréable. En effet, nous prenons cela très au sérieux et, si nous constatons un problème à résoudre, des comportements à changer, tout ce que nous devons faire différemment techniquement pour obtenir les résultats souhaités, nous abordons ouvertement ce sujet lors de la réunion. D’après moi, nous envoyons ainsi également un signal culturel indiquant que nous prenons cette question très au sérieux. Cela nous aide donc techniquement à nous améliorer. Je pense qu’il est également important sur le plan culturel de renforcer le fait que la sécurité est toujours la tâche zéro au sein d’Amazon.

Clarke Rodgers (10:13):
Dans cette veine, qu’en est-il des dirigeants de vos différents secteurs d’activité ? Comment les responsabilisez-vous en matière de sécurité de leur service spécifique ou de toute autre activité qu’ils gèrent au sein d’AWS ?

Adam Selipsky (10:24)
Eh bien, en général, ils assument leurs responsabilités. Nous en sommes arrivés là grâce à la culture que nous avons développée autour de cette question, ce qui est de loin une meilleure approche qu’un tiers essayant lui-même de les responsabiliser. Je pense donc qu’avec la culture que nous avons développée autour de la sécurité, avec le modèle de propriété clair que nous avons établi, qui n’est pas un élément supplémentaire mais fait bien partie de leur travail quotidien. Et grâce à des mécanismes tels que la réunion de sécurité hebdomadaire, à laquelle ils assistent bien sûr, si c’est leur équipe qui a un problème cette semaine-là, de nombreuses forces les incitent à se responsabiliser. C’est vraiment beaucoup plus facile, beaucoup mieux ainsi.

Il est important de disposer d’une équipe de sécurité centralisée. Ce sont eux les véritables experts en matière de sécurité dans tous les domaines. Ils peuvent examiner les bonnes pratiques de toutes nos équipes. Si nous pensons qu’un point de sécurité doit être appliqué différemment au sein d’une équipe donnée, ce sont eux qui peuvent parler aux dirigeants de cette équipe, qu’il s’agisse de responsables techniques ou commerciaux. Selon moi, c’est bien la combinaison de ces multiples mécanismes qui permet de vraiment responsabiliser cette équipe.

Dans les rares cas où un problème survient avec une équipe, il devient immédiatement évident que nous attendons de cette équipe qu’elle comprenne le problème et qu’elle y remédie. Bien entendu, elle obtiendra l’aide de la personne qui peut lui en fournir, mais le problème lui appartient.

Un certain nombre d’agences gouvernementales, y compris des membres éminents de la communauté du renseignement du gouvernement américain, ont déclaré publiquement qu’AWS offrait une meilleure sécurité que celle qu’ils offraient dans leurs propres centres de données. Et encore une fois, de nombreuses personnes, y compris de grandes entreprises, des banques, des sociétés pharmaceutiques, etc., en ont pris note. Donc, comme vous aviez de gros clients qui disaient : « C’est un excellent modèle de sécurité, nous allons confier ces fonctions à AWS ». Je pense que beaucoup d’autres entreprises l’ont remarqué.

Clarke Rodgers (11:53):
Le fait que les dirigeants des différents secteurs s’approprient la sécurité, les fonctionnalités du produit qu’ils développent et les résultats financiers est très important, n’est-ce pas ? Beaucoup de nos clients ont séparé ces responsabilités, ce qui pose parfois problème, alors que cette approche de propriété unique apporte des avantages fantastiques.

Adam, merci beaucoup d’avoir pris le temps de me rencontrer aujourd’hui malgré votre journée bien remplie.

Adam Selipsky (12:16):
C’est un plaisir. Merci.