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.

Comme beaucoup de personnes dans l'industrie de la sécurité, j'ai fait le voyage en mars avec plusieurs collègues pour assister à la conférence RSA à San Francisco. Bien qu'il s'agisse d'une période de l'année extrêmement chargée, c'est vraiment l'un de mes événements préférés. J'attends avec impatience le Mayhem at the Mint de Bugcrowd, qui est l'occasion de se détendre et de passer un bon moment avec ses pairs et ses amis après de longues journées de conférence.

Cette année a été un peu différente. Nous avions beaucoup de choses à célébrer personnellement. En tant que sponsors de l'événement, nous avions notre propre cocktail (Secure Code Sangria, bien sûr), mais ce qui m'a vraiment donné envie de faire la fête, c'est notre nouveau partenariat avec Bugcrowd. C'est officiel : nous unissons nos forces dans la lutte pour éduquer, responsabiliser et éclairer les développeurs sur le codage sécurisé.

J'ai apprécié l'enthousiasme exprimé par l'ensemble du secteur à l'égard de cette annonce, en particulier l'article et l'épisode de podcast d'ITSPmagazine. En s'adressant à Casey Ellis et Jason Haddix de Bugcrowd, le rédacteur en chef Sean Martin a vraiment saisi l'essence de la raison pour laquelle nous faisons ce que nous faisons : c'est parce qu'un changement significatif nécessite une foule. Bugcrowd l'a reconnu depuis longtemps, et travailler ensemble pour transformer les ingénieurs logiciels du monde entier en super-héros de la sécurité est un rêve devenu réalité.

Après plus de vingt ans passés à casser des choses, à trouver et à corriger des vulnérabilités qui ont fait des ravages dans le monde, il est devenu plus évident que jamais que la conversation autour de la sécurité doit changer. Les "hackers" ne sont pas toujours les méchants ; leurs compétences inhérentes sont inestimables dans le processus de fortification des logiciels, et nous devons faire un effort concerté pour commencer à gauche. Il ne doit pas s'agir d'un nouveau concept à essayer un jour, mais d'un élément central du cycle de vie du développement logiciel. Pour ce faire, Bugcrowd et nous-mêmes nous engageons à changer la perception qu'ont de nombreux développeurs de la sécurité, à savoir qu'elle est un obstacle gênant à la création de fonctionnalités et de caractéristiques.

Jusqu'à présent, la formation à la sécurité a été inadéquate. Beaucoup trop peu fréquente, souvent sans rapport avec les activités de codage quotidiennes ou tout simplement sans intérêt pour les cœurs et les esprits des développeurs. Secure Code Warrior cherche à changer cela - apprendre le codage sécurisé peut être amusant, et avec le soutien de Bugcrowd, ce message peut être diffusé largement dans la communauté qui nous tient tant à cœur et que nous cherchons à encourager.

En fin de compte, nous devons parvenir à ce que la sécurité des logiciels soit synonyme de qualité des logiciels ; les enjeux sont tout simplement trop importants aujourd'hui pour qu'il en soit autrement. Et grâce à ce partenariat, je pense que nous pouvons faire en sorte que les développeurs soient réellement enthousiasmés par le développement sécurisé. Un environnement florissant de sensibilisation à la sécurité et une culture positive sont essentiels, et je ne peux pas imaginer une autre entreprise plus parfaite pour nous permettre d'y parvenir.

Soyez attentifs : le débat sur la sécurité est sur le point de basculer radicalement vers la gauche.

... un tiers a accédé à votre dépôt en utilisant le nom d'utilisateur et le mot de passe corrects d'un des utilisateurs autorisés à accéder à votre dépôt. Nous pensons que ces informations d'identification ont pu être divulguées par un autre service, car d'autres services d'hébergement git subissent une attaque similaire.

En tant qu'utilisateur d'un service en ligne, il n'est jamais agréable de recevoir un tel courriel concernant une violation potentielle de vos données personnelles. Imaginez maintenant que ces données soient un dépôt de code représentant votre dur labeur, ou même les secrets commerciaux de votre logiciel. Au moins 392 utilisateurs de GitHub, Bitbucket et GitLab (jusqu'à présent) ont reçu cette semaine cette notification qui leur a brisé le cœur, et qui plus est, leur code a été téléchargé par les attaquants, effacé du référentiel et soumis à une rançon. Une fois que les fichiers des utilisateurs concernés ont disparu, il ne reste plus qu'un fichier texte contenant ce message :

Contrairement à la plupart des autres violations d'entreprises qui font la une des journaux (et même aux attaques précédentes contre GitHub), celle-ci n'a pas été causée par un bogue sur la plateforme de l'entreprise. Au contraire, les informations relatives aux comptes étaient stockées en clair de manière non sécurisée et ont probablement été divulguées par des services de gestion de référentiels tiers. Les développeurs stockaient activement des mots de passe importants de manière incorrecte et réutilisaient souvent les mêmes informations d'identification pour plusieurs comptes de grande valeur.

Il semblerait que les escrocs ne soient pas les meilleurs et les plus brillants du monde de la programmation, car (à l'heure où nous écrivons ces lignes) aucun utilisateur n'a payé la rançon pour récupérer son code, et quelques personnes intelligentes et soucieuses de la sécurité ont déjà trouvé des solutions de contournement pour permettre aux utilisateurs concernés de récupérer le code supprimé.

Néanmoins, cela met en lumière des problèmes que nous connaissons depuis longtemps dans le secteur de la sécurité : la plupart des développeurs ne sont tout simplement pas suffisamment sensibilisés à la sécurité, et des données précieuses peuvent être menacées à tout moment... même par ceux qui ne sont pas des génies du piratage informatique.

Pourquoi notre gestion des mots de passe est-elle encore si médiocre ?

L'être humain est bien sûr imparfait et nous avons tendance à vouloir nous faciliter la vie. Il est certainement beaucoup moins ennuyeux de réutiliser le même nom d'utilisateur et le même mot de passe, et se souvenir du nom de son premier chiot est bien plus facile que de taper "Z7b3#!q0HwXxv29 !" juste pour accéder à son courrier électronique. Cependant, avec les nombreuses cyberattaques à grande échelle qui ont lieu en permanence, les développeurs devraient vraiment être mieux informés.

L'avis de GitHub sur la question était simple, estimant que cette attaque par rançongiciel n'aurait pas eu lieu si l'authentification à deux facteurs était en place et si des gestionnaires de mots de passe sécurisés étaient utilisés. C'est tout à fait vrai, mais comme je ne cesse de le répéter, il est clair que l'éducation doit aller plus loin. Tous les développeurs doivent comprendre - à un niveau fondamental - pourquoi certaines actions peuvent rendre leurs comptes vulnérables à une attaque.

L'éducation : La pilule magique ?

Les codeurs avertis en matière de sécurité savent qu'une simple erreur de configuration peut avoir des conséquences désastreuses. Dans le cas de cette attaque sur GitHub, il semble que des fichiers mal configurés aient permis aux attaquants d'injecter avec succès des skimmers malveillants pour récupérer les clés de leurs châteaux.

L'exposition aux données sensibles est également une vulnérabilité critique à surmonter, toujours en troisième position dans le Top 10 de l'OWASP. Le stockage des mots de passe en clair est une preuve évidente que beaucoup ne comprennent pas les dangers d'une telle pratique et la facilité avec laquelle les systèmes peuvent être violés par des attaques de mot de passe par force brute.

La compréhension de la cryptographie (et en particulier du stockage cryptographique) est un élément essentiel de la gestion des mots de passe dans une base de code utilisant une sécurité à toute épreuve. Le salage et le hachage réussis de tous les mots de passe stockés, en forçant leur unicité, rendront beaucoup plus difficiles des situations telles que cet incident de rançon.

Il est important de comprendre que notre attitude collective à l'égard de la sécurité doit changer, en mettant davantage l'accent sur une formation adéquate des développeurs et en prenant au sérieux les risques liés aux cybermenaces. Nous devons faire de l'apprentissage de la sécurité une expérience positive et gratifiante, et je pense que cela sera fondamental pour une amélioration générale des normes pour chaque développeur qui évalue son travail.

Vous voulez essayer de vaincre les vulnérabilités dont vous avez pris connaissance ici ? Vous pouvez jouer à des défis connexes sur Secure Code Warrior dès maintenant :

• Mauvaises configurations de sécurité
• Stockage cryptographique non sécurisé
• Exposition aux données sensibles

Publié à l'origine dans Réglementation Asie.

Avec l'augmentation des cyberattaques, qui touchent tous les types d'organisations et tous les secteurs d'activité, la menace d'une violation de données coûteuse, embarrassante et préjudiciable aux résultats est bien réelle. Le problème ne se réduit pas, il se développe comme une tumeur.

On me demande souvent de donner des exemples d'organisations qui luttent contre ce problème, en naviguant dans le "Far West" des meilleures pratiques en matière de cybersécurité et d'AppSec avec une finesse et une maîtrise particulières. Une réponse me revient plus souvent que les autres : c'est le secteur de la finance qui s'en sort le mieux.

La réglementation : Un facteur déterminant dans le leadership du secteur financier en matière de cybersécurité

L'une des raisons pour lesquelles le secteur financier joue si bien dans l'espace AppSec est qu'il est (au moins en partie) motivé par les préoccupations des régulateurs mondiaux, régionaux et nationaux concernant les impacts universels (pour ne pas dire catastrophiques) qui pourraient résulter d'une attaque de cybersécurité réussie ou d'un vol de données.

Le Comité de Bâle sur le contrôle bancaire (BCBS) a publié en décembre un rapport détaillant l'éventail des pratiques observées en matière de cyber-résilience des banques, des autorités de réglementation et des autorités de contrôle dans de nombreuses juridictions. Parmi les principales conclusions de ce rapport figure le problème de la pénurie de compétences en matière de cybersécurité, un facteur auquel seules quelques rares juridictions ont tenté de remédier en mettant en place des certifications spécifiques en matière de cybersécurité.

"Certaines juridictions disposent de normes spécifiques aux technologies de l'information qui traitent des responsabilités du personnel informatique et des fonctions de sécurité de l'information, en accordant une attention particulière à la formation et aux compétences du personnel en matière de cybersécurité", indique le rapport. Mais la plupart des juridictions n'en sont qu'aux "premiers stades" de la mise en œuvre de pratiques prudentielles visant à contrôler les compétences et les ressources du personnel de cybersécurité des banques.

Dans l'ensemble, les dispositifs réglementaires exigent des entités réglementées qu'elles gèrent les risques, mais il est rare qu'elles disposent d'une voie claire pour réussir à atténuer ces risques. Ils ne fixent pas d'exigences spécifiques (ni d'ailleurs de critères de référence) concernant les compétences et les ressources du personnel chargé de la cybersécurité. La plupart des régulateurs évaluent le personnel de cybersécurité des institutions par des inspections sur place, où les questionnaires d'auto-évaluationassessment sont monnaie courante, et les processus de formation sont particulièrement examinés, mais ce n'est que dans quelques juridictions que les réglementations traitent spécifiquement des rôles et des responsabilités du personnel informatique. En d'autres termes, la marge d'erreur est grande et l'accent mis sur une formation adéquate et sur l'acquisition ultérieure de compétences ( assessment ) est plutôt faible.

Au Japon et en Corée du Sud, les pouvoirs publics ont établi des lignes directrices sur la gestion appropriée du personnel de cybersécurité. Dans la plupart des autres juridictions, cependant, les exigences réglementaires en matière de gestion des effectifs en cybersécurité se limitent aux attentes des autorités de surveillance, qui n'ont souvent pas accès au site assessment pour vérifier les compétences en cybersécurité et la formation du personnel dans les organismes réglementés.

Seuls Hong Kong, Singapour et le Royaume-Uni ont publié des cadres spécifiques pour certifier les aptitudes et les compétences de la main-d'œuvre informatique. Alors que les mots "conformité" et "certification" ont tendance à faire frissonner le développeur créatif moyen, chargé de résoudre les problèmes et de créer de superbes fonctionnalités logicielles (pour eux, la sécurité est souvent considérée comme le problème de quelqu'un d'autre, à savoir l'équipe de sécurité), les quantités massives de données sensibles détenues par de nombreuses entités réglementées sont tout simplement trop précieuses pour être laissées entre les mains de ceux dont les compétences sont "présumées" plutôt que vérifiées correctement.

Heureusement, de nombreuses institutions bancaires et financières reconnaissent ce fait sans nécessairement s'appuyer sur une voie réglementaire évidente. La réglementation donne certes un aperçu des attentes en matière de résultat final (c'est-à-dire des logiciels sécurisés), mais elle a permis d'identifier que pour y parvenir, il faut contourner la pénurie de compétences en cybersécurité en formant les développeurs, en entretenant leurs relations avec les professionnels de l'AppSec existants et en instaurant une culture positive de la sécurité qui engendre la responsabilité et l'appropriation.

Pourquoi le secteur financier a-t-il un "facteur X" en matière de cybersécurité ?

Les entreprises des secteurs de la banque, des services financiers et de l'assurance sont confrontées à plusieurs éléments qui constituent autant de piliers sur lesquels repose leur position de leader dans le domaine de la cybersécurité.

Naturellement, en tant que gardiennes des finances mondiales (sans parler des millions d'enregistrements de données hautement sensibles), elles sont généralement des organisations très axées sur la conformité et la réglementation " des lignes directrices, des réglementations et des exigences mises à jour sont attendues et planifiées de manière significative. Par conséquent, elles se sont adaptées comme des gouttes d'eau à l'évolution des besoins en matière d'atténuation des risques cybernétiques, se targuant de disposer de politiques de meilleures pratiques en matière de cybersécurité parmi les plus rigoureuses, ainsi que de processus de bout en bout visant à réduire leur exposition à des attaques potentielles.

Que font donc les institutions financières différemment des autres ? D'après mon expérience, elles ont jeté les bases d'une plus grande sensibilisation à la sécurité que les autres, en identifiant un besoin et en consacrant des ressources à des programmes de formation holistiques, non seulement pour les professionnels de l'AppSec et les testeurs de pénétration, mais aussi pour leurs équipes de développement (généralement très importantes et dispersées dans le monde entier).

La cybersécurité étant relativement nouvelle dans la plupart des organisations, il est rafraîchissant de constater que les institutions financières font preuve d'ouverture d'esprit et d'innovation dans leur quête pour fournir des logiciels sûrs et sécurisés. Nombre d'entre elles ont compris l'intérêt de renforcer les compétences de leur cohorte de développeurs grâce à une formation attrayante qui les fait sortir de la salle de classe pour les plonger dans une expérience d'apprentissage pratique et pertinente qui les aide non seulement à résoudre les problèmes, mais aussi à comprendre l'importance d'un codage sécurisé en général.

Après tout, le codage sécurisé est un ingrédient clé pour forger une relation solide et fonctionnelle entre les développeurs et l'équipe AppSec, ainsi que pour maintenir une solide culture de la sécurité au sein de l'entreprise. Un autre facteur clé de la réussite d'un programme de sécurité consiste à s'assurer que les principales parties prenantes adhèrent au projet et en perçoivent les avantages, même si elles ne sont pas elles-mêmes des professionnels de la sécurité.

Les institutions financières ont tendance à bien communiquer avec la direction générale, en veillant à ce que les décideurs de haut niveau comprennent que les processus de sécurité ne sont pas des mesures "à mettre en place et à oublier" ; ils doivent évoluer aussi rapidement que la technologie utilisée et s'adapter à des risques variables.

Cela peut coûter du temps et de l'argent aujourd'hui, mais les vulnérabilités étant trente fois plus coûteuses à corriger dans un code déjà écrit, un programme de sécurité bien conçu, qui comprend une formation de base, permet d'économiser de l'argent à long terme : il est bien moins coûteux de corriger les problèmes de sécurité au fur et à mesure qu'ils sont écrits par des développeurs sensibilisés à la sécurité.

Les normes de sécurité commencent à suivre le rythme des risques croissants

L'un des principaux moteurs de la cyberconformité pour le secteur financier est le Conseil des normes de sécurité PCI, qui s'engage à aider les organisations financières à mettre en œuvre des politiques de sécurité viables et à respecter les lignes directrices dans tous les domaines. Il a contribué à ce que ce secteur vertical atteigne les normes de sécurité les plus élevées dans le domaine des logiciels de paiement.

Cependant, il faut dire que bon nombre de nos clients du secteur financier ont dépassé les lignes directrices actuelles du Conseil des normes de sécurité PCI. Bien que ces lignes directrices recommandent la formation des développeurs (comme mentionné précédemment avec d'autres exemples d'informations réglementaires), elles ne spécifient pas un type particulier ou un certain niveau de référence à atteindre pour indiquer que la formation a été efficace.

Avec de nombreuses vulnérabilités comme l'injection SQL et le cross-site scripting (XSS) qui traînent depuis plus de vingt ans (et qui causent encore des problèmes en 2019), il est clair que toutes les formations ne sont pas égales ou efficaces. En adoptant une formation sécurisée pratique et gamifiée, les banques et autres entreprises de services financiers obtiennent de bien meilleurs résultats et une réelle réduction des vulnérabilités qui peuvent faire des ravages si elles sont exploitées.

Un bon exemple est la façon dont l'institution bancaire américaine Capital One a utilisé des techniques de formation gamifiées dans le cadre de son Tech College innovant et de son système de certification. Selon Russell Wolfe, son directeur de la formation en cybersécurité et en informatique dématérialisée, lors d'un récent webinaire, les programmes de formation volontaires et le site de codage tournaments ont très vite suscité une demande sans précédent et une motivation organique de la part des pairs pour obtenir une certification et contribuer à la montée en compétences d'autres personnes.

Que peuvent faire les régulateurs pour s'assurer que le personnel chargé de la cybersécurité est correctement formé ?

Les régulateurs du monde entier peuvent vraiment "faire mieux" en ce qui concerne leurs politiques et lignes directrices existantes en matière de cyber-réglementation, simplement en définissant des méthodologies et des normes de formation acceptées que les personnes chargées de la protection de nos données doivent respecter. À l'heure actuelle, il semble que la plupart des politiques réglementaires fassent référence à une exigence de formation, mais qu'il y ait peu de suivi pour s'assurer que les personnes qui suivent la formation prescrite assimilent le contenu et les techniques nécessaires pour contribuer réellement à la lutte contre les cybermenaces.

La récente décision de la MAS (Monetary Authority of Singapore) d'inclure l'adoption de programmes de formation à la sensibilisation à la sécurité et de meilleures pratiques de développement de logiciels sécurisés dans la dernière version de ses lignes directrices sur les risques technologiques est toutefois encourageante. Lorsque ces lignes directrices entreront en vigueur, elles obligeront les institutions financières à s'assurer que leurs développeurs de logiciels sont formés à l'application de normes de codage sécurisé, d'examen du code source et de tests AppSec lors du développement de logiciels, ce qui devrait contribuer grandement à réduire les bogues et les vulnérabilités.

Pour moi, former la cohorte de développement à l'aide de techniques pratiques et concrètes est de loin le moyen le plus engageant et le plus pertinent pour leur travail, tout en jetant les bases d'une solide culture de la sécurité que chaque organisation doit créer avant qu'il ne soit trop tard.

Publié à l'origine sur DevOps.com.

En matière de cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à l'affût de la prochaine faille (ainsi que des outils, techniques et tactiques de conception adéquats pour l'éliminer). Toutefois, cette focalisation sur l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, en nous empêchant de voir les dangers profonds qui existent tout autour et que les attaquants ne sont que trop heureux d'exploiter.

Je compare souvent la cybersécurité moderne à une armure en kevlar. Les propriétés apparemment éthérées du Kevlar peuvent bloquer les balles à grande vitesse et toutes sortes d'armes modernes et puissantes. Il peut même donner à son porteur un sentiment d'invincibilité. Cependant, un système d'armement relativement ancien (arc et flèches), fabriqué pour la première fois vers l'an 1000 avant J.-C., peut souvent pénétrer cette protection. Un couteau aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le Kevlar aussi facilement que s'il déchiquetait un sweat-shirt en coton. Enfin, le Kevlar n'est pas en mesure de protéger chaque millimètre du corps humain. Si un attaquant peut trouver une faille pour porter un coup préjudiciable, il le fera "un peu comme les petites zones exploitables dans les logiciels".

En matière de cybersécurité, de nombreuses organisations sont également vulnérables aux failles des systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne droit à une montre en or et à une pension de retraite. Mais si vous pensez que les failles de ces systèmes anciens sont inoffensives, alors vous avez probablement un ou deux écrans bleus de la mort dans votre avenir.

Une vulnérabilité pour un vétéran

L'une des bibliothèques JavaScript les plus anciennes et les plus utilisées est jQuery, une ressource open source qui permet de tout faire, de la gestion des événements à la traversée et à la manipulation de l'arbre DOM, en passant par la génération d'animations. C'est une véritable bête de somme, utilisée depuis de nombreuses années. Les gens supposent que parce que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et que toutes les vulnérabilités ont été éliminées.

Malheureusement, ce n'est pas le cas. Par défaut, la plupart des applications qui s'appuient sur jQuery utilisent les instructions de la bibliothèque interne pour l'authentification. Par exemple, avec les serveurs Apache, cela signifie qu'il faut vérifier les fichiers .htaccess. Peu de développeurs concevant des programmes utilisant Apache ont probablement pensé à vérifier que les mises à jour du serveur Apache incluaient le fichier .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui a été un pilier de la sécurité pendant des années ?

Aussi étrange que cela puisse paraître, c'est exactement ce qu'Apache a fait dans la version 2.3.9. Apparemment, le fait de devoir vérifier les fichiers de configuration .htaccess à chaque fois qu'un programme devait être exécuté ralentissait trop les choses. La suppression de ce fichier a amélioré les performances globales d'Apache, mais a également créé une vulnérabilité que la plupart des gens ignoraient. Si les développeurs ne prenaient pas la peine de vérifier si leurs applications pouvaient toujours accéder aux fichiers .htaccess, la plupart des demandes étaient simplement acceptées sans examen.

Récemment, des experts ont découvert cette faille et ont noté que son utilisation permettrait à des utilisateurs non autorisés de télécharger et d'exécuter des shells ou presque n'importe quel type de code sur des systèmes censés être sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité appelée CVE-2018-9206 en octobre. Mais, la facilité avec laquelle la faille a été découverte par un chercheur en sécurité implique que les pirates professionnels, dont le seul but est de rechercher des vulnérabilités comme celle-ci, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les corrections apportés dans la foulée, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle un logiciel malveillant voleur de bitcoins s 'est déchaîné sur une librairie NPM populaire, téléchargée par des millions de personnes chaque semaine.

Le majordome l'a fait

Comme jQuery, Jenkins est un logiciel libre, et l'un des plus populaires de son genre. Avec son nom de serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par des équipes de développement dans de nombreux secteurs d'activité. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, les failles récemment découvertes, ainsi qu'une opération de minage de crypto-monnaie d'une ampleur réellement massive, suggèrent que Jenkins faisait aussi beaucoup de travail pour les méchants.

L'une des vulnérabilités Jenkins les plus dangereuses s'appelle Java deserialization et est désignée sous le nom de CVE-2017-1000353. Il s'agit d'une attaque complexe, mais qui existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. La première démarre un canal bidirectionnel pour le téléchargement qui est initialement rejeté par le serveur. Cependant, la seconde demande ajoute un canal de téléchargement qui contient une charge utile avec les commandes souhaitées par l'attaquant et utilise le script payload.jar. Une fois la deuxième requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.

Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, il utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car le compte SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ne le font souvent pas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, et que les gens pensent donc que toutes les vulnérabilités ont été corrigées depuis longtemps.

Plus récemment, un pirate a utilisé ces vulnérabilités vieillissantes de Jenkins pour compromettre plusieurs serveurs. L'objectif était d'ajouter un programme de minage de crypto-monnaie sur chaque instance vulnérable de Jenkins qu'il pouvait trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de crypto-monnaie. Jusqu'à présent, ils ont trouvé environ 10 800 pièces de monnaie Monero, d'une valeur de près de 3,5 millions de dollars.

Ce qui est ancien est à nouveau nouveau nouveau

Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que beaucoup considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates d'insuffler une nouvelle vie à de vieilles astuces. Et malgré un nouveau cycle de succès utilisant des vulnérabilités anciennes, de nombreuses organisations n'ont pas de plan en place pour arrêter ce cercle vicieux.

Ce n'est pas parce qu'une chose est ancienne qu'elle est inoffensive. Et ce n'est pas parce que des bibliothèques et des ressources courantes existent depuis des années qu'elles sont totalement sûres (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est consacrée à l'utilisation de composants présentant des vulnérabilités connues). Ce n'est qu'en faisant preuve de diligence et en suivant une formation constante en matière de sécurité que nous pourrons nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais aussi de celles qui se sont déjà installées insidieusement dans nos propres jardins.

Publié à l'origine dans CSO Online

En tant que hacker éthique (semi-retraité), professionnel de la sécurité et féru d'informatique, on peut dire que je m'intéresse beaucoup à la technologie. Je m'intéresse à la façon dont elle a été conçue, à ce qu'elle fait et à la manière dont elle va améliorer certains aspects de notre vie ou la rendre plus efficace. Je regarde constamment "sous le capot" des appareils, découvrant certains des meilleurs (et des pires) exemples de code qui existent. Récemment, j'ai examiné comment mon système de climatisation pouvait être contrôlé à distance à l'aide d'une application Android (imaginez ma surprise lorsque j'ai découvert que n'importe qui sur le réseau WiFi pouvait contrôler cet appareil sans aucune authentification).

La sécurité des logiciels est toujours au centre de mes préoccupations, tout comme le danger très réel que représente notre mode de vie de plus en plus numérique et axé sur le partage d'informations personnelles. Après tout, nous nous trouvons dans un territoire largement non réglementé, non supervisé et ignoré. Nous sommes dans le Far West.

En tant que société collective, nous ne regardons pas sous le capot de la technologie que nous utilisons tous les jours. En fait, la plupart d'entre nous n'ont aucune idée du degré de sécurité des logiciels utilisés dans la myriade d'applications, de services et d'objets de plus en plus connectés que nous achetons et utilisons. Ce n'est même pas que nous leur fassions intrinsèquement confiance, nous n'y pensons tout simplement pas du tout.

Sony PlayStation Network (PSN), Ticketmaster, Yahoo !, Facebook, Target : chacune de ces entreprises largement répandues a été victime d'une violation de données. Les vulnérabilités de leurs logiciels ont été exploitées et des millions et des millions d'enregistrements de clients ont été exposés. Ces exemples ne représentent qu'une fraction des violations mondiales qui ont eu lieu au cours des dix dernières années. Elles sont la conséquence coûteuse d'une mauvaise sécurité logicielle qui permet aux malfaiteurs de voler nos précieuses informations.

Lorsque la plupart des gens pensent aux violations de données, ils pensent aux violations de la sécurité de l'information. Elles sont certes un cauchemar pour l'entreprise victime de la violation et un inconvénient pour les personnes dont les données personnelles ont été affectées, mais sérieusement, quel est le problème ? Si la sécurité continue d'être ignorée, les conséquences sont-elles vraiment si graves ? Jusqu'à présent, rien de bien grave ne s'est produit : les violations de données ont de graves conséquences pour les entreprises qui en sont responsables, mais c'est leur problème, n'est-ce pas ? Elles perdent des marchés, elles perdent la confiance des consommateurs ; en fin de compte, c'est à elles qu'il incombe de régler le problème et de payer les dégâts.

La sécurité des logiciels devrait être une priorité pour toutes les organisations.

Il y a une raison assez simple pour laquelle la sécurité des logiciels n'est pas la préoccupation numéro un de toutes les organisations disposant d'une équipe de développement : il n'y a pas encore eu assez de victimes et les risques ne sont pas suffisamment connus.

Morbide ? Peut-être. Mais c'est la vérité. La réglementation, les normes de construction et l'attention portée à la modification des lois sont prises en compte (par exemple par les agences gouvernementales) lorsqu'il y a un coût humain réel.

Prenons l'exemple d'un pont. Les ingénieurs civils (un métier vieux de plusieurs centaines d'années) considèrent la sécurité comme un élément essentiel de la construction d'un pont. Leur approche va bien au-delà de l'esthétique et de la fonctionnalité de base. Chaque pont construit doit respecter des règles de sécurité strictes, la profession d'ingénieur civil et la société dans son ensemble ayant appris au fil du temps à exiger un niveau de sécurité élevé. Aujourd'hui, un pont qui ne répond pas aux exigences de sécurité est considéré comme dangereux et inutilisable. C'est une évolution à laquelle nous devons encore parvenir dans le domaine de l'ingénierie logicielle.

Prenons un exemple plus moderne, celui de l'industrie du jouet. Dans les années 1950, la production et les ventes de jouets ont connu un essor considérable grâce au baby-boom de l'après-guerre. Il est intéressant de noter que le nombre de visites aux urgences pour des incidents liés aux jouets a également augmenté au cours de cette période. Les flèches des jouets provoquaient des blessures aux yeux, les petits jouets (et les pièces détachables des jouets plus grands) étaient ingérés, et les fours à jouets commercialisés pour les petites filles étaient capables de chauffer à des températures plus élevées que les fours domestiques ordinaires.

C'était un peu le Far West, avec peu de réglementation, à l'exception de quelques interdictions isolées et de rappels de produits dans les circonstances les plus désastreuses. Les fabricants de jouets étaient essentiellement libres de produire les jouets qu'ils souhaitaient, les problèmes de sécurité étant généralement signalés après que plusieurs incidents aient été signalés. Ce n'est qu'après l'adoption de lois telles que la loi de 1969 sur la sécurité des jouets de Richard Nixon que les tests et l'interdiction subséquente des jouets dangereux sont devenus la norme, aux États-Unis et dans le monde entier. Bien que des accidents puissent toujours se produire, le processus général de fabrication des jouets adopte aujourd'hui une politique de "sécurité d'abord", et nos enfants courent beaucoup moins de dangers potentiels.

Dans le domaine de la sécurité des logiciels, nous sommes actuellement au Far West. Hormis les lois et réglementations évidentes relatives à la protection de la vie privée (en particulier récemment avec le GDPR) et à la protection des données des clients, ainsi que la législation sur le signalement obligatoire des violations dans certains pays, très peu de choses sont dites et faites dans le monde des affaires ou dans la communauté en général sur le niveau de sécurité intégré dans les logiciels. Même ces lois concernent davantage la responsabilité de l'entreprise que le logiciel lui-même qui est réglementé ou qui doit répondre à une norme de sécurité obligatoire.

Nous y parviendrons, mais il faudra peut-être d'abord emprunter la voie de la destruction.

Gartner estime que 8,4 milliards d'appareils connectés à l'internet seront utilisés d'ici 2020, ce qui représente une augmentation de 31 % par rapport à 2016. Ce chiffre inclut l'électronique grand public, ainsi que des appareils médicaux et des équipements spécifiques à l'industrie. Cela fait beaucoup d'opportunités pour un pirate informatique.

Imaginez que le logiciel du stimulateur cardiaque d'une personne ne soit pas sécurisé. Un pirate informatique pourrait s'y introduire et potentiellement arrêter le cœur de sa victime (vous trouvez cela ridicule ? Les médecins ont désactivé le WiFi du pacemaker de Dick Cheney pour éviter qu'il ne soit assassiné par piratage). Un four à micro-ondes ou une bouilloire connectés pourraient exploser à distance (ainsi que tous les appareils de l'internet des objets dont nous bénéficions dans nos maisons), ou les freins d'une voiture électrique connectée pourraient être désactivés. Cela peut sembler un film d'action hollywoodien tiré par les cheveux, mais si le logiciel de l'un de ces éléments avancés de la technologie connectée peut être violé, nous avons vraiment une catastrophe potentielle sur les bras - tout comme les menaces que nous avons déjà couvertes avec les ramifications explosives des cyberattaques dans l'industrie du pétrole et du gaz.

Nous pouvons anticiper les conséquences désastreuses des piratages malveillants à mesure que nos vies deviennent de plus en plus dépendantes du numérique. Tout commence par l'enthousiasme des développeurs pour le codage sécurisé et par la volonté de développer une culture et un état d'esprit solides en matière de sécurité au sein des équipes de développement.

Votre révolution logicielle commence ici. Le secteur bancaire est le premier à adopter la formation par le jeu dans la lutte contre le mauvais code, dans le cadre d'une approche véritablement innovante qui bouleverse la formation traditionnelle (ennuyeuse). En fait, chacune des six plus grandes banques d'Australie fait actuellement participer ses développeurs de cette manière, en stimulant leur esprit de sécurité. Découvrez ce que notre client, IAG Group, a fait avec son prochain niveau tournament.

Chaque année, à l'occasion de l'Australia Day, la plupart des Australiens passent leur temps à déguster des crevettes, des grillades, de l'agneau et à s'échouer au soleil. Chaque année, ce jour-là, je réfléchis aux douze derniers mois, tant sur le plan personnel que professionnel. Plus ma fille et l'entreprise grandissent, plus je me rends compte qu'il existe de nombreuses similitudes entre le parcours d'une startup et celui d'un "premier" parent. J'en suis à ma quatrième année dans les deux cas.

"Votre enfant grandit. Avez-vous remarqué que votre enfant de quatre ans devient plus indépendant et plus sûr de lui ? La plupart des enfants de cet âge commencent à développer leur indépendance, leur maîtrise de soi et leur créativité. Ils se contentent de jouer plus longtemps avec leurs jouets, sont désireux d'essayer de nouvelles choses et, lorsqu'ils se sentent frustrés, sont mieux à même d'exprimer leurs émotions".

De temps en temps, on me pose des questions... et honnêtement, je ne connais pas la réponse à beaucoup d'entre elles.

Je ne cesse de m'étonner que l'on me pose des questions qui paraissent si banales à un enfant, mais auxquelles l'adulte que je suis est incapable de répondre de manière sensée : "Papa, comment notre bouche et notre langue nous permettent-elles de parler ?", "Pourquoi fait-il jour en Australie et nuit en Belgique en ce moment ?". Vous réalisez soudain qu'ils sont beaucoup plus intelligents et curieux que vous ne le pensiez. Et puis il y a notre startup, qui pose des questions existentielles telles que "Pourquoi Secure Code Warrior existe-t-il ?", "Comment ce que je fais contribue-t-il au succès de l'entreprise ?", "Que voulons-nous devenir quand nous serons grands dans cinq ans ?". Outre les investisseurs et le personnel en place, un grand nombre de candidats à l'emploi m'ont vraiment forcé à avoir des réponses solides à ce type de questions.

"Notre vision est de permettre aux développeurs d'être la première ligne de défense de leur organisation en rendant la sécurité très visible et en leur fournissant les compétences et les outils nécessaires pour écrire du code sécurisé dès le début.

Au cours des douze derniers mois, nous avons poursuivi cette mission en triplant notre personnel, en faisant plus que doubler notre chiffre d'affaires, en recrutant des clients dans vingt-et-un pays différents et en ajoutant plus de dix cadres de programmation différents à notre plateforme Secure Code Warrior .  

Faire des erreurs fait partie de la croissance.

Nous nous efforçons tous de faire ce qu'il faut tout le temps, mais il arrive que des erreurs soient commises et je dois me sentir à l'aise pour les tolérer. Ma fille de quatre ans est une "enfant à l'esprit libre", ce qui, à mon avis, est un euphémisme pour dire "un petit malin têtu". Mais même elle se rend compte qu'elle n'a pas toujours raison et qu'il peut être utile d'écouter les autres. Je suis d'avis que le fait de se tromper montre que l'on prend des décisions, et c'est une bonne chose. Cela démontre clairement l'indépendance et la confiance en soi dont j'ai parlé précédemment. Au travail, je demande à ceux qui ne sont pas d'accord avec mes décisions de me soutenir et de me laisser faire des erreurs. Je pense qu'il vaut mieux regretter quelque chose que l'on a fait, que de regretter quelque chose que l'on n'a pas fait (citation volée sans vergogne à Orbital).

Repousser les limites et déformer les niveaux.

Depuis qu'elle sait marcher, je suis le père qui l'encourage à escalader un mur de 2 mètres dans la cour de récréation, à se retourner et à sauter sans hésiter. J'ai descendu le toboggan la tête la première, je l'ai emmenée faire de la plongée avec masque et tuba sur la Grande Barrière de Corail avant qu'elle ne sache vraiment nager. Ah oui... Les autres parents et sa mère m'ont jeté des regards méchants ;-). Je n'étais pas un grand casse-cou quand j'étais jeune ... mais une fois que j'ai commencé à faire confiance à mon propre instinct à vingt-cinq ans, j'ai su que repousser mes propres limites me permettrait d'aller plus vite. Je suis sûre qu'elle me remerciera quand elle sera plus âgée.

En tant que PDG d'une startup, je ressens la même chose... j'encourage mon équipe à prendre des risques, à repousser les limites, à briser les barrières et à changer de niveau. "J'ai été confronté à de nombreuses questions : "Nous ne pouvons pas atteindre ces objectifs !", "Nous avons besoin de règles et de politiques, etc. Je me suis entouré à la fois de personnes qui prennent des risques et de personnes qui les évitent (vous savez qui vous êtes), et je pense qu'il est de mon devoir de prendre en compte leurs opinions... puis de faire un pas en avant et de me fier à mon instinct.  

Je suis sûre que l'année à venir sera encore une fois une montagne russe. La première fois qu'on lit et qu'on compte, la première fois qu'on passe des journées entières à l'école... et probablement beaucoup d'autres questions auxquelles je ne peux pas répondre. Avec Secure Code Warrior, nous allons franchir la barre des 100 employés dans les prochains mois, nos premiers clients auront passé plus de trois ans sur notre plateforme, et nous allons signer notre premier client en Chine.

Je suis certain que de nombreux défis nous attendent, mais nous formons une équipe formidable et nous sommes prêts à les relever.

Imaginez que vous créez quelque chose à partir de rien, que vous utilisez vos compétences et votre expérience avec maestria pour marquer le monde de votre empreinte, petite mais spéciale. Que vous soyez seul ou que vous fassiez partie d'une équipe, vous mettez tout votre cœur et toute votre âme à construire quelque chose à partir de rien. Vous y consacrez des centaines, voire des milliers d'heures, en veillant à ce que votre bébé soit le meilleur possible. Une fois le projet achevé, cette vague d'accomplissement peut être ressentie comme une récompense à part entière.

Imaginez maintenant qu'un rabat-joie vienne vous dire que ce n'est pas si bien que ça. Peut-être va-t-il plus loin en vous disant que, non, malgré l'énergie, le temps et l'amour que vous avez sacrifiés, il n'est même pas utilisable : il est cassé. Ils vous ont dit, en substance, que votre bébé est laid.

Le scénario ci-dessus est forcément source de tensions ; après tout, qui veut que son travail acharné soit critiqué et condamné comme étant inadéquat ? Malheureusement, pour de nombreux développeurs, cela peut être la réalité de leur relation avec l'équipe AppSec. Un développeur a pour principale responsabilité de créer des logiciels fonctionnels, riches en fonctionnalités et livrés dans des délais stricts. La sécurité est rarement une priorité et peut même être considérée comme un obstacle à la livraison rapide et à l'innovation. L'AppSec a la tâche peu enviable de vérifier méticuleusement le code, de procéder à des tests d'intrusion et de signaler la mauvaise nouvelle : la présence de failles de sécurité dans un code qui est souvent déjà engagé. Il s'agit d'un processus coûteux dans un environnement souvent à court de ressources et de temps, dont la mise en place provoque inévitablement un clivage entre deux équipes qui ont le même objectif, mais qui parlent des langues si différentes qu'elles semblent être à couteaux tirés.

Ne pensez-vous pas qu'il est temps de donner un coup de jeune à la sécurité ? Il suffit de changer la conversation et de rendre les choses un peu plus positives (pour ne pas dire amusantes !) pour les deux parties, en particulier pour l'équipe de développement.

De la salle de classe à l'arène de jeu

Comme de nombreux développeurs terminent leur formation professionnelle sans avoir beaucoup appris sur le codage sécurisé, il arrive souvent que leur premier contact avec l'éducation à la sécurité se fasse au moment de leur entrée sur le marché du travail. La formation en classe est une solution souvent utilisée, mais elle fait perdre un temps précieux à la présentation des fonctionnalités (et, avouons-le, si le professeur et le contenu ne sont pas assez stimulants, il peut s'agir d'une perte de temps facilement oubliable pour tout le monde). Il y a aussi la vidéo courses, les examens sur papier et la formation générique à la politique de sécurité de l'entreprise... qui peuvent être si peu spécifiques qu'ils sont inutiles dans la vie professionnelle quotidienne du développeur moyen.

Trop souvent, elle est traitée comme un exercice de conformité " cochez la case et passez à autre chose ", et trop souvent elle a l'effet inverse : elle ne fait que creuser le fossé entre l'AppSec et l'équipe de développement. Après tout, il ne semble pas que la formation conventionnelle ait l'effet positif sur la culture de la sécurité et la conformité que nous recherchons si désespérément en tant qu'industrie. Nous continuons à faire les mêmes erreurs.

Selon la communauté Common Weakness Enumeration(CWE), il existe plus de 700 faiblesses de sécurité logicielle courantes contre lesquelles il faut lutter. Certaines, comme l'injection SQL, sont comme des cafards qui n'ont pas été écrasés bien qu'ils existent depuis plus de vingt ans. Nous savons comment y remédier ; la formation est là pour donner aux développeurs les moyens d'y mettre fin, ainsi qu'à tant d'autres, et pourtant les tests d'intrusion et les processus d'examen manuel du code identifient continuellement ces violations.

Peut-être avons-nous fait fausse route et devons-nous, en tant qu'industrie, aborder l'éducation viable sous un angle différent... un angle qui exploite les compétences étonnantes si appréciées de nos développeurs. Ce sont des personnes créatives, curieuses de résoudre des problèmes et qui aiment relever des défis. Gamifier la formation à la sécurité, c'est parler leur langage, leur permettre de s'exercer par la pratique - et qui sait, ils pourraient bien tomber amoureux de la sécurité en cours de route.

Un peu de concurrence saine

La dépendance à l'égard d'outils (plutôt imprécis), de tests d'intrusion coûteux et de rares spécialistes de la sécurité des applications va nous plonger encore plus profondément dans le trou noir de la sécurité. Une trop grande partie de nos vies et de notre vie privée se déroule en ligne pour que les entreprises continuent à jeter la prudence dans les forteresses virtuelles qui protègent nos données. Alors que la transformation numérique de notre monde accroît notre dépendance à l'égard des logiciels, nous devons nous tourner vers les super-héros que nous avons toujours eus au bureau : l'équipe de développement.

La formation gamifiée, dans les langages et les cadres appropriés, est un outil puissant pour les responsables AppSec afin de commencer à transformer la culture de la sécurité au sein de l'entreprise. À partir de la formation, les développeurs peuvent exercer leurs nouveaux muscles de sécurité dans un cadre amusant tournament , qui peut être aussi excitant que votre imagination peut l'évoquer : il suffit de regarder comment le "jeu des codes" d'IAG a fait parler tout le monde de la sécurité au sein de leur organisation.

Secure Code WarriorLe moduletournament ne se contente pas de couronner un engagement de formation mesuré : il s'agit d'une plateforme à partir de laquelle chaque développeur peut valider ses compétences, voir où il en est depuis le début de la formation et identifier les domaines qui pourraient nécessiter des améliorations. L'aspect compétitif agit réellement comme une motivation pour s'engager positivement dans la sécurité, en utilisant la récompense et la reconnaissance pour soutenir la croissance d'une culture de sécurité robuste au sein de l'équipe et de l'entreprise au sens large.

Injecter un peu de plaisir dans ce qui peut être perçu comme une tâche laborieuse, voire décourageante, peut contribuer grandement à changer les mentalités négatives et à inspirer une participation continue. Après tout, qui n'aime pas la gloire de marquer plus de points que ses pairs dans un environnement compétitif (sain) ?

Les champions marchent parmi vous

La formation par le jeu et le site tournaments qui s'ensuit contribuent énormément à l'instauration d'une culture positive de la sécurité, les équipes AppSec et de développement ayant une meilleure connaissance du travail quotidien des uns et des autres. Un développeur sûr est un atout, qui corrige les vulnérabilités courantes et laisse les problèmes complexes aux rares spécialistes AppSec sur le terrain. De meilleures relations se développent et prospèrent, et le précieux budget de la sécurité n'est pas englouti dans la réparation des mêmes erreurs, comme dans un "jour de la marmotte".

Il existe cependant un autre sous-produit puissant : la révélation des champions de la sécurité dont vous ne soupçonniez pas l'existence. Tournaments peut découvrir ceux qui non seulement ont des aptitudes pour la sécurité, mais qui affichent activement une passion pour celle-ci. Ces champions sont essentiels pour maintenir l'élan et servir de point de contact entre les équipes, superviser les pairs et faire respecter les politiques de meilleures pratiques. La mise en œuvre d'un solide programme de champions, qui inclut la reconnaissance et le soutien de la direction, est un atout pour l'organisation, ainsi qu'un élément important pour le CV et la carrière future de l'intéressé.

Conclusion ? Nous devons exiger de meilleurs résultats dans les tests de sécurité. Moins d'erreurs courantes, plus de soutien pour ceux qui sont en première ligne. Pourquoi ne pas voir comment un développeur tournament peut vous permettre d'y parvenir plus tôt que vous ne le pensez ?

L'année 2018 a été une année record pour les professionnels de la cybersécurité. Malgré les avertissements invitant à prendre la sécurité plus au sérieux, la presse constante entourant la formation d'un plus grand nombre de talents dans le secteur de la sécurité et les tentatives générales visant à sensibiliser davantage les organisations à la cybersécurité, nous restons les yeux fixés sur les cratères fumants laissés par des centaines de cyberattaques, représentant des violations de données à grande échelle et la méfiance des consommateurs à l'égard de certains noms de famille très connus. Rien qu'au premier semestre 2018, 4,5 milliards d'enregistrements de données ont été compromis dans 945 incidents distincts.

Je l'ai déjà dit à maintes reprises : nous pouvons faire mieux. Cependant, la véritable bataille à laquelle nous sommes confrontés n'est pas celle contre les script kiddies, les dangereux syndicats de la cybercriminalité organisée ou les mystérieux personnages vêtus de capuches qui tapent sur des ordinateurs portables - la bataille consiste à faire en sorte que davantage de personnes se soucient du fait que ces brèches se produisent.

La conformité au GDPR est un bon début, mais elle n'aura pas d'effet considérable à court terme.

Le règlement général sur la protection des données (RGPD) de l'Union européenne bat désormais son plein ; une menace plane sur les organisations qui ne prennent pas la protection des données au sérieux. Avec des amendes considérables pour ceux qui ne respectent pas les règles, ce règlement devait inciter les entreprises à renforcer leurs pratiques de sécurité, à traiter les données de leurs clients avec plus de respect et à élaborer une stratégie pour atténuer les effets des cyberattaques.

Certaines organisations ont été averties d'amendes colossales à venir, mais nous n'avons pas encore vu de véritables retombées suite à la non-conformité au GDPR. Pas de sanctions entraînant la faillite, mais un grand nombre de fenêtres contextuelles sur lesquelles cliquer pour les internautes. Cela s'explique en partie par le fait que les procédures juridiques prennent beaucoup de temps, avec de nombreuses possibilités d'appel - toutes les entreprises qui ont pu être prises en exemple sont probablement engagées dans une bataille juridique qui durera des mois, voire des années. Au terme d'une année cauchemardesque, Facebook a récemment fait état d'une nouvelle violation de données : un bogue d'API exposant les photos privées de 6,8 millions d'utilisateurs à 1500 applications non autorisées. Le problème a été découvert et corrigé en l'espace de deux semaines, mais les agences de protection des données et le public n'ont été informés de la violation que plusieurs mois plus tard. Les lois du GDPR exigent la notification d'une violation dans les 72 heures, ce qui soulève de nombreuses questions sur l'influence et l'efficacité de ces lois à l'heure actuelle.

Et bien sûr, les brèches n'ont pas cessé ailleurs : En novembre, Marriott a révélé que 500 millions de données avaient été compromises et, ce qui est peut-être encore plus inquiétant, que les attaquants avaient accédé à leurs systèmes pendant quatre ans avant d'être découverts. Il convient toutefois de noter que Marriott semble s 'efforcer de limiter les dégâts : l'entreprise a offert aux victimes un abonnement gratuit de 12 mois à WebWatcher, un outil de surveillance du crédit... mais avec 500 millions d'enregistrements que les pirates peuvent passer au crible, il reste à voir si un an suffira pour surveiller quoi que ce soit de significatif pour la plupart des gens ; après tout, il peut s'écouler quelques années avant que vos données ne soient mises en évidence pour un usage peu scrupuleux.

À long terme, les réglementations telles que le GDPR entraîneront des changements positifs si elles sont appliquées. Lorsque les entreprises seront frappées par une pénalité financière importante (ou, en effet, par des recours collectifs de clients dont les données ont été compromises) ou par une baisse des bénéfices sur une échelle suffisamment longue, je pense que la plupart des entreprises se concentreront frénétiquement sur la fortification des bases de données en ligne.

Les institutions financières continueront à montrer la voie du changement positif à court terme.

Il n'est sans doute pas surprenant que les institutions financières, en tant que gardiennes de l'argent durement gagné dans le monde, aient des politiques de meilleures pratiques en matière de cybersécurité parmi les plus rigoureuses, ainsi que des processus de bout en bout pour réduire leurs risques.

L'un des principaux moteurs de cette conformité est le Conseil des normes de sécurité PCI, qui s'est engagé à aider les organisations financières à mettre en œuvre une politique de sécurité viable et à respecter les lignes directrices dans tous les domaines. Il a contribué à ce que ce secteur vertical atteigne les normes de sécurité les plus élevées dans le domaine des logiciels de paiement.

Qu'est-ce qui différencie les institutions financières des autres ? D'après mon expérience, elles sont généralement plus sensibilisées à la sécurité, consacrant des ressources à des programmes de formation holistiques destinés non seulement aux professionnels de l'AppSec et aux pen-testers, mais aussi à leurs équipes de développement (généralement très importantes et dispersées dans le monde entier). Elles veillent à ce que les décideurs de haut niveau comprennent que les processus de sécurité ne sont pas des mesures "fixes et oubliables" ; ils doivent évoluer aussi rapidement que la technologie utilisée et s'adapter aux risques variables.

Davantage d'organisations vont transformer leur pipeline de sécurité.

Comparé à d'autres branches de l'informatique, l'AppSec est relativement jeune. Il n'est pas facile d'être le petit nouveau : vous êtes facilement incompris et vous n'avez peut-être pas encore noué les relations clés dont vous avez besoin. Cependant, je pense qu'avec chaque année qui passe, il est de plus en plus facile pour l'AppSec de trouver sa place, même dans les organisations les plus désuètes et les plus résistantes au changement.

Il est devenu plus évident que les entreprises ne peuvent pas faire de la conformité en matière de sécurité une étape finale, de dernière minute, dans leurs processus logiciels. Il doit y avoir des contrôles et des mesures d'un point à l'autre, avec une plus grande concentration sur l'agrégation des données et la fourniture d'une plus grande visibilité aux niveaux exécutifs de l'entreprise. Sans cela, la sécurité restera hors de vue et hors d'esprit pour la plupart des entreprises. Et dans ce scénario, il est pratiquement impossible de rassembler les ressources nécessaires pour planifier les risques.

La bonne nouvelle, c'est que les organisations sont plus nombreuses que jamais à repérer leurs propres cyberattaques et à s'efforcer d'y remédier. La mauvaise nouvelle ? Ce processus prend en moyenne quatre-vingt-cinq jours.

Les outils de test de pénétration et l'examen manuel du code sont ardus, coûteux et lents à une époque où l'innovation rapide et la production de fonctionnalités sont indispensables dans la sphère technologique. La sensibilisation à la sécurité doit se faire dès le début : dès qu'un développeur écrit le code.

Notre industrie reconnaîtra le problème principal : nous avons besoin que les gens se soucient davantage des autres.

Voici ce qu'il en est : je pourrais compter vingt personnes dans mon réseau qui ont séjourné dans un hôtel Marriott à un moment ou à un autre au cours des quatre dernières années. Étant donné que 500 millions d'enregistrements ont été volés au cours de cette période, il y a de fortes chances que leurs données fassent partie de ce vol. Tout, des coordonnées actuelles aux numéros de carte de crédit encore valides en passant par les informations de passeport, pourrait être mis en vente en ce moment même sur le dark web. Cependant, leur facteur de sécurité est pratiquement nul.

Et il est facile de se reposer sur ses lauriers lorsque, dans le cadre d'un vol de données à si grande échelle, vous n'êtes qu'une aiguille dans une botte de foin.

Mais le vrai problème ? Les entreprises qui n'ont pas assuré la sécurité des données de leurs propres clients ne subissent que très peu de répercussions. Le cours de leurs actions est-il touché immédiatement après l'incident ? Bien sûr. Target, Equifax et maintenant Marriott peuvent en témoigner. Toutefois, un aperçu sur douze mois montre que le retour à la normale est assez rapide. Quelques années plus tard, tout est pardonné sur le plan financier.

Tant qu'il n'y aura pas de graves répercussions : amendes considérables, réglementations plus strictes et pertes d'activité importantes, l'AppSec sera un secteur qui devra constamment se battre pour faire comprendre la gravité des cyber-risques croissants auxquels une entreprise est exposée.

Je crains que la situation n'empire avant de s'améliorer, c'est pourquoi il est de la plus haute importance que nous nous efforcions de mettre en place des développeurs sensibilisés à la sécurité et des cultures de sécurité solides en première ligne des équipes techniques d'une organisation. Gardez cela à l'esprit et continuez à vous efforcer d'atteindre des normes plus élevées en matière de sécurité des logiciels.