Avec les modèles et pratiques modernes de DevOps et DevSecOps, il n’est plus clair qui sont les propriétaires de première ligne. Aujourd’hui, les processus d’audit interne de la plupart des organisations sont très laborieux et peu efficaces.
C’est quelque chose que John Willis, dans son nouveau rôle de chercheur émérite à Kosli, a appelé dans des présentations précédentes « Théâtre de la sécurité et de la conformité ».
C’est un sujet qu’il a déjà abordé avec Dan Lines sur le podcast Dev Interrupted, également présenté sur Développeurweb.com.
Dans cette conférence, filmée à Explorer DevOps, la sécurité, la conformité des audits et prospérer à l’ère numérique, John se penche sur DevSecOps et sur ce à quoi ressemblera une gouvernance efficace alors que la réglementation et l’automatisation continuent d’avoir des impacts concurrents sur la manière dont les logiciels sont livrés.
Il demandera comment nous en sommes arrivés à la passe actuelle avec des références à des risques bien connus et à des défaillances de conformité chez Equifax, Knight Capital, Capital One et Solar Winds.
Transcription complète
Donc, si vous repensez à mon évolution en essayant d’amener les gens à changer leur façon de penser à ce que nous faisons en matière de sécurité d’un point de vue DevOps, l’histoire d’Abraham Wald, vous l’avez probablement entendue ; vous ne l’avez tout simplement pas entendu avec son nom.
Ainsi, pendant la Seconde Guerre mondiale, il y avait un groupe de mathématiciens et de statisticiens dont le travail consistait à déterminer comment répartir le poids et réparer les avions de chasse qui revenaient avec des impacts de balles. Cet Abraham Wald s’est un jour réveillé et a dit — et c’est vraiment la définition du biais de survie — « Attendez une minute, nous réparons les avions là où se trouvent les impacts de balles ? Ce sont eux qui reviennent. Nous devrions réparer les avions là où il n’y a pas d’impacts de balles parce que ce sont eux qui ne reviennent pas.
Je pense que c’est une excellente métaphore de la façon dont nous pensons à la sécurité : peut-être cherchons-nous au mauvais endroit. Et donc j’ai posé cette méta-question il y a environ trois ou quatre ans, ce qui, je l’espère, vous fait un peu mal au cerveau, mais à la manière d’Abraham Wald – qui était « Et si DevSecOps arrivait avant DevOps? »
Eh bien, le monde serait différent. Parce que si vous y réfléchissez – je suis pro-DevSecOps, et je pense que tout le monde devrait avoir une bonne architecture de référence DevSecOps – en gros, ce qui s’est passé, c’est que nous avons fait tout ce travail DevOps, puis nous avons mis une couche de sécurité dessus, et c’est bon, c’est nécessaire. Mais peut-être que nous avions déjà ce parti pris des impacts de balles quand nous y pensions.
Et si on commençait par la sécurité ? Que se passerait-il si un agent de sécurité disait : « J’ai une excellente façon d’assurer la sécurité. Je vais l’appeler DevSecOps ! et nous avons commencé dans cet ordre? Les choses pourraient-elles être différentes ? Penserions-nous différemment, ou n’avons-nous pas pensé différemment ? Alors Shannon Lietz, qui est l’un de mes mentors – elle a écrit le Manifeste DevSecOps – a inventé le terme « tout le monde est responsable de la sécurité ».
On parlait à la pause de ces trois lignes de défense. Donc, je ne viens pas d’un milieu d’auditeur. Tout ce que je sais, c’est que j’ai été amené dans toutes ces entreprises et qu’elles me demandaient : « Hey John, regarde notre architecture de référence DevSecOps ! » Et je disais, « Eh bien, c’est génial », puis nous avions une conversation.
« Oui, nous achetons le modèle des trois lignes de défense. »
« Euh, ouais, celui-là n’est pas si génial! »
Parce qu’Andrew Clay Shafer, dans les premiers jours de DevOps, pré-DevSecOps, a fait ce beau personnage de ce qui décrivait le problème de l’énoncé original du problème DevOps. Il y avait un mur de confusion – et certains d’entre vous ont l’air d’être presque aussi vieux que moi – mais il fut un jour où les développeurs jetaient leur code par-dessus le mur, et les opérations l’attrapaient et disaient : « Ça ne fonctionne pas ! » Et l’autre partie disait : « Non, tu l’as cassé ; Ça marche!
Et cela durait des semaines et des semaines et des semaines, et Andrew parlait de trouver un moyen de briser ce mur. Et il y avait quelques-uns des DevOps originaux, ces belles histoires de développeurs travaillant ensemble en collaboration, et il y a toute une industrie qui en a été construite.
Ainsi, il y a éclatement du mur, et cela devient une métaphore pour tous les groupes non collaboratifs dans une organisation. Et donc, quand je pensais à quel était l’énoncé du problème qui a conduit DevOps, où en sommes-nous maintenant avec l’énoncé du problème de ce qui se passe dans une grande organisation entre la première ligne, la deuxième ligne et la troisième ligne ? La façon dont je le vois quand j’ai ces conversations, la deuxième ligne est, par définition, un tampon pour la troisième ligne.
La deuxième ligne n’a aucun moyen de communiquer avec la première. Et voici à quoi ressemblaient « dev » et « ops » il y a 15 ans. Nous n’avions pas les outils. Nous n’avions même pas la cartographie cognitive pour avoir ces discussions. Nous ne savions même pas que nous devrions avoir ces préoccupations. Dans Investments Unlimited, nous avons une brève description de la façon dont je ne vais pas aller à l’Institute of Internal Auditors et dire : « Hé, je suis John Willis ; vous n’avez jamais entendu parler de moi; débarrassez-vous de trois lignes de défense !
Ça n’arrive pas. Mais ce que je vais dire, c’est que, tout comme nous faisons une séparation, pouvons-nous recadrer – et nous l’avons fait un peu dans le livre – la conversation sur la façon dont nous pensons à cela ? Pourquoi ne pouvons-nous pas créer ce DSL dont j’ai parlé, où la deuxième ligne peut répondre à la première ligne dans les exigences des concepteurs ?
Et voici le kicker, non ? Je ne prétends pas être un génie de toutes choses. Mais ce que je sais, c’est que dans chaque banque et chaque entreprise dans laquelle je suis entré, à quoi sert cette deuxième ligne ? Ils s’assurent essentiellement qu’ils font le travail qu’ils doivent faire. Quel est le travail qu’ils doivent faire? Protégez la marque.
C’est ça, non ? Tout repose sur la protection de la marque. Lorsque vous êtes Equifax et que vous perdez une capitalisation boursière de 5 milliards de dollars en une journée, ou que vous êtes une autre société appelée Knight Capital qui était la deuxième plus grande société de trading à haute fréquence sur le NYSE, ils ont perdu 440 millions de dollars en 45 minutes et ont été en faillite en 24 heures. C’est ce qu’ils sont censés faire.
Et notre relation consiste maintenant à leur cacher des choses. Cela doit changer. Et c’est pourquoi nous entrons dans des sociétés comme Equifax, Ignite Capital et Capital One. Donc que fais-tu?
J’ai eu cette idée quand j’ai commencé à penser à la sécurité. Avez-vous déjà été au RSA ? Vous entrez dans le hall d’exposition du RSA et vous vous dites : « Je dois sortir d’ici ! » Il y a trop de lumières et trop de vendeurs ; c’est tout simplement trop déroutant. Il était presque impossible de trouver une taxonomie pour la sécurité car il y a tellement de façons d’en discuter et de la regarder. Alors, j’ai commencé à réfléchir à comment faire simple.
Pourrais-je l’inventer ? Et comme je le dis toujours – et je continuerai à le dire jusqu’à ce que je sois frappé au visage pour l’avoir dit – un monde post-cloud natif ou utilisant le cloud natif comme marqueur pour simplifier la conversation. Je ne veux pas dire que la sécurité n’existe pas pour l’héritage dans les mainframes ; c’est certainement le cas. Mais nous pourrions avoir une conversation plus simple si nous supposions simplement qu’il y avait une ligne où nous pourrions dire que tout ce qui se trouve à droite est natif du cloud.
Et donc avec ça, je vais vous dire que ce que nous devons faire et ce que nous faisons, sont incohérents. Ce que nous devons faire ou ce que nous faisons, c’est comment prouver que nous sommes en sécurité lorsque nous avons une forme de service d’audit généralement subjectif de nos dossiers qui raconte des histoires sur des choses qui pourraient conduire à des sérigraphies ?
Et ensuite, comment démontrer que nous avons une mauvaise deuxième ligne dans nos auditeurs internes ou externes, essayer de comprendre quelles sont toutes ces descriptions subjectives, et nous devons faire les deux. Nous devons donc être en mesure de créer un système qui puisse prouver que nous sommes en sécurité et être très cohérent avec ce que nous démontrons. Et c’est tout l’intérêt de quelque chose comme Kosli ou, juste en général, cette idée de données immuables et signées numériquement qui représentent ce que nous disons que nous faisons.
Ainsi, l’audit n’est pas une conversation subjective de 40 jours, c’est un regard d’une seconde sur le SHA, et nous avons terminé. Nous passons donc de modèles de sécurité implicites à des modèles de preuve explicites, et nous changeons de subjectif à objectif puis vérifiable. Revenons au modèle natif du cloud, si vous pouvez accepter qu’il existe un monde post-natif du cloud, alors je peux vous dire que je peux vous donner une taxonomie simple pour penser à la sécurité et ne pas avoir à y penser en 40 horizontales et 50 voies verticales.
J’ai travaillé avec quelques groupes, et j’ai commencé à entendre ces RSSI, et j’ai dit : « Je ne veux pas appeler cela une taxonomie, mais nous pouvons considérer cela comme une défense contre le risque et la confiance, et nous pouvons le considérer comme une transition du subjectif, à l’objectif, au vérifiable.
Nous avons donc évoqué dans la dernière présentation en 20 minutes le risque d’un changement au niveau de l’attestation. Je n’ai pas parlé de vérification continue, mais il existe des produits vraiment intéressants qui essaient essentiellement d’utiliser des outils de type singe du chaos pour aller au-delà de la simple rupture de choses, par exemple, ce port ne devrait jamais être ouvert… ouvrons simplement le port.
Si cette vulnérabilité n’aurait jamais dû traverser le pipeline, lançons une application qui a cette vulnérabilité, n’est-ce pas ? Il y a donc une vérification continue vraiment intéressante. Je vais dépenser un peu plus pour ça. Mais ensuite, en défense, ce sont les enjeux de table que vous détectez et répondez par Azure et tout ça.
Et puis tout le monde essaie essentiellement de construire un lac de données en ce moment, un cyber lac de données. C’est la chose branchée à faire. Je ne m’en moque pas, c’est nécessaire, mais il n’y a pas de véritable processus de réflexion sur la façon dont vous construisez un cyber lac de données qui n’est pas qu’un tas de bric-à-brac. Il y a donc quelques fournisseurs et projets qui réfléchissent à « Pouvons-nous normaliser les données et les ingérer comme si elles sortaient du fournisseur ? »
Ainsi, par exemple, vous prenez un message qui peut provenir d’Amazon, le même message peut provenir de Google Cloud et peut provenir d’Oracle, et cela peut être la même chose, comme des privilèges accrus. Mais le message est complètement différent;…