Définition du rôle des Distinguished Engineers

Clarke Rodgers (00:11) :
Paul, merci beaucoup d'être ici aujourd'hui.

Paul Vixie (00:13) :
Je suis ravi d'être ici.

Clarke Rodgers (00:15) :
Voudriez-vous, s’il vous plaît, nous parler un peu de votre parcours ? C'est l'illustre innovateur et leader d'opinion qui a contribué, dans une certaine mesure, à l'invention d'Internet dans le domaine du DNS. J’aimerais que vous nous parliez de ça.

Paul Vixie (00:30) :
J'ai joué un rôle précoce, mais je ne suis pas Al Gore, je ne l'ai pas inventé. Et concernant le DNS, j'ai commencé par essayer d’arranger les choses pour moi-même. Je travaillais dans une entreprise de mini-ordinateurs à la fin des années 1980. Le logiciel était nul et le protocole n'était pas très bien compris. Donc c'était de l’autodéfense, puis plus tard, c'est resté et j'ai créé une entreprise pour le maintenir. Et quand j'ai quitté cette entreprise, j'ai créé une start-up dans le domaine de la sécurité.

Au cours de tout cela, j'ai été intronisé au Hall of Fame d'internet et j'ai obtenu un doctorat à Keio, à l'université de Keio au Japon, ce qui est une étrange façon de finir puisque tout a commencé par un abandon du lycée en 1980.

Clarke Rodgers (01:18) :
Impressionnant. Voyons cela un peu plus en détail. Qu'est-ce qui a provoqué l'abandon des études secondaires, puis le changement de cap vers l'espace technologique ?

Paul Vixie (01:28) :
À l'époque, je faisais des petits boulots à temps partiel dans le domaine des mini-ordinateurs. Donc, quand mon conseiller d'orientation m'a dit : « Oui, tu vas redoubler l'année prochaine », c'est parce que j'avais passé tout mon temps dans le laboratoire informatique.

Clarke Rodgers (01:43) :
Impressionnant.

Paul Vixie (01:44) :
Alors, je me suis rendu compte que cela n'allait probablement pas s'améliorer et que je devais simplement passer à autre chose. Plus tard, j'ai quitté ce poste, comme nous le faisons tous inévitablement à cet âge. Mais oui, tout cela était dû au fait que j'étais un mauvais élève parce que je passais trop de temps à programmer.

Clarke Rodgers (02:00) :
Eh bien, ça a plutôt bien marché pour vous finalement.

Paul Vixie (02:03) :
Je suis ravi de toutes les décisions étranges qui ont été prises.

Clarke Rodgers (02:08) :
Voudriez-vous, s’il vous plaît, m'en dire un peu plus sur votre rôle chez AWS ?

Paul Vixie (02:13) :
En fait j'ai deux rôles, peut-être trois. J'ai été embauché en tant que vice-président et Distinguished Engineer, ce qui représente un très petit groupe de personnes très expérimentées. Ce rôle est donc en très grande partie autogéré. Pour être vice-président et Distinguished Engineer, la description de votre poste consiste à trouver les problèmes et à vous y intéresser. Il est très rare que quelqu'un me dise « Paul, nous avons vraiment besoin que tu fasses telle ou telle chose ». C'est donc un immense honneur, dans une entreprise de cette taille, d'être libre, surtout vingt-cinq ans après sa création, sans savoir comment nous en sommes arrivés là. Cela a donc été énorme.

Au cours de l'été, j'ai été nommé adjoint RSSI d'AWS et, par coïncidence, on m’a demandé de diriger le Bureau du RSSI. Vous pouvez considérer qu’au Bureau du RSSI ce sont des architectes de solutions de niveau C. S'il y a une conversation avec le client au cours de laquelle une personne de son niveau C doit être présente, nous souhaitons normalement que notre RSSI soit présent dans la pièce. Le problème, c'est que nous n'avons qu'un seul RSSI et que nous avons beaucoup de salles, nous sommes donc en quelque sorte la bande de secours du RSSI, soit une demi-douzaine de personnes qui sont absolument au sommet de leur art. Et j'ai travaillé avec eux, en fait, je me suis intégré à eux afin d'entrer en contact avec les clients. Et je pense que c'est pour cela que j'ai été choisi pour diriger cette équipe.

Clarke Rodgers (03:44) :
Y a-t-il quelque chose qui vous a vraiment attiré vers AWS ?

Paul Vixie (03:47) :
C'était la description du poste. En d'autres termes, si on m'avait demandé de venir ici et d'être vice-président d'un domaine ou d'un autre et d’être responsable d'une certaine fonction, j'aurais répondu : « Oui, je suis passé par là, je l'ai déjà fait ». Mais il s'agit avant tout d'un poste technologique, du moins la partie Distinguished Engineer de mon travail correspond essentiellement à un contributeur individuel au niveau de la direction. Et pour comprendre pourquoi c'était passionnant, la dernière fois qu’il y avait eu le mot « ingénieur » dans mon titre, c'était aussi la dernière fois que quelqu'un d'autre que moi m'avait écrit une lettre d'offre, et cela s'est terminé en 1993. J’ai donc seulement été PDG de start-ups et oui, j'ai toujours été un PDG qui codait, mais je ne suis toujours pas vraiment un ingénieur professionnel. Ça n’a jamais été mon travail principal dans aucune de mes entreprises.

C'était donc très flatteur de pouvoir revenir à la piste originale que j'aurais empruntée sans toutes ces start-ups, et d'être simplement un ingénieur contributeur individuel. Je ne pensais pas pouvoir encore le faire. Ils ont dû me convaincre, en quelque sorte. Mais une fois qu'ils ont décrit le poste, c’est resté au fond de mon cerveau, ça tournait en boucle et ça me disait « Oui, tu veux vraiment y revenir ». Donc, je ne savais pas. Je ne savais pas que j'étais employable parce que je suis une personnalité publique mineure dans les secteurs d’internet et de la sécurité, et que je suis connu pour être un peu un lanceur de bombes. Je me considérais donc comme trop controversé pour ce poste. Ils ont pensé le contraire. Jusqu'à présent, ils ont eu raison.

Clarke Rodgers (05:22) :
Donc, vous êtes ici depuis un moment maintenant. Vous avez pu observer, en quelque sorte. Quelles ont été vos impressions sur la culture de la sécurité chez AWS ?

Paul Vixie (05:32) :
Dans mes différentes start-ups, j'ai vendu à des entreprises comme celle-ci. La gouvernance d'entreprise est à peu près la même partout, sauf qu'ici, l'équipe de sécurité est là depuis si longtemps que nous affirmons à juste titre que la sécurité est un emploi primordial, et ce n'est pas qu'une simple affirmation. Cela se reflète tout au long de l'organigramme, de haut en bas dans les plans opérationnels, de haut en bas dans les priorités budgétaires.

En d'autres termes, bien sûr, nous sommes là pour répondre aux besoins des clients comme, nous l’espérons, toutes les entreprises sont là pour leurs clients. La différence, c'est que nous ne ferons rien pour nos clients qui puisse également les mettre en danger. Nous ne laissons jamais de côté la sécurité. C'est ce qui est différent ici.

Clarke Rodgers (06:20) :
Donc, lorsque vous travaillez en profondeur avec une équipe de service, par exemple dans le cadre de ce rôle de Distinguished Engineer, pouvez-vous nous donner un aperçu des coulisses de la question de savoir s'il y a un conflit entre la publication d'une fonctionnalité et un correctif de sécurité ? Ou est-ce simplement « Non, il y a un correctif de sécurité qui doit être appliqué ». À quoi ressemblent ces discussions ?

Paul Vixie (06:42) :
Nous ne recevons aucune plainte du type « Bon sang, si vous bloquez ce lancement à cause des résultats des tests de sécurité d'une application, etc., il sera trop tard pour nous. Nous allons rater notre fenêtre, et c'est déjà en cours. » Cela n'arrive pas. C’est délibérément et explicitement interdit. Ce que nous avons parfois, c’est lorsque c'est vraiment « à faire » mais pas « absolument à faire », où moi-même ou quelqu'un d'autre représentant AWS Security disons : « Cela va provoquer des problèmes et ce sera beaucoup plus coûteux de le réparer plus tard ». Les équipes de service ici disposent d'une autonomie à ce niveau.

Ils peuvent décider de ce qui est important, mais ils savent que s'il y a un problème de sécurité, le fait que nous leur en parlions sera consigné. Ils vont avoir quelques explications à donner. Et donc oui, il y a parfois des tensions parce que, évidemment, tout le monde a un patron et si le patron dit qu'il y a une date limite à respecter, alors vous vous y mettez, et nous sommes sensibles à cela. Nous ne voulons pas aggraver quoi que ce soit. Mais nous comprenons que les personnes avec lesquelles nous travaillons ont pour objectif premier d'atteindre leurs objectifs et que nous sommes la deuxième directive principale.

Clarke Rodgers (08:09) :
Passons donc à votre autre travail quotidien, qui consiste à diriger le Bureau du RSSI. Vous êtes donc très proche de nos clients et vous interagissez avec eux dans le monde entier, que ce soit en personne ou de manière virtuelle. L'un des programmes auxquels vous avez participé chez AWS, ce sont les AWS CISO Circles. Pourriez-vous nous en dire un peu plus à ce sujet et sur votre expérience ?

Paul Vixie (08:30) :
Mon introduction aux CISO Circles a été la suivante : « Eh bien, Paul, pourrais-tu aller à... » — c'était Madrid en l'occurrence — « et participer à un CISO Circle ? » J'ai donc dû demander « Qu'est-ce que c'est » et à quoi ressemblerait ma participation ? Je n'étais ici que depuis un an à l'époque. Il se pourrait que cela nécessite quelqu'un avec une plus grande expertise que celle que j’ai actuellement, sur ce que nous sommes et sur la façon dont nous en sommes arrivés là. J'y suis allé et c'était formidable parce que nous avions réuni un groupe de RSSI d'un secteur en particulier. Et le tout est régi par un accord de confidentialité, vous pouvez donc parler librement parce que les autres personnes présentes dans la salle ne répéteront pas ce que vous avez dit.

Clarke Rodgers (09:20) :
La règle de Chatham House.

Paul Vixie (09:21) :
Les règles de Chatham House qui sont, dans certains cas, les concurrents. Ce sont des RSSI d'entreprises du même secteur ou de la même région, et ils ne partagent normalement pas d'idées ni d'expériences. Mais parce qu'ils étaient chez nous et que nous étions là, nous étions en quelque sorte en train de modérer et d'amorcer la discussion par des présentations sur divers aspects de la technologie, puis nous avons encouragé la discussion, encouragé les défis, encouragé, en fin de compte, ce qui s'est avéré être un débat entre eux.

C'était magnifique à voir, car c'est l'une des choses que toutes les moyennes et grandes entreprises devraient être en mesure de faire, bénéficier de l'expérience de leurs concurrents. Et nous ne devrions pas essayer d’entrer en rivalité au sujet de qui offre le plus de sécurité, car si vous et moi travaillons dans le même secteur et que vous vous faites exploser, ça me fait toujours mal et ça signifie probablement que je serais le suivant. Alors, de cette façon...

Clarke Rodgers (10:24) :
Le partage d’informations et de bonnes pratiques...

Paul Vixie (10:26) :
Oui, nous devons être solidaires dans certains domaines, tout en étant compétitifs dans d'autres. Et ils ont fini par apprendre à se connaître, à déterminer le degré de confiance qu'ils pouvaient s’accorder sans risquer les secrets de leur entreprise, etc. Et l'objectif c’est qu'ils restent en contact les uns avec les autres après l'événement. Et bien sûr, cela signifie inévitablement que quelqu'un dira « Oh, j'ai eu une expérience horrible avec une API dans le cloud ce jour-là », et quelqu'un d'autre répondra « Eh bien, ça fonctionne pour moi », et s'ils finissent par se plaindre les uns aux autres de nous, eh bien, si cela arrive, nous devrons également l’accepter.

Nous ne serons pas en mesure de mieux servir nos clients si nous ignorons ce qui ne va pas. Il s'agit donc d'une énorme source de renseignements commerciaux pour nous. « Oh, j'aimerais avoir... » et parfois vous pouvez dire « En fait, ça existe ». Nous sommes une très grande entreprise, nous innovons beaucoup et nous créons de nouvelles fonctionnalités ou de nouvelles technologies à un rythme qu'aucun client ne pourrait suivre. Je veux dire, c'est mon travail de le faire, et j'ai du mal à suivre le rythme.

Nous avons donc besoin d'une interface client où quelqu'un sait quels sont les problèmes des clients et quels sont les problèmes du secteur, ce qu'ils font, comment ils s'y prennent, quels sont leurs points faibles. Il s'avère que nous avons des personnes qui le font et que les clients ne savent pas qu'ils devraient prendre le temps de les rencontrer régulièrement. Et si le CISO Circle y contribue, alors j'espère que cela se répandra par le bouche à oreille et que cela deviendra un mouvement.

Clarke Rodgers (11:59) :
Fantastique. Paul, merci beaucoup de vous être joint à moi aujourd’hui.

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