Il y a de fortes chances que si vous travaillez avec des logiciels d'une manière ou d'une autre, que vous soyez développeur, responsable de l'assurance qualité, responsable de l'ingénierie ou professionnel de l'AppSec, la sécurité fasse partie de votre travail. C'est le travail de l'équipe de sécurité de signaler les vulnérabilités des logiciels, et c'est le travail du développeur de faire de son mieux pour écrire un code sans faille au départ. Mais pour que ces tâches soient aussi efficaces que possible, il est important que toutes les parties collaborent pour lutter contre les menaces de sécurité, en commençant par le code sur lequel s'exécutent vos applications. 

L'apprentissage efficace du codage sécurisé et la conservation de ces connaissances peuvent toutefois donner l'impression qu'il s'agit d'une tâche difficile en soi. Avec les bons outils, ce n'est pas nécessaire. Mais il n'est pas toujours facile de convaincre les parties prenantes et les supérieurs d'investir dans le bon type de formation. La formation est trop souvent choisie dans le seul but de cocher une case de conformité et, la plupart du temps, elle n'a rien à voir avec le travail quotidien d'un développeur. Et si les développeurs pouvaient se former à la sécurité en temps réel, dans le langage et le cadre qu'ils utilisent tous les jours, tout en s'amusant ? Et pour couronner le tout ? Votre organisation se conforme en même temps aux normes de l'industrie.

Nous vous soutenons. Voici quelques stratégies pour obtenir l'adhésion de vos pairs, de vos responsables et des décideurs finaux de votre organisation à un programme de formation au codage de la sécurité axé sur les développeurs.   

Éviter les vulnérabilités des logiciels dès le départ permet d'économiser un temps et un argent incommensurables.

Passez-vous trop de temps à trouver, signaler ou résoudre des problèmes de sécurité récurrents ? Vous n'êtes pas le seul. 

Imaginez le scénario suivant : Dès que l'AppSec trouve une vulnérabilité et la signale au développement, les développeurs se lancent dans une leçon de formation pertinente et apprennent non seulement comment corriger cette faille, mais aussi comment éviter de commettre la même erreur à l'avenir. Quel serait, selon vous, le résultat ? Le développeur se souviendrait très probablement de cette leçon en raison de sa pertinence et serait moins susceptible de commettre à nouveau la même erreur. Cela signifie que si vous travaillez dans une équipe de sécurité, c'est un développeur de moins qui risque de créer à nouveau cette vulnérabilité sans le savoir et ce même développeur est moins susceptible de devoir revenir en arrière et la corriger à nouveau.

Regardez cette vidéo de notre client, Contrast Security, sur la puissance de la formation en temps réel pour son équipe de développement.

Si tous les développeurs participaient régulièrement à des formations sur le code sécurisé et disposaient d'outils leur permettant de se renseigner sur les problèmes de sécurité en temps réel, le temps récupéré pour créer des logiciels remarquables et travailler sur des programmes de sécurité serait incommensurable. Cela semble être un bon argument pour que votre organisation investisse dans un tel outil, n'est-ce pas ? 

Si vous avez trouvé un outil génial que vous aimeriez utiliser pour vous perfectionner en sécurité, quelque chose comme (cough) Secure Code Warriorc'est un excellent argument pour le présenter au CISO ou au CTO de votre organisation. 

Des développeurs responsabilisés produisent de meilleurs résultats et sont plus heureux.

Le temps et l'argent sont bien sûr très importants pour votre équipe de direction, mais la satisfaction au travail l'est tout autant. Des employés satisfaits obtiennent de meilleurs résultats, restent plus longtemps à leur poste et contribuent à un environnement de travail positif. C'est pourquoi le développement de carrière et la formation constituent un investissement et non un coût. Et si cette formation est amusante et qu'elle enseigne quelque chose de pertinent ? C'est un billet d'or pour la réussite. 

La bonne nouvelle, c'est que les développeurs sont généralement très motivés pour apprendre la sécurité parce qu'ils savent à quel point elle est importante pour leur travail. Nous avons interrogé des développeurs du monde entier dans le cadre d'une étude menée avec Evans Data Corporation et nous avons découvert que les développeurs veulent apprendre la sécurité pour les raisons suivantes : 

1. Il augmente la productivité et l'efficacité
2. Ils sont curieux et personnellement intéressés par le sujet.
3. Ils veulent éviter les problèmes liés à un code non sécurisé
4. Ils comprennent qu'ils ont la possibilité de progresser dans leur carrière.
5. Il s'agit d'une utilisation plus efficace des ressources humaines.
   

(Téléchargez le livre blanc complet ici).

Le seul problème, c'est que la plupart des formations au codage sécurisé les laissent tomber. Elle n'est pas adaptée à leur travail quotidien et, avouons-le, elle est carrément ennuyeuse. Ce sont là des caractéristiques qui ne donnent généralement pas de bons résultats en termes de rétention des informations et d'apprentissage réel. En revanche, lorsque le site Plateforme D'apprentissage est axé sur les développeurs, qu'il est amusant et attrayant et qu'il est en rapport avec leur travail, il peut donner de vrais résultats et créer des individus autonomes qui veulent écrire du code sécurisé. Et pourquoi votre patron, qu'il s'agisse d'un responsable du développement, d'un CISO ou d'un CTO, ne voudrait-il pas que les développeurs soient intéressés par le codage sécurisé et qu'ils aient les compétences nécessaires pour le faire ?

La compréhension de la sécurité fait de nous de meilleurs ingénieurs 

Lorsque les ingénieurs comprennent comment les logiciels peuvent être vulnérables aux attaques, ils font leur travail en gardant cela à l'esprit. Plus une personne comprend ce qui peut mal tourner, plus elle adopte une approche préventive.

En outre, un code de mauvaise qualité est plus susceptible de contenir des vulnérabilités logicielles et il est plus facile pour un développeur d'introduire à son insu une vulnérabilité dans ce code. Pourquoi ? Parce qu'une grande partie de leur travail consiste à lire et à modifier du code. Lorsque ce code est mal organisé et utilise une mauvaise logique, il faut plus de temps pour effectuer ces tâches et il devient plus facile de modifier quelque chose et d'introduire accidentellement un bogue de sécurité critique.

Lorsque l'on comprend la sécurité et la manière d'éviter les problèmes, on réfléchit aussi davantage à la qualité globale du code et à la manière de l'écrire de manière à ce qu'un bogue ne puisse pas être facilement introduit par accident. La formation à la sécurité est une formule gagnant-gagnant. Les développeurs apprennent à coder en toute sécurité, mais ils deviennent aussi de meilleurs ingénieurs. 

Le nombre fait la force

Une autre tactique efficace pour obtenir l'adhésion de vos dirigeants à l'adoption d'un codage sécurisé Plateforme D'apprentissage est d'obtenir l'adhésion de vos collègues. Plus il y a de développeurs désireux d'améliorer leurs connaissances en matière de sécurité, plus il sera facile de convaincre la direction ou la suite de la direction d'investir dans ce domaine.

Alors, comment faire ? Étant donné que la plupart des développeurs comprennent la nécessité de s'améliorer en matière de sécurité et veulent apprendre, cela ne devrait pas être trop difficile. Vous pouvez également leur demander de jeter un coup d'œil à la vitrine des développeursSecure Code Warrior , de découvrir notre produit et de commencer à tester leurs compétences en matière de codage sécurisé. Une fois qu'ils auront vu l'impact d'un code non sécurisé et appris que l'apprentissage de la sécurité peut être amusant, ils se sentiront encouragés à en apprendre davantage.

Une fois que vous avez adopté l'outil adéquat, une compétition saine est un excellent moyen d'inciter vos développeurs à s'impliquer. Essayez de lancer votre programme de formation en organisant un concours tournament. 

Découvrez comment Nelnet a fait preuve d'une grande créativité avec tournaments pour créer une culture de la sécurité au sein de son entreprise.

La formation continue en matière de sécurité favorise une culture d'entreprise souhaitable

La formation n'a pas à être ennuyeuse, et elle ne devrait pas l'être. Nous savons que les cours magistraux sont coûteux, difficiles à organiser - en particulier avec des équipes distribuées - et qu'il est peu probable que vous en retiriez grand-chose. Mais les organisations continuent à proposer aux développeurs des formations sur le codage sécurisé qui ne font guère plus que cocher une case chaque année pour la conformité. Il ne suffit plus de maintenir le statu quo. Il est temps que les responsables du développement et de l'AppSec améliorent leur jeu et travaillent ensemble pour mettre en œuvre un outil de formation qui favorise un apprentissage continu et engageant. Et cela commence par convaincre les décideurs.

Une formation continue et pratique est nécessaire pour un certain nombre de raisons. Les menaces liées à la cybersécurité évoluent en permanence, il est donc naturel que la formation à la lutte contre ces menaces soit elle aussi continue. De plus, comme nous l'avons déjà mentionné, lorsque nous apprenons en temps réel, nous avons beaucoup plus de chances de retenir ce que nous avons appris. Il est difficile de coder en tenant compte de la sécurité, car il est irréaliste d'attendre d'un développeur qu'il se souvienne de quelque chose qu'il a appris dans un diaporama hors contexte, peut-être près d'un an auparavant. Mais s'il apprend comment éviter une vulnérabilité logicielle particulière au moment où elle lui est signalée et qu'il a l'impression de jouer à un jeu en même temps, c'est une toute autre affaire. 

Dès qu'une formation pratique et pertinente est mise en place, la sécurité fait partie de la culture de l'entreprise et n'est plus considérée comme une réflexion après coup. Elle est intégrée au processus de développement dès le début du cycle de vie du logiciel. 

Qu'attendez-vous ? Commencez à améliorer la sécurité au sein de votre organisation et à protéger les données vitales de votre entreprise et de vos clients. Obtenez l'adhésion de vos développeurs et de vos supérieurs pour faire passer le codage sécurisé au niveau supérieur dans votre organisation. Ne subissez plus les mêmes vulnérabilités une fois pour toutes en pensant à la sécurité dès le départ. 

Besoin de plus de ressources? ‍

Téléchargez le kit complet "Convaincre votre RSSI / CTO".

Au début du mois d'octobre, Apache a publié la version 2.4.49 pour corriger une vulnérabilité de type "Path Traversal and Remote Code Execution", puis la version 2.4.50 pour remédier au fait que la correction de la version 2.4.49 était incomplète. Vous avez peut-être entendu parler sur les médias sociaux de l'importance de mettre à jour la dernière version pour éviter ces risques, étant donné qu'Apache alimente 25 % de l'internet selon certaines estimations. Mais qu'en est-il ? Quel est le niveau de risque ?

Pourquoi ne pas l'essayer vous-même ? 

Nous avons conçu une mission pour démontrer les risques dans un environnement réel et nous l'avons rendue publique pour que tout le monde puisse l'essayer. Dans cette mission, nous vous expliquons comment la vulnérabilité Path Traversal peut avoir un impact sur votre infrastructure et vos applications. Cliquez ci-dessous pour entrer directement dans le vif du sujet, ou continuez à lire pour en savoir plus sur la vulnérabilité en détail.

À propos de la vulnérabilité liée au détournement de chemin 

La vulnérabilité a été introduite dans la version 2.4.49(en raison d'une modification de la fonction de normalisation des URL), où une nouvelle fonction de normalisation des chemins a été introduite. Malheureusement, elle n'a pas réussi à normaliser correctement les chemins codés en URL. Il est donc possible de mener une attaque par traversée de chemin si la configuration suivante n'est pas présente :

Et si mod_cgi est activé, il peut également être exploité pour créer une vulnérabilité d'exécution de code à distance. Mais penchons-nous d'abord sur l'encodage des URL pour mieux comprendre ce qui a mal tourné.

Codage de l'URL

Dans sa forme la plus élémentaire, la vulnérabilité est due à un manque de prise en compte des URL codées. La fonction de normalisation des chemins nouvellement introduite n'a pas entièrement traité les cas où les points étaient codés en URL. 

Rappelez-vous que pour mener une attaque par traversée de chemin, vous devez traverser avec la séquence ../. La fonction de normalisation est cependant assez intelligente pour supprimer cette séquence. Que faire alors ? Vous pouvez coder un .(Point) en URL jusqu'à %2e, et utiliser une séquence comme .%2e/. Cela fonctionnerait dans de nombreux cas avec Apache 2.4.40. Mais vous pouvez aussi aller plus loin et le coder doublement. La version codée en URL de .%2e/ est .%252e/. Cela a permis de contourner la tentative de normalisation d'Apache.

Mais il y a un hic

Si quelqu'un voulait essayer d'exploiter cette vulnérabilité directement dans son navigateur, il n'y parviendrait pas. En effet, les navigateurs tentent également de normaliser les URL envoyées aux serveurs. Cela signifie que même notre séquence doublement codée sera supprimée. Cela signifie également que nous ne pouvons pas nous contenter d'utiliser un navigateur pour le démontrer.

Vous pouvez utiliser cURL pour démontrer cela en utilisant l'option --path-as-is , qui l'empêche de normaliser l'URL avant de l'envoyer :

Prévention et atténuation

Pour éviter complètement ce problème, il est important de rester à jour avec les derniers correctifs d'Apache. En particulier, vous devez mettre à jour vers la version 2.4.51 au minimum. Mais il est conseillé de procéder à des mises à jour régulières pour rester à jour.

Pour éviter ce problème, si vous utilisez la version 2.4.49, assurez-vous d'avoir inclus les éléments suivants dans votre configuration Apache :

Et pour éviter l'exécution de code à distance, désactivez mod_cgi si vous ne l'utilisez pas.

Faites l'expérience de l'impact par vous-même

Vous souhaitez savoir exactement ce qui s'est passé et l'essayer vous-même ? 

‍

Micha Martinez est analyste en cybersécurité et directeur de la photographie chez Nelnet, un conglomérat américain qui s'occupe de l'administration et du remboursement des prêts étudiants et des services financiers pour l'éducation. Lorsqu'il a été chargé de créer un programme de formation pour les développeurs sur le codage sécurisé, il a trouvé des moyens créatifs d'impliquer son équipe. Nous avons été tellement impressionnés par la manière dont il gère son programme de formation au codage sécurisé que nous nous sommes entretenus avec lui pour en savoir plus. 

Le résultat ? 

Créez une culture de la sécurité et nourrissez vos champions internes de la sécurité au sein de vos équipes de développement "pour qu'ils soient la force du bien". 

"En nous concentrant sur la sécurité du code, nous avons contribué à rendre l'entreprise plus forte et plus sûre. 

Chez Nelnet, Micha et son équipe de sécurité ont compris l'importance de construire un code sécurisé dès le départ. Ils voulaient y parvenir d'une manière attrayante, pertinente et gratifiante. Il a découvert qu'en identifiant les développeurs ayant un fort intérêt et des compétences en matière de codage sécurisé et en les encourageant à devenir des champions de la sécurité, ces champions sont devenus le catalyseur du changement de mentalité autour de la formation à la sécurité dans son ensemble. Ces personnes encadrent leurs collègues qui ont besoin de plus d'aide, d'égal à égal, et deviennent les leaders de la mise en œuvre des changements dans les pratiques de codage sécurisé au sein de l'organisation. 

Micha nous en dit plus sur la manière dont lui et son équipe ont fait évoluer les mentalités et la culture autour de la prévention de la sécurité, ce qui a rendu leur entreprise "plus forte et plus sûre".

Il s'agit avant tout de se vanter... et de réduire les vulnérabilités.

Micha ne dirige pas un programme de formation à la sécurité comme les autres. Il utilise la concurrence et ses talents de cinéaste pour rendre tournaments extrêmement attrayant et réussi. Les développeurs y gagnent des connaissances pratiques très pertinentes qui leur permettent d'obtenir des codes plus sûrs. 

L'entreprise est également gagnante car ses produits deviennent plus sûrs et offrent un niveau de protection plus élevé contre les vulnérabilités des logiciels. L'apprentissage de la sécurité des logiciels ne doit pas être une expérience d'apprentissage typique et ennuyeuse qui se limite à cocher une case. Les développeurs veulent des expériences de formation immersives et stimulantes, ainsi que pertinentes pour leur travail quotidien. 

Regardez Micha expliquer comment il rend la formation au codage sécurisé amusante grâce au site tournaments et aux ceintures de championnat physiques, à la manière de la lutte maniaque, qu'il offre en récompense. Tout ce qu'il faut, c'est un peu de compétition saine pour que son équipe garde la sécurité à l'esprit. 

Qui n'aime pas se vanter ? 

‍

Adoptez une culture centrée sur le codage sécurisé... l'outil ne suffit pas.

Micha nous a laissé une dernière réflexion sur les raisons pour lesquelles il recommande Secure Code Warrior. La plateforme a été le véhicule qui l'a conduit à créer une culture préventive et un apprentissage proactif. Il a fallu du temps pour mettre en place le programme de formation et investir dans les développeurs qui se forment et obtiennent de bons résultats. Il faut une culture de transformation pour développer les compétences de chaque développeur afin qu'il adopte une approche préventive pour coder en toute sécurité. 

Micha nous explique pourquoi l'adoption d'une culture de codage sécurisé fait toute la différence à l'adresse Secure Code Warrior.

Secure Code Warrior offre aux développeurs un codage sécurisé immersif et engageant : Plateforme D'apprentissage . Intéressé par une démonstration ? Réservez-en une ci-dessous. 

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.