Catégories
Start-up et applications

Méfiez-vous de ces créatures qui se cachent dans vos équipes DevSecOps

Halloween est à nos portes, et alors qu'une grande partie du monde se concentre sur des créatures effrayantes comme les fantômes, les goules ou les loups-garous, DevSecOps les équipes ont quelques créatures effrayantes à affronter.

Du développeur de type Dracula coincé dans un monde d'il y a des siècles qui contrecarre la création d'applications sécurisées, aux fantômes DevOps qui minimisent l'importance des vulnérabilités des applications, il est important pour les équipes DevSecOps de comprendre les menaces qui peuvent se cacher. équipes.

Tout d'abord, il y a les développeurs de type Dracula qui sont coincés des siècles dans le passé. Selon Dennis Hurst, fondateur de Sécurité des salines, ces développeurs existent par désir de ne pas changer la façon dont ils écrivent le code. «Nous sommes souvent confrontés à ceci:« Nous avons toujours construit une application de cette façon, pourquoi ai-je besoin de la tester en sécurité? »Et ils ne se rendent pas compte que ces applications sont maintenant sur Internet, elles face au public, ou ils sont connectés à des choses qui sont sur Internet, ou ils fonctionnent dans une infrastructure cloud, donc ce n'est plus une sorte de centre de données heureux », a déclaré Hurst.

Selon Hurst, le moyen pour les équipes de surmonter ces membres d'équipe de type Dracula est d'avoir un leadership clair. «Sans un leadership solide, les membres de l'équipe se sentent libres de continuer à faire ce qu'ils ont toujours fait, ce qui étouffe l'innovation», a-t-il déclaré.

Un autre membre effrayant de l'équipe DevSecOps à surveiller sont les fantômes DevOps, en d'autres termes, le shadow IT. Selon Hurst, ce sont ces personnes qui croient «qu'elles peuvent tout simplement faire le tour par magie de toute l'informatique et passer directement au cloud. Les applications sont là, un peu comme des fantômes, vous les entendez claquer et vous savez qu'elles sont là mais vous ne les voyez pas réellement, personne ne les connaît, elles sont en quelque sorte – peut-être qu'elles seront là. Nous voyons beaucoup cela dans la sécurité où nous trouvons des applications fonctionnant sur Internet dont personne ne savait. »

Hurst a ajouté que ce n’était pas un événement rare; c'est en fait assez courant, surtout avec plus d'employés travaillant à domicile. Les gens rentrent chez eux et emportent leur ordinateur portable avec eux, alors comment sécuriser cela?

«De nombreuses entreprises sont passées au cloud pour certaines parties de leurs activités à cause du COVID, peut-être qu’elles n’ont pas pu accéder au centre de données», a déclaré Hurst. «Il est donc plus facile pour les gens de se rendre compte que 'oh, je peux simplement placer cette application dans le cloud et lorsque tout sera terminé, nous trouverons comment la récupérer en interne.' Nous ' vous le voyez certainement plus. Nous voyons plus de gens aller dans le cloud, peut-être même utiliser une carte de crédit d'entreprise pour ouvrir les comptes, donc ce n'est même pas un compte d'entreprise, c'est juste la carte de crédit personnelle de quelqu'un qu'ils utilisent pour créer un site Web quelque part, nous voyez cela plus que nous ne le souhaiterions.

Hurst estime que l'utilisation de systèmes de surveillance est l'un des plus grands moyens de se protéger contre le shadow IT. Il a expliqué qu'il existe des services qui surveillent Internet à la recherche de propriétés qui pointent vers ou sont liées à l'infrastructure informatique de l'entreprise. Un gros inconvénient est qu'il n'y a pas vraiment de moyen proactif d'empêcher quelqu'un de créer un service par lui-même. «Tout le monde peut sortir et ouvrir un site Web, mais vous pouvez surveiller pour voir quand cela se produit. Plus vite vous pouvez y remédier, plus il est facile à gérer », a déclaré Hurst. "Donc, si un site Web est mis en veille pendant une journée, il est assez facile de le supprimer ou de le faire déplacer. S'il est là pour 6 mois ou un an, en affaires, il devient beaucoup plus difficile et difficile de se retirer parce que vous mettez votre entreprise hors ligne. "

Le «Bridge of Death» de l'Architecture Review Board est un autre composant DevSecOps effrayant à rechercher. Les équipes de développement passent par tous ces efforts et construisent des pipelines DevOps et mettent les choses en marche, mais une fois qu'elles arrivent au comité de révision de l'architecture, les questions qui leur sont posées sont similaires à celles posées dans la scène du pont de la mort dans Monty Python et le Saint Graal (c'est-à-dire qu'on demande à Arthur quelle est la vitesse d'une hirondelle à vide?).

«Souvent, la sécurité, qui fait partie de ce tableau, posera des questions qu’ils n’ont pas dites aux développeurs qu’ils allaient poser au démarrage du processus», a déclaré Hurst. «Ils mettent donc en œuvre de nouvelles exigences. Donc, en tant que développeur, vous arrivez au comité d'examen de l'architecture et ils vous posent trois questions, ou un certain nombre de questions qui semblent simplement aléatoires, et si vous vous trompez, ils vous disent de revenir en arrière et de retravailler. Donc, cela ressemble beaucoup à ce film où ils sont jetés dans le gouffre du désespoir. "

Pour faire face au pont de la mort dans le développement, Hurst recommande de définir clairement et de communiquer des normes aux équipes de développement sur ce qui est nécessaire pour mettre une application en production.

Un autre domaine à surveiller est le concept «construisez-le et il fonctionnera». «Dans Field of Dreams, ils n'arrêtaient pas de dire de le construire et ils viendront. C'est le construire et il fonctionnera », a-t-il dit. "Il semble y avoir une attitude selon laquelle si vous passez de la méthodologie que vous utilisiez précédemment à DevOps, l'application fonctionnera d'une manière ou d'une autre par magie même si vous ne la testez pas correctement et que vous ne la testez pas correctement."

Selon Hurst, il est courant que les gens se concentrent artificiellement sur la partie développement de DevSecOps, ils développent donc bien quelque chose, mais ne le testent pas bien, ou communiquent avec les clients sur la manière de vivre en toute sécurité.

Dans ce cas encore, un leadership approprié est l'antidote. Un bon leader peut exiger que lorsqu'une équipe passe à DevSecOps, cela doit être entièrement fait, y compris des tests appropriés pour la sécurité, les performances et les fonctionnalités, a expliqué Hurst.

Enfin, il y a les OSC inconscientes, ce qui est peut-être le problème le plus difficile de tous, estime Hurst. Selon Hurst, les OSC ont tendance à venir du monde du réseautage ou de l'audit, pas du monde du développement. «Souvent, ils ne comprennent pas le développement. Ils comprennent conceptuellement comment les choses se développent, mais ils ne comprennent pas les moteurs commerciaux du développement. Parce que les gens disent DevSecOps, il y a des hypothèses selon lesquelles la sécurité est correctement effectuée dans le monde du développement. »

Pour lutter contre cela, Hurst recommande aux OSC de s'impliquer davantage auprès des développeurs et des équipes DevOps.

«Ils doivent être impliqués, ils doivent comprendre ce qui est construit et comment il est construit», a déclaré Hurst. Ils doivent comprendre ce qui est fait pour le sécuriser correctement. Ils doivent donc être très impliqués. Vous ne pouvez pas être inconscient de ce qui se passe ou cela n'arrivera tout simplement pas. En fin de compte, dans une organisation, le RSSI est la seule personne centrale de l'entreprise qui possède la sécurité, et cela doit inclure la sécurité des applications, vous ne pouvez pas simplement être sûr que des centaines et des centaines d'équipes de développement font toutes ce qu'il faut pour protéger l'entreprise. . Ce n’est qu’une recette pour un désastre. »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *