Au cours de sa carrière d'ingénieur en cybersécurité, Matthew Rosenquist a connu son lot de frustrations. Il y a eu ce PDG qui a licencié sa propre équipe après que celle-ci lui eut signalé des failles dans le produit phare de l'entreprise. Il y avait des ingénieurs en informatique qui n'avaient aucune expérience en matière de sécurité, mais qui ne se souciaient pas d'en acquérir.
« À leurs yeux, ils étaient des programmeurs brillants, et cela leur suffisait », explique M. Rosenquist. « Ils ont dit : “Ce n’est pas mon problème.” » « Je me contente de le programmer pour que ça fonctionne, et le reste, c'est le problème d'un responsable de la sécurité. »
Cette attitude hostile est compréhensible. Les développeurs de logiciels évoluent dans un univers caractérisé par la conception itérative, les mises à jour rapides et le « produit minimum viable ». Par souci de gagner du temps et de se concentrer sur le code, ils ne se soucient guère d'autre chose, y compris de la sécurité. Ils considèrent souvent cela comme un frein au respect du calendrier, voire au 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 au conseil d'administration, qui a passé 23 ans chez Intel et occupe actuellement le poste de RSSI chez Eclipz.io, une entreprise spécialisée dans le chiffrement logiciel. « Vous avez des délais à respecter. » Votre évaluation porte sur votre capacité à faire fonctionner votre code dans les délais impartis. Ajoutez à cela un spécialiste de la cybersécurité qui ne connaît pas votre produit. « Vous voulez que je fasse X, Y et Z ? » « Ça va chambouler mon planning. » Ces tensions s'accumulent. « La seule chose pire, c’est de ne prendre aucune mesure de sécurité. »
Réparer la fracture
Les tensions décrites par Rosenquist ne sont pas nouvelles. Cette situation trouve son origine dans un fossé de longue date au sein de l'entreprise entre les équipes DevOps et les équipes de sécurité, et s'est aggravée en raison des défis posés par une crise sanitaire mondiale. Avec des millions de télétravailleurs accédant à des systèmes contenant des données sensibles via des dizaines de millions de terminaux, notamment 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 de dollars par an en raison des pannes informatiques. Les tensions entre les équipes n'arrangent rien.
Mais ils doivent travailler ensemble. Une pratique émergente appelée « DevSecOps », par exemple, vise à jeter des ponts entre ces deux domaines souvent en conflit en intégrant les membres et les processus de l'équipe de sécurité au cycle de vie du développement logiciel afin de détecter les vulnérabilités à un stade précoce. Malgré tout, des problèmes culturels profonds, une pénurie mondiale de compétences dans le domaine de l' ainsi que des structures organisationnelles et de sécurité continuent d'entraver l'harmonie entre les équipes. Alors que les responsables informatiques cherchent des moyens de surmonter ces obstacles, plusieurs bonnes pratiques se sont dégagées, à commencer par un engagement plus clair de la part de la direction et la mise en place d'une culture de collaboration. Voici comment commencer :
Donnez le ton dès le sommet
Après que deux virus dévastateurs eurent frappé Microsoft en 2001, Bill Gates a envoyé l’année suivante une note de service intitulée « » à l’ensemble de l’entreprise, annonçant que la sécurité ferait désormais partie intégrante du développement de tous ses produits : « Lorsque nous devons choisir entre ajouter des fonctionnalités et résoudre des problèmes de sécurité », a écrit M. Gates, « nous devons privilégier 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 sûr dans son fonctionnement que les clients n'aient même jamais à s'en soucier. »
C'est ainsi qu'est né le « cycle de vie de développement de la sécurité «» », une approche révolutionnaire et largement reprise par d'autres, qui consiste en un ensemble de pratiques visant à intégrer la sécurité au produit au fur et à mesure de son développement et de sa maturation. Depuis, les entreprises de tous les secteurs du monde des technologies ont adopté — et adapté — ces pratiques de sécurité.
La leçon à retenir : l'ajout de mesures de sécurité au cycle de vie du développement d'un produit peut très bien avoir une incidence sur les délais. Et si les dirigeants n'en font pas une priorité, cela sera bien plus difficile à faire accepter aux échelons inférieurs de la hiérarchie. « À un niveau hiérarchique élevé, il faut acquérir une compréhension des enjeux commerciaux qui soit en adéquation avec les objectifs de l’entreprise », explique M. Rosenquist.
«. Il faut, dès le départ, acquérir une compréhension des activités qui soit en adéquation avec les objectifs de l’entreprise »Matthew Rosenquist, responsable de la sécurité des systèmes d'information chez Eclipz.io Inc.
David Hahn en a fait l'expérience personnellement. En tant que RSSI ayant travaillé dans le domaine de la cybersécurité notamment à la Silicon Valley Bank, au sein du groupe de médias Hearst et chez Intuit, il a su nouer des partenariats fructueux avec des responsables informatiques en s'accordant sur le fait que la cybersécurité doit avoir sa place à la table des décisions et en faisant comprendre à leurs équipes l'importance des différentes compétences qui, en fin de compte, doivent travailler de concert. « Vous ne pouvez pas arriver plus tard et vous retrouver dans le rôle du méchant », dit-il.
Évolution de la responsabilité
Une façon de combler ce fossé consiste à intégrer davantage la sécurité dans le processus de développement. Selon une étude réalisée par EY, près des deux tiers des entreprises n'impliquent pas leurs équipes de sécurité dès les premières étapes de leurs projets informatiques.
Selon les experts, l’un des moyens de contribuer à combler ce fossé consiste à adopter une approche de test logiciel dite «shift left » (déplacement vers la gauche) : il s’agit de donner la priorité aux tests bien plus tôt dans le cycle de développement, plutôt que de les ajouter après coup. Cela encourage également, voire impose, une collaboration accrue entre les équipes de sécurité et les développeurs.
Ce genre de pratiques contribue à faire tomber les anciens cloisonnements. « Il s’agit de constituer une nouvelle équipe », explique Hahn. « Chacun devrait acquérir des compétences en développement, en sécurité et en exploitation, mais certains auront davantage d’expérience dans l’un de ces domaines que d’autres. »
L'une des façons d'y parvenir est de leur proposer une formation. Doter les développeurs de logiciels de compétences en matière de sécurité constitue « une opportunité de croissance », affirme M. Hahn. De même, de nombreux analystes en sécurité auraient tout intérêt à acquérir des connaissances de base en programmation. « Ils peuvent commencer par un langage de programmation tel que Go ou Python afin de comprendre la programmation procédurale et les subtilités du développement logiciel », explique Ax Sharma, chercheur en sécurité et ingénieur chez Sonatype, un éditeur de logiciels basé au Royaume-Uni. « Cela contribuera à réduire le scepticisme quant à la capacité du service de sécurité à participer aux livrables de l'équipe. »
DevSecOps : trouver de nouvelles façons d'aborder la sécurité et le développement
Si les équipes chargées de la sécurité et du développement logiciel parviennent à trouver un nouvel esprit de collaboration dans les années à venir, ce sera en partie parce qu’elles auront adopté un mode de travail qui s’est révélé extrêmement efficace pour combler un autre fossé historique au sein de l’entreprise : celui qui séparait les développeurs logiciels et les équipes d’exploitation informatique. Au cours de la dernière décennie environ, les développeurs ont collaboré beaucoup plus étroitement avec les équipes d'exploitation informatique afin d'intégrer ces deux fonctions et de mettre sur le marché de nouveaux logiciels plus rapidement et plus efficacement que jamais.
Il s'agit d'une méthodologie appelée « DevOps », qui est aujourd'hui mise en œuvre sous une forme ou une autre par environ 62 % des entreprises, selon GitLab. Le DevSecOps s'appuie sur ce même principe, en intégrant les tests de sécurité dès la phase de développement, et non après.
Le DevSecOps ne se contente pas d'impliquer les équipes de sécurité plus tôt dans le processus ; il permet à l'ensemble du groupe d'évaluer la tolérance au risque. Aux ingénieurs logiciels qui craignent que leurs collègues chargés de la cybersécurité ne ralentissent le développement, M. Hahn explique qu’il existe un moyen de mettre tout le monde d’accord et de maintenir le rythme de développement : leur exposer clairement les conséquences si les vulnérabilités ne sont pas détectées à temps. « Mettez en place un modèle de menaces », dit-il. « Lorsque vous commencez à mettre cela sur papier, cela prend une dimension concrète. » Cela se transforme en une discussion technique, plutôt qu’en une simple remarque du genre : « L’avis de David n’était pas terrible, ça ne me plaît pas. »
Un modèle de menace permet aux deux parties de rechercher un terrain d'entente. Par exemple, les ingénieurs en informatique tiennent à créer un MVP ou une version bêta d'un nouveau produit qui intègre une base de données complète de données propriétaires. Le service de sécurité ne souhaite pas que cette base de données se trouve à proximité du produit tant qu'un test complet visant à détecter les vulnérabilités n'aura pas été effectué. Un modèle de menace pourrait mettre en évidence les risques inhérents à la mise à disposition de données sensibles dans un produit inachevé.
Et c'est alors à l'équipe de sécurité de prendre la parole. « Ils doivent dire : “Nous n’avons pas besoin de prendre ce risque.” » « Nous pourrions insérer des données factices », explique M. Hahn. Le rapport d'EY conclut également que les équipes chargées de la sécurité pourraient mieux communiquer sur ces risques.
Pour rapprocher les deux parties, M. Sharma suggère de commencer par des initiatives à petite échelle, telles que l'examen de l'état des processus de sécurité et des niveaux de menace sur l'ensemble des produits. Cela vous permettra de mieux comprendre à quel moment les vulnérabilités apparaissent. Les deux équipes peuvent alors utiliser des outils d'automatisation de la sécurité d' , tels que des logiciels de détection de logiciels malveillants, afin de repérer les vulnérabilités restantes. « Considérez le premier mois de vos efforts comme une phase d’observation, afin que les équipes puissent en constater les effets, travailler ensemble et itérer pour éliminer le gaspillage », explique M. Sharma.
Quand les choses déraillent
Parfois, ça marche. D'autres fois, ce ne sera pas le cas. Lorsque les deux parties ne parviennent pas à collaborer, il faut en rechercher deux causes, explique M. Hahn : la dérive des objectifs, qui fait dérailler un projet par rapport à son calendrier et à son processus, et l'ego. « C’est-à-dire des personnes qui ne respectent pas les principes qu’elles avaient elles-mêmes acceptés », précise-t-il.
À ce stade, il est temps de suspendre le développement, même si cela implique de repousser votre date de sortie. « Mieux vaut découvrir une faille de sécurité qui retarde un projet de deux mois, affirme M. Hahn, que de devoir faire face à une catastrophe potentielle après un lancement public. »
« Il y aura toujours un coût », déclare M. Rosenquist, responsable de la sécurité des systèmes d'information chez Eclipz.io. « Mais vous prenez des mesures pour limiter les pertes ou vous vous assurez de respecter la réglementation. » Il ajoute que le fait de réunir vos équipes de sécurité et informatiques n'est pas seulement bénéfique pour les employés. « Cela peut constituer un avantage concurrentiel. »
