Au cours de sa carrière en tant qu’ingénieur en cybersécurité, Matthew Rosenquist a vu sa part de frustration. Il y a eu le PDG qui a licencié sa propre équipe après qu’il a montré des vulnérabilités dans le produit principal de l’entreprise. Il y avait des ingénieurs logiciels qui manquaient d’expérience en sécurité, mais qui ne se souciaient pas d’en acquérir.
« Dans leur esprit, ils étaient des codeurs brillants et cela était suffisant », déclare Rosenquist. « Ils ont dit : « Ce n’est pas mon problème. Je le code juste là où il fonctionne et le reste est un problème de sécurité. »
Cette attitude antagoniste est compréhensible. Les développeurs de logiciels vivent dans un monde de conception itérative, de versions rapides et de « produits minimaux viables ». Dans l’intérêt du temps et de l’accent mis sur le code, ils ne sont pas concernés par grand-chose d’autre, y compris la sécurité. Ils le perçoivent souvent comme une traînée sur le calendrier, ou même sur le produit lui-même.
« Si vous êtes développeur ou ingénieur, c’est votre bébé », déclare Rosenquist, stratège en cybersécurité et conseiller en conseil d’administration qui a passé 23 ans chez Intel et est actuellement RSSI chez Eclipz.io, une société de chiffrement logiciel. « Vous avez des échéances. Vous êtes évalué sur la façon dont vous obtenez votre code à temps. Maintenant, lancez une personne de cybersécurité qui ne connaît pas votre produit. « Vous voulez que je fasse X, Y et Z ? Cela va ébranler mon calendrier. » Cette friction s’accumule. La seule chose pire est de ne pas faire du tout de sécurité. »
Gérer la faille
La friction que Rosenquist décrit n’est pas nouvelle. Il est né d’une faille de longue date dans l’entreprise entre DevOps et les équipes de sécurité et s’est aggravé par les défis d’une crise sanitaire mondiale. Avec des millions de télétravailleurs accédant à des systèmes de données sensibles sur des dizaines de millions d’endpoints, y compris des ordinateurs portables, des PC et des tablettes, les vulnérabilités et les failles de sécurité ont explosé. Selon une enquête publiée par Tanium en 2020, les entreprises nord-américaines perdent 700 milliards USD par an en raison des temps d’arrêt informatiques. La faille entre les équipes n’aide pas.
Mais ils doivent travailler ensemble. Une pratique émergente appelée DevSecOps, par exemple, vise à créer des ponts entre les fiefs en matière de dueling en intégrant les membres de l’équipe de sécurité et les processus dans le cycle de vie du développement logiciel pour détecter les vulnérabilités rapidement. Malgré cela, des problèmes culturels profonds, une pénurie mondiale de compétences dans les structures de sécurité et organisationnelles handicapent toujours l’harmonie entre les équipes. Alors que les responsables informatiques cherchent des moyens de surmonter ces obstacles, plusieurs meilleures pratiques ont émergé, en commençant par une adhésion plus claire au niveau exécutif et en développant une philosophie collaborative. Voici comment commencer :
Définir le ton depuis le haut
Après que deux vers invalidants ont frappé Microsoft en 2001, Bill Gates a envoyé une note l’année suivante à l’ensemble de l’entreprise, annonçant que la sécurité deviendrait une partie intégrée du codage de tous ses produits : « Lorsque nous sommes confrontés à un choix entre ajouter des fonctionnalités et résoudre des problèmes de sécurité », a écrit Gates, « nous devons choisir la sécurité. ... Nous sommes en train de former tous nos développeurs aux dernières techniques de codage sécurisé. ... Notre logiciel doit être si fondamentalement sécurisé que les clients ne s’en préoccupent même jamais. »
Il en a résulté le « cycle de vie du développement de la sécurité » révolutionnaire et largement copié de l’entreprise, un ensemble de pratiques qui intègrent la sécurité au produit au fur et à mesure qu’il se développe et mûrit. Les entreprises du paysage technologique ont depuis adopté et adapté ces pratiques de sécurité.
La leçon : l’ajout d’étapes de sécurité au cycle de vie du développement de produits peut très bien avoir un impact sur les délais. Et si les hauts dirigeants n’en font pas une priorité, il s’agira d’une vente beaucoup plus compliquée, plus basse dans la chaîne alimentaire. « De haut en bas, vous devez obtenir une compréhension commerciale conforme aux objectifs de l’entreprise », déclare Rosenquist.
« De haut en bas, vous devez obtenir une compréhension commerciale conforme aux objectifs de l’entreprise »Matthew Rosenquist, RSSI chez Eclipz.io Inc
David Hahn l’a vu directement. En tant que RSSI qui a travaillé dans la cybersécurité à la Silicon Valley Bank, au conglomérat des médias Hearst, Intuit et autres, il a conclu un partenariat avec des responsables informatiques en acceptant que la cybersécurité doive avoir une place à la table et en transmettant à leurs équipes l’importance de différents ensembles de compétences qui doivent finalement fonctionner ensemble. « Vous ne pouvez pas venir plus tard et faire en sorte que votre rôle soit le mauvais », dit-il.
Faire évoluer la responsabilité
Une façon de combler la fracture est de faire de la sécurité une partie plus intégrante du processus de développement. Près des deux tiers des entreprises d’aujourd’hui n’impliquent pas d’équipes de sécurité aux stades précoces des projets informatiques, selon une étude d’EY.
Une façon d’aider à combler cette lacune, selon les experts, est d’adopter les tests logiciels « shift left », en privilégiant les tests beaucoup plus tôt dans le cycle de développement, plutôt que de les combler après coup. Il encourage également, si ce n’est requis, une plus grande collaboration entre les équipes de sécurité et les développeurs.
Ces types de pratiques aident à éliminer les anciens silos. « Il s’agit de créer une nouvelle équipe », déclare Hahn. « Tout le monde devrait adopter des compétences en développement, sécurité et opérations, mais certaines auront plus d’expérience dans l’une que d’autres. »
Une façon de les obtenir est avec la formation. Fournir aux développeurs de logiciels des compétences en sécurité est « une opportunité de croissance », déclare Hahn. De même, de nombreux analystes de sécurité bénéficieraient de l’apprentissage du codage de base. « Ils peuvent commencer par un langage de codage comme Go ou Python pour comprendre la programmation procédurale et les complexités du développement logiciel », déclare Ax Sharma, chercheur et ingénieur en sécurité chez Sonatype, développeur de logiciels basé au Royaume-Uni. « Cela aidera à réduire le scepticisme quant à la capacité de la sécurité à participer aux livrables de l’équipe. »
DevSecOps : trouver de nouvelles façons de penser à la sécurité et au développement
Si les équipes de sécurité et de développement de logiciels peuvent découvrir un nouveau sentiment de kumbaya dans les années à venir, cela sera en partie dû au fait qu’elles ont adopté un style de travail qui a été extrêmement efficace pour réparer un autre problème d’entreprise ancien, entre les développeurs de logiciels et les équipes d’opérations informatiques. Au cours de la dernière décennie, les développeurs ont travaillé beaucoup plus étroitement avec les opérations informatiques pour intégrer les deux fonctions et expédier de nouveaux logiciels plus rapidement et plus efficacement que jamais.
Selon GitLab, il s’agit d’une méthodologie appelée DevOps, désormais en pratique sous une certaine forme par environ 62 % des entreprises. DevSecOps s’appuie sur la même notion, intégrant les tests de sécurité dans le processus pendant le développement, et non après.
DevSecOps n’implique pas seulement les équipes de sécurité plus tôt dans le processus, il permet au groupe collectif d’explorer la tolérance au risque. Pour les ingénieurs logiciels qui craignent que leurs collègues en cybersécurité ralentissent le développement, Hahn explique qu’il existe un moyen de mettre tout le monde sur la même longueur d’onde et de maintenir le code en mouvement : exposez-leur ce qui se passe si les vulnérabilités ne sont pas détectées tôt. « Introduisez un modèle de menace », dit-il. « Lorsque vous commencez à le cartographier, cela devient quelque chose de tangible. Cela devient une discussion sur l’ingénierie plutôt que « L’opinion de David n’était pas excellente, je n’aime pas ça. »
Un modèle de menace offre aux deux parties un moyen de rechercher des compromis. Par exemple, les ingénieurs logiciels souhaitent créer une version MVP ou bêta d’un nouveau produit qui inclut une base de données complète d’enregistrements propriétaires. La sécurité ne veut pas que cette base de données se trouve à proximité du produit tant qu’un test complet des vulnérabilités n’a pas été effectué. Un modèle de menace pourrait indiquer les risques inhérents à la mise à disposition de données sensibles dans un produit inachevé.
Et c’est ensuite à l’équipe de sécurité de s’exprimer. « Ils doivent dire : « Nous n’avons pas besoin de prendre ce risque. Nous pourrions saisir des données factices », déclare Hahn. Le rapport EY révèle également que les équipes de sécurité pourraient mieux communiquer ces risques.
Lorsque les deux parties se réunissent, Sharma suggère de commencer par des efforts à petite échelle, tels que l’examen de l’état des processus de sécurité et des niveaux de menace sur tous les produits. Cela permettra de prendre conscience de l’endroit où les vulnérabilités sont introduites. Ensuite, les deux équipes peuvent utiliser des outils d’automatisation de la sécurité, tels qu’un logiciel de détection des logiciels malveillants, pour chasser les vulnérabilités restantes. « Considérez le premier mois de vos efforts comme une phase d’observation afin que les équipes puissent voir l’effet, travailler ensemble et itérer pour éliminer le gaspillage », déclare Sharma.
Lorsque les choses sortent des rails
Parfois, les choses fonctionneront. D’autres fois, ce n’est pas le cas. Lorsque les deux parties ne fonctionnent pas ensemble, recherchez deux causes, déclare Hahn : le fluage de portée qui exclut un projet des délais et processus, et l’ego. « Comme pour les personnes qui n’adhèrent pas aux principes qu’elles avaient acceptés », dit-il.
À ce stade, il est temps de mettre le développement en pause, même si cela signifie repousser votre date de publication. Mieux vaut découvrir une vulnérabilité de sécurité qui retarde un projet de deux mois, déclare Hahn, que de faire face à une catastrophe potentielle après un lancement public.
« Il y aura toujours un coût », déclare Rosenquist, RSSI chez Eclipz.io. « Mais vous atténuez les pertes ou vous assurez de vous conformer à la réglementation. » L’unification de vos équipes de sécurité et informatiques, ajoute-t-il, n’est pas seulement bénéfique pour les employés. « Cela peut être un avantage concurrentiel. »
