Le 3 septembre, j'ai assisté avec quelques membres de l'équipe à une impressionnante conférence sur les prix de la sécurité, organisée par CSO Australia. L'une des premières du genre en Australie, la remise des prix 2019 Women in Security a été un point culminant incroyable pour certains des esprits de sécurité les plus réputés de l'industrie. Il s'agissait d'une célébration des contributions féminines à la cybersécurité, ainsi que d'une plate-forme indispensable pour mettre en évidence l'incroyable talent et l'innovation apportés par des femmes qui sont souvent loin des projecteurs et qui travaillent à faire un travail incroyable.

Je suis très fière de dire que Fatemah Beydoun, vice-présidente de la réussite des clients (alias "Chief Awesome") de Secure Code Warrior, faisait partie intégrante de cette journée. Elle a présenté son exposé intitulé " Mentoring for the future : Comment nous pouvons tous faire mieux pour encourager les talents féminins dans le domaine de la cybersécurité, devant un public très réceptif. Bien que douze minutes soient loin d'être suffisantes pour révéler son impact de longue date sur nous et sur le secteur de la cybersécurité dans son ensemble, elle a vu (pour ne pas dire qu'elle a conduit) des changements positifs cruciaux.

Une approche plus inclusive.

"Lorsque j'ai commencé ma carrière dans ce secteur", a déclaré Fatemah, "j'étais l'une des rares femmes dans les équipes où j'étais placée. Beaucoup d'opportunités de réseautage étaient également centrées sur les hommes, ce qui rendait difficile pour moi de participer, de rencontrer les bonnes personnes et de démontrer une valeur critique pour l'entreprise. J'ai cherché à changer cette dynamique, en créant un espace plus inclusif lorsque c'était possible.

Par exemple, j'assistais souvent à des événements industriels et je constatais que de nombreuses entreprises utilisaient des mannequins promotionnels pour attirer l'attention sur leurs stands. En théorie, c'est une bonne chose, mais j'étais souvent ignorée, car je n'étais manifestement pas le marché cible. Au début de ma carrière, j'étais chargée d'organiser des événements et je me suis juré que nous pourrions trouver des moyens plus inclusifs et plus amusants d'attirer l'attention sur nos propres offres", a-t-elle déclaré.

Fatemah et moi travaillons ensemble depuis longtemps et elle a toujours défendu l'inclusion et la diversité dans les entreprises où nous avons travaillé. Cela s'est toujours traduit par davantage de passerelles pour les femmes dans l'équipe, par la reconnaissance des contributions clés et par une cohorte renforcée par des approches, des opinions et des horizons différents.

"Personne ne veut être la femme symbolique, bien sûr", a déclaré Mme Fatemah. "Cependant, le problème peut être que certaines équipes de direction moins diversifiées ont tendance à passer le relais à ceux qui leur ressemblent, auxquels ils peuvent s'identifier sur le plan personnel. Ces mêmes cadres pourraient bénéficier de la contribution d'une femme sur la base de son mérite et de ses compétences, mais il leur est souvent difficile de se faire entendre. Si les équipes de direction sont sensibilisées à la force que la diversité peut apporter (et qui va au-delà du sexe), elles sont souvent tout à fait disposées à créer ces passerelles et à commencer à élever les femmes qui sont prêtes, désireuses et capables de faire un travail formidable pour leur organisation", a-t-elle déclaré.

Flexibilité du lieu de travail : les ingrédients clés de la réussite.

J'ai appris très vite, lorsque j'ai créé ma propre entreprise, que le meilleur travail se fait lorsque les membres de l'équipe ont de l'espace pour respirer. La flexibilité est importante pour tout le monde, mais les politiques qui aident les familles qui travaillent peuvent contribuer à retenir les talents essentiels.

L'une des premières politiques introduites ici a été la politique relative aux nourrissons au travail, qui permet aux nouvelles mères de reprendre le travail plus tôt, avec la flexibilité nécessaire pour les rendez-vous et la possibilité d'amener les nourrissons au travail sans craindre d'être jugées.

"Je ne voulais pas avoir à choisir entre mon rôle de mère et ma carrière, et la possibilité d'emmener mon jeune fils au travail m'a permis de me sentir soutenue et valorisée", a déclaré Fatemah. "Mes compétences ne disparaissent pas après l'accouchement et, en tant que membre fondateur d'une startup, vous n'avez qu'une envie, c'est de vous y remettre !

Elle a même parlé à ABC News des avantages du travail flexible :

Avez-vous une culture de mentorat florissante ?

Pour lancer quelqu'un sur une bonne trajectoire de carrière et lui permettre de poursuivre sur sa lancée, il est souhaitable qu'il ait un mentor. Dans de nombreux domaines de l'informatique, de la cybersécurité et à prédominance masculine, il y a un déséquilibre entre le nombre de femmes cadres et le nombre d'hommes, ce qui peut être un peu difficile.

S'il est important que les femmes se voient elles-mêmes à des postes de direction, les hommes peuvent également contribuer à élever les femmes les plus brillantes de leurs équipes et à les encadrer, si possible.

"Les équipes de direction peuvent avoir un impact considérable sur la diversification au sein d'une organisation, tout en veillant à ce que les femmes exceptionnelles obtiennent la reconnaissance et les perspectives de carrière qu'elles méritent autant que n'importe qui d'autre. J'ai pu le constater avec Yvette Lejins, responsable de la cybersécurité chez Jetstar. Elle est une championne des femmes et, grâce à sa réussite et à son travail acharné, elle a fait profiter d'autres femmes de son expérience et les a aidées à trouver la confiance nécessaire pour viser le sommet", a déclaré Mme Fatemah.

À l'heure actuelle, Secure Code Warrior vient de fêter ses 100 employés. Je suis fière de dire que nous avons une représentation féminine de plus de 50 % dans l'entreprise, et Fatemah est un modèle et un mentor exceptionnel pour tous.

Toutes les entreprises peuvent trouver une grande force dans la diversification de leurs équipes. Un éventail d'opinions, provenant de différents horizons, peut être l'ingrédient secret nécessaire pour transformer de bonnes idées en grandes idées. Comme toujours, nous sommes tous plus forts ensemble.

L'industrie de la sécurité des logiciels n'est pas exactement connue pour ses sentiments chaleureux et flous, ses observations fantaisistes et ses commentaires sur la vie, mais, peut-être qu'en vieillissant, je me surprends à réfléchir à l'impact que nous pouvons tous avoir dans le monde. Et cela peut avoir un effet d'entraînement positif qui s'étend bien au-delà des frontières de la cybersécurité.

Grâce à la suggestion d'un membre de l'équipe, nous avons mis en œuvre le programme Warriors Give Back dans toute l'entreprise. Cette initiative a été conçue pour nous inciter à "rendre la pareille" aux communautés qui nous entourent, en travaillant activement en équipe pour rendre le monde un tout petit peu plus lumineux.

Bien que ce fut une occasion incroyable pour beaucoup d'entre nous de resserrer les liens au sein d'une équipe unie, ce fut un moment unique pour prendre du recul, faire le point et voir ce qui est vraiment important avec une clarté renouvelée. Toute personne travaillant dans une startup vous le dira : le rythme peut être effréné, les temps morts rares... C'est à la fois gratifiant, épuisant et passionnant. Cependant, lorsque vous vivez et respirez votre entreprise, il peut être trop facile de faire abstraction de la vie autour de vous.

Une force au service du bien.

La chose la plus importante que nous espérions réaliser était de faire quelque chose d'immédiatement utile pour la communauté, et pas seulement de poser pour quelques photos afin de nous féliciter. Il s'agissait de reconnaître nos privilèges et d'agir avec gratitude. Tout le monde, dans tous les secteurs d'activité, pourrait faire un peu plus de ce genre de choses. Après tout, on ne répand jamais trop de bonne volonté et on ne reste jamais trop humble.

Pour notre événement de lancement, nous avons décidé de travailler ensemble à la construction de vélos pour des enfants défavorisés, dans le cadre du programme Bikes for Tykes. Je suis sûr que nous nous souviendrons de cette journée avec de bons souvenirs de nos compétences mécaniques combinées (ou de leur absence) et de nombreux rires, mais l'étincelle de bonheur apportée à neuf enfants très spéciaux au moment où ils en avaient le plus besoin est une récompense qui va bien au-delà de l'aspect matériel d'un vélo flambant neuf. Cet événement était un petit geste de notre part, mais j'espère que pour un petit moment, ils ont pu oublier leurs problèmes et simplement apprécier d'être des enfants.

Donnez en retour, obtenez davantage.

Un vieux dicton dit que "la gentillesse est un cadeau que tout le monde peut s'offrir". C'est tout à fait vrai, mais il y a une chose que la communauté de la cybersécurité, en particulier, semble bien faire, c'est l'abondance du partage gratuit des connaissances et des ressources en ligne pour aider les gens à comprendre, à apprendre et à explorer. Naturellement, des organisations comme l'OWASP consacrent beaucoup de temps à nous rendre tous plus sûrs, et je vois constamment la volonté des autres d'aider à répondre aux questions après les présentations et les événements. Je pense que si nous donnions tous plus, nous constaterions que nous sommes finalement récompensés au décuple.  

Nous allons poursuivre notre quête pour rendre service, comme le font de nombreuses autres entreprises formidables à travers le monde. Soyons une force de changement positif, où que nous soyons.

(Psst : notre bibliothèque de ressources d'apprentissage pour les développeurs est toujours ouverte pour vous).

L'annonce récente de la découverte par un adolescent, Bill Demirkapi, d 'importantes vulnérabilités dans un logiciel utilisé par son école, m'a certainement rappelé quelques souvenirs. Je me souviens avoir été un enfant curieux, qui soulevait le capot d'un logiciel pour jeter un coup d'œil en dessous et voir comment il fonctionnait - et plus important encore - si je pouvais le casser. Pendant des décennies, les ingénieurs en informatique ont cherché à améliorer et à renforcer constamment leurs produits, et la communauté de la sécurité (bien qu'elle soit parfois un peu insolente dans son approche) joue un rôle important dans la découverte des failles et des catastrophes potentielles, avec un peu de chance avant qu'un méchant ne fasse la même chose.

Cependant, le problème ici est qu'en réponse à ses découvertes, il a écopé d'une suspension mineure de l'école. Et ce, après avoir épuisé tous les moyens de contacter l'entreprise(Follett Corporation) en privé, optant finalement pour un coup d'éclat plutôt public afin de se faire connaître et d'identifier sa capacité à pénétrer dans leur système. Ses tentatives répétées d'avertir la société Follett d'un point de vue éthique sont restées sans réponse, tandis que le logiciel demeurait vulnérable et que des montagnes de données sur les étudiants étaient assez facilement exposées, car la plupart d'entre elles n'étaient pas cryptées.

Il a également recherché des bogues dans le logiciel d'une autre entreprise : Blackboard. Bien que les données de Blackboard soient au moins cryptées, des attaquants potentiels auraient pu s'y introduire et s'emparer de millions d'enregistrements supplémentaires. Son école utilisait à la fois ce logiciel et le produit de Follett.

Le récit du "méchant hacker" est problématique.

Demirkapi a présenté ses découvertes lors de la DEF CON de cette année, et les détails les plus espiègles de son manège ont été applaudis par la foule. Bien qu'il ait d'abord été mal vu et qu'il ait dû faire face à de nombreux obstacles pour que ses découvertes soient reconnues, Follett Corporation l'aurait remercié pour ses efforts et aurait suivi ses conseils, ce qui lui a permis de rendre ses logiciels plus sûrs et d'éviter de devenir une autre statistique sur les violations de données. Il fréquentera également le Rochester Institute of Technology après avoir terminé ses études secondaires. Il est donc clair qu'il est sur la bonne voie pour devenir un spécialiste de la sécurité très demandé.

En tant que responsable de la sécurité, il est difficile de ne pas s'offusquer de la manière dont cette situation a été gérée. Même si tout est bien qui finit bien dans cette affaire, il a d'abord été traité comme un petit script ennuyeux qui mettait son nez là où il ne fallait pas. Une recherche Google sur l'incident permet de trouver des articles qui le qualifient de "hacker" (dans l'esprit du profane en matière de sécurité, cela le positionne comme le méchant à bien des égards), alors qu'en réalité son approche (et celle de beaucoup d'autres) est ce qui permet de préserver la sécurité de nos données.

Nous avons besoin de personnes curieuses, intelligentes et axées sur la sécurité qui regardent sous le capot, et nous avons besoin que cela se produise beaucoup plus souvent. En juillet dernier, plus de quatre milliards d'enregistrements avaient été exposés dans le cadre de violations de données malveillantes, rien que cette année. Vous pouvez potentiellement ajouter cinquante millions à ce chiffre, grâce à la violation en août de la marque de mode et de style de vie Poshmark.

Nous commettons les mêmes erreurs et, ce qui est encore plus inquiétant, il s'agit souvent de facepalmducing, de simples vulnérabilités qui continuent à nous faire trébucher.

Les scripts intersites et les injections SQL n'ont pas disparu.

Comme le rapporte WIRED, Demirkapi a découvert que le logiciel Blackboards Community Engagement et le système d'information des étudiants Folletts contenaient des bogues de sécurité courants tels que le cross-site scripting (XSS) et l'injection SQL, deux problèmes qui préoccupent les spécialistes de la sécurité depuis les années 1990. Nous avons enduré leur existence pendant très longtemps et, à l'instar des t-shirts Hypercolor et des disquettes, ils ne devraient plus être qu'un lointain souvenir.

Mais ce n'est pas le cas, et il est clair que trop peu de développeurs sont suffisamment sensibilisés à la sécurité pour empêcher l'introduction de ces éléments dans leur code. Les outils d'analyse et les examens manuels du code ne peuvent pas tout faire, et il existe des problèmes de sécurité bien plus complexes que les XSS et les injections SQL, pour lesquels ces mesures coûteuses et chronophages pourraient être mieux utilisées.

Des personnes comme Bill Demirkapi devraient inciter les développeurs à créer une norme de code plus élevée ; à seulement 17 ans, il a pénétré dans deux systèmes à fort trafic par le biais de vecteurs de menace qui auraient dû être détectés et corrigés avant même que le code ne soit validé.

La gamification : La clé de l'engagement ?

J'ai beaucoup écrit sur les raisons pour lesquelles les développeurs restent largement désintéressés par la sécurité, et la réponse courte est que peu de choses sont faites au niveau de l'organisation et de l'éducation pour encourager les développeurs à prendre conscience de la sécurité. Lorsque les entreprises prennent le temps de construire une culture de la sécurité qui récompense et reconnaît l'engagement, y compris en mettant en œuvre une formation qui parle le langage des développeurs et les motive à continuer d'essayer, ces reliques de vulnérabilités ennuyeuses commencent à disparaître des logiciels que nous utilisons.

Demirkapi a manifestement un intérêt extrascolaire pour la sécurité et a pris le temps d'apprendre à faire de la rétro-ingénierie de logiciels malveillants, à repérer les failles et, bien sûr, à casser des choses qui ne semblent pas cassées de l'extérieur. Toutefois, lors d'un entretien avec VICE (et par le biais de ses diapositives DEF CON), il a fait une déclaration intéressante sur son auto-apprentissage... il l'a ludifié :

"L'objectif étant de trouver quelque chose dans le logiciel de mon école, il s'agissait d'une manière amusante et ludique de m'enseigner une bonne partie des tests de pénétration. Bien que j'aie commencé mes recherches avec l'intention d'en apprendre davantage, j'ai fini par découvrir que les choses étaient bien pires que ce à quoi je m'attendais", a-t-il déclaré.

Même si tous les développeurs ne souhaitent pas se spécialiser dans la sécurité, chacun d'entre eux devrait avoir la possibilité d'être sensibilisé à la sécurité, les bases servant presque de "permis de coder" au sein d'une organisation, en particulier celles qui contrôlent des masses de nos données sensibles. Si les failles de sécurité les plus simples peuvent être corrigées par chaque développeur avant même qu'elles ne soient écrites, nous serons dans une position beaucoup plus sûre face à ceux qui cherchent à faire des ravages.

Curieux d'en savoir plus sur la formation ludique ? Consultez notre série Coders Conquer Security (Les codeurs à la conquête de la sécurité) sur les XSS et injection SQL.

Bien que VxWorks ne soit pas vraiment un nom familier pour le consommateur moyen, ce produit logiciel profite inévitablement à de nombreuses personnes comme vous et moi, chaque jour. En tant que système d'exploitation en temps réel (RTOS) le plus populaire au monde, il est le cheval de bataille sur lequel nous nous appuyons (par procuration) pour faire fonctionner les réseaux et les pare-feu des entreprises, les interfaces aérospatiales, les équipements industriels et même certains appareils médicaux, pour ne citer que quelques applications de son utilisation généralisée.

Aujourd'hui, nous sommes confrontés à la possibilité que des centaines de millions, voire des milliards, de ces appareils soient compromis par au moins onze vulnérabilités. Arlen Baker, architecte en chef de la sécurité chez Wind River, a contesté ce chiffre dans un article de SearchSecurity, révélant que la portée exacte n'est pas confirmée et qu'elle n'est pas considérée comme aussi élevée. Malgré cela, nous savons déjà que des violations de données et des attaques se produisent en permanence, mais il s'agit là d'un niveau supérieur : les failles confirmées sont relativement faciles à exploiter, beaucoup d'entre elles ouvrant la porte et permettant aux attaquants de contrôler des appareils à distance par la transmission de paquets réseau.

Wind River a, bien entendu, publié une série de correctifs et de patches à l'intention des clients et associés concernés. Le problème réside dans le grand nombre d'appareils nécessitant la mise à jour du correctif - tout comme Thanos mettant fin au monde d'un simple clic, il est inévitable que de nombreux appareils ne soient pas corrigés, et donc vulnérables, pendant une longue période.

La société de sécurité Armis est à l'origine de cette découverte colossale, qu'elle a baptisée URGENT/11. Elle l'a qualifiée de sérieuse, sans doute en raison de la facilité d'attaque à partir de vecteurs multiples et du potentiel d'infection à grande échelle. Il est tout à fait possible de créer et de déployer un ver dans un logiciel qui alimente tout, des scanners IRM aux produits VOIP, en passant par les réseaux ferroviaires et les feux de signalisation.

Faut-il paniquer ?

En tant que personne qui a fait de la sensibilisation à la sécurité une mission essentielle de sa vie, je vois beaucoup de problèmes de sécurité potentiels au quotidien. Je passerais la majeure partie de ma journée à être hystérique si je me laissais aller à trop paniquer (après tout, je préfère m'atteler à la tâche d'éduquer et d'aider à corriger les bogues !) Cependant, la portée de la découverte URGENT/11 est assez effrayante. Sur les onze vulnérabilités découvertes, six sont considérées comme critiques. Comme l'indique The Hacker News, ces failles existent dans les appareils fonctionnant sous VxWorks depuis la version 6.5 (à l'exclusion des versions conçues pour la certification, notamment VxWorks 653 et VxWorks Cert Edition), ce qui signifie qu'une technologie vitale est menacée par des attaques de prise de contrôle d'appareils depuis plus d'une décennie maintenant. Tous les appareils ne sont pas vulnérables aux onze failles (et certaines ne peuvent être exploitées que si l'attaquant se trouve sur le même sous-réseau LAB), mais même un pirate médiocre n'a besoin que d'une petite fenêtre d'opportunité.

Il est important de noter que Wind River a réagi rapidement et a fourni des conseils détaillés pour atténuer les problèmes, tout comme Armis. De plus, si le RTOS VxWorks est si largement adopté , c'est parce qu' il est très fiable et qu'il obtient d'excellents résultats en matière de sécurité logicielle - en général, les chasseurs de bogues ne s'en préoccupent pas trop. Cependant, les sociétés de sécurité et Wind River ne peuvent pas résoudre tous les problèmes... c'est à l'utilisateur final de télécharger les correctifs, de suivre les conseils de sécurité et de fortifier ses propres appareils, et c'est là que les choses se compliquent.

Il n'y a peut-être pas lieu de paniquer pour l'instant, mais il faudra peut-être un village pour faire plier cette bête.

Les vulnérabilités URGENT/11 expliquées

À ce stade, tout dispositif connecté à la pile TCP/IP IPnet de VxWorks compromise depuis la version 6.5 pourrait être affecté par au moins l'une des CVE URGENT/11. (Pour une liste complète des CVE de Wind River, voir ici).

La plupart de ces failles permettent l'exécution de code à distance (RCE) et des attaques par déni de service, et quelques-unes conduisent également à l'exposition d'informations et à des problèmes de logique commerciale. L'exécution de code à distance est un problème particulièrement sensible dans ce cas, car un attaquant peut prendre le contrôle d'un appareil sans aucune interaction avec l'utilisateur final. Personne n'a besoin de cliquer accidentellement sur quelque chose de suspect, de télécharger quoi que ce soit ou d'entrer ses coordonnées... Cela rend les appareils VxWorks très "vermoulus" et l'attaque prend une vie automatisée qui lui est propre. Vous vous souvenez du ver WannaCry d'EternalBlue ? URGENT/11 a un potentiel similaire, mais plus dévastateur, pour nous donner un mal de tête mondial.

Que pouvons-nous faire ?

À l'heure où nous écrivons ces lignes, les conséquences d'URGENT/11 restent inconnues. Les médias ont sensibilisé l'industrie et Wind River apporte clairement son soutien aux personnes touchées. Les mois à venir révéleront si des attaquants choisissent d'exploiter ces failles connues de manière significative, mais en attendant, la solution évidente est de suivre la pléthore de conseils et de patcher tous les dispositifs concernés dans votre orbite.

À long terme, la mission reste la même : tout le monde doit faire mieux en matière de sécurité des logiciels. Les CVE URGENT/11 sont généralement des portes dérobées d'une simplicité inquiétante, et le fait qu'ils n'aient pas été découverts pendant de nombreuses années témoigne du peu d'intérêt et de sensibilisation de l'ensemble du secteur.

Chaque développeur a la possibilité de faire sa part, et il a besoin de soutien pour apprendre à sécuriser le code dès le début de la production. Les équipes influentes qui les entourent, de l'AppSec à la C-suite, peuvent s'assurer qu'une culture de la sécurité positive se développe à chaque point de contact logiciel au sein de l'entreprise.

Vous voulez tester votre propre sensibilisation à la sécurité ? Notre plateforme gamifiée peut vous proposer des défis de code réels similaires à certains de ceux découverts dans URGENT/11. Testez-les et voyez comment vous vous en sortez :

• Débordement de tas dans l'analyse des offres/ACK DHCP dans ipdhcpc (CVE-2019-12257)
  Corruption de mémoire - débordement de tas
• Connexion TCP DoS via des options TCP malformées (CVE-2019-12258)
  Protection insuffisante de la couche transport - Transport non protégé d'informations sensibles
• Faille logique dans l'attribution d'IPv4 par le client DHCP ipdhcpc (CVE-2019-12264).
  Défauts de logique d'entreprise
• DoS via une déréférence NULL dans l'analyse IGMP (CVE-2019-12259)
  Corruption de mémoire - déréférencement nul
• Fuite d'informations IGMP via le rapport d'adhésion spécifique à IGMPv3 (CVE-2019-12265).
  Exposition d'informations - Exposition de données sensibles

Une version de cet article a été publiée sur DevOps.com; il a été renommé et mis à jour pour inclure de nouvelles informations.

Si les RSSI et les DSI ont la position peu enviable d'assumer la plus grande part de responsabilité en matière de sécurité des logiciels, notamment en cas de violation embarrassante des données de l'entreprise, ils bénéficient également d'une opportunité unique de plus en plus pertinente : ils sont les nouveaux innovateurs et peuvent avoir une grande influence en adoptant la bonne approche. Toutes les organisations de la planète, qu'elles soient publiques ou commerciales, se battent pour conserver (et gagner) leur place sur le marché dans un monde qui se numérise rapidement. Les clients s'attendent à une expérience en ligne transparente pour les produits passés et futurs, et une approche commerciale "numérique d'abord" devient obligatoire. Après tout, si ces attentes ne sont pas satisfaites, il y a presque certainement un concurrent prêt à saisir l'occasion.

Qu'est-ce que cela signifie pour le RSSI ou le DSI moderne ? Naturellement, cela signifie qu'ils emploient des équipes de développeurs, chacun créant ligne après ligne le code qui forme leur produit ou service numérique. La cybersécurité, qui est une préoccupation majeure depuis de nombreuses années, est un facteur de risque croissant, car de plus en plus d'activités commerciales sont menées en ligne et se trouvent dans la ligne de mire des attaquants. Les conséquences d'une violation sont énormes, mais il n'est pas possible de se soustraire à la numérisation.

Les RSSI et les DSI créatifs sont dans une position privilégiée pour continuer à tracer la voie de notre avenir numérique, en collaboration avec leurs équipes d'AppSec et de développement. Ils façonneront sans aucun doute l'innovation à long terme des entreprises, des administrations et des services publics en ligne, mais ils ont la lourde responsabilité de trouver un équilibre entre les objectifs de rapidité de mise sur le marché, la qualité élevée des logiciels et l' atténuation des risques de sécurité.

Jusqu'à présent, cet équilibre a été extrêmement difficile à trouver. Il a conduit à des équipes de développement souvent fragmentées, dont l'objectif principal est de fournir des caractéristiques et des fonctions, sans tenir compte des vulnérabilités qu'elles pourraient créer dans le code qu'elles produisent si rapidement. Les spécialistes de l'AppSec corrigent constamment les mêmes erreurs, alors que la menace d'une violation due à une porte dérobée relativement simple laissée ouverte se profile à l'horizon.

Pour que nos données restent en sécurité, les RSSI et les DSI doivent faire preuve de créativité dans la manière dont leurs équipes travaillent ensemble, et forger une culture de sécurité positive et de responsabilité partagée du haut en bas de l'échelle. Il suffit de regarder les conséquences catastrophiques auxquelles Marriott a dû faire face à la suite de la violation de 2018 : Une amende GDPR de plus de 123 millions de dollars, plus de 500 millions d'enregistrements volés et une réputation de sécurité en lambeaux. Ce désastre est en grande partie le résultat direct de pratiques de codage non sécurisées, avec des vulnérabilités d'injection SQL découvertes dès 2014 sur les serveurs de Starwoods, une société acquise par Marriott en 2016. L'utilisation ultérieure du logiciel n'a manifestement pas été contrôlée du point de vue de la sécurité des applications. Les attaquants malveillants ont ainsi eu plusieurs années pour accéder aux données et les acquérir, tandis que d'autres vulnérabilités, comme la faiblesse des mots de passe, ont laissé davantage de failles à exploiter au fil du temps.

Les DSI et les RSSI doivent examiner très attentivement l'état de leur propre climat de sécurité logicielle. Dans quelle mesure le développeur moyen est-il sensibilisé à la sécurité ? Les équipes de développement et d'AppSec travaillent-elles bien ensemble ? Il n'existe pas de solution miracle, mais la culture, la formation et le soutien peuvent être travaillés et améliorés. Les équipes de développement peuvent passer de la première ligne de risque de violation de données dans l'organisation aux super-héros de la sécurité qui arrêtent le mauvais code avant même qu'il n'entre en production.

Bilan de santé du codage sécurisé : Le vôtre est-il sous assistance respiratoire ?

Quelle est la place de votre équipe de développement ? J'ai créé cette liste de contrôle pour aider les DSI et les RSSI à déterminer si leurs équipes de développement sont vraiment équipées pour être des champions du codage sécurisé, contribuant à l'innovation avec un code plus rapide, meilleur et plus sûr (ou, en fait, si vous avez besoin d'une refonte de votre programme de sécurité) :

1. Quel est le degré de soutien du reste de votre équipe de direction ? Comprennent-ils que la sécurité traditionnelle des réseaux ne suffit plus ?

Dans l'avenir des logiciels, sécuriser la couche réseau à l'aide de mesures de sécurité dépassées n'est tout simplement pas suffisant (et, soyons honnêtes, ne réussit que rarement de toute façon), même contre des pirates semi-professionnels. Parmi de nombreux rapports concordants, le "2017 Data Breach Investigations Report" de Verizon indique qu'un pourcentage stupéfiant de 35 % des violations de données sont aujourd'hui causées par des vulnérabilités d'applications web.

La sécurité des applications web est tout aussi importante que la sécurité des réseaux ; si vous ne tenez pas compte de ce fait et si vous ne prévoyez pas de budget pour la couche de protection fondamentale des mesures AppSec et ne l'instaurez pas, vous risquez d'être victime d'une violation.

2. Vous déplacez-vous suffisamment vers la gauche et le faites-vous assez tôt ?

L'approche actuelle de la sécurité des applications est plutôt axée sur les outils et se concentre sur le passage de la droite à la gauche du cycle de vie du développement logiciel (SDLC). Par définition et par conception, cette approche reconnaît que le processus est défectueux et soutient un résultat de détection et de réaction. Les équipes de sécurité recherchent et détectent les vulnérabilités dans le code déjà écrit, réagissant pour corriger le code engagé au lieu de s'assurer qu'il est exempt de bogues au moment de sa création. Selon le National Institute of Standards and Technology(NIST), il est 30 fois plus coûteux de détecter et de corriger les vulnérabilités dans le code validé que de les prévenir au moment où elles sont écrites dans l'IDE. Cela ne prend même pas en compte les retards de production, la double manipulation et le temps passé à remédier aux mêmes problèmes de sécurité bien connus, encore et encore.

Une culture de la sécurité vraiment solide insiste sur le fait qu'il faut commencer par la base, en inspirant des champions de la sécurité au sein de la cohorte des développeurs, tout en donnant à l'équipe de développement les bons outils et la bonne formation pour se développer et agir avec un état d'esprit de codage sécurisé. L'accent est mis sur l'auto-développement continu et sur l'utilisation des muscles de résolution de problèmes afin qu'ils puissent être la première ligne de défense de leur organisation, en empêchant les vulnérabilités courantes de se produire en premier lieu.

3. Faites-vous l'effort de développer des compétences pratiques en matière de sécurité ou vous contentez-vous de transmettre des connaissances à sens unique ?

La grande majorité des solutions de formation à la sécurité (en ligne et CBT) se concentrent sur l'acquisition de connaissances plutôt que de compétences pratiques directement liées à leur travail. Pour que les développeurs s'épanouissent et s'engagent dans l'écriture de codes sécurisés, ils ont besoin d'un accès régulier à un apprentissage contextuel et pratique qui les encourage activement à continuer à se former et à développer leurs compétences dans un environnement réel. Ils doivent se familiariser avec les vulnérabilités récemment identifiées, à l'aide d'exemples de code réels, et être en mesure de travailler dans leurs langages et cadres préférés. Cette expérience d'apprentissage les aide à comprendre comment localiser, identifier et corriger les vulnérabilités connues dans le code sur lequel ils travaillent activement dans le cadre de leur travail.

Bien qu'il existe de nombreux enseignants compétents et de nombreuses informations sur la correction des failles de sécurité, le fait de feuilleter des manuels ou de regarder des heures de vidéo ne parvient pas à mobiliser l'esprit de nombreux développeurs créatifs et capables de résoudre des problèmes et, si l'on en croit le flux constant de violations de données, reste largement inefficace pour empêcher les failles d'entrer dans le code.

4. Mesurez-vous vos compétences en matière de codage sécurisé à l'aide d'indicateurs en temps réel ?

Pour s'assurer qu'une équipe de développement adopte un état d'esprit axé sur la sécurité, il est essentiel de recueillir et d'examiner des preuves. Il ne doit pas s'agir d'une hypothèse ou d'un jeu de devinettes : soit les développeurs sont soucieux de la sécurité, soit ils ne le sont pas.

Les mesures visent à prouver au développeur et à son organisation que son travail acharné porte ses fruits et que ses compétences individuelles en matière de codage sécurisé s'améliorent. Vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer. Il doit y avoir des évaluations pertinentes, et celles-ci doivent permettre d'identifier les progrès de vos équipes de développement en temps réel ainsi que de comparer leurs forces et faiblesses en matière de codage sécurisé en vue d'une amélioration continue.

Trop souvent, la formation à la sécurité devient un exercice "à cocher" pour les organisations, sans que l'accent soit mis sur l'efficacité, l'engagement ou même la rétention de cette formation.

5. Vos fournisseurs externalisés utilisent-ils des techniques de codage sécurisées et robustes ?

De nombreuses organisations décident de confier des travaux de développement à des agences tierces. Qu'elles existent à l'étranger ou à l'étranger, leurs capacités et leurs pratiques générales en matière de codage sécurisé sont un mystère pour leur client. Dans le meilleur des cas, la seule forme d'assurance qu'une organisation recevra en matière de sécurité sera une déclaration dans le contrat exigeant que le produit à livrer soit "sécurisé". Très peu d'entreprises prennent des mesures pour vérifier en amont les compétences de ces sociétés de développement, courant ainsi le risque de se voir livrer un logiciel qui fonctionne comme prévu, mais qui a été construit sans respecter de bonnes pratiques de codage sécurisé. Pire encore, si l'entreprise acheteuse n'est pas consciente des failles de sécurité inhérentes à l'application, elle risque d'envoyer un logiciel vulnérable dans la nature.

Le scénario le plus courant est que les vulnérabilités sont détectées par des spécialistes de la sécurité (des personnes difficiles à recruter et dont le coût est élevé) et que vous êtes confronté à un retard de la date de mise en service et à d'éventuelles discussions contractuelles sur la question de savoir qui doit payer pour corriger ces faiblesses en matière de sécurité. Toutefois, si vous faites preuve d'intelligence dès le départ et que vous évaluez les compétences en matière de sécurité des applications des développeurs qui vont créer votre prochaine application, vous économiserez beaucoup de retards potentiels, de frustration et d'argent.

6. Vos développeurs connaissent-ils les faiblesses de sécurité les plus couramment exploitées ?

Plus de 85 % des vulnérabilités exploitées dans les applications web sont attribuées à seulement 10 vulnérabilités connues, le Top 10 de l 'OWASP. Votre formation à la sécurité des applications doit au minimum couvrir ces vulnérabilités, ainsi que de nombreux autres types de vulnérabilités. Les défis de formation auxquels vos développeurs sont confrontés doivent être révisés et mis à jour régulièrement, avec de nouveaux défis pour de nouveaux cadres de codage ou de nouveaux types de vulnérabilités.

Une formation précise utilisant des scénarios de codage sécurisés du monde réel devrait être la norme ; de vagues connaissances générales ne sont tout simplement pas efficaces. (Vous vous demandez à quoi pourraient ressembler ces scénarios de codage sécurisé ? Consultez notre série de blogs Coders Conquer Security; chaque article contient un défi à relever).

7. Disposez-vous de champions de la sécurité en interne ?

Toute organisation à forte intensité de développement devrait investir dans un champion de la sécurité - une personne qui va prendre la responsabilité de maintenir une norme de sécurité élevée au sein de l'équipe de développement. Son objectif est de servir de point de contact pour toute personne ayant des questions sur la sécurité et de devenir le principal défenseur du respect des meilleures pratiques en matière de sécurité.

Ils sont une pièce essentielle du puzzle de la culture de la sécurité ; un grand champion de la sécurité peut maintenir l'élan après une formation intensive, s'assurer que tous les membres de l'équipe disposent de ce dont ils ont besoin et continuer à plaider en faveur d'un soutien.

8. Avez-vous investi dans des outils pour vos développeurs afin de faciliter le codage sécurisé ?

Si votre organisation pratique le développement agile, ou si vous êtes confronté à des mises à jour fréquentes des applications développées par l'entreprise, l'automatisation de certaines parties de votre sécurité est l'un des seuls moyens de suivre le rythme effréné et le volume de travail.

Il existe des outils disponibles à chaque étape du cycle de développement durable qui serviront de conseillers, de gardiens de la qualité ou d'outils de détection. En outre, certains outils exécutent des tests automatisés sur le code, simulant des tentatives de piratage une fois que le logiciel est en production. Tous ces outils présentent leurs propres avantages et défis, et aucun ne peut garantir à 100 % qu'aucune menace de sécurité n'existe au sein de l'application. La principale mesure préventive que vous pouvez employer est que plus tôt vous pouvez détecter la faiblesse, plus il est rapide et moins coûteux d'y remédier avec le moins d'impact possible sur votre entreprise.

La prochaine étape pour les RSSI tournés vers l'avenir

Comment votre organisation s'est-elle comportée par rapport à la liste de contrôle ci-dessus ?

Alors que les RSSI et les DSI sont essentiellement contraints de développer agressivement les capacités DevOps et DecSecOps de leur entreprise, cela ne signifie pas qu'il n'y a pas de temps pour envisager et mettre en œuvre les bons outils et la bonne formation au sein des équipes. Les compétences en matière de codage sécurisé seront une arme, et non un obstacle à l'innovation, et le fait d'y renoncer pourrait signifier la destruction absolue de la réputation et des données de l'entreprise. Ces compétences représentent des capacités essentielles et une solution à long terme beaucoup moins coûteuse pour réduire les vulnérabilités et atténuer les risques.

Un RSSI brillant et innovant a le pouvoir d'orchestrer une culture de la sécurité saine depuis le sommet jusqu'à la base ; assurez-vous que votre personnel dispose de ce dont il a besoin pour mettre en œuvre efficacement les meilleures pratiques en matière de sécurité.

Pieter Danhieux est un expert en sécurité et le cofondateur de. Secure Code Warrior.

Une version de cet article a été publiée dans Digital Transactions Magazine.

Cette année, le Conseil des normes de sécurité du PCI a publié un tout nouvel ensemble de lignes directrices sur la sécurité des logiciels dans le cadre du PCI Software Security Framework. Cette mise à jour vise à aligner les meilleures pratiques en matière de sécurité des logiciels sur le développement moderne des logiciels. Il s'agit d'une initiative fantastique qui reconnaît la façon dont ce processus a évolué au fil du temps, ce qui nécessite de repenser les normes de sécurité qui ont été établies bien avant que la majorité de nos vies ne deviennent rapidement numérisées.

Il s'agit d'une preuve évidente que notre industrie s'engage plus étroitement dans l'idée de lignes directrices adaptables - qui évoluent avec nos besoins changeants - ainsi qu'avec les exigences d'un paysage de cybersécurité qui pourrait très rapidement échapper à tout contrôle si nous continuons à être laxistes dans nos processus de développement sécurisés. Naturellement, le Conseil des normes de sécurité PCI agissant en tant qu'organe directeur du secteur bancaire et financier (c'est-à-dire définissant les normes de sécurité des logiciels auxquels nous faisons confiance pour protéger notre argent, nos cartes de crédit, nos transactions en ligne et nos points de vente), il est porteur d'un risque important et a une motivation énorme pour le réduire.

Bien que ces normes améliorent certainement la version précédente et comblent en partie les lacunes en matière de développement rapide et innovant de fonctionnalités, tout en accordant la priorité à la sécurité dans le cadre de la qualité globale assessment, il est quelque peu décevant de constater qu'il reste encore beaucoup de chemin à parcourir.

Non, ce n'est pas moi qui donne un "bah, humbug !" à cette initiative. Le fait est que ces nouvelles lignes directrices en matière de sécurité ne nous rapprochent pas suffisamment de la gauche.

Nous étions toujours obnubilés par les tests (et nous les avons effectués trop tard).

Un problème flagrant que j'ai trouvé dans le cadre des normes de sécurité PCI est sa dépendance apparente à l'égard des tests. Bien sûr, les logiciels doivent toujours être testés (et le processus SAST/DAST/IAST a toujours sa place), mais nous tombons toujours dans le même piège et nous attendons un résultat différent.

Qui écrit ligne après ligne de code pour créer les logiciels que nous connaissons, aimons et auxquels nous faisons confiance ? Les développeurs de logiciels.

À qui incombe la tâche peu enviable de tester ce code, que ce soit à l'aide d'outils d'analyse ou d'un examen manuel du code ? Les spécialistes de l'AppSec.

Que découvrent toujours ces spécialistes ? Les mêmes bogues qui nous affligent depuis des décennies. Des problèmes simples que nous savons corriger depuis des années : Injection SQL, scripts intersites, faiblesses dans la gestion des sessions... C'est un peu le jour de la marmotte pour ces types. Ils ont passé leur temps à trouver et à corriger des violations de code que les développeurs eux-mêmes avaient le pouvoir de corriger depuis des années, sauf que la sécurité n'est pas devenue une priorité dans leur processus " surtout maintenant, à l'ère du développement agile où la livraison de fonctionnalités est reine, et où la sécurité est le Grinch qui vole le processus créatif et le triomphe de l'achèvement du projet ".

Il ne s'agit pas d'une critique de l'une ou l'autre équipe ( assessment ) ; les développeurs et les professionnels de l'AppSec ont tous deux des tâches extrêmement importantes à accomplir, mais ils continuent à se mettre des bâtons dans les roues. Cette situation ne fait que perpétuer un SDLC défectueux, où les développeurs peu sensibilisés à la sécurité opèrent dans une culture de sécurité négative, produisant un code non sécurisé, qui doit ensuite être analysé, évalué et corrigé bien après qu'il a été initialement écrit. L'AppSec a à peine le temps de résoudre les problèmes vraiment complexes, parce qu'il est tellement pris par les petits problèmes récurrents qui pourraient toujours entraîner un désastre pour une entreprise s'ils n'étaient pas contrôlés.

Nous perdons du temps, de l'argent et des ressources en permettant aux tests d'être le fourre-tout des faiblesses de sécurité dans le code. Et avec les violations massives de données qui ont lieu tous les deux jours, il est évident que cette méthode ne fonctionne pas de manière optimale, voire pas du tout. Ces nouvelles normes évaluent toujours l'état d'un produit final (peut-être en supposant que tous les développeurs sont sensibilisés à la sécurité, ce qui n'est pas le cas), c'est-à-dire un produit déjà construit. C'est l'étape la plus coûteuse et la plus difficile pour corriger les défauts ; c'est comme si vous construisiez une belle maison neuve et que vous fassiez venir une équipe de sécurité pour vérifier qu'il n'y a pas de danger le jour même où vous emménagez. Si quelque chose ne va pas au niveau des fondations, imaginez le temps, le coût et le casse-tête que cela représente de se rendre sur place pour commencer à résoudre les problèmes. Il est souvent plus facile et moins coûteux de simplement recommencer (et quel processus insatisfaisant pour tous ceux qui ont construit la première version).

Nous devons absolument travailler à partir de la base : en faisant en sorte que l'équipe de développement s'engage dans les meilleures pratiques de sécurité, en leur donnant les connaissances nécessaires pour coder efficacement en toute sécurité, en plus de créer et de maintenir une culture positive de la sécurité sur chaque lieu de travail.

Est-ce une courbe d'apprentissage ? Oui, c'est vrai. Est-ce impossible ? Certainement pas. Et ce n'est pas forcément une corvée ennuyeuse. Les méthodes de formation qui font directement appel à la créativité des développeurs et à leur capacité à résoudre des problèmes ont déjà connu un immense succès dans le secteur bancaire et financier, si l'on en croit l'expérience de Russ Wolfes chez Capital One.

Nous sommes toujours à la recherche de l'état final parfait.

Si vous considérez les normes de sécurité PCI mises à jour dans le contexte pour lequel elles ont été conçues, c'est-à-dire que votre produit financier fini et prêt à l'emploi doit respecter ces meilleures pratiques pour une sécurité et une sûreté optimales, alors elles sont tout à fait correctes. Cependant, à mon avis, chaque entreprise - financière ou autre - aurait les meilleures chances d'atteindre un état final du logiciel qui soit représentatif à la fois de la qualité des fonctionnalités et d'un niveau élevé de sécurité, si seulement elle prenait du recul et réalisait qu'il est beaucoup plus efficace de le faire dès le début du cycle.

L'état final parfait ? Vous savez, celui qui se produit lorsqu'un produit est scanné, contrôlé manuellement et qu'il en ressort parfait et sans erreur ? Nous sommes toujours à sa recherche. Pour l'instant, il s'agit d'une licorne.

Pourquoi est-elle si insaisissable ? Il existe un certain nombre de facteurs :

• On se fie aux outils d'analyse, mais ils ne sont pas toujours efficaces. Les faux positifs sont un sous-produit frustrant et chronophage de leur utilisation, tout comme le fait que même ensemble, les analyses DAST/SAST/PCI ne peuvent tout simplement pas identifier et révéler toutes les vulnérabilités possibles dans la base de code. Certes, ils peuvent vous donner le feu vert, mais cherchent-ils vraiment tout ? Un attaquant n'a besoin que d'une seule vulnérabilité à exploiter pour accéder à quelque chose que vous pensez être protégé.
• Les développeurs continuent de commettre les mêmes erreurs. Il n'y a pas de répartition des connaissances entre les développeurs en matière de sécurité et il n'y a pas de "recettes de code sécurisé" (de bons modèles de code sécurisé) qui soient connues et documentées.
• L'accent n'est pas mis sur la mise en place d'une culture de sécurité positive et collaborative.
• Les développeurs doivent disposer des bons outils pour intégrer la sécurité dans les produits qu'ils écrivent, sans perturber leurs processus créatifs et leurs méthodologies de développement agiles.

Ces lignes directrices constituent une puissante liste de vérification des normes de sécurité auxquelles les logiciels doivent se conformer, mais le meilleur processus pour amener les logiciels à cet état est sujet à débat.

Ce n'est pas parce que nous manquons de scanners que nos logiciels ne sont pas sûrs, mais parce que les développeurs ne disposent pas d'outils de sécurité faciles à utiliser et à comprendre pour les guider.

Nous vivons actuellement une période d'évolution. Pendant de nombreuses années, la sécurité des logiciels en général était facultative. Aujourd'hui, elle est essentiellement obligatoire - en particulier pour les détenteurs d'informations sensibles (financières, médicales, sécurité sociale... vous voyez l'idée).

Le Conseil des normes de sécurité PCI contribue à établir la référence, mais j'aimerais qu'il s'efforce - avec toute l'estime et l'influence qu'il a dans l'industrie - d'inclure des lignes directrices pratiques pour les développeurs, en mettant l'accent sur une formation et des outils adéquats et positifs. À l'heure actuelle, aucune pression n'est exercée sur les organisations pour qu'elles veillent à ce que leurs équipes de développement soient sensibilisées à la sécurité et respectent les normes, et de nombreux développeurs ne comprennent pas l'ampleur de ces petites erreurs faciles à corriger lorsqu'elles sont exploitées par ceux qui cherchent à faire du tort à autrui.

Comme c'est le cas pour tout ce qui vaut la peine d'être vécu, il faut vraiment un village pour mettre en œuvre un véritable changement. Et le changement dans l'air va (espérons-le) nous entraîner plus loin vers la gauche.

Il semble presque comique qu'en 2019, nous parlions de travailler avec un langage informatique qui a été inventé en 1959. Il n'y a plus beaucoup de séminaires ou de conventions consacrés à l'art de réenfiler les machines à coudre Singer classiques, ou de remplacer le carter d'huile d'une Chevrolet Parkwood ou d'une Triumph Herald. La plupart de ces outils vieillissants ont depuis longtemps été mis au rancart et remplacés par de nouveaux modèles plus efficaces. Pourtant, ici, au pays de la technologie, qui est censé être à la pointe par rapport à d'autres industries, nous travaillons encore avec des langages comme le COBOL, qui a été publié à peu près à la même époque.

Il y a bien sûr de très bonnes raisons à cela. Le langage COBOL (Common Business Oriented Language) a peut-être 60 ans, mais il a été si bien conçu qu'il est encore pertinent et largement utilisé aujourd'hui.

COBOL a été créé comme un moyen relativement simple, utilisant un langage simple groupé en phrases et syntaxe spécifiques, pour programmer des systèmes dorsaux afin d'effectuer des tâches mathématiques et de formuler des formules. Pourquoi ce langage perdure-t-il aujourd'hui ? Tout simplement parce qu'il fait très bien son travail. D'une certaine manière, il est devenu un élément de la structure informatique de nombreux systèmes centraux dans des secteurs aussi divers que le secteur financier et l'industrie manufacturière.

Le COBOL a fait l'objet de mises à jour progressives au fil des ans, notamment en 2002 lorsqu'il a été transformé en langage orienté objet afin de rendre la programmation de nouvelles applications un peu plus fluide. Mais pour l'essentiel, le COBOL reste aujourd'hui ce qu'il était à l'époque : un héros méconnu et un langage de programmation qui fonctionne en arrière-plan pour étayer de nombreuses applications modernes au niveau de l'ordinateur central.

Quel est le degré de sécurité du COBOL ?

Malheureusement, il n'y avait pas beaucoup de considérations en matière de sécurité lorsque le COBOL a été créé. Par exemple, de nombreuses applications COBOL sont protégées par un programme de mot de passe, mais elles ne sont presque jamais protégées contre des éléments tels que la protection par force brute pour empêcher le craquage. Ajoutez à cela le fait que de nombreux outils de sécurité modernes qui surveillent le trafic réseau ne savent pas comment traiter ou évaluer les fonctions qui se produisent dans les programmes écrits dans des langages commerciaux comme le COBOL, et vous avez un vrai problème qui ne demande qu'à se produire. Un grand nombre de brèches modernes ont été réussies en raison d'un manque de surveillance de la sécurité des systèmes fonctionnant avec des langages informatiques classiques. En 2015, les données de plus de quatre millions d'employés fédéraux américains ont été exposées lorsque l'Office of Personnel Management (OPM) a été piraté, la faute à l'utilisation de COBOL, citant l'incapacité de mettre en œuvre des mesures de sécurité modernes sur un système aussi archaïque.

Il y a quelques années, la sécurité était assurée par une armée de programmeurs qui connaissaient le COBOL et d'autres langages en vogue à l'époque. Dans les années 1960, le COBOL était comme le Java ou le .Net d'aujourd'hui, et ceux qui le connaissaient étaient les vedettes de leur département. En 2019, ces personnes sont probablement à la retraite depuis longtemps, même si les systèmes qu'elles protégeaient ne le sont pas.

Extension des premières lignes de défense de COBOL

Un grand nombre de ces "barbes grises" ont été réintégrées dans leur organisation en tant que sous-traitants pour défendre les mêmes ordinateurs centraux que ceux sur lesquels ils travaillaient auparavant. Dans plus d'un endroit, ils constituaient une sorte d'anomalie : une cabale secrète de sorciers vieillissants dans un coin reculé du bureau, leurs vêtements étranges (cravates larges et costumes trois pièces) et leurs manières étrangement polies ne cadrant pas tout à fait avec tous les hipsters modernes arborant des jeans moulants et des chignons d'homme. Pourtant, ils étaient absolument nécessaires, car peu de programmeurs modernes utilisent le COBOL et d'autres langages anciens. Malheureusement, même ces dernières sentinelles de l'informatique sont en train de disparaître, de rendre l'âme, de déménager à Boca Raton et de profiter d'une véritable retraite.

C'est pourquoi il existe un besoin urgent de personnes qui comprennent les anciens langages et les failles de sécurité qu'ils contiennent. Même si les jeunes ne savent pas comment écrire du code dans les langages classiques, ils devraient au moins comprendre comment ils fonctionnent et quelles sont leurs vulnérabilités potentielles. En effet, si le développement du COBOL est resté relativement statique, les menaces qui pèsent sur les réseaux n'ont cessé d'évoluer. Essayer d'utiliser d'anciennes techniques de cybersécurité programmées il y a soixante ans, comme l'application de mot de passe COBOL susmentionnée, pour défendre un ordinateur central contre des attaquants modernes revient à déployer une phalange de lanciers pour combattre un peloton de marines de l'espace - à moins d'un miracle hollywoodien, cela se terminera mal pour les gars avec les lances.

Qu'il soit ancien ou nouveau, il doit également être sécurisé.

C'est pourquoi nous croyons en l'importance d'un système de formation avancée qui couvre une large gamme de langages de programmation et de cadres. Vous voyez, l'un des problèmes flagrants avec beaucoup d'options de formation en sécurité est que l'information est tout simplement trop générique, ou pire - complètement hors de propos dans le travail quotidien du développeur qui y participe. Passer une demi-journée à apprendre les vulnérabilités qui ne s'appliquent qu'à Java ne va pas aider un développeur COBOL à renforcer son système, et cela ne fait que perpétuer l'idée que la "sécurité" est un exercice à cocher et à oublier une fois que le cours obligatoire a été suivi. J'ajouterais que former quelqu'un aux bogues de sécurité Java n'est pas toujours applicable à un développeur Java Spring. Le codage sécurisé est tout simplement différent dans chaque langage, même au niveau du framework.

Dans le cadre de notre mission visant à permettre à tous les développeurs de devenir des super-héros de la sécurité, nous ne négligerons pas un langage informatique valide qui est toujours utilisé dans certaines des installations les plus ciblées et les plus critiques au monde. En explorant notre plateforme, vous trouverez des défis et des formations modernes et pratiques relatifs au COBOL, ainsi que certains des outils de programmation les plus modernes disponibles aujourd'hui, tels que Googles Golang. Cette flexibilité garantit que la formation est pertinente pour un individu et contextuelle, imitant son environnement de travail pour un engagement et une efficacité maximum. Après tout, l'instauration d'une solide culture de la sécurité est primordiale dans la lutte contre les cybermenaces, c'est pourquoi la formation doit être pratique (et amusante, bien sûr !).

Nous voulons que notre secteur atteigne le stade où il importe peu que les menaces de sécurité pèsent sur des systèmes utilisant des langages anciens ou sur les applications de mobilité les plus modernes. Nous voulons que chaque développeur soit armé des meilleures informations sur ces vulnérabilités, sur les outils et les techniques utilisés par les attaquants pour les exploiter et sur la manière de les arrêter à froid. Nous ne nous rendrons jamais et nous ne faiblirons jamais face aux menaces de cybersécurité. Quelle que soit la modernité ou l'ancienneté des menaces ou des vulnérabilités, vous pouvez toujours vous adresser à Secure Code Warrior pour apprendre à les déjouer, à chaque fois.

PS : Vous pensez qu'une langue ancienne échappe à la vulnérabilité aux injections SQL ? Détrompez-vous. Voyez si vous pouvez localiser et corriger une injection en COBOL dès maintenant.

Publié à l'origine dans L'âge de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement de Wind River Systems en ce qui concerne le soutien continu à la sécurité de son système d'exploitation en temps réel, VxWorks.

Un récent rapport du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus d'ingénierie logicielle de Huawei. Alors que la plupart des nouvelles concernant ce rapport critique se concentrent sur les problèmes non résolus de l'année précédente, le problème le plus dangereux et le plus négligé est l'absence évidente de directives et de pratiques de codage sécurisées employées par Huawei. Mais c'est un problème qui peut être résolu.

Les nouvelles concernant le géant chinois des télécommunications Huawei ne cessent d'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de travailler à l'avenir pour le gouvernement, le Royaume-Uni a mieux accepté le fait que de nombreuses failles sous-jacentes dans les appareils et le code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Huawei Cyber Security Evaluation Centre (HCSEC) en 2010 afin d'évaluer et de traiter les problèmes de sécurité des produits Huawei, et de produire un rapport annuel à ce sujet. Cette année, le rapport est particulièrement accablant.

Une grande partie de l'attention portée au rapport 2019 du HCSEC dans les médias a été liée au fait que presque aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River qui sera bientôt en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera d'un soutien continu de Wind River Systems), mais ce système reste un composant essentiel d'une grande partie de l'infrastructure de télécommunications du Royaume-Uni.

Un facteur critique qui semble avoir été négligé par la plupart des médias grand public concerne ce qui pourrait être un processus fondamentalement défaillant, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de "problèmes techniques importants" dans la manière dont Huawei gère ses méthodes d'ingénierie internes.

Examinons quelques exemples de ces problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisé pour aider ses ingénieurs et ses programmeurs à déployer du nouveau code. Ces lignes directrices couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues des fonctions et processus du système à partir de bibliothèques de confiance, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production de Huawei au Royaume-Uni a révélé que ces lignes directrices n'avaient jamais été communiquées aux programmeurs, qu'ils les avaient ignorées ou qu'elles n'avaient tout simplement pas été appliquées.

Le rapport s'est penché sur des fonctions spécifiques de traitement de la mémoire au sein d'applications publiques, en l'occurrence un ensemble de tableaux d'affichage où les utilisateurs étaient invités, en tant que fonction du programme, à ajouter des données. Étant donné que les zones d'entrée des utilisateurs ne doivent jamais être considérées comme "fiables", on s'attendait à ce que ces zones ne contiennent que du code sécurisé, conformément aux lignes directrices internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de manipulation de la mémoire memcpy(), strcpy() et sprintf() dans ces systèmes de production, connues pour entraîner potentiellement de graves problèmes de sécurité tels que des débordements de mémoire tampon depuis 1988.

Il est choquant de constater qu'il y a eu 5 000 invocations directes de 17 fonctions memcpy() connues et sûres, mais aussi 600 utilisations de 12 variantes non sûres. Le rapport est à peu près le même pour les autres fonctions. Il y a eu 1 400 invocations sûres de strcpy(), mais aussi 400 mauvaises avec des vulnérabilités connues. Enfin, 2 000 utilisations sûres de sprintf() ont été trouvées, contre 200 utilisations dangereuses. S'il est positif que la plupart des utilisations de ces fonctions soient sûres, il n'en reste pas moins qu'environ 20 % de l'ensemble du code est vulnérable à des attaques connues. Il s'agit là d'une surface d'attaque considérable, qui ne prend en outre en compte que les invocations directes des trois fonctions de gestion de la mémoire, et non leur utilisation indirecte par l'intermédiaire de pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à poser problème.

S'il est bon que Huawei ait créé un guide des meilleures pratiques à l'intention de ses programmeurs, il est clair qu'il faut aller plus loin. C'est une étape de définir les attentes en matière de sécurité, mais elles ne sont efficaces que si ces lignes directrices sont activement suivies et connues de la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de survoler les bases sur la manière de suivre ses directives internes. Ils doivent faire un pas de plus pour montrer comment coder de manière plus sûre en général. Les programmeurs doivent être suffisamment formés sur les bons (sécurisés) et les mauvais (non sécurisés) modèles de codage et se voir confier la responsabilité de mettre en pratique ce que leur entreprise prêche, à chaque fois.

Bon nombre des problèmes de codage spécifiques décrits dans le rapport du HCSEC sont abordés et appliqués dans le cadre de la plateforme de sécurité. Secure Code Warrior qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais faire confiance à l'entrée de l'utilisateur, toujours tirer des fonctions de bibliothèques établies, assainir toutes les entrées avant de les transmettre à un serveur et beaucoup d'autres pratiques de codage sûres sont constamment démontrés dans la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.

En plus d'une formation compétente, les entreprises comme Huawei pourraient utiliser des solutions DevSecOps. Ces solutions ajoutent un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées qui sont adaptées aux directives de sécurité de l'entreprise, agissant comme le sous-chef du développeur dans la "cuisine" de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un "livre de recettes" qui adhère à leurs politiques et aide à l'exécution des commandes.

L'une des principales leçons à tirer des problèmes de Huawei devrait être que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas, ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans le cas présent, les lignes directrices internes relatives aux meilleures pratiques se sont révélées être le zhilaohu de Huawei, ce que l'Occident appelleraitun "tigre de papier". Il s'agissait d'un document avec beaucoup de style, mais sans substance. Pour lui donner du mordant, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe en permanence les connaissances et les compétences.

Tout au long de ma carrière en tant que professionnel de l'AppSec, j'ai eu la chance de rencontrer et de travailler avec certains des talents les plus incroyables de l'industrie, chacun d'entre eux contribuant à sécuriser et à renforcer les réseaux de code de plus en plus nombreux dans le monde. À ce stade de mon parcours (avec un peu plus de connaissances et beaucoup moins de cheveux !), on me demande souvent de m'adresser aux futures stars de la sécurité des logiciels, et c'est un travail que j'adore. Cependant, je comprends également à quel point il est important d'être visible en tant que leader et mentor pour ceux qui cherchent à se tenir debout et à s'épanouir dans leur rôle.

Récemment, j'étais à Londres avec une partie de l'équipe d'AppSec. Secure Code Warrior et nous avons organisé un brunch dans le but de réunir une poignée de superstars de l'AppSec pour un réseautage, des idées et une ou deux pâtisseries. Devant plus de soixante invités, ils ont transmis leur riche expertise dans le cadre d'un panel d'experts, suscitant l'enthousiasme de tous quant à l'avenir de la sécurité des applications.

Abordant des questions brûlantes telles que la manière de tirer le meilleur parti du budget AppSec d'une organisation, ainsi que plusieurs questions curieuses de l'auditoire, le panel a livré une véritable magie matinale qui aidera sans aucun doute les responsables de la sécurité, les spécialistes et leurs développeurs à mettre en place des programmes viables au sein de leurs organisations.

Nous avons eu le privilège d'accueillir les leaders suivants pour le panel " Tools Vs. People : Votre budget AppSec est-il suffisant pour les deux ?

• Vincent Gilbert, RSSI, Société Générale
• C̩dric Levy-B̩ncheton, PDG, Cetome
• Reena Shah, responsable de la culture et de la sensibilisation en matière de sécurité et de protection de la vie privée, M&G Prudential
• Lee Thurlow, directeur mondial de l'AppSec, Pearson
• Lewis Bramfitt, directeur général, Bramfitt Lab.

Chaque intervenant a fait part de ses réflexions sur le paysage des outils AppSec (spoilers : avec de nombreuses organisations générant autant de logiciels, il peut s'agir d'un champ de mines pour sélectionner les outils qui exécutent toutes les fonctions dont vous avez besoin. Après tout, aucun outil unique ne peut tout couvrir).

Reena Shah a également soulevé un point intéressant. En quelques années seulement, nous avons constaté un changement positif dans la perception de l'AppSec au sein des grandes organisations, ce qui a permis à un élément essentiel de commencer à prendre forme - l'investissement dans le personnel pour maintenir les meilleures pratiques et la culture de la sécurité :

"Je pense que les choses évoluent. Lorsque j'ai commencé il y a quatre ans, il était très difficile d'obtenir un budget et une équipe pour la culture et la sensibilisation à la sécurité. Aujourd'hui, je constate que ce n'est plus un défi pour moi. Il m'est très facile de dire "voici le budget dont j'ai besoin, voici les personnes dont j'ai besoin pour réduire les risques". Je constate un changement radical, et je pense que c'est parce que le conseil d'administration - et la direction - comprennent à quel point il est important de fournir des fonds pour nous aider à réduire les incidents de sécurité". Et d'ajouter.

Vous pouvez regarder l'intégralité du panel dès maintenant :

Pour moi, il est incroyablement rafraîchissant de voir l'avenir de l'AppSec incorporer un accent sur la bonne formation et les connaissances pour les développeurs en première ligne, leur permettant de former une défense solide contre les vulnérabilités séculaires qui font toujours leur mauvaise tête.

Les outils fournissent un certain niveau de soutien, mais il est vraiment temps de regarder les choses en face. Nous devons simplement cesser de répéter les mêmes erreurs.

Fermer la boucle d'erreur AppSec

Dans le cadre du brunch Leaders in AppSec, j'ai également fait une présentation sur la manière dont nous pouvons résoudre le problème coûteux et permanent de l'apparition répétée des mêmes vulnérabilités de sécurité. Les outils peuvent les trouver, mais ils ne font pas grand-chose pour les prévenir. Les développeurs doivent recevoir une formation adéquate pour empêcher leur apparition.

Et nous, les développeurs, sommes une drôle de bande. Certaines formations sont beaucoup plus efficaces que d'autres lorsqu'il s'agit d'engagement et de fidélisation. Vous pouvez visionner l'intégralité de ma présentation ici :

L'accent mis sur la formation à la sécurité, la sensibilisation générale et une culture positive entre les développeurs et l'AppSec est comme de la kryptonite pour un attaquant. Ces petites portes dérobées se ferment, ces moyens faciles d'accéder à nos données se tarissent, et les super-héros de la sécurité travaillent ensemble pour faire de la sécurité un synonyme de qualité logicielle.

Lentement, mais sûrement, nous y arrivons.