Une introduction au Podcast Beyond the Edge d’Edgio épisode 4 : DevSecOps : Shift Left pour éviter de décaler votre feuille de route produit à droite, animée par Lauren Bradley, Global Campaign Manager chez Edgio.
Lauren Bradley : Hé là, et bienvenue à Beyond the Edge, où nous fouillons dans 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 alors que la protection des applications Web et des API devient une partie native et inhérente de votre cycle de vie DevOps.
Commençons par une statistique choquante de l’Institut Ponemon. Aujourd’hui, il faut plus, pour la plupart des entreprises, plus de 200 jours pour détecter une violation. Si vous ne détectez pas une brèche 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 va vous coûter. Et, nous ne parlons pas seulement d’argent, le remaniement, le temps et l’énergie peuvent finalement faire reculer les feuilles de route des produits. Alors, comment pouvez-vous effectivement passer à gauche et éviter de gaspiller des ressources précieuses et de freiner vos progrès?
Michael Grimshaw, directeur de l’ingénierie des plateformes chez Edgio, et Richard Yew, directeur principal de la gestion des produits pour Edgio Security Platform, se joignent à nous aujourd’hui. Bienvenue, Michael et Richard. C’est génial de vous avoir sur.
Michael Grimshaw : Merci Lauren. Super d’être ici. Merci.
Lauren Bradley : pouvez-vous me parler un peu de vous-mêmes et de vos premières réflexions sur ce sujet ? Mike, nous commencerons par toi.
Michael Grimshaw : absolument. Tout d’abord, permettez-moi de commencer par vous remercier, vous remercier, Lauren, pour avoir un tel intérêt. Dans ce sujet très important et, et vous creusez et accélérez et les conversations que nous avons eues et avons autour de cela, y compris cette année ici est, 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 loin et largement et, et vraiment apprécier l’intérêt. Je m’appelle Michael Grimshaw. Je suis le directeur de l’ingénierie des plateformes ici chez Edgio. Pour ceux d’entre vous qui ne connaissent pas, ou qui connaissent très bien, la plateforme en termes d’industrie, c’est vraiment penser en termes d’unification de vos applications et de votre infrastructure en unités cohérentes.
Et, je viens à la plateforme avec une forte expérience en sécurité, et c’est un domaine qui me passionne beaucoup, car il déplace l’aiguille d’une manière si importante, aussi loin que la sécurité, aussi loin que la rentabilité, et tant de domaines qui sont si importants pour notre industrie.
Et je peux continuer autour de DevSecOps, mais laissez-moi le remettre à Richard pour son introduction.
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. Ainsi, 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 évidemment inclurait comme l’optimisation de notre pratique de développement, notre sécurité, notre pratique ci CD. 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 et les budgets impartis, et garantit que nous offrons une expérience exceptionnelle à nos clients. Donc, mon objectif ici est de vraiment regarder l’ensemble DevSecOps, vous savez, du point de vue des gens – le processus par opposition à la technologie et comment nous pouvons réellement mettre en œuvre les meilleures pratiques, pour, l’industrie.
Qu’est-ce que DevSecOps ?
Michael Grimshaw : à votre avis, Richard, laissez-moi voler la balle là-bas si ça ne vous dérange pas.
Et juste je pense que nous allons normaliser ce que nous entendons par DevSecOps et décalage à gauche, n’est-ce pas? 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 nouvelle chose la plus chaude qui vient de frapper il y a un an.
Non, cela fait déjà un bon moment que ça fait du gâteau dans l’industrie. Et en fait, Gartner avait un rapport de 2017 sur le cycle de vie DevSecOps. Était juste une extension du DevOps, la tendance DevOps dans l’industrie, s’étendant simplement pour inclure la sécurité dans l’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, écrivait à ce sujet, en 2017, et cela avait déjà été, un processus et un mouvement dans l’industrie. Pendant un certain temps avant cela. Donc, ce ne sont pas des concepts tout à fait nouveaux. C’est juste une extension de ce sur quoi nous travaillons depuis des années. Et en fait, ce qu’est DevSecOps, c’est qu’il prend le même modèle, de DevOps en ce sens que vous avez un côté développement et vraiment un côté opération.
Et au fond, il intègre tous vos besoins de sécurité dès que possible, je veux dire, dans le début de la conception, construisez le, vous savez, tout le processus jusqu’à ce que vos développeurs sur le navire gauche sont du côté du développement, excusez-moi, le décalage à droite est plus du côté de l’observabilité des opérations. Nous allons nous concentrer sur le décalage côté gauche ici aujourd’hui, mais il s’agit essentiellement de tester vos scans, et votre validation, dès l’extrême gauche. Et aussi tôt que possible dans le cycle de vie du développement dans votre SDLC. Donc, 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, 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 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.
De sorte que lorsqu’ils écrivent leur code, ils obtiennent un retour immédiat. OH, j’ai juste laissé 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à, c’est l’écriture du code. Ainsi, ils peuvent immédiatement corriger cela, de sorte qu’ils n’ont pas un client se plaindre que le client ou l’utilisateur final est mis en gage, vous savez, un mois plus tard, non, c’est traité juste là.
Moins cher, plus rapide, plus facile au début. Richard, tu allais dire quelque chose.
Pourquoi le déplacement vers la 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, n’est-ce pas ? Parce que nous mettons beaucoup d’efforts et que nous parlons du pourquoi, vous savez, je suis sûr que nous allons entrer dans le « comment » plus tard, mais nous voulons nous pencher sur 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 que vous avez publié votre code et les productions coûtent 15 fois plus cher que vous ne le savez quand 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 première phase de l’effort de développement permettrait de détecter complètement toutes les vulnérabilités de sécurité.
C’est pourquoi nous devons mettre en œuvre la défense en profondeur. Mais il est très important que vous sachiez, en regardant les huit phases, vous savez, en général, des cycles de dette, des cycles de vie de, vous savez, planifier, coder, construire, tester, tout le chemin pour aimer surveiller et fonctionner. Exact. Vous les regardez plus loin que vous allez, vous savez, comme lorsque 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 avez déjà publié un tas de codes pour les productions et disons, vous savez, comme faire une tâche de sécurité d’application dynamique dans l’environnement de préparation pour réellement la détecter tôt avant que vous expédiez ce code aux productions, n’est-ce pas ?
Richard Yew : vous pouvez peut-être résoudre ces problèmes, ou implémenter une sorte de correctifs virtuels 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. Hey, quelle partie de la conception pourrait potentiellement être exploitée ?
Implications quotidiennes pour les équipes DevOps et sécurité
Lauren Bradley : Oui, et ce sont vraiment de bons points, vous les gars. Je veux dire, du point de vue de l’utilisateur, qu’est-ce que, en dehors des coûts, sur le plan monétaire, que peut signifier pour un DevOps ou une équipe de sécurité l’expérience quotidienne si elle ne met pas cela en œuvre dès le départ ?
Et je veux également parler de la manière dont nous l’implémentons efficacement dans le cycle de vie DevOps.
Michael Grimshaw : bonne question. Bonne question. Et, permettez-moi d’être très franc dans ma réponse initiale. Est-ce que tout le monde dans l’industrie, chaque PDG, directeur technique, directeur financier – tout le monde, ingénieurs, utilisateurs – ce que nous voulons tous, c’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 n’avez qu’à basculer 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, que les gens nous demandent. Je veux leur demander, quel temps fait-il en Fantasy Land? 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 boulonnage. Vous savez, « Oh, je vais acheter des outils que je vais boulonner après que nous aurons tout développé, construit et déployé, et ça va continuer et tout sécuriser », vous achetez un presse-papiers 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 d’outillage. C’est pourquoi la cohérence de l’ensemble de cette approche est si importante. Est-ce vous, nous sommes de longues années, des décennies, si jamais cela a été possible. Pour être honnête avec vous, nous avons appris beaucoup de leçons de l’idée que vous concevez simplement quelque chose et mettez un outil de sécurité et vous êtes, vous êtes prêt à partir.
Il a un impact sur tout, de votre coût à la vitesse de développement et le coût là-bas pour vos clients. Et, un bon exemple de cela est mon soupçon est que 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 va bien. Et puis soudain, vous recevez un appel de l’un de vos clients ou infosecs 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 en est que, d’accord, vous l’avez déployé, mais peut-être que les scans n’étaient pas terminés, ou que vous n’avez pas fait de scans, ou que vous ne les avez pas réglés correctement, et vous venez d’introduire une vulnérabilité de sécurité massive.
Peut-être que cela vous affecte, mais plus important encore, cela affecte vos clients. DevSecOps consiste à cuire 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, d’une grande manière. Mais il s’agit aussi de supprimer la responsabilité de votre entreprise et 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 la cuisson, vous savez, comme Mike a utilisé un tel terme de totalité cohérente. Comme ceci est si vrai. C’est très puissant, c’est un mot très puissant pour montrer pourquoi c’est important d’avoir ça 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 et je suis, vous savez, j’ai entendu ça génial. Les analogies, je pense, serviraient de base solide pour promouvoir les bonnes cultures au sein de toute organisation comme nous le savons tous, en tant que personnes chargées de la 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.
Dire aux gens que la sécurité est importante pour l’entreprise, n’est-ce pas ? Parce que, vous savez, en tant que leaders de la sécurité, ce n’est pas seulement comme si les gens pensaient souvent à la sécurité, comme l’ajout de couches de processus supplémentaires dans votre flux de travail, mais vous savez, la bonne façon de penser à cela est que la sécurité peut accélérer l’activité ?
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 entendue qui était géniale est que vous savez, la sécurité ne devrait pas être traitée comme une cerise sur le gâteau, vous savez, comment vous cuisez du gâteau et mettez juste tous les cerises comme une dernière étape, vous savez, c’est généralement ce que les gens font quand ils n’ont pas de sécurité, flux de travail ICD, et ils mettent juste en place des pare-feu et, vous savez, protection API, peu importe à la dernière phase de la phase de la phase de la phase de la production. Ce que ça devrait être, la sécurité, c’est comme de la farine, tu sais, ça, ça aurait dû être quelque chose depuis le début.
La sécurité est comme de la farine pour que vous fassiez le gâteau. Et puis, lorsque la sécurité est bien faite, vous ne pouvez pas la voir. Et tout le point de la sécurité est quand c’est bien fait, ça aurait dû être cuit et ça n’est pas visible. Ce ne devrait pas être quelque chose qui crée des défis. Cela ne devrait pas ralentir l’organisation.
Comme les analogies que, vous savez, j’ai utilisées pour aider à montrer à l’entreprise pourquoi c’est important, c’est qu’avoir un processus de sécurité solide, des cultures technologiques de sécurité, c’est un peu comme avoir des freins puissants. Dans une voiture de course, vous savez pourquoi toutes les supercars ont de gros, vous savez, vraiment gros, freins de fantaisie parce que cela leur permet de prendre des virages plus rapides.
Il leur permet de freiner fort. Ça leur permet d’aller plus vite et de tourner plus fort, non ? Il leur permet de gagner la course. Donc, avoir des freins puissants est aussi important que d’avoir un moteur puissant, 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 hauts niveaux, non ? Donc, nous voulons évidemment, vous savez, un peu comme aller plus loin là-dedans. L’essentiel de, OK, donc tout ça va bien, mais comment allons-nous exactement mettre cela en œuvre ?
Michael Grimshaw : Oui. Je pense que c’est un excellent appel, c’est freiner. Un freinage puissant vous donne le contrôle. Il y a le courant ou la route que nous avons devant nous est rempli de courbes, de virages en épingle à cheveux, et tout ça, et il y a, bien sûr, des lignes droites où vous le planez et vous ne touchez pas aux freins, mais pour naviguer tout, cela, ce frein, je pense, amour, j’aime ces deux analogies, Richard, parce que cette analogie de freinage, ça vous donne le contrôle, ça vous donne un meilleur grain quand vous faites face à des bordures, des défis, et des choses inattendues.
Richard Yew : excellent appel. Au fait, je veux clarifier, je n’ai pas trouvé cette analogie, c’est de ce gars qui s’appelle Dr Eric Koh. Il l’a fait, et il dirige un super podcast. Donc, je recommande à tout le monde d’aller regarder ça. Mais oui, je trouve cela si approprié pour expliquer le concept à l’entreprise, surtout avec ceux qui sont nouveaux à ce genre de concept.
Équipes problématiques, cloisonnées et feuilles de route de changement
Lauren Bradley : Richard, vous parlez de la façon dont vous, vous avez mentionné, vous savez, si, si c’est le cas, DevSecOps est fait, n’est-ce pas ? Vous ne le voyez pas. Et évidemment, une de ces visibilités flagrantes est le coût. C’est aussi des équipes cloisonnées. On a également 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, quelle communication n’avait pas 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 problèmes ont tendance à être les plus problématiques lorsque les équipes opèrent en cloisonnement à 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, de genre de planification, il est important que parfois vous ayez une équipe de sécurité qui n’est pas en quelque sorte 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é réalisés après coup. Ainsi, par exemple, nous nous trouvons dans une situation où nous lançons beaucoup de produits, lançons 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 par faire, 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 bogues de sécurité différents, vous savez, comme peut-être, peut-être 20, comme dans le top 20, il y a une gravité de un et deux et plus, tandis que le reste, vous savez, c’est à peu près, vous devez vous concentrer sur la correction de ces choses. »
Et il y a un SLA au sein de l’organisation que vous devez corriger, vous savez, ce qui a fini par se produire, c’est qu’en faisant cela, vous avez simplement pris ma feuille de route et vous les avez juste renvoyées au trimestre suivant. Donc, en ne tournant pas à gauche, en ne mettant pas vraiment ce processus en place, en faisant simplement ces choses uniquement 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 potentiellement avoir à bouger correctement afin que nous puissions, vous savez, dépenser un trimestre, c’est essayer, après coup, d’atténuer ces problèmes.
C’est pourquoi je dis, eh bien, c’est extrêmement cher pour l’organisation et pour l’entreprise d’imaginer avoir, avoir à décaler les éléments de la feuille de route d’un quart. Donc, tous vos calendriers de sortie de vos nouveaux produits, fonctionnalités et fonctionnalités doivent être décalés, n’est-ce pas ? 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 pourtant et l’équipe de développement. C’est pourquoi nous constatons que de nombreuses organisations commencent à avoir ce nouveau concept. Vous savez, vous avez entendu parler des partenaires d’affaires RH, vous savez, des partenaires d’affaires RH qui sont 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 That, qui pourrait devenir une pratique où vous avez des gens qui travaillent. Presque comme un gestionnaire semi-intégré de l’équipe d’ingénierie pour s’assurer qu’ils fournissent les bons conseils, outils et processus à chaque étape du flux de développement de, disons, vous savez, la mise en œuvre de l’analyse de 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, pendant le processus pour s’assurer que, vous savez, nous sommes en mesure de capturer certains de capturer certains de ces problèmes avant, vous savez, juste au début du cycle de vie de 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 département des ventes. Vous avez eu un impact sur vos clients parce que vous avez, surtout en matière de sécurité, beaucoup de clients. Côté plateforme, quand je parle à mes fournisseurs, je veux savoir quelle est la feuille de route parce que, d’accord, peut-être que je dois aller voir mes auditeurs et que je dois obtenir un contrôle compensatoire jusqu’à ce que vous publiiez quelque chose sur votre feuille de route. Eh bien, si vous me le disiez, OK, ce que je m’attendais à être livré dans un trimestre sera les trois quarts. Je vais commencer à regarder d’autres fournisseurs. Pourquoi ? Parce que j’ai des obligations envers mes auditeurs 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, 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 opérez toujours une mentalité d’asile, vous allez probablement avoir quelqu’un qui est en conformité ou info sec qui parlera à vos auditeurs, ils vont devoir traduire cela à travers une ou deux couches du côté ingénierie qui, espérons-le, va mettre en œuvre tout ce qui est juste pour le faire implémenter. Et puis toutes les preuves et le scan et tout ce que vous devez fournir à vos autres, bonne chance.
Si cela se traduit réellement, nous avons tous joué au, vous savez, ce vieux jeu de rumeur de l’école primaire est un type similaire de fonction 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 tourner cela immédiatement autour et le mettre dans votre jeu de règles et scanner et valider cela à la fois en temps réel, ainsi que lorsque vous rencontrez les auditeurs. Vous avez toutes vos preuves ensemble juste là. C’est un changement radical de la donne. Il vous permet de livrer les choses plus rapidement à vos clients plutôt que, comme Richard l’a dit, de continuer à changer votre feuille de route dès maintenant.
Lauren Bradley : Oui. Donc, pour être plus tangible sur ce point, je veux dire, comment les RSSI et les responsables AppSec peuvent-ils quantifier leurs indicateurs pour comprendre les implications en termes de coûts ou même simplement le succès général ?
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 à cela que beaucoup de notre public sert. 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.
Donc peut-être que nous pouvons faire apparaître le graphique DevSecOps que nous avons, et nous pouvons ensuite passer en revue comment nous pouvons optimiser les étapes. D’accord. Donc, comme vous pouvez le voir, les tests de sécurité traditionnels, vous savez, un peu comme s’exécutent 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 sur le côté droit. Donc, maintenant que le nouveau concept est, si nous passons aux images suivantes, non ? Est-ce 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, non ? Vous savez que certaines organisations pourraient ne pas l’appeler ce cycle. Certaines organisations l’appellent AppSec, n’est-ce pas ? Ainsi, certaines organisations les appelleront un pipeline de sécurité. Voici 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 disposez de l’analyse des menaces de modélisation 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, n’est-ce pas ? 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, n’est-ce pas ? 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, n’est-ce pas ? Vous voulez vous assurer que vous avez un processus – qui est capable de fournir, euh, une analyse statique de tout votre code pour s’assurer qu’ils vérifient l’auto-dépendance, la chaîne d’approvisionnement, la vulnérabilité, etc., ainsi que 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 plaisante 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é. Ça me déconcerte que ce soit encore une statistique, vous savez, maintenant que nous sommes presque deux ans. Je ne sais pas, était-ce deux ou trois ans depuis que la première vulnérabilité Apache Log4j zero-days a été annoncée début décembre ? C’était 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 utilisez.
C’est important. Donc, alors nous nous dirigeons vers les 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. Nous sommes en mesure de tester l’application en cours d’exécution et de voir s’il y a 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 ressemble à une pratique assez standard de l’industrie, non ? Alors que nous progressons tout droit vers le déploiement, la surveillance et la réponse. Historiquement, vous mettiez le pare-feu des applications Web, le gestionnaire de bots, les sécurités API, toutes leurs solutions de protection 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 réellement déplacer 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 de sécurité d’application dynamique, n’est-ce pas ? Pourquoi ne pas les tester 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 les cycles de vie actuels des applications en faisant en sorte qu’un développement fonctionne plus rapidement. Une pratique générale lorsque vous trouvez une faille de sécurité au cours de ce test est que vous arrêtez fondamentalement le train. Tu y retournes, n’est-ce pas ? Vous corrigez le code, vous les rééditez. Vous repassez par les huit étapes. Mais que se passerait-il si je vous disais qu’il y a peut-être un moyen pour vous de dire : « bon, n’arrêtons pas le train ? »
Gardons le train en marche. Relâchons 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 pratiquement corriger dans la production afin que vous n’ayez pas à arrêter votre train. Tu gardes ton train en marche. 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 se produira très rapidement. C’est également l’une de ces façons, les façons innovantes 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, tirer ça dans le quart gauche. Donc, juste à votre point, si votre plan de match est, oh, mettons cela en production et ensuite nous nous en soucierons. Vous allez avoir des problèmes et avoir quelque chose qui peut atténuer qui peut couvrir votre arrière-plan, à la fois par le biais de 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 le singe du Chaos. Voici le truc. Si vous avez Chaos Monkey qui 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’entre en production. Sinon, vous serez dans la misère.
Quantifier les indicateurs pour comprendre les implications en termes de coûts et la réussite
Richard Yew : Oui, et Lauren, j’aime répondre aux questions précédentes, comment mesurer le succès maintenant que nous regardons l’ensemble du cycle de vie DevSecOps et comment nous pouvons l’optimiser. Quelle est la meilleure pratique, n’est-ce pas ?
Très rapidement. Nous devons donc suivre le succès. Donc évidemment, vous devez être en mesure de quantifier le succès. Exact. Donc, vous savez, là, il y a certaines des mesures 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 couverture des applications vous avez, n’est-ce pas?
Ainsi, par exemple, avez-vous plus de 90/95 % de toutes vos applications ou applications Internet dans l’ensemble de vos organisations couvertes par le même processus ? Disposez-vous de la même couverture de processus standardisée ? Exact. Que tout, y compris la composition logicielle, l’analyse, SAS, test, test, test, vous savez, comme les applications web, les protections API.
Avez-vous ces éléments en place pour continuer à suivre 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 phase de validation de code, vous savez, où vous effectuez une analyse statique, car évidemment, revenir en arrière des productions.
Cela va être beaucoup plus cher que d’aller réparer le code après un peu d’analyse statique du code. Exact. Les deux autres statistiques là-bas, vous voulez certainement mesurer comme, comme Lauren a fait allusion plus tôt. Le temps moyen moyen de détection de ce que nous appelons un MTTD est de 200 jours. Donc, je crois qu’avec le bon processus avec le processus de décalage à droite à gauche, vous pouvez réduire considérablement l’intervalle à détecter, à beaucoup plus court. Essayez donc de commencer à rassembler des indicateurs pour détecter combien de temps faut-il à la divulgation d’une vulnérabilité pour vous de détecter ces bâtiments au sein de votre organisation.
Et aussi mettre en œuvre en attendant la réponse, n’est-ce pas ? MTTR en attendant de résoudre en attendant les résolutions, n’est-ce pas? La moyenne de l’industrie est de 70 jours, donc 70 jours après la découverte de la 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émarrage, à quelle vitesse pouvez-vous résoudre? Dès que vous trouvez une version vulnérable des logs 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 aller mettre à jour vos bibliothèques pour utiliser un autre logiciel, n’est-ce pas ? 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’ai vu toutes sortes. Et j’ai vu des organisations clientes qui ont des semaines, voire des mois d’intervalle, à résoudre pour 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 KPI que je veux ajouter ici, c’est que, comme du côté de la plate-forme, lorsque vous avez affaire à l’infrastructure ou, dans de nombreux cas, à quelque chose d’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 tarissent vraiment, mais le nom du jeu et l’environnement de la hausse des taux d’intérêt est un battement 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’adore le côté technique, mais surtout ces dernières années, une grande partie de si vous travaillez dans la plateforme, comme je l’ai dit, l’infrastructure et des choses comme ça, l’aspect financier et dans la clarification et la fourniture de commentaires à votre directeur financier, ainsi qu’à votre directeur technique, est devenu impératif.
Et donc l’ICP 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, et je veux juste souligner que certaines choses comme celle-ci sont, par exemple, du côté des recettes. Si vous êtes assis avec une discussion de 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é old-School. OH, oui, nous développons des choses et ensuite, nous laissons, nous nous assurons que notre infosec les scanne et tout ça. J’ai été dans beaucoup de discussions de ligne rouge et de discussions de contrat, 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, et encore moins 10 ans. Et, être en mesure d’avoir 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 fait bouger l’aiguille d’une grande façon. Qu’est-ce que cela signifie ? Cela signifie qu’il vous permet de conclure des affaires plus rapidement. Et une des choses si vous ne pratiquez pas le shift à gauche ou si vous pensez simplement 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 de ligne rouge de 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 une énorme somme 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 implications de revenus en bêta ici que je pense qu’il est important de souligner parce que c’est là que beaucoup d’yeux se trouvent dans ce monde de taux d’intérêt en hausse.
Conclusion
Richard Yew : C’est un excellent point. Je suis content que nous ayons changé un peu de chapeaux, vous savez, comme mettre mes chapeaux SDLC et vous mettez 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 tous les deux. Je pense que c’est une bonne note pour terminer. Nous avons abordé l’importance du déplacement à gauche et comment 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 des logiciels ? Et gagnez-vous plus de revenus ?
Tous ces indicateurs sont essentiels à la réussite d’une entreprise. Donc, je vous remercie tous les deux, Michael et Richard, de vous être joints à moi aujourd’hui. Ce fut un réel plaisir et merci à notre public de nous rejoindre sur Beyond the Edge. Nous vous reverrons dans le prochain épisode.
