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

‍

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

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

Trop d'outils de cybersécurité

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

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

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

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

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

Une meilleure façon de faire

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

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

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

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

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

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

L'essor et la possible ruine des API

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

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

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

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

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

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

Défendre les API

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

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

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

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

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

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

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

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

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

Quand votre chargeur de VE en dit trop

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

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

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

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

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

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

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

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

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

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

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

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

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

‍

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

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

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

Comprendre l'ampleur du travail à accomplir 

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

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

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

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

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

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

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

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

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

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

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

Ne faites pas une croix sur vos développeurs.

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

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

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

‍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Passer à l'AppSec

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

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

La culture pop regorge de références à l'IA et aux robots malveillants, ainsi qu'aux appareils qui se retournent contre leurs maîtres humains. Il s'agit d'un thème fortement imprégné de science-fiction et de fantastique, mais comme l'IdO et les appareils connectés sont de plus en plus présents dans nos foyers, la conversation autour de la cybersécurité et de la sûreté devrait l'être aussi. Les logiciels sont partout autour de nous, et il est très facile d'oublier à quel point nous dépendons de lignes de code pour réaliser toutes ces choses intelligentes qui nous apportent tant d'innovation et de commodité. À l'instar des logiciels basés sur le web, des API et des appareils mobiles, le code vulnérable des systèmes embarqués peut être exploité s'il est découvert dans la nature par un attaquant. 

S'il est peu probable qu'une armée de micro-ondes vienne asservir la race humaine (bien que le robot Tesla soit un peu inquiétant) à la suite d'une cyberattaque, des cyberévénements malveillants sont toujours possibles. Certaines de nos voitures, certains de nos avions et certains de nos appareils médicaux reposent également sur des systèmes intégrés complexes pour effectuer des tâches essentielles, et la perspective que ces objets soient compromis n'est pas seulement alarmante, elle peut aussi mettre des vies en danger.

Comme pour tous les autres types de logiciels, les développeurs sont parmi les premiers à toucher le code, dès le début de la phase de création. Et comme pour tous les autres types de logiciels, il peut s'agir d'un terrain propice à l'apparition de vulnérabilités insidieuses et courantes qui pourraient ne pas être détectées avant que le produit ne soit mis en service. 

Les développeurs ne sont pas des experts en sécurité, et aucune entreprise ne devrait attendre d'eux qu'ils jouent ce rôle, mais ils peuvent être dotés d'un arsenal bien plus puissant pour s'attaquer aux menaces qui les concernent. Les systèmes embarqués - généralement écrits en C et C++ - seront de plus en plus utilisés à mesure que nos besoins technologiques continueront d'évoluer, et il est essentiel que les développeurs reçoivent une formation spécialisée en matière de sécurité sur les outils utilisés dans cet environnement. 

Explosion de friteuses, véhicules hors-la-loi... Sommes-nous des cibles faciles ?

Bien qu'il existe des normes et des réglementations en matière de développement sécurisé pour nous protéger, nous devons faire des progrès beaucoup plus précis et significatifs en ce qui concerne tous les types de sécurité logicielle. Il peut sembler exagéré de penser à un problème pouvant être causé par le piratage d'une friteuse, mais cela s'est produit sous la forme d'une attaque par exécution de code à distance (permettant à l'acteur de la menace d'augmenter la température à des niveaux dangereux), tout comme les vulnérabilités conduisant à la prise de contrôle d'un véhicule.

Les véhicules, en particulier, sont particulièrement complexes, avec de multiples systèmes intégrés à bord, chacun prenant en charge des micro-fonctions, allant des essuie-glaces automatiques aux capacités du moteur et du système de freinage. Associé à une pile de technologies de communication de plus en plus importante, comme le Wi-Fi, le Bluetooth et le GPS, le véhicule connecté représente une infrastructure numérique complexe exposée à de multiples vecteurs d'attaque. Et avec 76,3 millions de véhicules connectés attendus sur les routes du monde entier d'ici 2023, cela représente un monolithe de fondations défensives à poser pour une véritable sécurité.

MISRA est une organisation clé dans la lutte contre les menaces qui pèsent sur les systèmes embarqués. Elle a élaboré des lignes directrices pour faciliter la sécurité du code, la portabilité et la fiabilité dans le contexte des systèmes embarqués. Ces lignes directrices sont l'étoile polaire des normes que chaque entreprise doit s'efforcer d'atteindre dans ses projets de systèmes embarqués.

Cependant, pour créer et exécuter un code qui adhère à cet étalon-or, il faut des ingénieurs en systèmes embarqués qui soient confiants dans les outils - sans parler de la sensibilisation à la sécurité. 

Pourquoi les compétences en matière de sécurité des systèmes embarqués sont-elles si spécifiques ?

Les langages de programmation C et C++ sont gériatriques par rapport aux normes actuelles, mais ils restent largement utilisés. Ils constituent le noyau fonctionnel de la base de code des systèmes embarqués, et Embedded C/C++ jouit d'une vie brillante et moderne dans le monde des appareils connectés.

Bien que ces langages aient des racines plutôt anciennes - et qu'ils présentent des comportements de vulnérabilité similaires en termes de problèmes courants tels que les failles d'injection et les débordements de mémoire tampon - pour que les développeurs parviennent réellement à atténuer les bogues de sécurité dans les systèmes embarqués, ils doivent se familiariser avec un code qui imite les environnements dans lesquels ils travaillent. Une formation générique en C sur les pratiques générales de sécurité ne sera tout simplement pas aussi efficace et mémorable que si l'on consacre plus de temps et d'attention à travailler dans un contexte de C embarqué.

Avec une douzaine à plus d'une centaine de systèmes embarqués dans un véhicule moderne, il est impératif que les développeurs reçoivent une formation précise sur ce qu'il faut rechercher et comment le réparer, directement dans l'IDE.
‍

La protection des systèmes embarqués dès le départ est l'affaire de tous

Dans de nombreuses organisations, le statu quo veut que la vitesse de développement l'emporte sur la sécurité, du moins lorsqu'il s'agit de la responsabilité des développeurs. Ceux-ci sont rarement évalués sur leur capacité à produire du code sécurisé, mais le développement rapide de fonctionnalités impressionnantes est la norme. La demande de logiciels ne fera qu'augmenter, mais cette culture nous a conduits à une bataille perdue d'avance contre les vulnérabilités et les cyberattaques qu'elles permettent. 

Si les développeurs ne sont pas formés, ce n'est pas de leur faute, et c'est une lacune que quelqu'un dans l'équipe AppSec doit aider à combler en recommandant les bons programmes, accessibles (sans parler de l'évaluation) de mise à niveau pour l'ensemble de la communauté de développement. Dès le début d'un projet de développement logiciel, la sécurité doit être une préoccupation majeure, et tout le monde - en particulier les développeurs - doit recevoir ce dont il a besoin pour jouer son rôle. 

S'attaquer aux problèmes de sécurité des systèmes embarqués

Les débordements de mémoire tampon, les failles d'injection et les bogues de logique d'entreprise sont autant d'écueils courants dans le développement de systèmes intégrés. Lorsqu'ils sont enfouis dans un labyrinthe de microcontrôleurs dans un seul véhicule ou appareil, ils peuvent être catastrophiques du point de vue de la sécurité.

Le dépassement de tampon est particulièrement répandu, et si vous souhaitez vous plonger dans la manière dont il a contribué à compromettre la friteuse dont nous avons parlé précédemment (permettant l'exécution de code à distance), consultez ce rapport sur la CVE-2020-28592.

Il est maintenant temps de mettre la main à la pâte avec une vulnérabilité de débordement de mémoire tampon, dans un véritable code C/C++ intégré. Relevez ce défi pour voir si vous pouvez localiser, identifier et corriger les mauvais schémas de codage qui conduisent à ce bogue insidieux :
‍

‍

Comment avez-vous fait ? Visitez www.securecodewarrior.com pour une formation précise et efficace sur la sécurité des systèmes embarqués.

En tant que professionnel de la sécurité des applications, il vous incombe de garantir la cybersécurité des applications de votre organisation. Cependant, vous n'êtes pas responsable de l'écriture du code sur lequel l'application fonctionne. Ce sont les ingénieurs de l'équipe de développement qui s'en chargent. Comment pouvez-vous donc vous assurer qu'ils développent ces systèmes en gardant la sécurité à l'esprit ? 

Il est très probable que vous fassiez certaines des choses suivantes, voire toutes : 

• Examiner l'ensemble du code pour détecter les failles de sécurité et les signaler à l'équipe de développement pour qu'elle les corrige. 
• Appliquer un processus strict d'évaluation par les pairs tout au long du cycle de développement sécurisé. 
• Faire réaliser régulièrement des tests d'application assessment/de pénétration par des équipes de sécurité internes ou externes.
• Mettre en place des outils d'analyse pour détecter les vulnérabilités.
  

Il s'agit là d'excellentes pratiques, mais elles sont également coûteuses et reviennent à prendre une série d'antibiotiques chaque fois que vous tombez malade. Non seulement le coût est élevé, mais les médicaments perdent de leur efficacité et peuvent affaiblir votre système immunitaire au fil du temps. 

Comment s'assurer que le code livré par les développeurs est écrit de manière sécurisée ? 

Au-delà du codage sécurisé, réfléchissez d'abord à la manière dont les gens apprennent. La plupart d'entre nous sont des apprenants visuels et nous apprenons par la pratique. Or, la formation au codage sécurisé est souvent proposée comme une activité "à cocher" et n'est pas pertinente pour le travail quotidien d'un développeur. Elle est conçue pour prouver que les développeurs ont suivi une formation à la sécurité, souvent pour se conformer aux normes de l'industrie, et non pour que les développeurs retiennent réellement ces connaissances, et encore moins pour qu'ils apprécient le processus d'apprentissage. 

Les humains ont également tendance à apprendre en commettant des erreurs, comme le fait notre système immunitaire. Les cellules T se souviennent des agents pathogènes qu'elles ont rencontrés et éradiqués avec succès dans le passé, de sorte qu'elles peuvent se protéger contre eux à l'avenir. C'est exactement le rôle que les développeurs devraient jouer dans votre SDLC sécurisé .

Il n'est pas réaliste d'attendre d'eux qu'ils ne fassent pas d'erreurs, mais vous pouvez les préparer de manière à ce qu'ils soient capables de reconnaître les schémas de codage qui se traduiront par des vulnérabilités en matière de sécurité à l'avenir. 

C'est également ainsi qu'un processus robuste d'évaluation par les pairs devient si puissant. Ce n'est pas parce qu'un développeur ne remarque pas une faille de sécurité qu'un autre ne le fera pas. Et plus l'équipe de développement est bien formée, plus les vulnérabilités sont susceptibles d'être détectées et de ne jamais atteindre la production. 

Les vulnérabilités des logiciels sont comme des agents pathogènes

Les vulnérabilités des logiciels sont comme des agents pathogènes, en ce sens qu'il faut s'en souvenir pour les combattre. Dans le cas des agents pathogènes, notre système immunitaire doit souvent être exposé plusieurs fois avant de se souvenir de la manière de les combattre et d'éviter une maladie grave, voire pire. 

Une cyberattaque réussie à partir d'un logiciel vulnérable peut gravement paralyser ou tuer une organisation. Mais si les développeurs sont d'abord confrontés aux vulnérabilités des logiciels dans un environnement contrôlé, ils peuvent s'efforcer de s'immuniser contre les menaces en renforçant et en pratiquant régulièrement leurs connaissances et leurs compétences en matière de codage sécurisé. 

Exposer les développeurs aux failles de sécurité dans un environnement contrôlé

Nous ne pouvons jamais nous protéger totalement contre les maladies, mais il y a des choses que nous pouvons faire pour renforcer notre système immunitaire et rester en aussi bonne santé que possible. L'exercice physique régulier, une alimentation saine et un sommeil suffisant font partie des choix de vie généralement associés à un système immunitaire fort. Mais toutes ces choses demandent un peu d'effort et doivent être continues. Faire du jogging tous les jours pendant une semaine ou arrêter de boire pendant un mois ne changera pas grand-chose à votre état de santé général. Il n'est pas non plus conseillé de courir un 10 km le premier jour où l'on se met à la course à pied. Nous devons d'abord exposer notre cœur et nos muscles à l'exercice. Nous savons également qu'il faut expérimenter un peu avant de trouver un bon équilibre pour notre corps, des aliments sains et des exercices que nous aimons.

Il en va de même pour le développement de logiciels sécurisés. L'apprentissage se fait avec le temps et la pratique, et les développeurs ont besoin de la même formation continue pour renforcer régulièrement leurs compétences en matière de codage sécurisé. De plus, le développement de logiciels évolue et s'adapte en permanence, ce qui signifie que les vulnérabilités évoluent également. C'est pourquoi un simple cours de formation ne suffit pas. Les développeurs ont besoin d'une formation continue régulière afin d'être suffisamment familiarisés avec les menaces potentielles pour être correctement équipés pour s'en défendre. 

Viser l'immunité collective au sein de l'équipe de développement

Une seule personne ne peut pas prévenir tous les problèmes de sécurité. C'est une bonne chose d'avoir des champions de la sécurité dans l'équipe, mais pour obtenir la meilleure protection, plus il y a de personnes qui ont appris à connaître les vulnérabilités en matière de sécurité et à les prévenir, plus votre organisation a de chances de les prévenir. Encore une fois, ce n'est pas très différent de la façon dont le système immunitaire a différents types de cellules T pour différents objectifs. Chaque développeur fait partie d'une équipe qui assure la sécurité. S'ils sont habilités à prendre des responsabilités, à bien faire leur travail et même à aimer le faire, vous pouvez alors créer une immunité collective contre les cybermenaces au sein de l'équipe de développement.

Gardez la sécurité à l'esprit grâce à une exposition répétée

Notre cerveau apprend de la même manière que notre système immunitaire. Le psychologue allemand Hermann Ebbinghaus a été un pionnier dans le domaine de la mémoire et de l'apprentissage. Il en a déduit que l'apprentissage doit se faire dans la durée et au cours de multiples sessions d'apprentissage. À l'école, on ne s'attend jamais à ce que nous conservions de nouvelles connaissances après la première introduction. L'information nous est d'abord présentée, puis nous la pratiquons avec des conseils, puis nous la pratiquons seuls. Et même lorsque nous les avons suffisamment bien assimilées pour réussir un examen, les informations ont tendance à être oubliées peu de temps après si nous n'utilisons pas régulièrement les connaissances que nous avons consacré du temps et des efforts à apprendre. Combien d'entre nous peuvent affirmer qu'ils se souviennent du français qu'ils ont appris au lycée ?

Dès lors, comment croire qu'une seule journée passée à regarder des diapositives et à écouter quelqu'un parler de sécurité permettra aux développeurs présents de coder de manière plus sûre ?

Les schémas de vulnérabilités récurrentes nous montrent que cela ne fonctionne tout simplement pas. 

Comment parvenir à une immunité de développement sécurisée ?

La réponse se trouve dans notre nature. Notre corps et notre esprit fonctionnent de la même manière et apportent de belles solutions aux problèmes, à condition de travailler avec eux et non contre eux. 

Pour garantir la sécurité de vos applications, vous devez commencer par former les développeurs à l'écriture de codes sécurisés. Sinon, l'AppSec continuera à passer tout son temps à examiner l'ensemble du code à la recherche de failles de sécurité et à rapporter les mêmes vulnérabilités récurrentes au développement pour qu'elles soient rapidement corrigées sans que rien n'ait été appris. Et l'on recommence pour la prochaine version.

Répétons-le donc.

Si vous collaborez avec vos responsables du développement pour y parvenir, vous ne vous contenterez pas de mettre en œuvre un SDLC sécurisé et de cocher la case de l'exigence de formation à la sécurité pour la conformité, vous aurez un impact réel sur le processus de développement. Pour couronner le tout, l'AppSec ne rencontrera plus de vulnérabilités répétées et ne les signalera plus aux équipes de développement, et les développeurs passeront moins de temps à les corriger. Cela signifie qu'ils pourront consacrer plus de temps à la création et à l'amélioration des logiciels extraordinaires qui rendent notre monde meilleur. 

Prêt à renforcer les compétences de votre équipe de développement ? Réservez une démonstration avec nous.

Sur Secure Code Warrior, nous cherchons toujours à étendre notre couverture de formation. Pour permettre aux développeurs de systèmes embarqués et aux responsables de la sécurité de construire des systèmes embarqués sûrs, nous nous appuyons sur le monde de la sécurité des systèmes embarqués. Dans ce billet, nous partagerons les éléments clés que les développeurs et les architectes doivent connaître pour construire des systèmes embarqués sécurisés. 

Un dispositif embarqué est une unité informatique indépendante, dotée de son propre matériel et logiciel à base de microprocesseur. Ils sont généralement utilisés pour exécuter des fonctions spécifiques, soit de manière indépendante, soit en tant que parties de systèmes plus importants.

Qu'est-ce qu'un dispositif et un système embarqués ?

Les dispositifs intégrés sont des systèmes informatiques conçus à cet effet, dotés d'un matériel et d'un logiciel minimalistes, programmés pour exécuter des fonctions spécifiques. La complexité des dispositifs embarqués varie en fonction de leur objectif. 

Si un système embarqué doit effectuer des opérations compliquées et gourmandes en ressources, son matériel peut comprendre plusieurs processeurs, avec divers périphériques interconnectés. En revanche, s'il est conçu pour effectuer une tâche simple, il peut ne contenir qu'un seul microcontrôleur. 

Certains systèmes embarqués sont des boîtes noires sans interface utilisateur, tandis que d'autres peuvent être dotés d'interfaces utilisateur graphiques détaillées.

Exemples de dispositifs embarqués

Les dispositifs intégrés trouvent des applications dans de nombreux secteurs, de l'aérospatiale à l'informatique, en passant par les appareils ménagers et les soins de santé. En voici quelques exemples :

• Un thermostat dans un climatiseur. 
• Un tracker de fitness, avec de petits composants électriques fonctionnant avec un minuscule système d'exploitation, qui ne peut rien faire de plus que d'enregistrer et de synchroniser vos statistiques de santé.
• Systèmes numériques de contrôle de la température.
• Systèmes de navigation à l'intérieur d'un avion.
• Montres numériques.
• Dispositifs GPS.
• Composants Wi-Fi dans les fours à micro-ondes et autres appareils électroniques grand public.
• Moniteurs de tension artérielle et de rythme cardiaque.
• Composant de mise en réseau d'un appareil d'IRM qui envoie des données au nuage.

Un ordinateur portable est-il un dispositif embarqué ?

Réponse courte : Réponse longue :

Par définition, un dispositif embarqué encapsule tous les logiciels et le matériel dont il a besoin pour remplir ses fonctions. Un ordinateur portable renferme en effet divers composants matériels dans un boîtier métallique et englobe tous les logiciels dont il a besoin pour offrir son ensemble de fonctionnalités.

Cependant, contrairement aux systèmes intégrés typiques, qui ont un ensemble de fonctions minimal et prédéfini, un ordinateur portable est plus polyvalent et peut être utilisé pour un large éventail d'activités.

Dispositifs intégrés dans l'internet des objets

Les systèmes intégrés sont au cœur de l'IdO. Votre réfrigérateur intelligent peut être contrôlé par votre appareil mobile grâce à un dispositif intégré. C'est un dispositif intégré à votre système de sécurité qui vous permet de visionner des images de vidéosurveillance à des milliers de kilomètres de distance. Et lorsque vous appuyez sur un bouton pour mettre votre voiture en pilote automatique, en coulisses, c'est un dispositif intégré qui fait toute la magie.

Cycle de développement des logiciels embarqués

Le cycle de développement d'un logiciel typique pour un appareil embarqué comprend les étapes suivantes :

Étape 1 : Objectif et exigences

Un dispositif embarqué possède un ensemble de fonctionnalités distinctes et précises. C'est pourquoi il est très important d'énoncer explicitement son objectif et ses exigences avant de commencer le développement. Il est recommandé de créer un document de conception détaillé pour le système. Répondez à des questions telles que :

• Quelles sont les fonctions de l'appareil ?
• Sera-t-il intégré à une autre machine ou fonctionnera-t-il de manière autonome ?
• L'appareil doit-il être doté d'une interface utilisateur ? Si oui, une ligne de commande suffit-elle ou une interface graphique est-elle nécessaire ?
• Quelles sont les limites de taille, de coût ou de consommation d'énergie que l'appareil doit respecter ?
• Existe-t-il des critères de performance ? Par exemple, le dispositif doit-il réagir en temps réel ou dans certaines limites ?

Étape 2 : Architecture du système

Une fois que nous avons identifié les exigences uniques du système, nous sommes prêts à concevoir l'architecture du système. Répondez à des questions telles que :

• Quels sont les composants matériels nécessaires au développement de l'appareil ? Il s'agit d'identifier les circuits, les puces de processeur et les microcontrôleurs, ainsi que tous les périphériques internes et externes nécessaires. 
• Quelle est la puissance nécessaire aux composants ? 
• L'appareil sera-t-il connecté à l'internet ?
• Quelles interfaces doivent être ajoutées/développées pour permettre à l'appareil de se connecter à d'autres appareils ou à la machine dans son ensemble ?
• Comment allez-vous mettre en œuvre le cryptage ? (pensez aux algorithmes, au stockage des clés, etc.)
• Comment allez-vous identifier et éviter les vulnérabilités potentielles, les exploits et les logiciels malveillants ?

Étape 3 : Sélectionnez le système d'exploitation

Le choix du système d'exploitation détermine souvent l'efficacité de vos applications embarquées. Windows pour l'IdO peut obtenir de bons résultats en matière de graphisme, mais il ne prend pas en charge le matériel. Linux embarqué et Android sont gratuits, tandis que VxWorks et Windows pour l'IdO ont des coûts de licence. 

Avec les systèmes à code source ouvert comme Linux et Android, vos développeurs ont plus de contrôle sur le noyau. En revanche, avec les systèmes propriétaires, l'ensemble des fonctionnalités par défaut du noyau est tout ce avec quoi vous pouvez travailler. 

Il est également important de prendre en compte les implications en matière de sécurité lors du choix d'un système d'exploitation. Les correctifs de sécurité sont-ils publiés rapidement, au cas où des vulnérabilités seraient découvertes ? Existe-t-il une protection intégrée contre les attaques de cybersécurité les plus courantes ?

Étape 4 : Les outils de développement

Les différents langages et cadres de programmation présentent des avantages et des inconvénients. En fonction de vos exigences en matière de fonctionnalités, de vitesse et de fiabilité, vous pouvez choisir un langage ou un cadre plutôt qu'un autre. 

Si votre application est basée sur le web et que vous souhaitez des performances élevées, optez pour Java.
En revanche, si vous souhaitez obtenir le débit le plus rapide, optez pour C/C++. Si vous souhaitez bénéficier de la meilleure prise en charge des bibliothèques tierces, optez pour Python.

Étape 5 : Coder, remanier, tester, coder encore

Une fois que vous avez choisi la plate-forme de développement, vous êtes prêt à commencer à coder. N'oubliez pas que les systèmes embarqués sont des dispositifs sensibles dont les ressources matérielles et logicielles sont limitées. Il est donc essentiel de garder à l'esprit les meilleures pratiques en matière de sécurité et de performance des applications.

Les revues de code permettent d'optimiser le code et d'identifier les bogues potentiels. Vous devez également procéder à des tests aussi rigoureux que possible. Veillez à dresser une liste exhaustive de tous les cas de test que le dispositif peut rencontrer lorsqu'il est utilisé en production.

Étape 6 : Maintenance et soutien

Comme pour toute autre application/appareil, le cycle de vie ne se termine pas lorsque l'appareil embarqué a été livré et installé. Au fur et à mesure que l'appareil est utilisé en production, de nouveaux cas d'utilisation sont identifiés, ce qui nécessite l'ajout de nouvelles fonctionnalités. Les bogues signalés peuvent également nécessiter la publication de nouvelles mises à jour du micrologiciel.

Principaux langages de programmation embarqués

De nombreuses organisations réputées, telles que l'IEEE et la TIOBE, classent les langages de programmation en fonction de leur popularité et de leur utilisation. Cependant, que vous consultiez l'index TIOBE ou le Spectre IEEE, vous remarquerez un thème commun.

Les trois premiers langages sont toujours C, Python et Java. L'indice TIOBE de juillet 2021 classe le C en première position, Java en deuxième position et Python en troisième position. Selon le classement de IEEE Spectrum pour les langages de programmation embarqués, l'ordre est le suivant : Python, Java, puis C.

Quelles sont les différences entre les microprogrammes écrits en Java, en C ou en Python ?

Les différents langages gèrent la mémoire, les interactions avec le système d'exploitation et le temps d'exécution de différentes manières. Par exemple, les applications Java s'exécutent dans un environnement d'exécution spécialisé connu sous le nom de machine virtuelle Java (JVM). 

La gestion de la mémoire en C/C++ est manuelle, mais en Java ou en Python, vous n'avez pas à vous préoccuper de la gestion de la mémoire, le langage le fait pour vous. De plus, en C, vous devez collecter vous-même vos déchets, c'est-à-dire que si vous allouez dynamiquement une partie de la mémoire, vous devez la libérer explicitement. Si vous ne le faites pas, cela entraînera une fuite de mémoire. En Java ou en Python, le ramassage des ordures se fait automatiquement. Cependant, le langage C est intrinsèquement beaucoup plus rapide que Java ou Python.

Une chose qui manque à C et Java (mais surtout à C) par rapport à Python est la disponibilité de bibliothèques tierces. Python dispose d'une base de données de bibliothèques plus riche, ce qui permet aux développeurs d'ajouter plus facilement certaines fonctionnalités.

Dans l'ensemble, choisissez C si :

• Vous souhaitez une interface de bas niveau avec le système d'exploitation et le matériel.
• Vous souhaitez obtenir les meilleures performances possibles.
• Vos développeurs sont compétents en C/C++.
• Vous n'avez pas besoin d'un soutien trop important de la part d'un tiers ou de l'extérieur.

Utilisez Python si :

• Vous souhaitez mettre en œuvre des algorithmes de science des données ou d'apprentissage automatique.
• Vous voulez un support riche en bibliothèques tierces.
• Vous êtes prêt à sacrifier la vitesse à la facilité d'utilisation.
• Vous avez une expérience limitée en matière de développement embarqué.
• Vous n'avez pas besoin d'une interface de bas niveau avec le système d'exploitation ou le matériel.

Optez pour Java si :

• Vous créez des applications web.
• Vous souhaitez une plus grande facilité de développement que le C, mais vous voulez plus de performance que Python.
• Vous n'avez pas besoin d'un soutien trop important de la part d'un tiers ou de l'extérieur.

Le langage C cessera-t-il lentement d'être un choix de premier ordre pour le développement embarqué ?

Les langages de haut niveau facilitent le codage en faisant abstraction des complexités qui ne peuvent tout simplement pas être évitées en C. Cependant, pendant des décennies, malgré l'apparition de langages et de cadres plus sophistiqués, le C est resté un choix de premier ordre pour le développement embarqué. 

En effet, la vitesse, les performances et la fiabilité qu'il offre sont encore inégalées. Le fait que Python et une grande partie de l'écosystème Java (y compris le moteur d'exécution, le langage et le compilateur) soient écrits en C en dit long sur l'efficacité et la durabilité du langage.

Cela dit, le C est indéniablement plus difficile à apprendre pour les nouveaux développeurs, qui préfèrent la simplicité de langages comme Python. Cela entraîne une diminution sensible de la taille de la communauté des développeurs C. L'augmentation du développement d'applications d'IA et de ML pousse également les gens à choisir Python plutôt que C, simplement parce qu'il offre un plus grand support de bibliothèque.

Il est important de se rappeler que Python n'est entré que récemment dans le débat sur les principaux langages de programmation embarqués . Oui, son adoption peut continuer à augmenter dans les années à venir, mais nous ne nous attendons pas à ce que le langage C cesse jamais d'être un choix de premier plan pour le développement embarqué.

Pourquoi le codage sécurisé est-il important en C/C++ ?

Beaucoup de choses peuvent mal tourner lorsque vous écrivez du code en C/C++. L'accès à une adresse mémoire qui ne pointe plus vers des données valides, ou le partage incorrect de données entre les fils d'exécution, peuvent entraîner le plantage de toute votre application. 

Pour les dispositifs intégrés, ces implications sont bien plus importantes, car un accident à l'intérieur de ces dispositifs peut entraîner l'arrêt du fonctionnement d'une machine beaucoup plus grande. Par exemple, si le module de pilotage automatique d'une voiture s'arrête, la voiture ne sera plus en mesure d'éviter les obstacles.

Voici d'autres raisons pour lesquelles le codage sécurisé des applications C/C++ est si important :

• Une gestion non sécurisée de la mémoire (pointeurs nuls, corruption de la mémoire, débordements de la pile, débordements de la mémoire tampon et du tas) entraîne le plantage de l'application entière.
• Les pointeurs font partie intégrante des langages C et C++. Leur manipulation nécessite une grande attention et une connaissance approfondie des concepts sous-jacents.
• Le ramassage des ordures est manuel. Il est donc obligatoire pour les programmeurs de supprimer explicitement toute mémoire allouée dynamiquement. Une mémoire non libérée ou incorrectement libérée peut entraîner des fuites ou une corruption de la mémoire.
• Il n'existe pas d'API normalisées pour les structures de données avancées (tables de hachage, ensembles, etc.), ce qui oblige les développeurs à réinventer la roue.

Il est absolument essentiel que les développeurs soient formés au codage sécurisé pour les applications C/C++. Secure Code Warrior propose un site personnalisé learning platform avec des défis interactifs, courses, et des évaluations qui peuvent permettre aux développeurs d'écrire du code C/C++ sécurisé. Il s'agit ici d'un contenu spécifique à la langue et au cadre, et non d'une simple adaptation de la formation conceptuelle générale.

Découvrez comment nous aidons les industries de l'automobile et du transport. Ou essayez dès aujourd'hui un défi de codage axé sur l'embarqué pour découvrir comment nous permettons aux développeurs d'écrire des applications embarquées sécurisées!‍