Code de sécurité Insight

Cet article a été initialement publié sur. Informations sur la sécurité, et repris par plusieurs autres publications. Il a été mis à jour ici à des fins de syndication.

À la fin de l'année dernière, la remarquable communauté MITRE a publié une liste des 25 erreurs logicielles les plus dangereuses qui ont eu un impact mondial en 2019. Cette liste n'est pas basée sur des opinions, mais sur les résultats d'une analyse multidimensionnelle utilisant les travaux d'organisations telles que le NIST et le Common Vulnerabilities and Exposures (CVE). Le NISTa publié des données sur les vulnérabilités et les expositions courantes (CVE). Afin d'identifier les failles « majeures », celles-ci sont notées en fonction de leur gravité, de leur exploitabilité et de leur prévalence dans les logiciels actuels. Il ne s'agit pas d'une liste susceptible de susciter des éloges, cela ne fait aucun doute.

Cependant, contrairement à la plupart des résumés annuels, de nombreux participants figurant sur cette liste ont déjà été mentionnés précédemment. Si ce classement était le Billboard Hot 100, il serait similaire àcelui de Britney Spears.Baby One More Time et BackstreetBoys apparaissent chaque année depuis leur sortie initiale.Pourquoi ai-je sélectionné ces chansons ? Eh bien, j'ai environ vingt ans (cela semble-t-il déjà lointain ?) et, bien qu'elles aient été découvertes il y a plusieurs décennies, elles sont très similaires aux erreurs logicielles dangereuses qui continuent de nous affecter en 2020.

Pourquoi les anciens bugs restent-ils dangereux ? Comment les corriger ?

Actuellement, le sixième élément de la liste MITRE est mieux connu sous le nom de CWE-89SQLInjection (SQLi). La vulnérabilité SQLi a été découverte pour la première fois en 1998, à une époque où de nombreuses personnes posaient leurs questions les plus importantes à Zibs plutôt qu'à Google.Bien que des correctifs aient été rapidement mis à disposition, cette méthode reste l'une des techniques de piratage les plus utilisées en 2019. rapport sur l'état de l'Internet , SQLi était responsable de deux tiers des attaques. Toutes les attaques contre les applications web

En termes de complexité, l'injection SQL est loin d'être une exploitation de niveau génial. Il s'agit d'une solution simple pour les développeurs web, et nous devons sans hésiter apprendre comment empêcher cette vulnérabilité d'exposer des données précieuses aux attaquants... Le problème est qu'aujourd'hui encore, la sécurité n'est pas une priorité pour de nombreux développeurs. Cela était peut-être plus facile il y a 20 ans, mais avec la quantité considérable de logiciels créés aujourd'hui et à l'avenir, cela ne peut plus être considéré comme normal.

La plupart des développeurs travaillent sur des systèmes défaillants.

Il est très facile de rester assis et de critiquer les développeurs qui fournissent un code « incorrect ». En réalité, leurs priorités diffèrent considérablement de celles de l'équipe de sécurité. En général, on demande aux équipes de développement de créer des logiciels esthétiques et fonctionnels le plus rapidement possible. En raison de la demande sociale incessante en matière de logiciels, les équipes de développement sont déjà surchargées et la sécurité n'est pas une priorité. N'est-ce pas là la raison d'être des experts en sécurité des applications ? Les ingénieurs logiciels sont habitués à entretenir une relation quelque peu distante avec la sécurité. Ils ne sont sollicités que lorsque des problèmes surviennent, ce qui peut retarder leur travail déjà chargé.

En revanche, les experts en sécurité des applications sont épuisés de devoir corriger des erreurs vieilles de plusieurs décennies qui apparaissent systématiquement lors de chaque analyse et révision manuelle du code. Ces experts sont coûteux et rares, et il est préférable d'investir leur temps dans la correction de failles de sécurité complexes plutôt que dans l'élimination répétitive de bogues bien connus.

Ces équipes ont une culture implicite de transfert de responsabilité, mais elles partagent (ou devraient partager) le même objectif : la sécurité des logiciels. Les développeurs travaillent dans un environnement où ils ont peu de chances de réussir en matière de codage sécurisé. Les meilleures pratiques en matière de sécurité sont rarement enseignées dans l'enseignement supérieur, et la formation pratique est souvent trop rare ou inefficace. Il y a un manque flagrant de sensibilisation à la sécurité et de formation approfondie dans ce domaine. Il en résulte des coûts astronomiques pour corriger les anciens bogues du code validé et la menace imminente d'une atteinte à la réputation due à une violation des données.

Facteur humain, ou « Pourquoi tous ces outils ne parviennent-ils pas à sécuriser davantage les données ? »

Un autre problème récurrent est que, plutôt que de se concentrer sur la formation, une quantité considérable d'outils de sécurité est déployée pour détecter les problèmes avant la sortie des logiciels. Les outils d'inspection et de protection des applications en réseau (Fast/Dust/Raz/Toast) peuvent certes contribuer à la création de logiciels de sécurité, mais ils présentent leurs propres défis. Le fait de s'appuyer entièrement sur ces solutions ne garantit pas la sécurité. Les raisons sont les suivantes :

• Il n'existe pas d'outil unique capable d'examiner toutes les vulnérabilités dans tous les cas d'utilisation de tous les frameworks.
• En particulier, lorsque les analyses statique et dynamique du code sont exécutées simultanément, la vitesse peut être réduite.
• Les faux positifs constituent toujours un problème. Dans de tels cas, la production est souvent interrompue et une vérification manuelle inutile du code est nécessaire pour identifier les avertissements.
• Ces outils suscitent des attentes quant à leur capacité à résoudre les problèmes, ce qui conduit à une perception erronée de la sécurité, notamment en reléguant la priorité accordée au codage sécurisé.

Ces outils permettront certainement de détecter les failles de sécurité pouvant être corrigées par des correctifs. Cependant, peuvent-ils tout détecter ? Il n'est pas possible de garantir un taux de réussite de 100 %, et il suffirait qu'une seule porte soit laissée ouverte pour qu'un attaquant puisse s'introduire et causer des dommages considérables.

Heureusement, de nombreuses organisations reconnaissent l'importance du facteur humain. Vulnérabilité des logiciels. La plupart des développeurs n'ont pas reçu une formation suffisante en matière de codage sécurisé et ont une faible conscience globale de la sécurité. Cependant, ils se trouvent au début du cycle de vie du développement logiciel et sont les mieux placés pour empêcher les vulnérabilités de s'infiltrer dans le code validé. En codant de manière sécurisée dès le départ, ils peuvent constituer la première ligne de défense contre les cyberattaques destructrices qui causent des milliards de dollars de pertes chaque année.

Les développeurs doivent avoir la possibilité de réussir grâce à une formation leur permettant de maîtriser leur langage, d'acquérir des compétences pertinentes pour leur poste et de s'intéresser activement à la sécurité. Un code sans bug doit être une source de fierté. Tout comme la création d'une fonctionnalité remarquable peut susciter le respect de ses collègues.

Les programmes de sécurité les plus récents doivent constituer une priorité pour les entreprises.

L'équipe de développement ne peut pas utiliser Bootstrap pour promouvoir une culture de sécurité positive dans l'ensemble de l'entreprise. Pour intégrer la sécurité dès le début du processus de développement logiciel, il est nécessaire de disposer des outils, des connaissances et du soutien appropriés.

Si la liste du MITRE contient encore un nombre excessif de failles de sécurité anciennes, il est évident que les méthodes de formation précédentes ne sont pas efficaces. Par conséquent, il est recommandé d'essayer de nouvelles approches. Veuillez envisager les solutions de formation suivantes.

• Vous pouvez l'essayer par vous-même. Les développeurs préfèrent « apprendre en essayant par eux-mêmes » plutôt que de regarder des explications dans des vidéos.
• Pertinence : Si vous utilisez Java quotidiennement, il est préférable de ne pas vous former à C#.
• L'apprentissage intéressant et simple est facile à comprendre et permet aux développeurs de continuer à progresser en s'appuyant sur leurs connaissances antérieures.
• Mesurable. Veuillez ne pas simplement cocher la case et passer à autre chose. Veuillez vérifier l'efficacité de la formation et établir un plan d'amélioration.
• C'est intéressant. En plus de favoriser une culture de sécurité positive, veuillez examiner les moyens de renforcer la sensibilisation à la sécurité et de créer ainsi un environnement d'équipe cohérent.

La sécurité doit être une priorité absolue pour tous les membres de l'organisation, et le RSSI doit mener des efforts visibles et transparents à tous les niveaux pour renforcer la sécurité des données. En effet, qui souhaiterait entendre la même vieille chanson en boucle ? Il est temps de réfléchir sérieusement à la suppression définitive des anciens bugs.

Que pensez-vous de ces statistiques alarmantes ? 60 % des petites et moyennes entreprises cessent leurs activités dans les six mois suivant une cyberattaque réussie. Les grandes entreprises subissent des pertes de plusieurs millions (voire milliards) de dollars, sans compter la perte de réputation de leur marque. De plus en plus d'organisations adoptent des pratiques de codage sécurisé, ce qui entraîne un changement de mentalité. Avec l'émergence du DevSecOps, le codage sécurisé est désormais au cœur du cycle de vie du développement logiciel (SDLC) dès le début.En collaboration avec Evans Data Corp, Secure Code Warrior a commandé une étude récente sur l'attitude des développeurs à l'égard du codage sécurisé, des pratiques de codage sécurisé et des opérations sécurisées afin d'évaluer l'impact réel de cette tendance.

Déplacement vers la gauche — Déplacement en plusieurs étapes

Les entreprises ont pris conscience que le coût de la correction des vulnérabilités après leur apparition est trente fois plus élevé que celui de leur prévention. Par conséquent, les mesures préventives sont désormais la norme. Cependant, pour que ces mesures soient efficaces, il est essentiel que tous les acteurs du cycle de vie du développement logiciel (SDLC), en particulier les développeurs, soient sensibilisés à la sécurité.

Shift One — Alors, qui est responsable à présent ?

Avec l'émergence de DevSecOps, les organisations adoptent des pratiques de codage sécurisé. En conséquence, l'un des changements les plus importants mis en évidence dans cette étude est le transfert de la responsabilité de la sécurité du code au niveau opérationnel.

Lorsqu'on a demandé aux développeurs et aux responsables du développement « Qui est responsable en dernier ressort de la sécurité du code ? », 46 % ont répondu que c'était le responsable du projet/de l'équipe, soit près de deux fois plus que ceux qui ont répondu que cette responsabilité incombait à l'équipe chargée de la sécurité des applications.

Cela démontre clairement que la responsabilité de la sécurité est transférée de l'équipe de sécurité des applications existantes aux chefs d'équipe de développement.

Shift 2 — Le rôle évolutif du gestionnaire  

Les responsables sont soumis à des pressions de toutes parts pour mettre en œuvre la formation aux codes de sécurité.

41 % ont déclaré que les tâches essentielles de l'organisation étaient les suivantes : formation au code de sécurité, provenant de cadres supérieurs. L'exigence croissante en matière de conformité réglementaire est également un facteur.

Les responsables jouent un rôle essentiel dans la transition des processus de développement existants vers DevSecOps et apparaissent comme des décideurs clés pour les décisions relatives à la formation et à l'acquisition d'outils.

Shift 3 — Des développeurs qui vont toujours plus loin

Cependant, nous observons une pression croissante en faveur du changement. 24 % des responsables déclarent mettre en œuvre des pratiques de codage sécurisé à la suite des suggestions et recommandations des développeurs. Cela démontre clairement le rôle de plus en plus important que jouent les développeurs dans les programmes de sécurité des entreprises. La transition vers DevSecOps, qui met nouvellement l'accent sur les pratiques de codage sécurisé préventif, transforme les développeurs en « première ligne de défense ».

Quatre équipes — Amélioration de la dynamique d'équipe  

La mise en œuvre de pratiques de code sécurisé a un impact significatif sur la qualité des logiciels, mais elle modifie également la manière dont les équipes travaillent pour obtenir de meilleurs résultats. Parmi les développeurs ayant participé à l'enquête, 60 % estiment que l'utilisation de code sécurisé a amélioré la communication avec les autres développeurs, mais les avantages ne s'arrêtent pas là.

La moitié des développeurs et des responsables ayant participé à l'enquête ont convenu que les pratiques de codage sécurisé favorisent la collaboration entre les développeurs et les dirigeants. 46 % ont indiqué que la collaboration entre les développeurs et les parties prenantes s'était intensifiée. Parallèlement, 41 % ont déclaré que la collaboration entre les dirigeants et les parties prenantes s'était également renforcée.

DevSecOps favorise la collaboration à travers les différents rôles et étapes du cycle de vie du développement logiciel en réunissant les équipes, les dirigeants et les parties prenantes de manière innovante.

62 % des responsables ayant participé à l'enquête ont déclaré que les pratiques de sécurité du code contribuaient à accélérer la publication du code. Ce constat, combiné à tous les autres changements, souligne les avantages évidents d'une transition vers une approche DevOps.Cependant, comme expliqué précédemment dans cet article, pour que ces mesures soient efficaces, il est essentiel que tous les acteurs du SDLC soient sensibilisés à la sécurité. Ces informations ont un impact significatif sur la manière dont les organisations forment leurs développeurs. Les équipes doivent se familiariser avec les vulnérabilités récemment découvertes et apprendre à utiliser des langages et des frameworks spécifiques. En résumé, les équipes doivent comprendre comment trouver, identifier et corriger les vulnérabilités connues du code dans le contexte de leur utilisation quotidienne. Cette formation permet aux équipes de passer du statut de première ligne de défense à celui de première ligne de risque.

Secure Code Warrior, qui est à l'avant-garde des changements dans le domaine du codage sécurisé, adopte une approche centrée sur l'humain pour aider les organisations à « prendre un virage à gauche » et à passer d'une approche réactive à une approche proactive en matière de sécurité globale.

Pour en savoir plus sur notre formation pratique, participative et éprouvée sur la sécurité du code, qui permet d'aligner les besoins des administrateurs, des développeurs et des organisations afin de concrétiser l'avenir du DevSecOps, nous vous invitons à réserver une démonstration dès maintenant.

‍

60 % des petites entreprises ferment leurs portes dans les six mois suivant un piratage informatique.
https://cybersecurityventures.com/60-percent-of-small-companies-close-within-6-months-of-being-hacked/

IBM Software Group ; minimise les défauts de code, améliore la qualité des logiciels et réduit les coûts de développement.
https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

Transition de la réponse à la prévention : évolution de la sécurité des applications en 2021. Secure Code Warrior et Evans Data Corporation.
https://scw.buzz/3169uzS

Le 11 juin 2019, le National Institute of Standards and Technology (NIST) a publié un livre blanc mis à jour contenant des informations détaillées. Ce document présente plusieurs plans d'action visant à réduire les vulnérabilités logicielles et les risques cybernétiques. Intitulé « Atténuer les risques liés aux vulnérabilités logicielles grâce à l'adoption d'un cadre de développement logiciel sécurisé (SSDF) », le NIST fournit aux organisations des directives claires pour éviter les conséquences désagréables des violations de données, sans parler des coûts élevés qu'elles entraînent.

À titre indicatif, le SSDF ne présume pas que toutes les organisations partagent les mêmes objectifs en matière de sécurité logicielle et ne prescrit pas de mécanismes précis pour atteindre ces objectifs. Son objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. L'auteure Donna Dodson a déclaré : « Chaque concepteur de sécurité souhaite que toutes les pratiques applicables soient respectées, mais le degré de mise en œuvre de chaque pratique dépendra des hypothèses de sécurité du concepteur. Ces pratiques offrent une certaine flexibilité aux développeurs, mais il est également clair qu'elles ne doivent pas laisser trop de place à l'interprétation. »

Il est particulièrement intéressant de noter que le contenu spécifique de la formation sur la sécurité logicielle destinée aux développeurs a été inclus. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate pour protéger leur organisation dès le début du processus de développement logiciel. Cependant, qu'entend-on exactement par « adéquate »? Il existe de nombreuses opinions différentes à ce sujet. Néanmoins, nous pensons que nous élargissons enfin nos limites dans une direction qui apportera des résultats positifs significatifs.

Il existe également des formations en matière de sécurité, et certaines sont particulièrement efficaces.

J'ai longuement discuté de la nécessité de mettre en œuvre plus efficacement la formation à la sécurité logicielle et de l'adapter aux besoins des développeurs. À l'heure actuelle, de nombreuses organisations se contentent encore d'exercices « standardisés ».Il est possible que l'on consacre plusieurs heures à des formations vidéo ou à l'utilisation d'outils d'apprentissage en classe, ce qui représente un investissement de temps précieux. Le fait que des attaques exploitant des vulnérabilités bien connues (et généralement faciles à corriger) se produisent tous les deux jours, entraînant des violations de données à grande échelle, démontre que la formation à la sécurité logicielle n'est pas aussi efficace qu'elle devrait l'être. Et le plus important est peut-être qu'il existe peu de moyens de vérifier si la formation a été efficace. Les vulnérabilités ont-elles été corrigées plus rapidement ? La vulnérabilité du code a-t-elle diminué ? Les personnes ont-elles réellement suivi la formation ? Ou ont-elles simplement cliqué sur « Suivant » pour la terminer ?

Les développeurs sont des personnes très occupées qui travaillent dur pour respecter des délais stricts. La sécurité est souvent source de nombreux désagréments et, dans la plupart des cas, les formations ne permettent pas d'acquérir les connaissances nécessaires pour atténuer efficacement les cyberrisques. En général, lorsque les membres de l'équipe AppSec signalent des failles dans le travail, le mot « sécurité » vient immédiatement à l'esprit, ce qui rend les relations quelque peu tendues et empêche le bon fonctionnement du système. C'est un peu comme si on disait : « Le bébé est laid, va le refaire ».

Qu'est-ce que cela nous indique ? Le manque d'intérêt des développeurs pour la sécurité est un signal d'alarme qui existe depuis des décennies. Les développeurs ne sont pas motivés à assumer leurs responsabilités et ne recherchent pas les outils nécessaires pour créer des logiciels fonctionnels et conformes aux meilleures pratiques en matière de sécurité.

Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que le visionnage incessant de vidéos sur les failles de sécurité suscite leur intérêt ou les incite à s'impliquer.En tant que formateur SANS, j'ai rapidement compris que la meilleure formation était celle qui permettait aux apprenants de tester leurs connaissances, d'analyser et de mettre à l'épreuve leurs capacités intellectuelles à l'aide d'exemples concrets basés sur des connaissances préalables. La gamification et la compétition amicale sont également des outils puissants qui permettent à chacun d'assimiler de nouveaux concepts tout en restant utiles et pratiques dans le domaine d'application.

Les directives du NIST stipulent ce qui suit : « Offrez une formation spécifique à chaque rôle à tous les employés qui ont des responsabilités en matière de développement sécurisé. Réexaminez régulièrement les formations spécifiques à chaque rôle et mettez-les à jour si nécessaire. » Ensuite : « Définissez les rôles et les responsabilités des employés chargés de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le SDLC. »

Bien que cette déclaration ne soit pas spécifique au type de formation, elle contribue néanmoins à transformer l'organisation et à garder à l'esprit les meilleures pratiques en matière de sécurité. Elle renvoie la responsabilité à l'entreprise de trouver des solutions de formation efficaces et plus spécifiques, dans l'espoir que les développeurs disposeront ainsi des outils et des connaissances nécessaires à leur réussite.

Culture : le chaînon manquant.

Même si l'organisation investit du temps et des ressources dans la formation des développeurs et autres employés clés, en mettant l'accent sur la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent s'avérer vains si la culture de sécurité de l'organisation est fondamentalement défaillante.

En formant efficacement les individus, en définissant des objectifs et en clarifiant les attentes, il devient beaucoup plus facile de comprendre sa place dans l'environnement de sécurité et d'assumer les responsabilités appropriées. Les développeurs, en particulier, reçoivent dès le départ les outils et les connaissances nécessaires pour écrire du code sécurisé. Cependant, c'est dans un environnement de sécurité positif, caractérisé par un minimum de doublons, de transfert de responsabilités et de cloisonnement des projets, que cette approche peut être le mieux coordonnée.

La sécurité de l'ensemble de l'organisation doit être une priorité absolue, grâce à un soutien et une coopération visant à fournir des logiciels de qualité et sécurisés. En d'autres termes, il est possible de déployer des formations intéressantes et participatives qui exploitent les vulnérabilités réelles du code et d'obtenir le consentement de l'ensemble de l'organisation afin de disposer d'un budget suffisant pour maintenir cette tendance. Dans un environnement numérique en constante évolution, la formation doit être aussi continue que la diffusion. Dans le passé, on considérait que la formation à la conformité, « une fois pour toutes », était appropriée ou efficace, mais il s'agit d'une idée erronée. « à configurer une fois pour toutes », c'est une erreur.

Bien que ce nouveau cadre du NIST ne spécifie pas explicitement les exigences relatives à la création d'une culture de sécurité positive, celles-ci sont indispensables pour garantir le respect des directives. Il convient toutefois de noter que les organisations doivent « définir une politique précisant les exigences de sécurité auxquelles leurs logiciels doivent satisfaire, y compris les pratiques de codage sécurisé que les développeurs doivent respecter ».

Les éléments ci-dessus sont essentiels pour développer et perfectionner les compétences en matière de sécurité au sein de l'équipe. Il peut être utile de prendre en considération les points suivants lors de l'évaluation de votre propre politique et de votre environnement AppSec actuel.

• Les directives et les attentes en matière de sécurité logicielle sont-elles clairement définies ?
• Est-ce que tout le monde comprend clairement le rôle qu'il joue dans la réalisation des objectifs ?
• La formation est-elle fréquente et évaluée ?
• Les développeurs sont-ils conscients de l'importance de leur rôle dans l'élimination des bogues de sécurité courants avant qu'ils ne surviennent ?

Comme mentionné précédemment, la dernière partie dépend principalement de l'organisation et de la formation choisie par celle-ci. Elle doit être pertinente, fréquente et susciter une forte participation. Recherchez des solutions applicables à vos tâches quotidiennes et acquérez des connaissances adaptées à votre situation.

Que devons-nous faire maintenant ?

Il peut être relativement complexe d'examiner en détail ces nouvelles directives. Il est nécessaire de déployer des efforts considérables pour créer, vérifier et déployer les logiciels de sécurité rigoureux requis par la plupart des entreprises de la manière la plus sécurisée possible. Cela ne se limite pas à la formation. Il existe des directives à prendre en compte lors de l'utilisation de logiciels tiers. (utilisation de composants présentant des vulnérabilités connues, toujours présentes dans le classement OWASP Top 10), des recommandations en matière de vérification, de tests d'intrusion et de révision du code, des directives sur la conservation des enregistrements de sécurité, des chaînes d'outils appropriées et bien d'autres éléments. Vous trouverez des informations exploitables sur l'ensemble de ces questions dans l'ouvrage du Dr Gary McGraw, le modèle BSIMM, quiest référencé dans l'ensemble des documents du NIST.

Cependant, en fournissant aux développeurs les outils et les connaissances appropriés pour créer des logiciels sécurisés dès le départ, il est possible d'obtenir des résultats plus rapides. Prévenir les vulnérabilités courantes qui apparaissent à la fin du cycle de vie du développement logiciel (SDLC) est plus économique pour l'entreprise (et globalement plus rapide). Il est recommandé de mettre en avant leurs atouts et de les encourager à s'impliquer dans la sécurité de l'organisation.Cela pourrait s'avérer très intéressant et ils pourraient devenir les héros dont vous avez besoin pour empêcher les personnes malveillantes d'accéder à vos données et les protéger.

Références :

1. Réduction des risques liés aux vulnérabilités logicielles grâce à l'adoption du SSDF (11 juin 2019) Page 2.
2. Réduction des risques liés aux vulnérabilités logicielles grâce à l'adoption du SSDF (11 juin 2019), page 5.
3. Atténuation des risques liés aux vulnérabilités logicielles grâce à l'adoption du SSDF (11 juin 2019), page 4.

Dans mon enfance, j'ai beaucoup joué. Bien sûr, au début, j'ai dû terminer plusieurs parties du jeu en passant par différents niveaux de difficulté. Cela allait de « Trop jeune pour mourir » (facile) à « Cauchemar » (très difficile). Il m'arrive parfois de souhaiter pouvoir simplement réinitialiser et modifier le niveau de difficulté de la gestion d'une entreprise technologique. C'est particulièrement vrai dans les premières étapes, où de nombreux éléments sont délicats, instables et susceptibles d'échouer. Les statistiques d'

s sont les suivantes : C'est bien connu et cela peut sembler surprenant: environ 90 % des start-ups échouent, ce qui est le cas depuis plusieurs années, mais en y regardant de plus près, on constate que 21 % des start-ups échouent au cours de leur première année, 30 % dans les deux ans, 50 % dans les cinq ans et 70 % dans les dix premières années.

Les cofondateurs Matthias Madou, Fatema Beydoun, Colin Wong, Nathan Desmet et Yap Karan Singh, ainsi que les investisseurs Goldman Sachs, Cisco Investments, Paladin Capital, Posit Point, AirTree, Tidal, ainsi que les membres indépendants du conseil d'administration Jim Flagg et Nanhi Singh, sont fiers d'avoir atteint le « niveau 10 ».

L'équipe fondatrice a travaillé ensemble pendant dix ans, surmontant toutes les leçons, les victoires et les échecs. Nous sommes en pleine expansion et, en tant que leader dans le domaine de la gestion des risques des développeurs, nous sommes prêts à aborder le prochain chapitre, SCW 2.0.

2024 : Année du lancement sur le marché du premier outil d'analyse de données du secteur.

Il est extrêmement difficile de démontrer le retour sur investissement des ressources techniques, mais en 2024, SCW a atteint l'objectif fixé par l'ensemble du secteur. « Est-il possible de prouver que le logiciel est plus sécurisé en améliorant les compétences des développeurs ? »Google a recueilli des données sur les vulnérabilités et les corrections auprès de certains de ses principaux clients qui ont mis en œuvre un programme bien établi, et peut fièrement démontrer, grâce à la validation de ses clients, que le taux de réduction des vulnérabilités du code créé par les développeurs de sécurité était en moyenne 53 % inférieur à celui du code créé par d'autres développeurs. Il a également été démontré que les développeurs de sécurité résolvent les problèmes de sécurité deux à trois fois plus rapidement, ce qui permet de gagner du temps et de réduire l'exposition aux risques.

a été le premier à franchir le pas. SCW Trust Score, une fonctionnalité de benchmarking qui quantifie l'impact des programmes de codage sécurisé d'entreprise. Pour la première fois, les responsables de la sécurité peuvent obtenir des informations détaillées et basées sur des données concernant les compétences en codage sécurisé de leur équipe de développement et les comparer aux normes du secteur. Il s'agit d'une visibilité parfaite que beaucoup attendaient pour ajuster leurs programmes de manière significative et offrir aux développeurs individuels un parcours d'apprentissage leur permettant de renforcer leurs compétences en matière de sécurité tout au long de leur carrière.Nous avons même publié un article de recherche en collaboration avec Chris Inglis, ancien directeur national de la cybersécurité aux États-Unis, et Kemba Walden, président du Paladin Global Institute et ancien directeur national adjoint de la cybersécurité aux États-Unis.

Nous avons ensuite lancé SCW Trust Agent, une offre complémentaire qui analyse tous les commits par rapport aux techniques de codage sécurisé des développeurset offre une visibilité sur l'ensemble du référentiel de code de l'organisation. SCW Trust Agent s'appuie sur SCW Trust Score et, ensemble, ils montrent dans quelle mesure le programme de sécurité de l'entreprise est appliqué efficacement à tous les commits.

Ces outils jouent un rôle essentiel pour aider les responsables de la sécurité d'entreprise à atteindre les objectifs suivants : vérifier les éléments essentiels des principes de conception de sécurité éprouvés grâce aux directives de conception de sécurité de la CISA, aux techniques de sécurité des développeurs, aux engagements de sécurité et, en fin de compte, à l'élimination des catégories de vulnérabilités.

Bonjour, partenaire ! Tout comme notre clientèle, notre réseau de partenaires continue de s'étendre.

L'un des aspects les plus touchants du secteur de la cybersécurité est de comprendre que nous formons tous, au fond, une grande communauté passionnée et enthousiaste, qui, dans la plupart des cas, est prête à unir ses forces non seulement pour réussir ensemble, mais aussi pour créer un monde numérique plus sûr pour tous.

Nous avons le privilège de pouvoir faire appel à divers collègues des secteurs de la sécurité et des technologies. Nous proposons à nos partenaires commerciaux un programme de partenariat qui joue un rôle essentiel dans la promotion de notre croissance. Fin 2024, nous avons annoncé un deuxième partenariat OEM avec des leaders mondiaux dans le domaine de la gestion de l'information. Ouvrir le texte. Cette évolution, associée à notre partenariat OEM principal, offre à Black Duckune opportunité exceptionnelle de fournir une solution complète et globale qui répond aux besoins modernes des entreprises et des programmes de sécurité.

Nous comptons également plus de 650 entreprises clientes. Depuis nos modestes débuts il y a dix ans, lorsque notre équipe de quatre personnes a célébré son premier client important autour d'un déjeuner bon marché, nous avons su nous imposer auprès de clients qui n'ont pas peur d'adopter une approche préventive de la sécurité, en plaçant les développeurs au cœur du changement.

L'intelligence artificielle, à la fois destructrice ultime et avenir de la sécurité axée sur les développeurs.

L'intelligence artificielle, le LLM et les outils de codage IA ont été des termes à la mode dans le vocabulaire de tous les professionnels de l'informatique pendant plus de deux ans, et notre société est à un moment décisif de l'histoire technologique. Les divers outils d'IA, présents dans presque toutes les catégories, promettent une augmentation considérable de la productivité. Dans le domaine du développement logiciel, une récente enquête GitHub a révélé que la plupart des ingénieurs ont commencé à adopter des assistants de codage basés sur l'IA.

Bien que seulement 38 % des organisations aient approuvé leur utilisation, ces outils font désormais partie intégrante de l'environnement de développement logiciel. Leur utilisation est inévitable, et les responsables de la sécurité doivent se concentrer sur l'accompagnement des développeurs vers un parcours de codage sécurisé et responsable, plutôt que de créer un environnement de « shadow AI ». Les développeurs bien informés en matière de sécurité peuvent atténuer les risques permanents liés aux développeurs moins compétents en matière de sécurité. les responsables de la sécurité doivent se concentrer sur l'accompagnement des développeurs vers un codage sûr et responsable plutôt que de créer une situation de « shadow AI ». Les développeurs avertis en matière de sécurité peuvent utiliser ces outils en s'appuyant sur leur esprit critique et leur expertise en sécurité pour tirer pleinement parti des avantages en termes de productivité, sans aggraver les risques permanents liés au manque de compétences en sécurité des développeurs.

L'année 2025 sera marquée par la poursuite du développement du codage IA. Cependant, il se peut que seules quelques mesures puissent aider les entreprises à appliquer efficacement la gestion des risques liés aux développeurs dans ce domaine et dans plusieurs autres. Nous vous invitons à suivre attentivement la suite de notre parcours.

À mesure que les cybermenaces se généralisent et se perfectionnent, la cybersécurité se concentre de plus en plus sur l'importance du code de sécurité. La stratégie nationale de cybersécurité de la Maison Blanche et l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) ont lancé une initiative de conception sécurisée qui, à l'instar d'autres initiatives et lois nationales, confie l'entière responsabilité de la sécurité aux éditeurs de logiciels.Autrefois considéré comme un atout, le fait de se concentrer sur la sécurité dès le début du cycle de vie du développement logiciel (SDLC) est désormais essentiel pour permettre aux organisations de protéger leurs données et leurs systèmes et d'éviter les conséquences réglementaires d'une violation de la sécurité.

La clé pour garantir les pratiques de codage sécurisé réside dans la formation des développeurs. Les ingénieurs logiciels bénéficient généralement des avantages suivants : Une formation en cybersécurité quasi inexistante. Dans le contexte actuel d'accélération des DevOps, leur mission consiste à déployer le plus rapidement possible de nouvelles applications, mises à niveau et services à l'aide de modèles d'IA générative fonctionnant à grande vitesse, afin que l'équipe de sécurité puisse résoudre les problèmes de cybersécurité à un stade ultérieur du cycle de vie du développement logiciel (SDLC). Cette approche est inefficace pour corriger les nombreuses failles qui apparaissent lorsque trop de code est généré, ce qui entraîne souvent la propagation de vulnérabilités logicielles dans l'écosystème.

Les développeurs doivent être formés dès le début à la rédaction de codes sécurisés et doivent être en mesure de détecter les codes non sécurisés générés par l'IA ou présents dans les logiciels open source et autres logiciels tiers qu'ils utilisent. Pour de nombreuses équipes de développement et organisations, ce domaine est souvent négligé. Comment s'assurer que les développeurs reçoivent la formation nécessaire ? Et cette formation est-elle dispensée régulièrement ?

Certaines entreprises qui privilégient la formation des développeurs ont constaté qu'il était utile de définir un ensemble de compétences de base afin que les développeurs puissent acquérir des connaissances et mesurer leurs progrès à l'aide de critères de référence clairement définis. Afin de soutenir ces efforts, Secure Code Warrior a publié des critères de référence conçus pour mesurer avec précision les progrès des développeurs en matière de formation à la sécurité. Le SCW Trust Score permet aux organisations de mesurer dans quelle mesure la formation est appliquée dans le cadre du travail et facilite la collaboration entre les équipes chargées de la sécurité, du développement et de l'ingénierie.

Il s'agit d'une méthode permettant d'identifier les domaines nécessitant des améliorations tout en fournissant la preuve que la formation au code de sécurité est correctement dispensée.

Exemples de conception sécurisée

Les développeurs de logiciels ont de bonnes raisons d'intégrer la sécurité dès le début du processus SDLC. La demande croissante en applications et services, ainsi que la rapidité apportée par l'IA au processus de développement, se sont avérées utiles pour les développeurs qui ont rapidement adopté l'IA générative. Cependant, cela a inévitablement conduit à la publication de logiciels bogués. Plus le code généré est important, plus les défauts sont nombreux. Une étude récente a révélé que près des trois quarts des applications (quelle que soit leur méthode de création) contiennent au moins un défaut de sécurité, dont près de 20 % sont considérés comme graves.

La détection des vulnérabilités dans la phase finale du cycle de vie du développement logiciel (SDLC) nécessite un investissement considérable en temps et en ressources. Le National Institute of Standards and Technology (NIST) a constaté que la correction des défauts lors des tests prend 15 fois plus de temps que la protection du logiciel au début du SDLC, et que la correction des défauts lors des phases de déploiement et de maintenance peut prendre entre 30 et 100 fois plus de temps.

Tout cela démontre l'importance d'intégrer la sécurité dès le début du cycle de développement. Il a été prouvé que c'est non seulement le moyen le plus efficace de réduire les risques, mais aussi le plus rentable. Les développeurs sont les mieux placés pour intégrer la sécurité dès le début du cycle de développement logiciel (SDLC) en collaborant avec l'équipe de sécurité plutôt qu'en la considérant comme une entité distincte. De plus, les développeurs ayant reçu une formation sur les meilleures pratiques en matière de sécurité ont pu réduire efficacement les vulnérabilités. Le problème est que très peu d'entre eux ont bénéficié d'une telle formation.

La beauté des benchmarks

Le parcours de base d'une entreprise comprend la définition de normes en matière de technologies de sécurité, la mise en place de formations et la vérification, tant par l'organisation que par les organismes de réglementation, que les développeurs ont acquis les compétences nécessaires. Bien que cela se soit avéré difficile pour de nombreuses organisations dans tous les secteurs économiques, cela ne doit pas nécessairement être le cas.

L'un des problèmes soulevés par les responsables de la sécurité est la difficulté d'étendre les programmes de formation à l'ensemble de l'entreprise. Cependant, selon une étude de SCW, les organisations, en particulier celles qui comptent un grand nombre de développeurs, peuvent mettre en œuvre avec succès une approche de conception sécurisée. Les résultats des petites organisations ont tendance à varier considérablement en fonction de la qualité de l'application des principes de conception sécurisée. Toutefois, ces entreprises peuvent également tirer parti d'une approche incluant des scores de confiance et sont susceptibles de montrer des améliorations plus rapidement.

Le score de confiance utilise des indicateurs de référence pour mesurer les progrès de chaque apprenant, compile les scores pour évaluer les performances de l'équipe dans son ensemble et compare les progrès de l'organisation aux références du secteur et aux meilleures pratiques. Cela permet non seulement de suivre la formation, mais aussi de montrer dans quelle mesure les développeurs appliquent quotidiennement les nouvelles compétences acquises. De plus, cela met en évidence les domaines à améliorer afin que l'organisation puisse optimiser ses programmes de formation et de perfectionnement des compétences.

Dans l'ensemble du CISA, la plupart des organisations se situent à un niveau similaire en matière de mise en œuvre des principes de conception de sécurité, quel que soit le secteur d'infrastructure critique concerné. Les scores de confiance de divers secteurs, allant des services financiers et de la défense à la santé, à l'informatique et à la fabrication de pointe, se situent dans la même fourchette. Sur une échelle de 1 000 points, elles ont légèrement dépassé les 300 points. Contrairement à l'idée reçue selon laquelle le secteur des services financiers, le plus réglementé, serait en tête, aucun secteur ne surpasse les autres.

Les principaux secteurs d'infrastructure qui ne figurent pas dans le classement des scores de confiance, tels que la chimie, l'énergie et le nucléaire, dépendent généralement d'autres secteurs, en particulier des technologies de l'information, pour leurs besoins logiciels, plutôt que de développer leurs propres logiciels. Cependant, l'importance de maintenir la sécurité des systèmes dans ces secteurs (personne ne souhaite voir une centrale nucléaire compromise) souligne à quel point il est essentiel de protéger les logiciels utilisés.

Conclusion

En raison de l'intensification des pressions réglementaires et de la réalité des cybermenaces, l'approche Secure By-Design est devenue indispensable pour les organisations qui souhaitent protéger leurs données, leurs systèmes, leurs opérations commerciales et leur réputation. La création de logiciels de sécurité repose en grande partie sur les développeurs, mais ceux-ci ont besoin d'une formation adéquate et d'un soutien sous la forme de programmes de perfectionnement technique et de formation approfondis qui leur montrent comment les méthodes de développement sont appliquées.

Les programmes comprenant des benchmarks basés sur des outils tels que Trust Score permettent de suivre clairement les progrès réalisés par l'équipe de développement. Il s'agit d'une approche très novatrice pour les entreprises travaillant avec des développeurs, qui doivent à la fois répondre aux nouvelles exigences de sécurité dès la conception et améliorer en permanence leurs compétences en matière de développement de logiciels sécurisés.

‍

Chez Secure Code Warrior, notre devise est d'offrir aux développeurs une expérience d'apprentissage agile et pratique, ainsi qu'une formation à la sécurité réaliste et utile dans le cadre de leur travail quotidien. Nous appelons cela « l'apprentissage par la pratique ».

Nous sommes conscients qu'une formation personnalisée axée sur les tâches actuelles des développeurs offre une expérience enrichissante qui contribue à fournir des résultats beaucoup plus significatifs pour les entreprises. En d'autres termes, grâce à des tests pratiques, à un contrôle qualité et à des versions de code rapides, prêtes à être commercialisées en temps opportun, nous pouvons fournir des résultats beaucoup plus significatifs aux entreprises. Quelle entreprise ne serait pas intéressée par une telle proposition ?

Nous améliorons cette expérience grâce à une nouvelle intégration remarquable. Apivertest une plateforme de gestion de la sécurité des applications (ASPM) de premier plan qui offre aux équipes et aux responsables de la sécurité des applications la visibilité nécessaire pour hiérarchiser, corriger, prévenir et gérer les risques applicatifs critiques. L'intégration de ces deux plateformes permet de fournir aux développeurs un contexte pertinent et une formation en temps réel sur la sécurité lorsqu'ils corrigent des risques de sécurité. Ainsi, les développeurs peuvent apprendre sans avoir à changer de contexte ni à quitter l'environnement familier des outils de développement qu'ils utilisent quotidiennement.

Comment cette transformation est-elle possible ? Apiiro mappe les résultats de sécurité des applications détectés par Apiiro ou collectés par des outils de sécurité tiers aux formations pertinentes de Secure Code Warrior, classées par type et par langage, puis les transmet aux développeurs ou aux équipes concernés via des tickets, des tickets d'incident ou des messages.L'intégration d'Apiiro et de Secure Code Warrior permet de minimiser les interruptions dans le cycle de vie du développement logiciel, car il n'est plus nécessaire d'utiliser des outils distincts à différents moments pour prendre des mesures. Il s'agit simplement d'un autre moyen d'aider les entreprises à améliorer l'efficacité des développeurs tout en leur permettant de publier plus rapidement un code de qualité.

Pour en savoir plus sur cette nouvelle intégration et ce partenariat, veuillez consulter le blog d'Apiiro ici.

‍

La plupart des organisations éprouvent encore des difficultés à mettre l'accent sur la sécurité en tant qu'élément central du cycle de vie du développement logiciel (SDLC), et rares sont celles qui parviennent à adopter une approche DevSecOps solide. Beaucoup continuent de privilégier les fonctionnalités et les délais de lancement plutôt que la sécurité. Cela a plusieurs conséquences, notamment un risque accru de violations de données coûteuses et une baisse de productivité, car les équipes doivent examiner minutieusement les tickets de sécurité et les retouches.

La première ligne de défense pour éliminer les facteurs de risque est constituée par les développeurs. Il est essentiel que les organisations réfléchissent à la manière d'améliorer la maturité de leur équipe de développement en matière de vulnérabilités logicielles. Cependant, cela soulève plusieurs questions.

Comment une organisation peut-elle évaluer le niveau de maturité en matière de sécurité de son équipe de développement ? Comment établir une feuille de route pour la maturité en matière de sécurité sans que cela semble impossible ? Comment maintenir l'engagement des développeurs et les motiver à améliorer leur niveau de maturité en matière de sécurité ?

Nous avons exploité les connaissances de Secure Code Warrior. Enquête sur la sécurité menée par les développeurs. Nous avons examiné les réponses à ces questions et avons utilisé notre équipe de service client de classe mondiale pour déterminer ce que d'autres organisations font pour trouver des réponses.

Comment pouvons-nous améliorer la maturité de la sécurité au sein de l'équipe de développement ?

En matière d'amélioration de la maturité de la sécurité, aucune organisation n'est identique à une autre. En effet, il est nécessaire de prendre en compte de nombreux facteurs susceptibles d'influencer le succès des efforts de transformation numérique d'une entreprise. Cela présente de nombreux avantages, notamment la possibilité de générer et de publier rapidement du code sans en utiliser beaucoup, voire pas du tout. Il existe des vulnérabilités. En conséquence, cela permet de réduire les retouches coûteuses et, en fin de compte, de diminuer les risques.

Les organisations qui progressent disposent d'un plan défini, incluant un soutien administratif, et d'une approche cohérente visant à améliorer continuellement la maturité de la sécurité au fil du temps. Cela comprend les éléments suivants :

• Définition des critères de maturité en matière de sécurité
• Évaluation de la maturité de la sécurité de l'équipe
• Identification des principales vulnérabilités en matière de sécurité
• Mise en place d'une culture de sécurité positive

Veuillez consulter notre nouveau livre blanc. L'importance de la maturité en matière de sécurité pour les équipes de développement Pour en savoir plus :

• Qu'est-ce que la maturité en matière de sécurité d'une équipe de développement et pourquoi est-elle importante ?
• Quels sont les niveaux de maturité et les caractéristiques de l'équipe de développement en matière de sécurité ?
• Quels sont les éléments nécessaires pour améliorer la maturité de la sécurité au sein de l'équipe de développement ?

Il y a cinq ans, les banques belges se sont associées pour créer cette remarquable publicité télévisée. Elles ont présenté l'histoire de Dave, un personnage très doué doté d'une grande perspicacité, qui connaissait des informations personnelles et financières très précises. Elles ont ainsi sensibilisé des millions de consommateurs au fait que leur vie pouvait être consultée en ligne et les ont incités à rester vigilants.

En visionnant la vidéo, vous constaterez que le sujet est aujourd'hui beaucoup plus pertinent qu'en 2012. De plus, vous vous rendrez compte que les conséquences sont bien plus inquiétantes.

Si les présentations PowerPoint monotones, les règles contraignantes et les consignes sur ce qu'il ne faut pas faire constituent un véritable casse-tête pour la direction et les employés, nous vous recommandons de visionner cette vidéo afin de trouver l'inspiration créative.

Veuillez visionner la vidéo, la partager avec l'équipe chargée des relations publiques et de la communication, et demander leur aide pour rendre la sécurité de l'information à nouveau intéressante.

Que ce soit pour former les cadres supérieurs à la cybersécurité ou pour assister les développeurs dans leurs compétences de codage sécurisé en JAVA ou C#, nous avons un espace dédié à la créativité, à la ludification et au divertissement.

Que ce soit pour former les cadres supérieurs à la cybersécurité ou pour assister les développeurs dans leurs compétences de codage sécurisé en JAVA ou C#, nous avons un espace dédié à la créativité, à la ludification et au divertissement.

VxWorks n'est pas un produit bien connu du grand public. Ce logiciel apporte inévitablement des avantages quotidiens à de nombreuses personnes, y compris vous-même et moi-même. Ce logiciel, qui est le système d'exploitation temps réel (RTOS) le plus populaire au monde, est un produit phare utilisé via des proxys pour alimenter les réseaux d'entreprise et les pare-feu, les interfaces aérospatiales, les équipements industriels et même certains appareils médicaux. Pour citer quelques exemples d'applications largement utilisées.

Et aujourd'hui, nous sommes confrontés à la possibilité de perdre des centaines de millions de dollars. Plus de 11 vulnérabilités ont été découvertes à ce jour dans cesappareils. Arlen Baker, concepteur en chef de la sécurité chez Wind River, a contesté ce chiffre dans un article. La sécurité des recherches, dont la portée exacte n'a pas été confirmée, ne semble pas être aussi élevée. Néanmoins, nous savons déjà que les violations de données et les attaques sont monnaie courante, mais cela représente un niveau supérieur. Les failles identifiées peuvent être exploitées relativement facilement et permettent pour la plupart aux attaquants de contrôler à distance les appareils via la transmission de paquets réseau.

Wind River a bien sûr publié une série de correctifs et de mises à jour pour les clients et les employés concernés. Le problème réside dans le nombre considérable d'appareils nécessitant une mise à jour. Tout comme Thanos a détruit le monde d'un simple claquement de doigts, de nombreux appareils inévitablement non corrigés resteront vulnérables pendant une longue période.

La société de sécurité Armis a été à l'origine de cette découverte majeure. Urgent/11. Les chercheurs ont conclu sans aucun doute qu'il s'agissait d'une menace grave, car elle pouvait être facilement propagée par divers vecteurs et entraîner une infection à grande échelle. Il est tout à fait possible de créer et de diffuser un ver dans les logiciels qui font fonctionner tout, des scanners IRM et des produits VOIP aux réseaux ferroviaires et aux feux de signalisation.

Est-ce le moment de s'inquiéter ?

En tant que personne pour qui la sensibilisation à la sécurité est une mission essentielle dans la vie, je suis confronté quotidiennement à de nombreux problèmes de sécurité potentiels. Si je me laissais envahir par la panique, je passerais la majeure partie de ma journée dans un état d'hystérie. (Après tout, je préfère me consacrer à l'éducation et à la correction des bogues !).Cependant, l'étendue des vulnérabilités découvertes par URGENT/11 est assez inquiétante. Six des onze vulnérabilités découvertes sont considérées comme graves. Il a été confirmé que ces vulnérabilités existent sur les appareils exécutant VxWorks depuis la version 6.5 de Hacker News (à l'exception des versions conçues pour la certification, notamment VxWorks 653 et VxWorks Cert Edition). Cela signifie que certaines technologies importantes sont exposées depuis plus de dix ans à des attaques visant à prendre le contrôle des appareils. Tous les appareils ne sont pas vulnérables aux 11 failles (certaines ne peuvent être exploitées que si l'attaquant se trouve sur le même sous-réseau LAB), mais un pirate informatique moyen n'a besoin que d'une seule occasion pour réussir.

Il est important de noter que Wind River a agi rapidement et fourni des conseils détaillés. Tout comme Armis , il s'agit d'atténuer le problème. De plus, le RTOS VxWorks est très largement adopté. En effet, il est très stable et a obtenu d'excellentes notes en matière de sécurité logicielle. En général, les chasseurs de primes ne s'en soucient guère. Cependant, les sociétés de sécurité et Wind River ne peuvent pas faire grand-chose pour résoudre le problème. Il appartient à l'utilisateur final de télécharger les correctifs, de prendre connaissance des conseils de sécurité et de renforcer ses propres appareils, ce qui est précisément ce qui pose problème.

Il n'est pas nécessaire de s'inquiéter pour l'instant, mais il se peut que nous ayons besoin du village pour vaincre cette bête.

Urgent/11 Description de la vulnérabilité

À ce stade, tous les appareils connectés à la pile IPNet TCP/IP VxWorks endommagée depuis la version 6.5 peuvent être affectés par au moins l'une des vulnérabilités URGENT/11. (Veuillez consulter la liste complète des CVE de Wind River ici).

Ces vulnérabilités permettent généralement des attaques par exécution de code à distance (RCE) et par déni de service, dont certaines entraînent la divulgation d'informations. Il en va de même pour les problèmes liés à la logique métier. Dans ce cas, l'exécution de code à distance est particulièrement préoccupante, car elle permet à un attaquant de prendre le contrôle d'un appareil sans aucune interaction de la part de l'utilisateur final. Il n'est pas nécessaire que quelqu'un clique accidentellement sur un élément suspect, télécharge un fichier ou saisisse des informations. Cela rend les appareils VxWorks extrêmement « exploitables » et l'attaque elle-même prend une dimension automatisée. Vous vous souvenez du ver WannaCry, produit par EternalBlue ? URGENT/11 est similaire, mais présente un potentiel plus destructeur qui pourrait causer des problèmes à l'échelle mondiale.

Que pouvons-nous faire à ce sujet ?

À l'heure où nous écrivons ces lignes, les résultats de l'URGENT/11 ne sont pas encore connus. Les médias ont suscité un vif intérêt dans le secteur, et Wind River apporte un soutien indéfectible aux personnes touchées. Les prochains mois nous diront si des attaquants cherchent à exploiter ces failles connues de manière significative. En attendant, la meilleure solution consiste à suivre les nombreux conseils prodigués et à appliquer les correctifs aux appareils concernés.

À long terme, notre mission reste la même : améliorer les performances de tous en matière de sécurité logicielle. URGENT/11 CVE est généralement une porte dérobée préoccupante et simple, et le fait qu'elle soit restée longtemps inconnue témoigne du manque de sensibilisation et de préoccupation de l'ensemble du secteur.

Tous les développeurs ont l'opportunité de jouer leur rôle et ont besoin d'aide pour apprendre les méthodes de sécurité du code dès le début du développement. De la sécurité des applications à la haute direction, la présence d'équipes influentes autour de vous permet de favoriser une culture de sécurité positive à tous les points de contact logiciels de l'entreprise.

Souhaitez-vous évaluer votre niveau de sécurité informatique ? Notre plateforme ludique vous permet de résoudre des problèmes de code réels similaires à ceux détectés par URGENT/11. Nous vous invitons à l'essayer et à évaluer vos compétences.

• Débordement de pile dans l'analyse syntaxique des offres/accusés de réception DHCP de l'ipdhcpc (CVE-2019-12257)
  Corruption de mémoire - Débordement de pile
• Attaque par déni de service (DoS) via une connexion TCP utilisant des options TCP mal formatées (CVE-2019-12258)
  Protection insuffisante de la couche transport - Transmission non sécurisée d'informations sensibles
• Faille logique dans l'attribution IPv4 par le client DHCP (CVE-2019-12264)
  Faille dans la logique métier
• DoS via une référence nulle dans l'analyse IGMP (CVE-2019-12259)
  Corruption de mémoire - référence nulle
• Fuite d'informations IGMP via un rapport de membre spécifique IGMPv3 (CVE-2019-12265)
  Divulgation d'informations - Divulgation de données sensibles