Aperçu du code sécurisé

Dans ce monde de plus en plus chaotique, il y a toujours eu quelques constantes sur lesquelles les gens pouvaient compter : Le soleil se lèvera le matin et se couchera le soir, Mario sera toujours plus cool que Sonic le hérisson, et les attaques par injection occuperont toujours la première place sur la liste de l'Open Web Application Security Project (OWASP) des dix vulnérabilités les plus courantes et les plus dangereuses que les attaquants exploitent activement.

Le soleil se lèvera demain et Mario a toujours une longueur d'avance sur Sonic, mais les attaques par injection ont perdu la première place sur la fameuse liste de l'OWASP, mise à jour en 2021. Les vulnérabilités par injection, l'une des plus anciennes formes d'attaques, existent depuis presque aussi longtemps que les réseaux informatiques. La vulnérabilité de couverture est à l'origine d'un large éventail d'attaques, allant des injections SQL traditionnelles aux exploits lancés contre les bibliothèques de navigation dans les graphes d'objets (OGNL). Elle est même à l'origine d'attaques directes contre des serveurs à l'aide de techniques d'injection de commandes du système d'exploitation. La polyvalence des vulnérabilités d'injection pour les attaquants - sans parler du nombre d'endroits susceptibles d'être attaqués - a permis à cette catégorie de rester en tête pendant de nombreuses années.

Mais le roi de l'injection est tombé. Vive le roi. 

Cela signifie-t-il que nous avons enfin résolu le problème des vulnérabilités par injection ? Il n'en est rien. Elle n'est pas tombée bien loin de sa position d'ennemi numéro un de la sécurité, puisqu'elle n'occupe plus que la troisième place sur la liste de l'OWASP. Ce serait une erreur de sous-estimer les dangers persistants des attaques par injection, mais le fait qu'une autre catégorie de vulnérabilité ait pu la surpasser est significatif, car il montre à quel point le nouvel ennemi numéro un de l'OWASP est répandu, et pourquoi les développeurs doivent y prêter une attention particulière à l'avenir.

L'élément le plus intéressant, cependant, est que le Top 10 2021 de l'OWASP reflète une refonte significative, avec de toutes nouvelles catégories qui font leur apparition : Conception non sécurisée, Défauts d'intégrité des logiciels et des données, et une entrée basée sur les résultats de l'enquête de la communauté : Falsification des requêtes côté serveur. Cela montre que l'accent est mis de plus en plus sur les vulnérabilités architecturales et que l'on va au-delà des bogues de surface pour la référence en matière de sécurité des logiciels.

Le contrôle d'accès brisé remporte la palme (et révèle une tendance)

Le contrôle d'accès brisé est passé de la cinquième place sur la liste des dix principales vulnérabilités de l'OWASP à la première place actuelle. À l'instar de l'injection et des nouvelles entrées telles que la conception non sécurisée, la vulnérabilité du contrôle d'accès interrompu englobe un large éventail de failles de codage, ce qui ajoute à sa popularité douteuse, car elles permettent collectivement de causer des dommages sur plusieurs fronts. La catégorie comprend tous les cas où les politiques de contrôle d'accès peuvent être violées afin que les utilisateurs puissent agir en dehors des autorisations prévues. 

Parmi les exemples de contrôle d'accès défaillant cités par l'OWASP pour élever cette famille de vulnérabilités au rang de priorité, on peut citer ceux qui permettent aux attaquants de modifier une URL, l'état interne d'une application ou une partie d'une page HTML. Elles peuvent également permettre aux utilisateurs de modifier leur clé d'accès principale afin qu'une application, un site ou une API croie qu'ils sont quelqu'un d'autre, comme un administrateur disposant de privilèges plus élevés. Il existe même des vulnérabilités où les attaquants ne sont pas limités à la modification des métadonnées, ce qui leur permet de modifier des éléments tels que les jetons web JSON, les cookies ou les jetons de contrôle d'accès.

Une fois exploitée, cette famille de vulnérabilités peut être utilisée par des attaquants pour contourner les autorisations de fichiers ou d'objets, ce qui leur permet de voler des données, voire d'exécuter des fonctions destructrices au niveau de l'administrateur, telles que la suppression de bases de données. En plus d'être de plus en plus courantes, les failles dans le contrôle d'accès sont donc extrêmement dangereuses.

Il est tout à fait convaincant - mais pas surprenant - que les vulnérabilités en matière d'authentification et de contrôle d'accès deviennent le terrain le plus fertile à exploiter pour les attaquants. Le dernier rapport d'enquête de Verizon sur les violations de données révèle que les problèmes de contrôle d'accès sont fréquents dans presque tous les secteurs, en particulier les technologies de l'information et les soins de santé, et que 85 % de toutes les violations impliquent un élément humain. L'expression "élément humain" couvre des incidents tels que les attaques par hameçonnage, qui ne sont pas un problème d'ingénierie, mais 3 % des brèches impliquaient des vulnérabilités exploitables et, selon le rapport, il s'agissait principalement de vulnérabilités plus anciennes et d'erreurs humaines, telles qu'une mauvaise configuration de la sécurité.

Alors que les bogues de sécurité décrépits comme XSS et l'injection SQL continuent de faire trébucher les développeurs, il est de plus en plus évident que la conception de la sécurité de base est défaillante, laissant place à des vulnérabilités architecturales qui peuvent être très avantageuses pour un acteur de la menace, en particulier si elles ne sont pas corrigées après que la faille de sécurité d'une version particulière d'une application a été rendue publique. 

Le problème est que peu d'ingénieurs bénéficient d'une formation et d'un développement des compétences allant au-delà des bases, et encore moins voient leurs connaissances et leurs applications pratiques étendues au-delà des bogues localisés, au niveau du code, qui sont généralement introduits par les développeurs.

Prévenir les bogues que les robots trouvent rarement

La nouvelle famille de vulnérabilités de contrôle d'accès brisé est assez diversifiée. Vous pouvez trouver des exemples spécifiques de contrôles d'accès brisés et comment les arrêter sur notre chaîne YouTube et notre blog.

Cependant, je pense qu'il est important de célébrer ce nouveau Top 10 de l'OWASP ; en effet, il est plus varié, englobant un plus large éventail de vecteurs d'attaque, y compris ceux que les scanners ne détecteront pas nécessairement. Pour chaque faiblesse trouvée au niveau du code, des failles architecturales plus complexes passeront inaperçues pour la plupart des technologies de sécurité, quel que soit le nombre de boucliers et d'armes automatisés dans l'arsenal. Si la majeure partie de la liste OWASP Top 10 est toujours établie sur la base de données d'analyse, les nouvelles entrées couvrant la conception non sécurisée et les failles d'intégrité des données - entre autres - montrent que les horizons de formation des développeurs doivent s'élargir rapidement pour réaliser ce que les robots ne peuvent pas faire.

En d'autres termes, les scanners de sécurité ne font pas de grands modélisateurs de menaces, mais une équipe de développeurs compétents en matière de sécurité peut aider l'équipe AppSec de manière incommensurable en développant leur QI de sécurité en ligne avec les meilleures pratiques, ainsi qu'avec les besoins de l'entreprise. Cela doit être pris en compte dans un bon programme de sécurité, en sachant que si le Top 10 de l'OWASP est une excellente base, le paysage des menaces évolue si rapidement (sans parler des exigences des objectifs de développement internes) qu'il doit y avoir un plan pour aller plus loin et de manière plus spécifique dans la montée en compétence des développeurs en matière de sécurité. Si vous ne le faites pas, vous manquerez inévitablement des occasions de remédier rapidement à la situation et vous empêcherez une approche holistique réussie de la cybersécurité préventive, dirigée par l'homme.

‍

Nous sommes prêts pour le Top 10 2021 de l'OWASP, et ce n'est que le début ! Mettez vos développeurs sur la voie d'une parcours de compétences en matière de sécurité dès aujourd'hui.

Le paysage des cybermenaces devient chaque jour plus complexe. Les attaquants scrutent constamment les réseaux à la recherche d'applications, de programmes et d'instances en nuage vulnérables, et la dernière nouveauté du mois est l'API, largement considérée comme une proie facile grâce à ses contrôles de sécurité souvent laxistes. Ils sont si tenaces que les nouvelles applications peuvent parfois être compromises et exploitées dans les heures qui suivent leur déploiement. Le rapport Verizon 2021 Data Breach Investigations Report montre clairement que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.

Il est de plus en plus évident que le seul moyen de fortifier véritablement les logiciels créés est de s'assurer qu'ils sont construits sur un code sécurisé. En d'autres termes, le meilleur moyen d'arrêter l'invasion des acteurs de la menace est de les empêcher de pénétrer dans vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont en faveur des attaquants.

Cette situation a d'abord donné naissance au développement agile et à DevOps, puis à l'ensemble du mouvement DevSecOps, où la sécurité est une responsabilité partagée par toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais la base de cette pyramide, et sans doute la partie la plus importante, ce sont les développeurs. Alors que la plupart des développeurs veulent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'un tel changement de priorités exige.

La défaite à dessein

Pendant de nombreuses années, on a dit aux développeurs que leur rôle principal au sein de leur entreprise était de créer et de déployer rapidement des applications dans un environnement en constante évolution, où les affaires ne s'arrêtent jamais et où les clients ne dorment jamais. Plus les développeurs pouvaient coder rapidement et déployer de fonctionnalités, plus ils étaient considérés comme utiles en termes d'évaluation des performances.

La sécurité n'était qu'un pis-aller, si tant est qu'elle ait été prise en compte. Tout cela était laissé à l'appréciation des équipes chargées de la sécurité des applications (AppSec). Ces équipes n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent les applications terminées en développement pour appliquer les correctifs de sécurité ou réécrire le code afin de remédier aux vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà "terminée" était une heure qu'il ne passait pas à créer de nouvelles applications et fonctionnalités, ce qui diminuait ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).

Ensuite, l'environnement des menaces a modifié l'importance et la priorité de la sécurité pour la plupart des entreprises. Selon le récent rapport Cost of a Data Breach Report d'IBM et du Ponemon Institute, le coût moyen d'une atteinte à la cybersécurité s'élève aujourd'hui à environ 3,8 millions de dollars par incident, bien que ce chiffre soit loin d'être la limite supérieure. Une entreprise a subi à elle seule des pertes de 1,3 milliard de dollars à la suite d'une atteinte à son réseau. Les entreprises d'aujourd'hui veulent la sécurité offerte par DevSecOps, mais, malheureusement, elles ont été lentes à récompenser les développeurs qui répondent à cet appel.

Il ne suffit pas de dire aux équipes de développement de prendre en compte la sécurité, surtout si elles sont encore récompensées sur la base de la seule rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de s'informer sur la sécurité et de sécuriser leur code pourraient en fait perdre de meilleures évaluations de performance et des primes lucratives que leurs collègues moins sensibilisés à la sécurité continuent de gagner. C'est un peu comme si les entreprises truquaient involontairement le système pour leurs propres échecs en matière de sécurité, et cela revient à la perception qu'elles ont de l'équipe de développement. Si elles ne les considèrent pas comme la ligne de front de la sécurité, il est très peu probable qu'un plan viable d'utilisation de leur main-d'œuvre aboutisse.

Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des dizaines d'années d'expérience en matière de codage, mais très peu en ce qui concerne la sécurité... après tout, cela ne leur a jamais été demandé. À moins qu'une entreprise n'offre un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ces derniers acquièrent soudainement de nouvelles compétences et les mettent en œuvre de manière significative afin de réduire activement les vulnérabilités.

Récompenser les développeurs pour leurs bonnes pratiques en matière de sécurité

La bonne nouvelle, c'est que l'écrasante majorité des développeurs font leur travail parce qu'ils le trouvent à la fois stimulant et gratifiant, et parce qu'ils apprécient le respect que leur position implique. Michael Shpilt, codeur professionnel de longue date , a récemment écrit sur toutes les choses qui le motivent, lui et ses collègues codeurs, dans leur travail de développement. Certes, il cite la rémunération monétaire parmi ces motivations, mais elle arrive étonnamment loin dans la liste. Il privilégie plutôt le plaisir de créer quelque chose de nouveau, d'acquérir de nouvelles compétences et la satisfaction de savoir que son travail sera directement utilisé pour aider les autres. Il dit aussi vouloir se sentir valorisé au sein de son entreprise et de sa communauté. En bref, les développeurs sont comme beaucoup de gens bien qui sont fiers de leur travail.

Les développeurs comme Shpilt et d'autres ne veulent pas que des acteurs menaçants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement changer leurs priorités en faveur de la sécurité sans soutien. Sinon, c'est comme si le système travaillait contre eux.

Pour aider les équipes de développement à améliorer leurs prouesses en matière de cybersécurité, il faut d'abord leur enseigner les compétences nécessaires. L'utilisation de l'apprentissage par échafaudage et d'outils tels que la formation juste à temps (JiT) peut rendre ce processus beaucoup moins pénible et permet de s'appuyer sur les connaissances existantes dans le bon contexte. 

Par exemple, si un outil de formation des développeurs JiT détecte qu'un programmeur crée un morceau de code non sécurisé ou introduit accidentellement une vulnérabilité dans son application, il peut activer et montrer au développeur comment il peut résoudre ce problème et comment écrire un code plus sécurisé pour exécuter la même fonction à l'avenir.

Avec un engagement en faveur de l'amélioration des compétences, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Au lieu de cela, les codeurs devraient être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs d'entre eux devenant des champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. Ces champions doivent être récompensés à la fois par le prestige de l'entreprise et par une compensation financière. Il est également important de se rappeler que les développeurs n'ont généralement pas une expérience positive de la sécurité, et les encourager avec un apprentissage positif et amusant et des incitations qui répondent à leurs intérêts contribuera grandement à assurer à la fois la rétention des connaissances et le désir de continuer à développer les compétences.

Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation d'un développeur, mais en sachant que le développement d'applications sécurisées peut prendre un peu plus de temps, notamment parce que les codeurs acquièrent ces nouvelles compétences.

DevSecOps peut être l'ultime défense contre les arts sombres d'un paysage de menaces de plus en plus dangereux. N'oubliez pas que les champions de ce nouveau monde, les développeurs qui créent constamment de nouveaux codes, doivent être respectés et rémunérés pour leur travail.

Vous voulez mettre vos compétences en matière de sécurité à l'épreuve face à d'autres développeurs du monde entier ? Consultez le site Secure Code Warrior's Devlympics 2021et vous pourriez remporter un prix important sur notre site tournaments!

Le secteur de la cybersécurité a connu ces derniers temps des évolutions très positives. Il semble que le sentiment d'accorder la priorité à la sécurité dans la conception des logiciels, le plus tôt possible, commence à s'améliorer dans de nombreuses organisations. Cette évolution, associée à des mesures officielles telles que le décret de M. Biden sur la cybersécurité, montre clairement que tout le monde doit faire sa part pour garantir la sécurité des logiciels et des données. Ce qui est particulièrement intéressant, c'est que le débat sur le rôle du développeur dans le maintien de normes de codage sécurisées continue d'évoluer, même au niveau gouvernemental.

Cependant, il manque quelque chose dans la conversation. Le décret suggère que les développeurs doivent posséder des compétences vérifiées en matière de sécurité, mais il n'existe actuellement aucune certification officielle de ce type. De nombreuses entreprises restent guidées par le NIST (qui a mis à jour ses lignes directrices en réponse au décret) dans leur quête de conformité et de normes plus élevées en matière de sécurité des logiciels, mais si nous pensons à des stratégies visant à réduire de manière significative les vulnérabilités, tout en incorporant les bons outils et en maintenant la vitesse de publication, la plupart d'entre elles sont tout simplement trop génériques pour produire le résultat désiré. C'est là que beaucoup d'entreprises se retrouvent bloquées, persévérant avec une formation limitée des développeurs, ou ne s'appuyant pas sur des bases générales pour leur permettre d'acquérir des compétences pratiques et concrètes.

Les développeurs sensibilisés à la sécurité ne poussent pas sur les arbres, mais ils peuvent être nourris et élevés beaucoup plus rapidement avec les bons outils. À cette fin, nous avons le plaisir d'annoncer notre propre cours de conformité NIST, structuré selon les directives de l'ordre exécutif du gouvernement américain.

Un soutien significatif au niveau du code pour les développeurs

En nous appuyant sur les lignes directrices du NIST relatives aux logiciels critiques pour l'ordre exécutif (EO-critical), nous avons structuré le cours de manière à atteindre les cinq objectifs clés qui, en fin de compte, amélioreront la sécurité des logiciels vitaux utilisés aux plus hauts niveaux du gouvernement et devraient idéalement servir de référence pour un développement de meilleure qualité à partir de la base.

Pour une véritable percée dans une cohorte de développement, tout perfectionnement doit aller au-delà de la théorie et être mis en œuvre d'une manière qui n'entraîne pas un changement constant de contexte entre le travail et la formation afin de trouver des réponses et de rester agile. Des pratiques de sécurité méticuleuses (sans parler de l'équipe de sécurité) sont considérées comme des obstacles à la réalisation de sprints de développement dans les délais et entravent sérieusement le style de l'ingénieur moyen axé sur les fonctionnalités. 

Les micro-apprentissages courts, à grignoter et adaptés aux besoins des développeurs reçoivent un accueil beaucoup moins glacial et permettent d'acquérir des compétences pratiques et mémorables. 

Regardez comment nous avons structuré cela pour notre cours NIST :

Objectif 1 : Protéger les logiciels critiques pour l'OT et les plates-formes logicielles critiques pour l'OT contre les accès et utilisations non autorisés.‍

Les pirates s'appuient sur une mauvaise configuration de la sécurité et sur des pratiques d'authentification inappropriées pour réussir à s'infiltrer dans les systèmes, à prendre le contrôle des comptes et à voler des données. Il s'agit d'un bogue courant qui peut entraîner d'énormes problèmes s'il est exploité avec succès.

Sur le site Secure Code Warrior Plateforme D'apprentissageles développeurs peuvent relever des défis basés sur des extraits de code réels qui reflètent fidèlement la façon dont ces bogues apparaîtraient dans leur travail quotidien, et les amener à trouver une solution précise pour les sécuriser. Pour les ingénieurs DevOps, la sécurisation de l'infrastructure nécessite des configurations de contrôle d'accès méticuleuses, et il existe des défis spécialisés pour répondre à cette exigence dans les langages Infrastructure as Code (IaC) comme Terraform, CloudFormation et Ansible, ainsi que dans le code utilisé dans Docker et Kubernetes.

Objectif 2 : Protéger la confidentialité, l'intégrité et la disponibilité des données utilisées par les logiciels critiques pour l'observation de la Terre et les plates-formes logicielles critiques pour l'observation de la Terre.

Pour cet objectif, tous les chemins mènent au contrôle d'accès. Un contrôle d'accès défaillant a récemment détrôné les failles d'injection en tant qu'entrée principale dans le Top 10 2021 de l'OWASP, et il s'agit d'un bogue sérieux qui nécessite les compétences de développeurs sensibilisés à la sécurité pour le trouver et le corriger le plus tôt possible.

Le cours aborde des concepts tels que le moindre privilège au niveau du code, et contribue à inculquer l'approche consistant à limiter l'accès aux comptes d'utilisateurs aux seuls domaines nécessaires en tant que meilleure pratique.

Objectif 3 : Identifier et maintenir les plateformes logicielles critiques pour l'OT et les logiciels déployés sur ces plateformes afin de protéger les logiciels critiques pour l'OT contre l'exploitation.

L'un des plus grands défis des grandes organisations est de maintenir une surveillance de la sécurité sur l'ensemble des différents logiciels, systèmes et composants actuellement en jeu. En ce qui concerne la gestion des risques et les correctifs, ces éléments doivent être une priorité dans tout programme de sécurité, les développeurs étant en état d'alerte pour assurer la maintenance de la sécurité. 

Sur le site Secure Code Warrior Plateforme D'apprentissage , les développeurs peuvent relever des défis qui les aideront à identifier et à corriger les composants vulnérables, ainsi que les erreurs de configuration de la sécurité fondées sur les autorisations.

Objectif 4 : Détecter rapidement les menaces et les incidents impliquant des logiciels et des plates-formes logicielles critiques pour l'OT, y répondre et s'en remettre.

Il est regrettable (et c'est une perte de temps et d'argent) que de nombreuses organisations se concentrent encore sur la réponse aux incidents - par opposition à la prévention - lorsqu'elles traitent des questions de cybersécurité. C'est une culture que nous nous efforçons de changer, et les développeurs sont en mesure de fournir une puissance de feu préventive lorsqu'ils sont correctement formés aux meilleures pratiques en matière de sécurité. 

L'objectif 4 exige des développeurs, dans le cadre de leur rôle, qu'ils surveillent en permanence la sécurité de leurs environnements et de leurs points d'extrémité, tant au niveau du logiciel que du réseau. L'insuffisance de la journalisation et de la surveillance est un autre bogue courant et insidieux, et il est vital que les ingénieurs soient capables de s'en servir avec succès dans leurs tâches quotidiennes.

Sur le site Secure Code Warrior Plateforme D'apprentissage , les développeurs peuvent relever des défis pour perfectionner ces compétences, qu'ils travaillent avec des langages web, API ou cloud.

Sensibilisation à la sécurité et durabilité.

Objectif 5 : Renforcer la compréhension et la performance des actions humaines qui favorisent la sécurité des logiciels critiques d'OT et des plateformes logicielles critiques d'OT.

Cet objectif est assez général, mais c'est le plus important à atteindre... et vous ne pouvez pas le faire sans maîtriser les quatre premiers objectifs. Cette ligne directrice demande que des activités fréquentes de sensibilisation à la sécurité soient menées et que toutes les "actions humaines" sur les logiciels critiques pour l'OT soient effectuées par des personnes ayant reçu une formation adéquate dans le cadre de leur rôle et de leurs responsabilités.

Les développeurs font partie de ceux qui sont les plus proches du code, en plus des configurations de sécurité et du contrôle d'accès. Leurs compétences en matière de sécurité doivent être entretenues et, pour atteindre les normes élevées définies par le NIST, une structure de cours pratique pourrait bien être le moyen le plus efficace d'y parvenir, en particulier avec de grandes cohortes de développeurs. 

Commencez dès aujourd'hui à ajouter des points d'expérience et un QI de sécurité à votre équipe de développement.

Cet article a été publié à l'origine dans Boulevard de la sécurité. Il a été mis à jour et publié ici.

‍

Il est presque ancré dans notre psyché collective qu'une plus grande quantité d'une bonne chose est une chose encore meilleure. Si vous avez un exemplaire de quelque chose que vous aimez vraiment, il n'y a rien de mal à en avoir deux ou trois, voire plus. Après tout, on ne peut pas avoir trop d'une bonne chose, n'est-ce pas ?

Malheureusement, si cette logique fonctionne pour certaines choses, il arrive qu'elle s'effondre rapidement à des volumes plus élevés. Dans certains cas, vous commencez à constater des rendements décroissants. Quelle valeur ajoutée ou quelle joie ce treizième morceau de gâteau au chocolat va-t-il vraiment vous apporter ? Et puis il y a d'autres moments où l'ajout d'une trop grande quantité d'une bonne chose peut devenir un profil de risque important pour vous ou votre organisation.

Trop d'outils de cybersécurité

Les outils de cybersécurité constituent un domaine critique où l'excès d'une bonne chose est rapidement devenu une mauvaise chose. En effet, ces dernières années, la plupart des organisations ont connu une prolifération incontrôlée d'outils de cybersécurité. Selon une étude publiée dans Dark Reading, la plupart des responsables de la sécurité de l'information utilisent en moyenne entre 55 et 75 produits ou applications de sécurité distincts pour protéger leurs réseaux. Et pourtant, les attaques continuent de passer. Selon le rapport Verizon 2023 Data Breach Investigations Report, les attaques réussies sont en augmentation, et les plus complexes d'entre elles prennent plus de temps que jamais à être détectées.

Comment les attaquants peuvent-ils contourner ce qui semble être à première vue un gantelet impossible de 75 outils de cybersécurité ou plus ? Le fait est qu'ils déclenchent souvent des alarmes, mais les défenseurs humains sont trop occupés à entretenir leurs outils de défense ou à répondre à des milliers d'alertes quotidiennes pour s'en apercevoir. Le fait de disposer d'un grand nombre d'outils de sécurité peut en fait donner aux attaquants la couverture dont ils ont besoin pour ne pas être détectés.

Un récent rapport de TechRadar a mis en évidence les conséquences négatives d'un trop grand nombre d'outils de cybersécurité. Parmi les entreprises interrogées, 71 % estimaient avoir plus d'outils que leurs équipes de cybersécurité ne pourraient jamais gérer avec succès. En fait, leur position en matière de sécurité se détériore au fur et à mesure que de nouveaux outils sont ajoutés. En fait, contrairement à la croyance selon laquelle plus d'outils équivaut à plus de sécurité, l'écrasante majorité des personnes interrogées ont déclaré se sentir beaucoup moins en sécurité à cause de tous les outils de cybersécurité installés dans leur environnement.

La situation n'a fait qu'empirer avec le passage massif à l'informatique dématérialisée dans la plupart des organisations. L'une des raisons pour lesquelles la superposition de nombreux outils de cybersécurité dans un réseau afin de couvrir toutes les voies d'attaque possibles est devenue populaire est qu'à une époque où les actifs étaient presque entièrement sur site, la stratégie a en quelque sorte fonctionné. Ou du moins, les organisations n'ont pas été confrontées à des rendements décroissants et à des conséquences négatives aussi rapidement. Dans les environnements en nuage, cependant, plus vous ajoutez d'outils, plus vous produisez de complexités et de vulnérabilités.

Outre le travail nécessaire pour maintenir des outils qui se chevauchent, l'autre grand problème d'une approche centrée sur les outils est l'océan de faux positifs qui ne manquera pas de se produire au fur et à mesure que de nouveaux outils seront mis en ligne. La chasse aux faux positifs peut accaparer tout le temps du personnel de sécurité humain sans que l'organisation n'en tire un réel bénéfice. Et pendant ce temps, une véritable attaque peut facilement se cacher dans toutes les fausses alertes. Les professionnels de la cybersécurité risquent de ne découvrir les vraies menaces que bien trop tard.

Une meilleure façon de faire

Il serait désastreux de supprimer tous les outils de sécurité de votre environnement. Mais vous ne voulez pas non plus en avoir tellement que les outils clés qui pourraient vraiment vous aider ne reçoivent pas suffisamment d'attention. Il est important de trouver la bonne sélection d'outils et de veiller à ce qu'il n'y en ait pas trop qui absorbent votre temps et vos ressources.

Pour que la consolidation des outils fonctionne, il faut investir simultanément dans une approche humaine de la sécurité. Et cela devrait inclure l'utilisation d'un atout qui n'a traditionnellement pas été déployé dans ce rôle : les équipes de développeurs chargées de coder les applications et les logiciels mêmes qui sont ciblés par les attaquants.

Bien que les développeurs n'aient traditionnellement pas été chargés de la sécurité, cette situation est en train de changer. En fait, encourager les développeurs à se concentrer sur la sécurité est une facette clé des mouvements DevSecOps, où chacun assume une part de responsabilité dans le déploiement d'applications sécurisées. Personne ne s'attend à ce que les développeurs deviennent soudainement des experts en sécurité ou qu'ils assument la responsabilité principale de la sécurité au sein de leur organisation, mais leur apprendre à écrire du code sécurisé et les récompenser pour un travail bien fait peut contribuer grandement à préparer le terrain pour l'élimination de tous ces outils de sécurité qui se chevauchent.

Si vous commencez par un code sûr et de qualité, vous pourrez facilement commencer à éliminer quelques-uns des centaines d'outils de cybersécurité conçus pour rechercher les exploits et les vulnérabilités les plus courants. Vous finirez par favoriser un environnement dans lequel les développeurs créeront un code sûr, et quelques outils de cybersécurité sélectionnés pourront servir de contrôle supplémentaire que les équipes de sécurité pourront facilement surveiller et maintenir sans être surchargées par une trop grande quantité d'une supposée bonne chose.

Les cyberattaques sont, sans aucun doute, en augmentation. Selon le rapport Verizon 2021 Data Breach Investigations Report, le paysage des menaces est aujourd'hui plus dangereux que jamais. Les organisations de toutes tailles sont confrontées à un volume d'attaques plus important et à un niveau de sophistication plus élevé de la part des acteurs de la menace qui les ciblent. Les taux de réussite des attaquants montent également en flèche.

L'analyse des attaques les plus récentes permet de révéler certaines des vulnérabilités et des techniques les plus courantes utilisées par les pirates au cours de cette offensive sans précédent contre les cyberdéfenses. Certaines des attaques les plus populaires, comme celles qui figurent dans le Top 10 des risques et vulnérabilités de sécurité pour 2021 de l'Open Web Application Security Project (OWASP), impliquent le vol ou la compromission d'informations d'identification. Et selon les recherches sur la sécurité menées par Akamai, l'écrasante majorité, près de 75 %, ciblait directement les informations d'identification détenues par les API.

L'essor et la possible ruine des API

Il n'est pas étonnant que les interfaces de programmation d'applications, plus communément appelées API, soient de plus en plus présentes dans les réseaux de presque toutes les organisations. Elles constituent un élément essentiel de la plupart des services en nuage, qui remplacent rapidement les fonctions des actifs sur site dans la plupart des entreprises, organisations et agences gouvernementales. De nos jours, il est pratiquement impossible d'exercer une activité ou d'accomplir une tâche sans passer par le cloud, en particulier pour les activités tournées vers le public. Cela signifie que les API seront certainement le ciment qui maintiendra ensemble un grand nombre de services dans chaque réseau.

Ce qui est étonnant avec les API, c'est qu'elles sont généralement petites et discrètes en termes d'allocation des ressources du réseau. De plus, elles sont totalement flexibles, ce qui leur permet d'effectuer presque n'importe quelle tâche. À la base, les API sont des éléments individuels de logiciel conçus pour contrôler ou gérer un programme particulier. Elles peuvent être utilisées pour exécuter des fonctions très spécifiques, comme l'accès aux données d'un système d'exploitation hôte, d'une application ou d'un service.

Malheureusement, c'est cette même flexibilité, et le fait qu'elles soient souvent petites et négligées par les équipes de sécurité, qui font des API des cibles attrayantes. La plupart des API sont conçues par les développeurs pour une flexibilité totale, de sorte qu'elles peuvent, par exemple, continuer à fonctionner même si le programme de base qu'elles gèrent est modifié ou changé. Et il existe peu de normes. Presque comme des flocons de neige, de nombreuses API sont uniques en ce sens qu'elles sont créées pour remplir une fonction particulière avec un seul programme sur un réseau spécifique. Si elles sont codées par des développeurs qui ne sont pas très sensibilisés à la sécurité ou qui ne se concentrent pas spécifiquement sur la sécurité, elles peuvent présenter et présenteront probablement un certain nombre de vulnérabilités que les attaquants pourront trouver et exploiter.

Malheureusement, le problème devient rapidement incontrôlable. Selon Gartner, d'ici 2022, les vulnérabilités impliquant des API deviendront le vecteur d'attaque le plus fréquent dans toutes les catégories de cybersécurité.

La principale raison pour laquelle les attaquants veulent compromettre les API n'est pas qu'ils puissent prendre le contrôle d'une fonction spécifique de l'API, mais plutôt qu'ils volent les informations d'identification qui y sont associées. L'un des plus gros problèmes des API, outre le fait qu'elles sont pleines de vulnérabilités, est qu'elles sont souvent sur-autorisées par rapport à leur fonctionnalité de base. Pour simplifier, la plupart des API ont un accès proche de celui d'un administrateur sur un réseau. Si un attaquant prend le contrôle d'une API, il peut souvent utiliser ses autorisations pour lancer des incursions plus profondes et plus substantielles dans un réseau. Et comme l'API a l'autorisation d'effectuer toutes les tâches vers lesquelles l'attaquant la redirige, ses actions peuvent souvent contourner la surveillance traditionnelle de la cybersécurité, car l'API n'enfreint aucune règle grâce à son accès à toutes les zones et à son laissez-passer VIP pour les coulisses.

Si les entreprises ne font pas attention, l'augmentation des API au sein de leur réseau et de leurs nuages peut également entraîner de graves problèmes si elles sont la cible d'attaquants.

Défendre les API

Aussi dangereuse que soit la situation des API, elle est loin d'être désespérée. Des mouvements tels que DevSecOps s 'efforcent de sensibiliser les développeurs à la sécurité et d'intégrer la sécurité et les meilleures pratiques dans tous les aspects de la création de logiciels, du développement aux tests et au déploiement. L'intégration de la sécurité des API dans le cadre de cette formation sera essentielle pour toute organisation qui souhaite contrer la tendance à l'exploitation des API jusqu'en 2022 et au-delà.

Cela dit, il existe quelques bonnes pratiques qui peuvent être mises en œuvre dès maintenant en termes de sécurité des API.

La première chose à faire est d'inclure des contrôles d'identité stricts pour toutes les API. Vous devriez presque les considérer comme des utilisateurs humains lorsque vous attribuez des autorisations. Ce n'est pas parce qu'une API n'est conçue que pour remplir une fonction spécifique que vous devez penser à ce qui pourrait se produire si un pirate parvenait à la compromettre. Envisagez d'utiliser un contrôle d'accès basé sur les rôles. Idéalement, vous devriez appliquer les principes de la confiance zéro à vos API et à vos utilisateurs, mais la route est souvent longue. Une bonne gestion des identités est un bon point de départ. Veillez simplement à inclure les API dans ce programme.

Vous devez également contrôler étroitement les différents appels effectués par vos API dans la mesure du possible. Si vous limitez ces appels à des demandes très contextuelles, il sera beaucoup plus difficile pour un pirate de les modifier à des fins malveillantes. Vous pouvez même superposer vos API, une API initiale effectuant un appel très contextuel à une autre API qui sait exactement ce qu'elle doit rechercher et ce qu'elle doit ignorer. Cela peut être un moyen efficace de limiter la fonctionnalité disponible pour un acteur de la menace, même s'il est en mesure d'exploiter et de compromettre une API au sein de cette chaîne.

Les menaces qui pèsent sur les API peuvent certainement sembler écrasantes. Mais en mettant en œuvre les meilleures pratiques et en aidant et récompensant les développeurs qui deviennent des champions de la sécurité, la situation peut sembler beaucoup moins désespérée. Avec une bonne formation et une bonne pratique, vous pouvez mettre en place un programme de sécurité solide qui laisse peu de marge de manœuvre aux attaquants, même s'ils devaient compromettre l'un de vos minuscules mais essentiels chevaux de bataille que sont les API.

À quand remonte votre dernier voyage en voiture ? Selon l'endroit où vous vous trouvez dans le monde, il s'agit peut-être d'un retour récent à l'ordre du jour, mais il n'y a rien de mieux que la route et le dépaysement. 

À moins que vous ne soyez une vulnérabilité logicielle, bien sûr.

Nous avons longuement parlé des dangers posés par les mesures de cybersécurité laxistes dans l'industrie automobile, avec des entreprises comme Tesla et Jeep qui travaillent déjà avec des chercheurs en sécurité, trouvant des bogues exploitables qui auraient pu conduire à de graves problèmes de sécurité s'ils n'avaient pas été découverts à temps et corrigés rapidement. Nous avons également évoqué le fait que, d'une manière générale, la sécurité des logiciels en est encore au stade du Far West. Les logiciels sont omniprésents et, pour de nombreux appareils connectés, véhicules et périphériques, les mesures de sécurité nécessaires vont bien au-delà de l'éducation et de la vigilance de l'utilisateur final.

Les vulnérabilités des API deviennent particulièrement insidieuses, le trafic d'API malveillantes ayant augmenté de plus de 300 % au cours des six derniers mois seulement. C'est plutôt inquiétant, étant donné que les véhicules modernes sont essentiellement des API sur roues. Ils sont connectés, très bavards avec d'autres applications, et pourraient être pris dans des attaques ciblées comme l'un des nombreux points d'extrémité vulnérables. 

Quand votre chargeur de VE en dit trop

Les véhicules connectés ont fait l'objet d'un examen minutieux en ce qui concerne la sécurité de leurs logiciels, mais qu'en est-il de leurs accessoires ? L'équipe de génie de Pen Test Partners a découvert plusieurs vulnérabilités au niveau du code dans six marques de recharge de véhicules électriques domestiques, ainsi que dans un réseau public de recharge de véhicules électriques très répandu.

Qui se soucie d'un chargeur ? Qu'est-ce qu'un pirate pourrait y gagner ? Malheureusement, l'un des inconvénients des technologies puissantes et profondes qui font des heures supplémentaires pour nous est que ces appareils ont généralement un mauvais cas de TMI. Les chargeurs de VE communiquent avec les applications mobiles qui les accompagnent par le biais d'API, dans un environnement basé sur le nuage, et tout cela peut être vulnérable à l'exploitation si le codage et la configuration ne sont pas sécurisés. Les API, de par leur conception, ouvrent les vannes de la communication entre les applications, et si ces points de terminaison ne sont pas soigneusement configurés, trop de choses pourraient être partagées - ou pire - accessibles via une porte dérobée vulnérable de l'application.

Pen Test Partners a découvert des vulnérabilités extrêmement dangereuses qui auraient pu conduire au détournement de millions de chargeurs de véhicules électriques, plusieurs cas de problèmes d'autorisation API qui ont permis la prise de contrôle d'un compte et le contrôle/accès à distance à un compte, et même la possibilité de perturber le réseau électrique par le biais du contrôle synchronisé de plusieurs dispositifs de véhicules électriques. Ces problèmes ont tous été corrigés, mais le fait que quelques lignes de code étaient tout ce qui séparait les attaquants d'une perturbation complète de la fonctionnalité de base et de l'infrastructure de service est profondément inquiétant. 

Ce n'est pas non plus comme s'il s'agissait d'une affaire de génie. Wallbox, par exemple, avait deux références d'objet directes non sécurisées (IDOR) dans son API, qui auraient permis la prise de contrôle du compte si elles avaient été exploitées. L'IDOR fait partie des failles d'authentification, qui occupent la deuxième place dans le Top 10 des vulnérabilités des API de l'OWASP. Cette vulnérabilité est aussi courante que la saleté, ce qui indique une défaillance dans l'apprentissage et la mise en œuvre d'un code de qualité. Nous ne pouvons pas continuer à connecter des appareils et des applications sensibles par le biais d'une myriade de voies de communication boguées, et les API mal configurées sont précisément cela. 

Travailler en toute sécurité avec les API automobiles demande de la formation et de la patience

Ce qui est frustrant avec la sécurité des API, c'est qu'elle est présentée comme une nouvelle vague de désastres de cybersécurité à essayer d'atténuer, alors qu'en réalité, il s'agit simplement d'un nouveau cadre pour les mêmes vieux problèmes que nous avons vus pendant des décennies dans le développement web. Les scripts intersites, les injections, les erreurs de configuration : cela vous rappelle quelque chose ?

Les indicateurs récents d'organisations telles que le NIST sont prometteurs et montrent que la sécurité des logiciels est de plus en plus réglementée et normalisée. Cependant, nous sommes encore loin de disposer des experts nécessaires pour ne serait-ce qu'entamer la quantité de protection qui doit être apportée au déluge de code écrit chaque jour. Les développeurs doivent voir leurs connaissances et leurs responsabilités en matière de sécurité renforcées, et ce n'est pas à eux de prendre l'initiative. Si vous avez une équipe qui travaille sur des systèmes embarqués dans des appareils, ou sur des API qui pourraient transformer une voiture en jouet télécommandé, vous devez vous assurer qu'elle est équipée de ce dont elle a besoin pour cesser d'introduire des vulnérabilités courantes. 

Les différences entre une API sécurisée et une API vulnérable en raison d'un XSS sont minimes, par exemple, mais il faut montrer aux développeurs les nuances qui différencient un mauvais modèle de codage d'un bon. En outre, les processus de développement paresseux sont souvent habituels dans les configurations d'API, de nombreuses autorisations étant accordées au-delà des exigences minimales requises pour que l'API puisse accomplir les tâches qui lui sont assignées, ce qui ouvre une surface de menace supplémentaire et un potentiel de vol de données. Ces facteurs doivent être pris en compte lors de la construction, mais s'ils ne sont pas intégrés dans des pratiques de développement acceptables, le processus continuera d'être un facteur de risque.

Éviter le nouveau terrain de jeu des acteurs de la menace

L'augmentation spectaculaire du nombre d'API ciblées par les acteurs de la menace montre que l'attention se porte sur ce qui est perçu comme un fruit à portée de main... et dans ce cas, il s'agit d'un fruit qui pourrait être une source de revenus importants, en plus des menaces potentielles pour la vie sous la forme d'une prise de contrôle potentielle d'un véhicule. 

Laisser la sécurité des API au hasard est un moyen infaillible d'introduire des problèmes plus tard, avec des conséquences potentiellement dévastatrices dans le pire des cas, et des travaux frustrants et des performances médiocres dans le meilleur des cas. Il devrait s'agir d'une considération essentielle dans le cadre de l'écosystème de communication des logiciels, et d'une priorité dans le cadre d'un programme de sécurité de premier ordre. La clé est de traiter chaque API comme s'il s'agissait d'un être humain et d'évaluer l'accès qu'il doit avoir. Jim de la comptabilité doit-il avoir accès à tous les documents juridiques sensibles de l'ensemble de l'entreprise ? Probablement pas, et en général, le contrôle d'accès est correctement déterminé dans le cas du personnel réel. On ne peut pas en dire autant des API, et il est important de se rappeler que ce sont de puissants bavards qui laisseront tout le monde connaître vos secrets s'ils ne sont pas configurés avec les mêmes méthodes de confiance zéro que tout le reste.

L'organisation doit être en état d'alerte, et les développeurs sont les yeux nécessaires sur le terrain pour créer un code de qualité exempt de ces portails vulnérables qui mènent au désespoir. Il est temps de leur donner la possibilité de se développer et de s'épanouir en tant qu'ingénieurs sensibilisés à la sécurité, avec l'état d'esprit adéquat pour atteindre cet objectif et les compétences pratiques nécessaires pour prendre les bonnes décisions lors des étapes critiques de la création.

Une version de cet article a été publiée dans le cadre d'un article de fond pour le Conseil technologique de Forbes. Elle a été mise à jour et publiée ici.

‍

Il n'y a rien de tel que de se trouver du mauvais côté d'une violation de données. Au début, il peut y avoir du déni, puis de la panique. Une fois que tous les jurons ont été prononcés et que le RSSI a dû organiser une conférence téléphonique avec les relations publiques à 2 heures du matin, il est temps de se retrousser les manches et de se mettre au travail pour sécuriser les terminaux et les systèmes, et éliminer rapidement tous les vecteurs d'attaque potentiels. Le moins que l'on puisse dire, c'est que ce n'est pas une partie de plaisir. 

Il s'agit pourtant d'une réalité à laquelle de nombreuses organisations seront confrontées à l'avenir et à laquelle il faut absolument se préparer au moyen d'un plan complet de réponse aux incidents de cybersécurité. Le problème, cependant, c'est que c'est sur cette stratégie réactive que se concentre une grande partie du temps, des ressources et des efforts, au lieu de travailler à prévenir ou à réduire la gravité potentielle des cyberattaques en amont. C'est un peu comme appeler une ambulance pour une crise cardiaque présumée ; les résultats sont souvent beaucoup moins positifs - pour ne pas dire plus dommageables - que si des mesures sanitaires préventives avaient été mises en place avant qu'il ne soit trop tard. 

À cette fin, à quoi ressemble un plan de prévention ? Voyons comment les professionnels de la sécurité peuvent utiliser tous les outils à leur disposition pour atténuer les cyberrisques qui ne cessent d'augmenter, chaque jour :

Comprendre l'ampleur du travail à accomplir 

Cela semble évident, mais le "bon" plan pour atténuer les cyberrisques présente des nuances selon les secteurs, et il est important de comprendre ce qui est nécessaire en amont pour atteindre le résultat souhaité.

Quels sont les problèmes de sécurité actuels ? Quels sont le temps et les ressources qu'ils requièrent ? Combien d'entre eux sont récurrents ? Ces facteurs sont importants et vous donneront un point de départ fondamental. Tenez compte des rôles à pourvoir, des lacunes dans les outils et de ce qui est nécessaire du point de vue de l'expertise et des outils pour sécuriser les points finaux et réduire la surface d'attaque, tout en évitant d'autres domaines de risque potentiel.

Un rapport récent a révélé que onze secteurs d'activité ont constaté une vulnérabilité grave, dans au moins la moitié de leurs applications, chaque jour au cours de l'année écoulée. En particulier, les secteurs des services publics, de l'administration publique et des services professionnels ont mis en moyenne 288 jours pour corriger les vulnérabilités connues. C'est incroyablement lent, ce qui laisse à un attaquant plus de temps qu'il n'en faut pour causer de graves dommages si ces vulnérabilités sont découvertes avant qu'un correctif ne puisse être appliqué. Cette situation, associée au fait que la probabilité que les organisations subissent une violation de données approche les 30 %, nous rappelle que la réaction aux incidents ne suffit pas et que les enjeux sont tout simplement trop importants pour se préparer à l'impact d'une cyberattaque à grande échelle et espérer que tout ira pour le mieux.

Préparez-vous à obtenir l'adhésion au changement culturel

Bousculer le statu quo a tendance à faire froncer les sourcils, mais la vérité est que les programmes de sécurité devraient être dans un état constant d'amélioration continue. Chaque composante doit rester pertinente et les nouveaux développements doivent être évalués et pris en compte. 

Mettre l'accent sur une approche préventive - par opposition à une approche réactive - peut ne pas être largement compris en dehors de l'équipe de sécurité, en particulier si un incident de sécurité important et grave n'a pas eu lieu. Cela peut être perçu comme quelque chose qui n'est pas cassé et qui n'a pas besoin d'être réparé. Dans ce cas, il est essentiel d'obtenir l'adhésion de la direction. Voici quelques-uns des points les plus pertinents à prendre en compte :

• Les économies de temps et d'argent réalisées grâce à des mesures préventives, telles que la formation basée sur les rôles et les outils connexes, par rapport au coût potentiel d'un incident critique. 
• Comment la recherche et la correction des vulnérabilités permettent désormais de respecter les délais de publication, avec moins d'interruptions de la part de l'équipe chargée de la sécurité.
• Pourquoi la préparation et l'anticipation des risques de sécurité potentiels, depuis l'équipe de développement jusqu'à la publication, permettent de gagner du temps (sans parler de l'argent) dans l'ensemble. Pour mettre les choses en perspective, les vulnérabilités tardives découvertes lors de la phase de test - ou pire, après la production - peuvent augmenter les coûts jusqu'à 3000 % en moyenne.
  

Il est essentiel que les changements culturels proposés soient alignés sur les objectifs de l'entreprise, même s'ils semblent inconfortables au départ. 

La sensibilisation à la sécurité est une chose, les compétences en matière de sécurité sont tout

En tant qu'industrie, nous parlons fréquemment de l'importance de la sensibilisation à la sécurité, et il s'agit d'un élément de plus en plus critique pour chaque membre du personnel d'une organisation. Cependant, il ne suffit pas de se contenter d'un discours et d'une formation passive, en particulier pour les personnes occupant des postes techniques.

En d'autres termes, toute personne qui touche au code présente un risque potentiel pour la sécurité si elle ne possède pas les compétences nécessaires pour coder de manière sécurisée. Une sensibilisation générale aux paramètres de sécurité de base est un bon début, mais sans une connaissance contextuelle des bons modèles de codage sécurisé, les mauvaises habitudes prévalent, et c'est sur ce manque de compétences en matière de développement de qualité que les attaquants s'appuient pour faire leur sale boulot. 

Ne faites pas une croix sur vos développeurs.

Bien que l'attitude évolue, de nombreuses organisations sont structurées de telle sorte que les développeurs sont rarement pris en compte dans les plans d'atténuation de la sécurité. Certains secteurs, comme la banque et la finance, ont des exigences strictes en matière de conformité et de réglementation qui se traduisent par des pratiques et des formations renforcées en matière de sécurité pour l'ensemble du personnel. Bien qu'elles soient certainement en avance sur d'autres secteurs, presque toutes les organisations de la planète pourraient bénéficier d'une armée interne de développeurs sensibilisés à la sécurité, tous dotés d'une capacité de base à détecter les bogues de sécurité les plus courants avant qu'ils ne soient commis. La plupart d'entre elles sont loin d'avoir réalisé cette pièce essentielle du puzzle du programme de sécurité - et c'est nécessaire si nous avons un jour l'espoir de sécuriser le déluge de code qui augmente en volume d'une année sur l'autre.

La sécurité préventive devrait commencer dès que les doigts touchent le clavier pour créer un logiciel, mais on ne peut pas attendre des développeurs qu'ils comblent seuls le fossé des compétences en matière de sécurité. Ils ont besoin des bons outils et d'une orientation contextuelle pour atteindre un niveau plus élevé de qualité du code, et les meilleurs résultats sont toujours obtenus lorsque cela fait partie de leur travail quotidien, et non pas d'une réflexion après coup qui est sporadiquement mise en œuvre lorsque les exigences de conformité annuelles se présentent.

Une version de cet article a été publiée dans TechCrunch. Elle a été mise à jour et publiée ici.

‍

Comme si nous n'avions pas eu assez de perturbations au cours de l'année qui ne peut être nommée, 2021 a commencé par un coup de tonnerre assourdissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds est une attaque dévastatrice et sophistiquée d'un État-nation qui a semé la panique dans plusieurs ministères et grandes organisations, qui se sont empressés de sécuriser leurs points d'extrémité. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, et l'incident a montré très clairement que la cybersécurité et la défense des chaînes d'approvisionnement en logiciels sont essentielles.

Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?

L'état de la cybersécurité dans l'équipe de développement moyenne

Une quantité énorme de logiciels est produite chaque jour, ce qui représente des milliards de lignes de code chaque année, et cela ne fait qu'augmenter avec la demande créée par nos modes de vie de plus en plus numériques. La population mondiale des développeurs devrait atteindre près de 29 millions de personnes d'ici à 2024, et il n'existe actuellement aucune certification officielle permettant d'évaluer et de certifier leur capacité à coder en toute sécurité. Cela ne veut pas dire que chaque développeur produit ou réutilise un code non sécurisé, mais il existe indubitablement un risque durable que des faiblesses de sécurité de base soient introduites dans les logiciels auxquels nous confions nos données.

Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer le code le plus rapidement possible. La sécurité n'a pas été un critère de réussite dans la plupart des organisations, mais ce sentiment commence à changer car de plus en plus d'entreprises réalisent le potentiel qu'elles détiennent en matière de prévention des bogues de sécurité courants dès les premières étapes de la création de logiciels. Cependant, la prise de conscience et la mise en œuvre sont deux choses différentes, et comme la plupart des développements tertiaires courses ne contiennent aucun contexte sur les pratiques de codage sécurisé, c'est souvent au lieu de travail d'un développeur de combler les lacunes. Si le développement des compétences et le partage des connaissances sont peu fréquents ou non pertinents, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues au manque de développement des compétences reste ininterrompu. 

Naturellement, il n'incombe pas au développeur de logiciels moyen de résoudre les problèmes de cybersécurité dans le monde ; après tout, ce n'est pas pour rien que les organisations embauchent des professionnels de la sécurité qui coûtent très cher. Les gourous de la sécurité se font rares, cependant, et les développeurs peuvent certainement jouer un rôle en réduisant la pression. 

Mais où cela nous mène-t-il - ainsi que les fournisseurs qui créent des logiciels pour les infrastructures critiques et les organisations sensibles - en termes de prévention d'une cyberattaque dévastatrice ? Il faudra à tout le moins modifier le statu quo en matière d'achat de logiciels.

Les pièges qui entravent la sécurité de la chaîne d'approvisionnement en logiciels

L'adage selon lequel une chaîne est aussi solide que son maillon le plus faible est malheureusement tout aussi vrai lorsqu'il s'agit de l'approvisionnement en logiciels. Peu importe que votre entreprise ait renforcé ses meilleures pratiques en matière de sécurité, qu'elle ait investi dans la formation continue des développeurs et qu'elle ait évolué vers un environnement DevSecOps fonctionnel (c'est-à-dire que tout le monde partage la responsabilité de créer des logiciels aussi sûrs que possible) ; si vous utilisez des logiciels d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences.

Bien sûr, l'équipe de sécurité devrait aider à évaluer la sécurité des ajouts de tiers à la pile technologique, mais les décisions peuvent être prises sur la base d'un besoin commercial avec peu de choix parmi les solutions. À ce stade, il peut s'agir d'un exercice de confiance. Le fournisseur se préoccupe-t-il de la sécurité autant que votre entreprise ? Et peut-il réellement évaluer les risques comme vous seul pouvez les comprendre, ainsi que les actifs que vous devez protéger ?

La transparence est un facteur très important dans l'évaluation de la viabilité de la sécurité des ajouts logiciels des fournisseurs. Sont-ils francs quant à leurs propres pratiques en matière de sécurité? Ils doivent être fiers de leur approche en matière de sécurité des données et en faire une priorité absolue. Si les pratiques de sécurité ne sont publiées nulle part, ou si aucune information n'est disponible, il y a de fortes chances que la sécurité ne soit pas une priorité. Le fournisseur doit être en mesure de répondre aux questions techniques, et des certifications indépendantes telles que ISO27001 et SOC2 ne seraient pas de trop. Par ailleurs, si vous ne pouvez pas "regarder sous le capot" et rechercher les vulnérabilités dans le cadre de vos propres pratiques internes de diligence et de sécurité, laissez tomber.

La demande entraînant une mise en œuvre aussi rapide des besoins logiciels, en particulier si le code du fournisseur est intégré dans des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur et l'acheteur doivent tous deux être au sommet de leur art, et leurs développeurs doivent être sur le terrain pour détecter les bogues et les failles de sécurité les plus courants avant l'expédition. Des centaines - voire des milliers - de dépendances peuvent être compromises si un nouvel élément vient s'ajouter à la toile d'araignée des solutions technologiques existantes, et une petite défaillance peut conduire à une défaite catastrophique.

Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? Si nous étions en 1998, cela pourrait avoir du sens. Cependant, de même que nous ne demandons plus à Jeeves où se trouve la station de lavage la plus proche, nous devons mettre en œuvre des mesures de protection réalistes qui fonctionnent dans le contexte d'aujourd'hui.

Il n'y a pas encore de solution miracle, mais il existe des solutions

Pour les acheteurs, la sécurité assessment des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme de sécurité global et du plan d'atténuation des risques. Posez des questions sur les certifications, les pratiques et la réputation de sécurité de leurs développeurs.

Les fournisseurs (et en fait toutes les entreprises qui créent des logiciels) doivent être prêts à démontrer que la sécurité est au centre de leurs préoccupations et doivent se concentrer sur la formation continue. Les développeurs compétents en matière de sécurité sont très demandés et, avec les outils et le soutien adéquats, ils peuvent être formés à partir de votre équipe existante et être habilités à se défendre contre les attaques résultant des vulnérabilités courantes. Mais ne leur donnez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité qui complètent leurs flux de travail existants. Rendez les choses aussi simples que possible et observez les bogues gênants commencer à disparaître du code qui alimente l'entreprise.

En définitive, les risques liés aux logiciels sont immédiatement exacerbés s'ils font partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et tous les systèmes où des composants vulnérables ont été utilisés. Si les fournisseurs ne sont pas aussi sérieux en matière de sécurité que les entreprises qui mettent en œuvre leurs logiciels - ou si le fournisseur et l'organisation présentent tous deux des lacunes dans leur programme de sécurité - des attaques de la chaîne d'approvisionnement plus dévastatrices et de plus grande portée comme celle de SolarWinds deviendront inévitablement la norme - et il s'agit là d'un problème critique pour tout le monde.

Bien que cela puisse sembler contre-intuitif pour toute personne travaillant en dehors du développement de logiciels, de nombreux professionnels employés dans la sécurité des applications au fil des ans ont travaillé dans ces rôles critiques avec peu ou pas d'expérience en programmation. Ces professionnels de l'AppSec font partie de l'équipe chargée de veiller à ce qu'aucune vulnérabilité ne se glisse dans les applications qui sont devenues l'élément vital de nombreuses industries et organisations, et pourtant, peu d'entre eux peuvent directement évaluer ou corriger le code eux-mêmes. 

Au lieu de venir d'une formation en codage, de nombreux professionnels de la sécurité abordent leur rôle du point de vue des connaissances clés sur les vecteurs d'attaque, les menaces, les exploits et les risques commerciaux ; ils ont une vision limitée du code. Si tous les gourous de l'AppSec n'ont pas les mêmes compétences, la journée type de beaucoup d'entre eux consiste à travailler avec des réviseurs de code et des outils d'analyse pour s'assurer que les programmes et les systèmes sont sécurisés conformément aux normes de l'organisation ou aux cadres sectoriels et gouvernementaux pertinents. Ils rédigent ensuite des rapports sur leurs conclusions et renvoient des informations sur le vecteur d'attaque susceptible de casser le code. Il appartient alors aux développeurs d'apporter les corrections nécessaires, même si cela perturbe le travail en cours.

Si la situation a évolué de la sorte, c'est parce que la logique qui a prévalu au fil des ans était que le travail de protection des réseaux et des applications était si vaste qu'il n'était pas logique d'attendre de chaque personne travaillant dans le domaine de la cybersécurité qu'elle remplisse toutes les fonctions. Les compétences en matière de codage profond étaient laissées aux développeurs, et la capacité à écrire ou à modifier du code plus loin dans le pipeline de développement n'était guère valorisée.

Cet état d'esprit est en train de changer rapidement, et cela représente une opportunité unique pour les développeurs de faire le saut lucratif et de changer de carrière dans l'AppSec. Tous les développeurs ne voudront pas embrasser le soi-disant côté obscur, et beaucoup de développeurs n'ont pas d'opinion particulièrement positive sur les équipes AppSec. Mais pour ceux qui le souhaitent, il n'y a jamais eu de meilleur moment pour saisir cet anneau de laiton de plus en plus tentant.

DevSecOps est au cœur de presque tous les secteurs d'activité

L'un des facteurs les plus importants pour accroître la valeur des programmeurs et des développeurs sensibilisés à la sécurité dans toute organisation est l'adoption quasi universelle de pratiques de développement plus agiles comme DevSecOps. Lorsque le développement, la sécurité et les opérations sont combinés, la cybersécurité devient une responsabilité partagée intégrée dans le développement d'un nouveau logiciel de bout en bout. Dans cet environnement, la capacité à coder est de plus en plus considérée comme un atout précieux pour tous, et c'est particulièrement vrai pour les ingénieurs qui comprennent aussi intrinsèquement la sécurité.

Un professionnel de l'AppSec qui comprend non seulement la cybersécurité à un haut niveau, mais aussi le code qui permet à tout de fonctionner, est intrinsèquement plus précieux pour une organisation que quelqu'un dont les connaissances sont concentrées sur la théorie. La capacité à découvrir et à évaluer rapidement les vulnérabilités trouvées dans le code, puis à atténuer ces problèmes, est au cœur de la raison pour laquelle DevSecOps connaît une telle popularité.

Les développeurs travaillant dans l'AppSec apportent également un autre avantage important à toute organisation qui les emploie. Comme ils viennent du côté du développement, il leur est facile de parler de sécurité et de vulnérabilités avec les développeurs. Il leur est également beaucoup plus facile de devenir des coachs pour les équipes de développement, en les aidant à devenir de meilleurs codeurs. Avec le temps, ils pourraient même être en mesure d'éliminer le stigmate du "côté obscur" de l'AppSec et d'aider à unifier les équipes de développement de logiciels au sein d'une organisation.

La pénurie de compétences en cybersécurité s'aggrave

Shakespeare a dit que c'est un vent mauvais qui ne fait de bien à personne. Ce qu'il voulait dire, c'est que même la situation la plus sombre profite probablement à quelqu'un. La pénurie de compétences en cybersécurité en est un excellent exemple.

La pénurie de personnel se fait sentir de manière aiguë presque partout. Dans une enquête récente menée par le Center for Strategic and International Studies, 82 % des décideurs informatiques ont déclaré que leur organisation souffrait d'une pénurie de compétences en matière de cybersécurité, et 71 % ont déclaré que cette pénurie avait entraîné des dommages directs et mesurables pour leur organisation. Pour mieux comprendre cette crise, le rapport souligne que rien qu'aux États-Unis, il y aura plus de 520 000 emplois non pourvus dans le domaine de la cybersécurité en 2020, alors qu'il n'y en a que 940 000 qui sont employés.

La pénurie de personnel dans le domaine de la cybersécurité est une mauvaise nouvelle pour les organisations qui tentent de protéger leur infrastructure, leurs activités et leurs données contre un paysage de menaces de plus en plus dangereux. Mais elle constitue une bonne opportunité pour les développeurs qui cherchent à se lancer dans l'AppSec et la sécurité. Il y a de fortes chances que des postes en cybersécurité et en AppSec soient disponibles presque partout. Et comme les postes en cybersécurité prennent en moyenne 21 % plus de temps à pourvoir ces jours-ci, les salaires augmentent dans tous les domaines.

Passer à l'AppSec

Il n'y a peut-être jamais eu de meilleur moment pour que les développeurs fassent le saut lucratif vers le côté ensoleillé de la sécurité. Les développeurs sensibilisés à la sécurité ne sont plus considérés comme un simple élément d'une méthode de sécurité palliative, mais remplissent au contraire un rôle à part entière et respecté de défenseurs de la cybersécurité. Cela est particulièrement vrai pour les organisations qui ont adopté DevSecOps et d'autres méthodologies de développement plus agiles. Et la pénurie de talents en cybersécurité signifie que des postes sont disponibles dans presque toutes les entreprises, agences gouvernementales ou organisations. Ceux qui possèdent les bonnes compétences peuvent choisir où ils veulent travailler.

Le passage à l'AppSec n'est peut-être pas fait pour tout le monde, et bien sûr, la plupart des développeurs resteront concentrés sur la création de fonctionnalités étonnantes. Mais pour ceux qui envisagent de faire le saut, investir dans une formation en sécurité pour compléter leurs compétences de codage existantes peut ouvrir de nombreuses portes. Les meilleurs spécialistes de l'AppSec sont issus de l'ingénierie, parce qu'ils comprennent profondément la technologie et ont de l'empathie pour les difficultés de leurs collègues développeurs. DevSecOps signifie que tout le monde est désormais responsable de la sécurité, alors pourquoi ne pas profiter de la pénurie actuelle de compétences critiques pour faire évoluer votre carrière vers la sécurité des applications ? Il n'y a jamais eu de meilleur moment pour prendre une décision positive pour vous-même, votre famille et votre carrière.