Introduction au podcast Beyond the Edge d’Edgio Episode 4 : DevSecOps : Shift Left pour éviter de changer votre feuille de route produit à droite animé par Lauren Bradley, Global Campaign Manager chez Edgio.
Lauren Bradley : Bonjour, et bienvenue à Beyond the Edge, où nous explorons les tenants et aboutissants des entreprises numériques modernes. Je suis Lauren Bradley, votre co-pilote pour cet épisode, et aujourd’hui, nous allons explorer le sujet du changement à gauche, en particulier comment la culture et la technologie changent à mesure que les applications Web et la protection des API deviennent une partie native et inhérente de votre cycle de vie DevOps.
Commençons par une statistique choquante du Ponemon Institute. Aujourd’hui, il faut plus, la plupart des entreprises, plus de 200 jours pour même détecter une violation. Si vous ne détectez pas une violation assez rapidement, cela va vous coûter cher. IBM a constaté que le coût des bogues corrigés détectés lors de la phase de test peut être 15 fois plus élevé que ceux détectés lors de la conception.
Donc, pour le dire simplement, plus vous attendez pour attraper un problème, plus cela vous coûtera. Et, nous ne parlons pas seulement d’argent, le retravail, le temps et l’énergie qui peuvent finalement faire reculer les feuilles de route des produits. Alors, comment pouvez-vous changer efficacement de direction à gauche et éviter de gaspiller des ressources précieuses et de bloquer vos progrès ?
Nous accueillons aujourd’hui Michael Grimshaw, directeur de l’ingénierie des plateformes d’Edgio, et Richard Yew, directeur principal de la gestion des produits pour la plateforme de sécurité d’Edgio. Bienvenue, Michael et Richard. C’est génial de vous avoir dessus.
Michael Grimshaw : Merci, Lauren. Super d’être ici. Merci.
Lauren Bradley : pouvez-vous me parler un peu de vous-même et de vos premières réflexions sur ce sujet ? Mike, nous allons commencer par toi.
Michael Grimshaw : tout à fait. Tout d’abord, laissez-moi commencer par remercier, vous remercier Lauren, pour avoir un tel intérêt. Dans ce sujet très important et, et vous creusez et intensifiez et les conversations que nous avons eu et avons autour de cela, y compris cette année ici, est juste un inestimable et impératif pour le travail que nous faisons dans l’industrie.
Michael Grimshaw : cette compréhension doit être partagée de loin et, et vraiment apprécier l’intérêt. Je m’appelle Michael Grimshaw. Je suis le directeur de l’ingénierie des plateformes chez Edgio. Pour ceux d’entre vous qui ne sont pas familiers avec, ou super familiers avec la plateforme en termes industriels, il s’agit vraiment de penser en termes d’unification de vos applications et de votre infrastructure en unités cohérentes.
Et, je viens à la plateforme avec une solide expérience en sécurité, et c’est un domaine qui me passionne beaucoup parce que cela déplace l’aiguille d’une telle manière, en ce qui concerne la sécurité, en ce qui concerne la rentabilité, et tant de domaines qui sont si importants pour notre industrie.
Et je peux continuer à faire le tour de DevSecOps, mais laissez-moi le remettre à Richard pour son intro.
Richard Yew : Merci beaucoup, Michael. Oui. Oui. C’est un sujet très important. C’est très proche et cher dans mon cœur parce que j’ai personnellement vécu tout le processus du cycle de vie du développement logiciel ainsi que de les traduire dans l’entreprise.
Maintenant, en parlant de ce que je fais… Évidemment, comme Lauren l’a mentionné, je dirige nos organisations de gestion des produits de sécurité chez Edgio. Donc, ma vie quotidienne implique de travailler avec l’équipe de R&D, l’équipe d’ingénierie pour s’assurer que nous apportons de la valeur à nos clients. Et, vous savez, tout ce qui inclut évidemment comme optimiser notre pratique de développement, notre sécurité, ci CD pratique. pour nous assurer que nous sommes réellement en mesure de livrer des produits sécurisés.
Exact. Cela apporte de la valeur à nos clients, les livre dans les délais, les budgets et garantit que nous offrons une expérience exceptionnelle à nos clients. Donc, mon objectif ici est de vraiment regarder le DevSecOps dans son ensemble, vous savez, du point de vue des personnes – le processus par opposition à la technologie et comment nous pouvons réellement mettre en œuvre les meilleures pratiques, pour le secteur.
Qu’est-ce que DevSecOps ?
Michael Grimshaw : à ton avis, Richard, laisse-moi voler la balle là-bas, si ça ne te dérange pas.
Et je pense juste que nous allons normaliser ce que nous entendons par DevSecOps et décaler à gauche, non? Il y avait Gartner, voici les choses pour certaines personnes qui écoutent sur ce DevSecOps, et les termes shift left, shift right, etc. Pourraient sembler relativement nouveaux. Ce n’est pas nouveau, vous savez, ce n’est pas comme, Oh, la dernière chose la plus chaude qui vient de frapper il y a un an.
Non, cela fait de la cuisson dans l’industrie depuis un bon moment. Et en fait, Gartner avait un rapport de 2017 sur le cycle de vie DevSecOps. C’était juste une extension du DevOps, la tendance DevOps dans l’industrie, juste s’étendant pour inclure la sécurité dans infosec dans la boucle de rétroaction et votre cycle de vie de développement logiciel.
Et donc, comme je l’ai dit, Gartner écrivait sur ce sujet, en 2017, et cela avait déjà été un processus et un mouvement dans l’industrie. Pendant un bon moment avant cela. Donc, ce ne sont pas des concepts tout nouveaux. C’est juste une extension de ce sur quoi nous travaillons depuis des années. Et en fait, ce que DevSecOps est, c’est qu’il prend le modèle similaire, de DevOps en ce sens que vous avez un côté développement et vraiment un côté opération.
Et au cœur, il intègre tous vos besoins de sécurité dès que possible, je veux dire, dès le début de la conception, construisez le processus entier jusqu’à ce que vos développeurs sur le vaisseau gauche soient du côté du développement, excusez-moi, le déplacement vers la droite est plus du côté de l’observabilité des opérations. Nous allons nous concentrer sur le décalage à gauche ici aujourd’hui, mais il est fondamentalement cuit dans vos tests de vos scans, et votre validation, aussi tôt que possible à gauche. Et aussi tôt que possible dans le cycle de vie de développement de votre SDLC. Ainsi, par exemple, une des choses dont il parle, et encore une fois, cela remonte à plus de sept ans, c’est des choses comme avoir la sécurité, scanner et scanner vos, vous savez, vos bibliothèques tierces open source, dépôts, base de code, ainsi que le code que vous écrivez, la conception, l’architecture, les neuf mètres entiers, et la préparation de tout cela dès le début. Et l’un des exemples que j’ai donnés est la construction et l’analyse de sécurité dans les IDE mêmes que vos développeurs utilisent. Ce n’est qu’un exemple, et il y en a beaucoup.
Pour qu’ils écrivent leur code, ils reçoivent un retour immédiat. Oh, je viens de laisser la porte ouverte à, vous savez, le bourrage d’informations d’identification ou l’injection de suite, et ils obtiennent juste comme une erreur de syntaxe, ils obtiennent une erreur de sécurité juste là est l’écriture du code. Donc, ils peuvent immédiatement corriger cela, afin qu’ils n’aient pas de client se plaignant que le client ou l’utilisateur final soit mis en gage, vous savez, un mois plus tard, non, c’est géré juste là.
Le moins cher, le plus rapide, le plus facile au début. Richard, tu allais dire quelque chose.
Pourquoi le déplacement à gauche est-il si important en matière de coûts ?
Richard Yew : Oh, oui. Oui. Comme je pense que le coût est en fait très important de parler, vous savez, Eh bien, tout le monde connaît beaucoup de coûts d’exploitation, vous savez, toutes les organisations, c’est comme le développement, n’est-ce pas? Le processus de R&D.
Donc, quand il s’agit de coût, c’est pourquoi le déplacement à gauche est plus important, non? Parce que nous mettons beaucoup d’efforts et parlons du pourquoi, vous savez, je suis sûr que nous allons aborder le « comment » plus tard, mais nous voulons nous rendre compte de la raison pour laquelle c’est si important parce que, vous savez, nous avons des données.
Oui. Cela, selon nos recherches, montre que vous savez, si vous corrigez une vulnérabilité de sécurité qui a été trouvée après la publication de votre code et les productions coûtent 15 fois plus cher que vous ne le savez lorsqu’elle est trouvée dans une phase de conception lorsque vous faites le montage de menaces. Évidemment, nous ne disons pas que vous savez, la phase initiale de l’effort de développement permettrait de capturer complètement toutes les vulnérabilités de sécurité.
C’est pourquoi nous devons mettre en place une défense en profondeur. Mais il est très important que vous sachiez, en regardant les huit phases, que vous connaissiez, en général, les cycles de la dette, les cycles de vie de, vous savez, planifier, coder, construire, tester, tout le chemin pour aimer surveiller et fonctionner. Exact. Vous les regardez plus vous allez à droite, vous savez, comme quand vous trouvez une faille de sécurité, plus cela va coûter cher, vous savez.
Pour que vos organisations résolvent réellement le problème. Donc, nous parlons de la différence entre, vous savez, trouver une vulnérabilité sur un scan qui se produit après que vous ayez déjà publié un tas de codes pour les productions et dire, vous savez, comme effectuer une tâche dynamique de sécurité des applications dans l’environnement de préparation pour la détecter rapidement avant d’envoyer ce code aux productions, n’est-ce pas ?
Richard Yew : vous pourriez être en mesure de résoudre ces problèmes, ou vous implémentez une sorte de correctif virtuel juste à l’avance avant de publier une réduction de code pour atténuer cela. Mais, encore une fois, il est très important de comprendre que la sécurité doit être intégrée dès la première étape du processus, avant même de commencer à écrire le code avant de mettre quoi que ce soit dans votre IDE et de commencer à penser à faire de la modélisation des menaces. Hé, quelle partie de la conception pourrait potentiellement être susceptible d’exploitation ?
Implications quotidiennes pour les équipes DevOps et sécurité
Lauren Bradley : Oui, et ce sont de très bons points, vous les gars. Je veux dire, du point de vue de l’utilisateur, qu’est-ce que, en dehors des coûts, financièrement, cela peut signifier pour un DevOps ou une équipe de sécurité d’expérimenter au quotidien s’ils ne mettent pas en œuvre cela dès le départ ?
Et je veux également parler de la façon dont nous l’implémentons efficacement dans le cycle de vie DevOps.
Michael Grimshaw : excellente question. Bonne question. Permettez-moi d’être très franc dans ma réponse initiale. Est-ce que tout le monde dans le secteur, chaque PDG, CTO, CFO – tout le monde, ingénieurs, utilisateurs – ce que nous voulons tous est juste une balle magique que nous pouvons faire, ce que nous faisons au quotidien.
Et puis nous avons une balle de sécurité magique que vous actionnez simplement l’interrupteur et tout votre travail est soudainement sécurisé. C’est ce que tout le monde veut, mais ce n’est pas la réalité. C’est-à-dire, vous savez, les gens nous demandent. Je veux leur demander, quel temps fait-il en terre fantastique? J’ai entendu dire que c’était sympa. Ce type d’année est, et si vous approchez votre sécurité, votre infosec, ainsi que votre développement, car ce n’est qu’un boulon sur. Vous savez, « Oh, je vais acheter des outils que je vais boulonner après que nous ayons tout développé, construit et déployé, et cela va continuer et sécuriser tout », vous achetez un presse-papier très cher, pour être honnête avec vous.
Et c’est pourquoi, vous savez, il a été mentionné, il s’agit de personnes, de processus, et outillage. C’est pourquoi la totalité cohérente de cette approche est si importante. Est-ce que vous, nous sommes loin années, décennies, si jamais il a même été possible. Pour être honnête avec vous, nous avons appris beaucoup de leçons de l’idée que vous concevez quelque chose et mettez un outillage de sécurité et vous êtes prêt à partir.
Cela a un impact sur tout, de votre coût à votre vitesse de développement et le coût là-bas pour vos clients. Et, un bon exemple de cela est mon soupçon est, presque tous ceux qui écoutent ce podcast à un moment donné de leur carrière ont été dans une situation où une nouvelle fonctionnalité ou un nouveau service ou quelque chose comme ça, ou même juste un patch et une mise à jour ont été déployés. Tout semble bon. Tout fonctionne bien. Et puis soudain, vous recevez un appel de l’un de vos clients ou infosec recevez un appel de l’un de vos clients. « Nous venons d’être mis en gage », ou « nous venons d’avoir un incident de sécurité », ou quelque chose comme ça. Et la raison est que, OK, vous l’avez déployé, mais peut-être que les analyses n’avaient pas fini de fonctionner, ou vous n’avez pas fait d’analyses, ou vous ne les aviez pas correctement réglées, et vous venez d’introduire une vulnérabilité de sécurité massive.
Peut-être cela vous affecte-t-il, mais plus important encore, cela affecte vos clients. DevSecOps consiste à réaliser tout cela ensemble dans un processus cohérent et à éviter cela. Il s’agit de réduire les coûts. Absolument. S’agit-il d’améliorer les marges ? Oh, dans un grand sens. Mais il s’agit aussi de supprimer la responsabilité de votre entreprise et de celle de vos clients.
Intégrer la sécurité dans DevOps – c’est comme faire un gâteau !
Richard Yew : absolument. Vous savez, parler de, vous savez, parler de cuisson, vous savez, comme Mike a utilisé un tel terme de totalité cohérente. Comme si c’était si vrai. C’est très puissant, c’est un mot très puissant pour montrer pourquoi est-ce important d’avoir cela cuit en place, vous savez, comme je suis connu au sein d’Edgio pour être le gars de l’analogie.
J’aime jeter un tas d’analogie autour et je suis, vous savez, j’ai entendu ça très bien. Des analogies, je pense, serviraient de base solide pour pousser pour les bonnes cultures au sein de toute organisation comme nous le savons tous, en tant que personnes de sécurité, une grande partie de notre travail est l’évangélisation. Il ne s’agit pas seulement de mettre en œuvre les bonnes technologies et de créer un processus, mais aussi de faire beaucoup de marketing interne.
Pour dire aux gens que la sécurité est importante pour l’entreprise, n’est-ce pas ? Parce que, vous savez, en tant que responsables de la sécurité, ce n’est pas seulement comme, c’est comme si les gens pensent souvent à la sécurité, comme ajouter des couches de processus supplémentaires dans votre flux de travail, mais vous savez, la bonne façon de penser est que la sécurité peut accélérer l’entreprise ?
Comment la sécurité peut-elle réellement générer plus de revenus, parce que c’est un bon moyen de justifier une grande partie de la sécurité, vous savez, des implémentations de sécurité supplémentaires que vous devez faire pour assurer la sécurité de l’organisation. Donc, une des analogies que j’ai entendu qui était géniale, c’est que vous savez, la sécurité ne devrait pas être traitée comme une cerise sur le gâteau, vous savez, comment vous cuisinez hors du gâteau et juste mettre tous les glaçages comme une dernière étape, vous savez, c’est généralement ce que font les gens lorsqu’ils n’ont pas de sécurité, de flux de travail ICD, et qu’ils mettent simplement en œuvre des pare-feu et, vous savez, une protection API, quoi qu’il en soit à la dernière phase de la phase de production. Ce que ça devrait être, la sécurité, c’est comme de la farine, tu sais, ça, cela aurait dû être quelque chose depuis le début.
La sécurité est comme de la farine pour faire cuire le gâteau. Et puis quand la sécurité est bien faite, vous ne pouvez pas la voir. Et tout le point de la sécurité est que lorsque c’est fait correctement, il aurait dû être incorporé et ce n’est pas visible. Cela ne devrait pas créer de défis. Cela ne devrait pas ralentir l’organisation.
Comme des analogies que, vous savez, j’aidais à montrer à l’entreprise pourquoi c’est important, c’est qu’avoir un processus de sécurité fort, des cultures technologiques de sécurité, c’est un peu comme avoir des freins forts. Dans une voiture de course, vous savez pourquoi chaque supercar a de gros, vous savez, de très gros freins fantaisie parce qu’ils leur permettent de virer plus vite.
Il leur permet de freiner fort. Ça leur permet d’aller plus vite et de tourner plus fort, non ? Cela leur permet de gagner la course. Donc, avoir des freins forts est aussi important que d’avoir un moteur fort, n’est-ce pas ? C’est ainsi que nous devrions envisager la sécurité sur un plan philosophique. Tu sais, évidemment, on parle beaucoup de niveaux élevés, non ? Donc, nous voulons évidemment, vous savez, un peu plus approfondir cela. L’essentiel du genre, OK, donc tout ça va bien, mais comment allons-nous le mettre en œuvre exactement ?
Michael Grimshaw : Oui. Je pense que c’est un bon appel au freinage. Un freinage puissant vous donne le contrôle. Il y a le courant ou la route que nous avons devant nous est remplie de courbes, de virages en épingle à cheveux, et tout cela, et il y a, bien sûr, des voies droites où vous le posez et vous ne touchez pas aux freins, mais pour naviguer tout, ce, ce frein, je pense, l’amour, j’aime ces deux analogies, Richard, parce que cette analogie de freinage, ça te donne le contrôle, ça te donne un contrôle plus fin du grain quand tu es confronté à des bordures, des défis et des choses inattendues.
Richard Yew : Super appel. Au fait, je veux clarifier, je n’ai pas trouvé cette analogie, c’est de ce gars qui s’appelle le Dr Eric Koh. Il a, et il dirige un excellent podcast. Donc, je recommande à tout le monde d’aller regarder ça. Mais oui, je trouve cela si approprié lorsqu’il s’agit d’expliquer le concept à l’entreprise, surtout avec ceux qui sont nouveaux dans ce genre de concept.
Équipes cloisonnées problématiques et feuilles de route changeantes
Lauren Bradley : Richard, vous parlez de la façon dont vous, vous avez mentionné, vous savez, si, si elle, DevSecOps est terminé, non ? Vous ne le voyez pas. Et évidemment, l’une de ces visibilités flagrantes est le coût. C’est aussi des équipes cloisonnées. On a aussi l’impression qu’il y a une déconnexion entre les équipes quand il y a ces problèmes qui se posent et pourquoi n’ont-ils pas été pris avant?
Quels processus, quelles communications n’ont pas eu lieu pour résoudre ces problèmes rapidement ou efficacement? Donc, ma question pour vous est, vous savez, dans votre expérience, lequel de… Vous savez, il y a, il y a probablement un manque de transparence. Il y a une prise de décision lente, il y a un potentiel de gaspillage des ressources.
Lorsque vous avez des équipes cloisonnées, quels sont les problèmes les plus problématiques lorsque les équipes fonctionnent en silos à votre avis ?
Richard Yew : Oui, je vais prendre celui-ci. Je pense qu’une chose que, vous savez, j’ai personnellement vécue dans ma vie passée, c’est que vous savez, et c’est quand, vous savez, quand nous parlons de produits similaires, vous savez, comme une sorte de planification, il est important que parfois vous ayez une équipe de sécurité qui n’est pas intégrée au sein de la R&D, comme au sein de l’organisation CTO.
Parfois, dans de nombreuses organisations, nous observons des silos entre les équipes de sécurité et l’organisation CTO, et vous constaterez que beaucoup de processus ont été effectués après coup. Ainsi, par exemple, nous nous heurtons à une situation où nous publions beaucoup de produits, publions beaucoup de codes parce qu’il n’y a tout simplement pas un type de collaboration de communication solide entre les équipes de sécurité et les équipes d’ingénierie.
Ce que vous avez fini avec, c’est que, vous savez, une organisation doit être conforme. Parfois, les exemples spécifiques sont que vous avez des équipes qui viennent faire les scans comme une ou deux fois par an. Quel est le résultat de ces scans ? Eh bien, on me dira : « Hé Richard, nous devons ralentir le trimestre prochain parce que nous venons de trouver une centaine de bugs de sécurité différents, gros et petits, vous savez, peut-être, peut-être 20, comme parmi les 20 premiers, il y a la sévérité un et deux et au-dessus, tandis que le reste, vous savez, il s’agit de, vous devez vous concentrer sur la réparation de ces choses. »
Et il y a un SLA au sein de l’organisation pour que vous puissiez corriger, vous savez, ce qui a fini par se passer, c’est qu’en faisant cela, vous avez simplement pris ma feuille de route et vous les avez simplement rejetés au trimestre suivant. Donc, en ne déplaçant pas vers la gauche, en ne mettant pas vraiment ce processus en place, en ne faisant ces choses que du bon côté, nous poussons essentiellement notre feuille de route, qui est, vous savez, des livrables générateurs de revenus, potentiellement qui pourraient aider à développer notre entreprise. Nous allons avoir potentiellement déplacé les choses correctement afin que nous puissions réellement, vous savez, dépenser un quart essaie, après le fait, d’atténuer ces problèmes.
C’est pourquoi je dis, Eh bien, c’est extrêmement coûteux pour l’organisation et pour l’entreprise d’imaginer avoir, devoir décaler les éléments de la feuille de route d’un quart. Donc, tous vos calendriers de lancement de vos nouveaux produits, fonctionnalités et fonctionnalités doivent être modifiés, non ? Parce que vous n’avez pas basculé à gauche dans votre pratique.
Et certaines de ces choses auraient pu être améliorées avec de meilleures collaborations, en particulier entre les équipes de sécurité des applications au sein d’une organisation et encore et l’équipe de développement. C’est pourquoi nous voyons que de nombreuses organisations commencent à avoir ce nouveau concept. Vous savez, vous avez entendu parler des partenaires d’affaires des RH, vous savez, des partenaires d’affaires des RH intégrés dans différentes unités commerciales.
Il existe maintenant un concept de BP de sécurité des applications. Donc, vous allez commencer à entendre ces termes comme APP SEC BP qui, cela pourrait devenir pratique là où vous avez des gens qui travaillent. Presque comme un responsable semi-intégré de l’équipe d’ingénierie pour s’assurer qu’ils fournissent les conseils, les outils et les processus appropriés à chaque étape du flux de travail de développement, par exemple, vous savez, la mise en œuvre de l’analyse de la composition logicielle, la mise en œuvre de l’identification sécurisée, la mise en œuvre de toutes les tâches de boîte noire et blanche, vous savez, au cours du processus pour nous assurer que, vous savez, nous sommes en mesure de capturer certains de ces problèmes avant, vous savez, dès le début du cycle de vie du développement.
Michael Grimshaw : et j’aime tout. Bonne question Lauren. Et j’aime tout ce que tu viens de dire Richard. Parce qu’il y a un coût associé à cela. Vous savez, si les gens, si quelqu’un est dans un produit où ils entendent, attendez, vous savez, si je change à gauche, je n’ai pas à changer ma feuille de route à droite.
C’est de la musique à leurs oreilles. Mais pour peut-être les directeurs financiers, ou même les opérations, ou d’autres secteurs de l’entreprise, vous pourriez dire, OK, Eh bien, quel est l’impact de cela ? L’impact est énorme. Vous venez de mettre à genoux votre service commercial. Vous avez eu un impact sur vos clients parce que vous avez, surtout en matière de sécurité, beaucoup de clients. Du côté de la plate-forme, quand je parle à mes fournisseurs, je veux savoir quelle est la feuille de route parce que, d’accord, je dois peut-être aller voir mes auditeurs et j’ai besoin d’obtenir un contrôle compensatoire jusqu’à ce que vous publiiez quelque chose sur votre feuille de route. Eh bien, si vous venez de me le dire, OK, ce que je m’attendais à livrer dans un trimestre sera trois quarts. Je vais commencer à chercher d’autres fournisseurs. Pourquoi ? Parce que j’ai des obligations envers mes vérificateurs que je dois respecter.
Et j’aime aussi, Richard, que vous ayez parlé des auditeurs et vraiment du processus de conformité. C’est un autre exemple ici à votre point de vue, Lauren, sur l’endroit où la siloisation peut radicalement faire exploser les choses.
Si vous êtes au milieu d’un PCI, SOC, ISO, FedRAMP, n’importe lequel de ces différents cadres de conformité, et que vous n’avez pas vraiment intégré, vous avez toujours une mentalité d’asile, vous allez probablement avoir quelqu’un qui est en conformité ou info sec parler à vos auditeurs, ils vont devoir traduire cela à travers une couche ou deux du côté de l’ingénierie qui, espérons-le, va implémenter tout ce qui est prévu, et ensuite c’est juste pour le mettre en œuvre. Et puis toutes les preuves et la numérisation et tout ce que vous devez fournir à vos autres, bonne chance.
Si cela se traduit réellement par, nous avons tous joué au, vous savez, ce vieux jeu de rumeur de l’école primaire est un type de fonction similaire où si vous avez des équipes intégrées qui travaillent avec les auditeurs qui savent immédiatement comment traduire cela dans la technologie spécifique et vous avez le scan et vous pouvez retourner cela immédiatement et le mettre dans votre jeu de règles et analysez et validez cela à la fois en temps réel, ainsi que lorsque vous rencontrez les auditeurs. Vous avez toutes vos preuves ensemble juste là. Cela change radicalement la donne. Il vous permet de livrer les choses plus rapidement à vos clients au lieu, comme Richard l’a dit, de continuer à changer votre feuille de route dès maintenant.
Lauren Bradley : Oui. Donc, pour être plus tangible à ce sujet, je veux dire, comment les RSSI et les responsables AppSec peuvent-ils quantifier leurs métriques pour comprendre les implications en termes de coûts ou même simplement la réussite générale ?
Richard Yew : Quoi, vous savez, c’est drôle parce que nous parlons beaucoup du pourquoi, vous savez quoi, mais plongeons plus profondément dans le comment, parce que je sais que c’est ce que beaucoup de notre public veulent. Nous ne sommes pas ici pour vous donner des déclarations moelleuses et de haut niveau. Ce que nous sommes ici pour, espérons-le, fournir est un peu de valeur pour quand il s’agit exactement de la façon de mettre en œuvre cela.
On peut peut-être sortir le diagramme DevSecOps que nous avons, et ensuite on peut voir comment on peut optimiser les étapes. D’accord. Donc, comme vous pouvez le voir, les tests de sécurité traditionnels, vous savez, un peu comme s’ils fonctionnaient de façon linéaire, n’est-ce pas ? C’est, c’est un peu comme quand on parle de cascade, comme votre plan, vous avez, beauté, un test, n’est-ce pas ?
De nombreux tests de sécurité ont été effectués pendant la phase de surveillance de l’opérateur. Donc, c’est du côté droit. Donc, maintenant que le nouveau concept est, si nous passons aux prochaines photos, n’est-ce pas ? C’est que vous pouvez trouver 100 variétés différentes de ce tableau. Comme, quand vous venez de Google DevSecOps aujourd’hui, comme Mike l’a dit plus tôt, ce concept existe, vous savez, depuis 7 ans, n’est-ce pas ? Vous savez que certaines organisations pourraient ne pas appeler cela ce cycle. Certaines organisations appellent ça AppSec, non ? Certaines organisations les appelleront donc un pipeline de sécurité. Voici donc une représentation approximative de ce que représente un pipeline de sécurité. N’est-ce pas ? Donc, dès le début, vous avez sur la phase de planification, n’est-ce pas ?
Vous avez la modélisation des menaces analyse des menaces. Vous essayez de vous assurer que vous avez cuit dans toute cette modélisation pendant que vous concevez des solutions. Donc, comme vous codez, comme vous allez à une deuxième phase, votre phase de codage, non? Vous voulez vous assurer que vous avez le crochet. Vous voulez vous assurer que vous avez un IDE sécurisé, qui est toujours vraiment en temps réel car les développeurs écrivant le code ont effectivement capturé certains des problèmes en temps réel. Évidemment, ce n’est pas une balle d’argent, non? Mais c’est une couche supplémentaire et nous parlons de couches supplémentaires dans les cycles de défense en profondeur. Maintenant, alors que nous avançons de plus en plus dans le processus, n’est-ce pas? Une fois que vous vous êtes engagé à coder, non ? Vous voulez vous assurer que vous avez un processus – qui est capable de fournir, euh, un scan statique de tout votre code pour s’assurer qu’ils vérifient la dépendance automatique, la chaîne d’approvisionnement, la vulnérabilité, etc. avec l’analyse de la compensation logicielle pour créer une vue logicielle des matériaux qui vous montre quel type de version de logiciel vous utilisez? Quel âge ont-ils ?
Parce que, vous savez, je ne vous méfie pas, je viens de lire une statistique il y a une semaine ou deux – 25% des téléchargements d’Apache Log4j est toujours hors de l’ancienne version qui contient encore une vulnérabilité. Cela me déconcerte que ce soit encore une statistique, vous savez, maintenant que nous avons presque deux ans. Je ne sais pas, était-ce deux ou trois ans après l’annonce de la première vulnérabilité zero-Days d’Apache Log4j début décembre ? Était-ce 2021? Donc, c’est vraiment quelque chose que nous devons nous concentrer sur faire mieux et avoir ce genre de conversation / analyse logicielle en place pour nous assurer que vous savez exactement quelle version du logiciel vous exécutez.
C’est important. Alors, nous passons aux tests, non ? Vous voulez vous assurer que vous avez des tests internes, vous avez vos tests dynamiques, vous savez, mis en œuvre pour vous assurer que cela. Nous sommes en mesure de tester l’application en cours d’exécution et de voir s’il existe une vulnérabilité qui peut être exploitée.
Vous savez que cela se fait généralement par fuzzing. Maintenant, qu’est-ce qui n’est pas montré ici dans un cycle DevSecOps traditionnel? Parce que tout cela semble assez pratique courante dans l’industrie, non ? Alors que nous avançons tout le chemin pour déployer, surveiller, répondre. Historiquement, vous mettriez le pare-feu des applications Web, le gestionnaire de bots, les valeurs mobilières des API, toutes leurs solutions de protection des API des applications Web en phase de réponse et de surveillance, n’est-ce pas ? C’est lorsque vous surveillez votre trafic de production, vous vous assurez qu’il n’y a pas d’exploit vers.
Mais ce qui est quelque chose à considérer est de déplacer réellement certaines de ces protections API d’application Web que vous avez en place. Déplacez-les également vers la gauche. Mettez-les dans ce cas, dans la photo, c’est un pas en avant. Mettez-les en phase de test pendant que vous effectuez votre test dynamique de sécurité des applications, n’est-ce pas ? Pourquoi ne les testez-vous pas via votre mécanisme de sécurité de production ? Donc, vous savez, en fait, combien de vulnérabilités existent entre le code, combien de ces vulnérabilités peuvent être atténuées, parce que l’important est que nous essayons toujours de trouver des moyens d’améliorer ce cycle de vie actuel des applications en faisant fonctionner un développement plus rapidement. Une pratique générale lorsque vous trouvez une faille de sécurité pendant ce test est que vous arrêtez le train. Tu retournes, non ? Vous corrigez le code, vous les relancez. Vous repassez par les huit étapes. Mais si je vous disais qu’il y a peut-être un moyen pour vous de dire : « Hé, n’arrêtons pas le train ? »
Continuons le train. Libérons cela en ayant une sorte de test supplémentaire avec des solutions de sécurité devant l’étape quatre qui vous permettra de savoir bien à l’avance ce qu’il faut corriger virtuellement en production afin que vous n’ayez pas à arrêter votre train. Tu fais avancer ton train. Vous maintenez votre vélocité.
Vous publiez le code avec le correctif virtuel en place pour atténuer la vulnérabilité, puis vous les corrigez dans le cycle suivant, espérons-le, ce qui arrivera très rapidement. C’est aussi l’une de ces façons novatrices que nous voulons, vous savez, éduquer et travailler avec nos clients pour essayer d’améliorer le flux de travail de sécurité CICD existant.
Michael Grimshaw : J’adore ça, Richard. J’aime que vous appeliez le fait de tirer, tirant ceci dans le décalage à gauche. Donc, juste à votre point de vue est si votre plan de jeu est, Oh, mettons ceci en production et puis nous nous en inquiéterons. Vous allez avoir des problèmes et avoir quelque chose qui peut atténuer qui peut couvrir votre dos, à la fois à travers votre processus de développement et de déploiement et d’opérations. J’adore ce que tu as appelé là-bas. Et une analogie, et une analogie similaire, je dirais, serait comme chaos Singe. Voici la chose. Si chaos Monkey travaille en production, et que le seul moment où vous avez affaire à chaos Monkey est quand il est en production, vous allez avoir une expérience horrible de développement et d’exploitation.
Vous devez planifier, concevoir et concevoir pour cela bien avant qu’il n’atteigne la production. Sinon, vous allez être dans la misère.
Quantifier les métriques pour comprendre les implications en termes de coûts et de réussite
Richard Yew : Oui, et Lauren, j’aime répondre à des questions plus tôt, comment mesurer le succès maintenant que nous regardons tout le cycle de vie DevSecOps et comment l’optimiser. Quelle est la meilleure pratique, n’est-ce pas ?
Très rapidement. Nous devons donc suivre le succès. Il est donc évident que vous devez être en mesure de quantifier le succès. Exact. Donc, vous savez, là, il y a quelques indicateurs qui pourraient vous aider si vous êtes un leader de la sécurité et que vous essayez de mesurer le succès des programmes de sécurité des applications, une des choses que vous pouvez regarder, c’est aussi quoi, combien de la couverture des applications vous avez, n’est-ce pas ?
Ainsi, par exemple, plus de 90/95 % de toutes vos applications ou applications Internet dans vos organisations sont-elles couvertes par le même processus ? Avez-vous le même processus standardisé de couverture ? Exact. Que tout, y compris la composition logicielle, l’analyse, SAS, test, testez, testez, vous savez, comme les applications web, les protections API.
Avez-vous mis en place ces éléments pour assurer le suivi de la couverture ? À quelle fréquence libérez-vous et à quelle fréquence devez-vous revenir en arrière ? À quelle phase en raison de la vulnérabilité de sécurité que vous détectez et à quelle fréquence devez-vous revenir en arrière lors de la phase de production par rapport à quelle fréquence devez-vous revenir en arrière lors de la, vous savez, phase de validation de code où vous faites une analyse statique car évidemment le retour arrière des productions.
Cela va être beaucoup plus coûteux que de réparer le code après un peu d’analyse statique du code. Exact. Les deux autres stats là, vous voulez certainement mesurer comme, comme Lauren a fait allusion plus tôt. Le délai moyen de détection de ce que nous appelons un MTTD dans l’industrie est de 200 jours. Donc, je crois qu’avec cela avec le bon processus avec le décalage à droite processus à gauche, vous pouvez réduire drastiquement le temps de détecter, à beaucoup plus court. Essayez donc de commencer à rassembler des métriques pour détecter le temps nécessaire à une divulgation de vulnérabilité pour détecter ceux qui se trouvent dans vos organisations.
Et aussi mettre en œuvre entretemps pour répondre, non ? MTTR entre-temps pour résoudre entre-temps en résolutions, non ? La moyenne de l’industrie est de 70 jours, donc c’est 70 jours après la découverte d’une vulnérabilité, n’est-ce pas ? Exploité, il faut encore 70 jours à une organisation moyenne pour résoudre ce problème. Mais avec ce suivi de départ, à quelle vitesse pouvez-vous résoudre? Dès que vous trouvez une version vulnérable des journaux pour J en utilisant votre code dans votre analyse de composition logicielle, à quelle vitesse pouvez-vous les corriger virtuellement avec un pare-feu, ou à quelle vitesse pouvez-vous mettre à jour vos bibliothèques pour utiliser un logiciel différent, non ? Donc, en mesurant cela dans une organisation très mature, j’ai parlé avec certaines organisations qui ont en fait ce que nous parlons de quatre heures de temps moyen pour résoudre le temps pour l’événement log4j.
C’est extrêmement impressionnant. Et cela témoigne de la maturité de leurs processus DevSecOps. Alors, j’en ai vu toutes sortes. Et j’ai vu des organisations clientes qui ont des semaines, voire des mois, pour résoudre des problèmes critiques comme log4j. Il est donc très important de garder ces indicateurs à l’esprit lorsque vous essayez d’améliorer le processus dans son ensemble.
Michael Grimshaw : et il y a d’autres indicateurs clés de performance que je veux aborder ici, c’est que, comme du côté de la plateforme, quand il s’agit d’infrastructure ou, dans de nombreux cas, de toute ingénierie, le coût a toujours été un élément important ici. Mais au cours des dernières années avec la hausse des taux d’intérêt, vous savez, le robinet est aussi loin que l’argent de VC et beaucoup de cela se dessèche vraiment, mais le nom du jeu et l’environnement de hausse des taux d’intérêt est un battement vers le haut très rentable.
Et il y a un aspect ici. J’adore cette technique. Clairement, vous savez, directeur de l’ingénierie de plate-forme. J’aime le côté technique, mais surtout ces dernières années, une grande partie de si vous travaillez dans la plate-forme, comme je l’ai dit, l’infrastructure et des choses comme ça, l’aspect financier et la clarification et la fourniture de commentaires à votre CFO, ainsi qu’à votre CTO est devenu impératif.
Et donc, le KPI est autour d’un coût et le chiffre d’affaires est, c’est un autre, c’est un aspect énorme important ici aussi. Et je veux juste souligner certaines choses comme celle-ci, par exemple, du côté des recettes. Si vous êtes assis avec une discussion sur la ligne rouge, si vous avez un client qui cherche à acheter votre achat, mais votre produit, vous allez passer par une ligne rouge de sécurité parce que la sécurité est dans l’esprit de tout le monde et vos clients vont vouloir s’assurer qu’ils sont protégés.
Ils vont vouloir minimiser leur risque ici. Et si vous venez à lui avec la mentalité de la vieille école. Oh, oui, nous développons des choses et ensuite nous, nous laissons, nous nous assurons que notre infosec les scanne et tout ça. J’ai participé à beaucoup de discussions sur la ligne rouge et les contrats, et cela ne vole tout simplement plus.
Le niveau des questionnaires et des questionnaires du service des risques et du service juridique de votre client a atteint un tout autre niveau de détail au cours des cinq dernières années, sans parler des 10 dernières années. Et, être capable de disposer d’une solution Shift-Left entièrement intégrée pour avoir des applications Web et une protection API – tout cela. Lorsque vous parlez aux avocats d’autres personnes, cela déplace l’aiguille d’une grande façon. Qu’est-ce que cela signifie ? Cela signifie qu’il vous permet de conclure des transactions plus rapidement. Et une des choses si vous ne pratiquez pas Shift Left ou si vous pensez juste que c’est infosec comme un add-on, je vous encourage à revenir en arrière et à regarder vos ratios de clôture et où ils se sont effondrés et à regarder spécifiquement les discussions sur la ligne rouge de la sécurité parce que ces types de problèmes de produits sont trop souvent considérés comme un centre de coûts. Ils ne le sont pas, ils peuvent débloquer des revenus et ils peuvent vous faire économiser énormément d’argent.
Plus tôt dans le podcast, nous avons couvert une grande partie des économies de coûts en ce qui concerne les coûts internes, mais il y a des revenus dans les implications bêta ici que je pense qu’il est important de souligner parce que c’est là que se trouvent tant d’yeux dans ce monde en hausse des taux d’intérêt.
Conclusion
Richard Yew : C’est un excellent point. Je suis content que nous ayons changé un peu de chapeaux, vous savez, comme mettre sur mes chapeaux SDLC et vous mettre sur votre, votre chapeau d’affaires. C’est génial. J’espère que toutes ces choses que nous avons partagées apporteront un peu de valeur à notre public.
Lauren Bradley : Merci beaucoup à toutes les deux. Je pense que c’est une bonne note pour terminer. Nous avons abordé l’importance du changement à gauche et la façon d’intégrer efficacement les applications Web et la protection des API dans le cycle de vie DevOps. Et bien sûr, comment mesurer efficacement le succès. Y a-t-il moins de faux positifs ? Quelle est votre résolution temporelle moyenne ? À quelle vitesse expédiez-vous le logiciel ? Et gagnez-vous plus de revenus ?
Tous ces indicateurs sont essentiels au succès d’une entreprise. Je vous remercie tous les deux, Michael et Richard, de vous être joints à moi aujourd’hui. Ce fut vraiment un plaisir et merci à notre public de nous rejoindre sur Beyond the Edge. Nous vous verrons dans le prochain épisode.
