Ce n'est un secret pour personne : à l'adresse Secure Code Warrior , nous croyons fermement au pouvoir de la gamification pour inciter les développeurs à coder en toute sécurité. C'est ce que nous faisons, et les résultats ont été étonnants jusqu'à présent. Mais qu'en est-il de l'utilisation d'un véritable jeu vidéo pour évaluer les nouvelles recrues potentielles ? Est-ce que cela va trop loin, ou est-ce que cela pourrait être une pratique efficace ?

C'est ce que fait la startup Scoutible, et je dois dire que son approche m'intrigue. Scoutible évalue les candidats potentiels à l'aide d'un jeu vidéo - pas des évaluations gamifiées, mais une véritable expérience de jeu vidéo - et vérifie comment la personne se comporte dans certaines situations. Le jeu saisit "des millions de points de données utilisés pour mesurer les différents attributs d'un candidat" pendant seulement 20 minutes de jeu, et utilise ces points de données pour évaluer comment le candidat se comporterait pour le poste en question.

Il y a beaucoup de choses à aimer ici, et beaucoup de choses à apprendre aussi. Le produit est flexible pour répondre aux besoins des clients, et il cible un problème que de nombreuses personnes responsables de l'embauche connaissent depuis longtemps. Les tests autodéclarés assessment, comme Myers-Briggs, ne sont tout simplement pas fiables. Ils vous permettent de "jouer" le système, ou du moins d'essayer de le faire, en n'étant pas entièrement honnête. Dans un jeu, vous avez un objectif et vous devez vous adapter et résoudre des problèmes pour atteindre cet objectif. C'est assez simple et ingénieux si cela fonctionne comme le prétend Scoutible. J'ai hâte d'en savoir plus.

Jeux et gamification

L'approche de Scoutible est logique pour son public cible et son cas d'utilisation. À un moment donné du parcours de Secure Code Warrior, nous avons envisagé la valeur d'une plate-forme de jeu complète ou de mini-jeux intégrés à la formation, mais en fin de compte, cet angle n'a pas ajouté suffisamment de valeur à nos objectifs. Les utilisateurs finaux qui suivent notre formation à la sécurité savent qu'ils sont censés apprendre.

Au sein de notre plateforme Secure Code Warrior , nous mesurons les compétences en codage sécurisé d'un développeur de logiciels tout en utilisant des éléments basés sur le jeu pour maintenir l'intérêt des participants. Cela signifie qu'il faut garder ces questions à l'esprit :

• Comprennent-ils les faiblesses les plus courantes en matière de sécurité des logiciels ?
• Peuvent-ils corriger des bogues de sécurité courants à l'aide de fonctions de sécurité spécifiques au cadre ?
• Ont-ils confiance en leurs compétences en matière de sécurité des logiciels ?
• Quels sont leurs points forts et leurs lacunes en matière de code sécurisé ?

La prise en charge dès la conception

Il y a une autre raison pour laquelle je suis très attaché au produit de Scoutible. Il s'agit d'un avantage non seulement pour l'entreprise qui recrute, mais aussi pour le candidat. Tous les candidats que vous rencontrerez ne sont pas doués pour les entretiens. Pour certains, ce n'est tout simplement pas dans leur personnalité. Pour d'autres, il se peut qu'on ne leur ait jamais enseigné l'art de l'entretien ou qu'ils soient nouveaux sur le marché du travail et qu'il s'agisse de leur premier entretien.

C'est là que je vois une similitude avec les développeurs de logiciels. Malheureusement, de nombreux programmes universitaires ne mettent pas l'accent sur la sécurité. Les développeurs en herbe s'entendent dire : "Vous l'apprendrez sur le tas". Ils quittent l'école en sachant comment faire fonctionner leur code, mais ils perpétuent sans le savoir toutes les vulnérabilités contre lesquelles nous luttons depuis 20 ans ou plus.

Lorsque les développeurs obtiennent ce poste et demandent à se former à la sécurité, ils ont encore moins de temps que lorsqu'ils étaient à l'école. Ils sont payés pour produire des logiciels fonctionnels et efficaces, et la plupart des formations à la sécurité destinées aux développeurs ( courses ) sont ennuyeuses. Soyons honnêtes.

Et si vous pouviez amener vos développeurs, nouveaux et anciens, à se préoccuper de la sécurité sans vraiment y penser ? Comment rendre la formation intéressante, engageante, voire amusante, tout en restant efficace ?

C'est notre défi, et tout comme celui de Scoutible, c'est un défi très réel. Ce n'est pas parce que le problème est extrêmement grave que la solution doit être banale et ennuyeuse. Nous avons déjà essayé. Nous préférons injecter un peu d'amusement, d'excitation, de compétition et d'engagement dans notre solution. Jusqu'à présent, cela a très, très bien fonctionné.

J'ai pensé que si nous pouvions construire un outil qui ressemble à un jeu et qui intègre des tests pour les attributs cognitifs et de personnalité appropriés, nous pourrions résoudre un grand nombre des problèmes que j'ai étudiés.

https://www.inc.com/kevin-j-ryan/scoutible-video-game-reinventing-the-hiring-process.html

Lorsqu'elles sont développées pour la téléphonie mobile, les applications doivent souvent demander des autorisations au système. Elles peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou à la possibilité d'envoyer des messages SMS. Toutes les permissions mentionnées ci-dessus sont des permissions de plateforme, définies par le cadre Android.

Mais dans certains cas, ces autorisations ne suffisent pas et l'application doit définir ses propres autorisations personnalisées. Prenons l'exemple de notre propre entreprise. Secure Code Warrior pourrait créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Nous aimerions permettre à une autre application de formation à la sécurité, par exemple DevTrainer, d'utiliser ces données si l'utilisateur lui en donne l'autorisation. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les connaisse, mais l'application SCW ne devrait pas complètement les cacher et les protéger car elles pourraient être utiles. Nous souhaitons donc permettre à l'utilisateur d'exercer un contrôle sur ces données. C'est là qu'interviennent les autorisations personnalisées.

Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il veut l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.

Malheureusement, les permissions personnalisées présentent certains comportements non intuitifs qui les rendent risquées du point de vue de la sécurité. Concrètement, les autorisations personnalisées peuvent être définies par n'importe quelle application à n'importe quel moment, et "le premier qui gagne", ce qui n'est pas sans conséquences.

Pour le scénario suivant, nous définissons deux profils d'applications que nous avons introduits ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :

1. SCWApp: l'application qui définit une permission personnalisée et défend un composant utilisant cette permission.

2. DevTrainer: cette application définit la même permission que SCWApp et déclare à l'utilisateur qu'elle souhaite détenir cette permission.

Il s'agit d'un scénario courant, appelé "Peer Apps Case" (cas des applications homologues). Si l'application DevTrainer n'était qu'un plugin pour SCWApp, elle n'aurait pas à définir de permission personnalisée. L'hypothèse, dans ce cas, est que SCWApp sera installée avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWApp, la permission n'est pas accordée rétroactivement à DevTrainer, de sorte que les tentatives d'utilisation du composant sécurisé par l'application DevTrainer échoueront.

C'est là qu'intervient le cas de l'application Peers. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Par exemple, si Facebook et Twitter veulent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de l'un et de l'autre.

Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.

La situation est encore plus délicate. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur, mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer modifie le niveau de protection des permissions pour qu'il devienne normal, toutes les applications futures qui demanderont cette permission n'auront pas à être confirmées par l'utilisateur, mais se verront automatiquement accorder l'accès.

Ce scénario a été inspiré par l'explication de ce problème trouvée sur le github de cwac-security.

La stratégie du "premier qui gagne" a des conséquences dangereuses et la méconnaissance de son comportement peut conduire le développeur à prendre des décisions de sécurité basées sur des données non fiables et à permettre à des applications non souhaitées d'accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter les décisions de sécurité basées sur des données non fiables, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais comme actuellement, plus de 22% des appareils Android utilisent encore une version inférieure d'Android, il est important d'atténuer les risques du comportement original dans votre application. Vérifiez si la permission a déjà été définie lors de la première exécution de votre application et prenez les mesures appropriées si c'est le cas pour résoudre les risques de sécurité.

Bonne chance pour le codage et à la semaine prochaine !

En définissant des autorisations personnalisées, une application peut partager ses ressources et ses capacités avec d'autres applications.

https://developer.android.com/guide/topics/permissions/defining.html

On parle d'attaque par canal latéral lorsqu'un pirate informatique peut obtenir des informations à partir de la mise en œuvre physique d'un système logiciel plutôt qu'à partir d'une faiblesse théorique dans l'algorithme ou d'un bogue dans le code du logiciel.

Un exemple que j'aime utiliser pour rendre cela plus clair est une façon d'énumérer le nom d'utilisateur. Si vous voulez savoir ce qu'est l'énumération de noms d'utilisateur ou pourquoi c'est mauvais, visitez notre site web pour une explication vidéo ou jouez à un défi pour voir si vous pouvez l'identifier dans le code.

Pour comprendre comment l'énumération des noms d'utilisateur peut être effectuée par le biais d'une attaque par canal latéral, vous devez comprendre comment les mots de passe sont (ou du moins devraient être) traités dans les applications web modernes. Une bonne application web ne connaît pas votre mot de passe, elle ne l'enregistre ni ne le stocke nulle part. Alors comment sait-elle que ce que vous avez tapé est correct et qu'il s'agit bien de votre mot de passe ? Eh bien, votre mot de passe est haché.

Une fonction de hachage est une opération mathématique facile à réaliser dans un sens (bien qu'un peu coûteuse en termes de calcul), mais très difficile à inverser. Lorsque vous vous inscrivez sur un site web, c'est ce hachage qui est stocké en toute sécurité, et non votre mot de passe lui-même. Cela signifie qu'à chaque fois que vous vous connectez, l'application web procède au hachage de votre entrée et compare les résultats du hachage au hachage stocké. Si vous souhaitez en savoir plus sur le stockage sécurisé des mots de passe, vous pouvez le faire sur notre plateforme.

Le hachage des données prend un certain temps sur un ordinateur et les développeurs essaient toujours d'optimiser tout ce qu'ils écrivent pour que les utilisateurs aient une expérience fluide. L'un des moyens d'accélérer le programme est d'ignorer le hachage lorsqu'il n'est pas nécessaire. Par exemple, lorsque le nom d'utilisateur n'existe pas (et donc qu'aucun mot de passe ne doit être vérifié), ils peuvent répondre à l'utilisateur immédiatement. De cette façon, ils peuvent sauter le calcul lent du hachage du mot de passe. Si le nom d'utilisateur est correct, il hachera le mot de passe saisi et le comparera au hachage stocké.

À ce stade, vous avez peut-être deviné où les choses peuvent mal tourner. Même si, en réalité, le hachage ne prend que quelques millisecondes, un pirate peut utiliser ce délai supplémentaire pour savoir si le nom d'utilisateur qu'il a saisi est correct ou non, car un nom d'utilisateur erroné aura une réponse légèrement plus rapide puisque aucun hachage n'a été effectué. Ce type d'attaque par canal latéral est appelé attaque temporelle et constitue un bon exemple de la manière dont différentes exigences non fonctionnelles peuvent se contrecarrer mutuellement. Parfois, un code ne peut pas être à la fois rapide et sûr.

Ainsi, même si les mots de passe sont traités parfaitement et que le message affiché est générique et ne précise pas si le mot de passe ou le nom d'utilisateur est incorrect, le système reste vulnérable. La solution est simple : toujours hacher le mot de passe ou retarder l'envoi de la réponse du temps nécessaire au hachage.

Les informations obtenues peuvent être utilisées par un pirate pour obtenir une liste des utilisateurs du système. Ces informations peuvent être utilisées pour attaquer l'application web, par exemple, par une attaque par force brute ou par nom d'utilisateur/mot de passe par défaut.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

La suppression de fichiers sur un système informatique est une opération délicate. Tout le monde, même votre mère, a déjà supprimé un fichier de trop et a été heureux de le retrouver dans la corbeille et de pouvoir le récupérer.

Dans les systèmes informatiques, les données sont représentées par une séquence de bits. Cela signifie que le système doit tenir une comptabilité au sein du système de fichiers pour savoir quels bits représentent quel fichier. Parmi ces informations figurent la taille du fichier, la date de sa dernière modification, son propriétaire, les autorisations d'accès, etc. Ces données comptables sont stockées séparément du contenu du fichier.

En général, lorsqu'un fichier est supprimé, rien ne se passe au niveau des bits représentant le fichier, mais les données comptables sont modifiées de manière à ce que le système sache que cette partie de l'espace de stockage n'a plus de sens et peut être réutilisée. Jusqu'à ce qu'un autre fichier soit enregistré à cet emplacement et que les bits de cet emplacement soient écrasés, vous pouvez souvent encore récupérer les données qui ont été enregistrées. Cela permet non seulement d'accélérer la suppression des fichiers, mais c'est aussi souvent une fonction utile pour annuler la suppression.

Cette approche présente toutefois des inconvénients. Lorsqu'une application sur un système informatique traite des informations sensibles, elle enregistre ces données quelque part sur le système de fichiers. À un moment donné, lorsque les informations ne sont plus nécessaires, ces données peuvent être supprimées. Si aucune précaution supplémentaire n'est prise, ces données peuvent encore être récupérées, même si l'intention du développeur était que toutes les données soient supprimées.

La manière la plus simple d'effacer complètement ces données est de réécrire le contenu du fichier avec des données aléatoires (parfois même plusieurs fois). Il existe plusieurs méthodes de suppression sécurisée des fichiers, qui varient selon les types de stockage et les systèmes de fichiers, comme la méthode Gutmann. Toutefois, pour une utilisation quotidienne, ces méthodes sont un peu excessives et vous pouvez simplement réécrire les données vous-même.

Mais attention ! N'utilisez pas de zéros ou d'autres données à faible entropie. De nombreux systèmes de fichiers peuvent optimiser l'écriture de tels fichiers épars et laisser une partie du contenu original. Il est recommandé de générer des données aléatoires sûres pour écraser l'ensemble du contenu du fichier avant de supprimer le fichier lui-même.

La rémanence des données est la représentation physique résiduelle des données qui ont été effacées d'une manière ou d'une autre. Après l'effacement d'un support de stockage, certaines caractéristiques physiques peuvent permettre de reconstituer les données.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

Le BSIMM 8 est sorti ! Fantastique. La seule et unique étude à grande échelle sur les pratiques de sécurité mises en place par les grandes organisations pour produire des logiciels sûrs.

L'étude est réalisée par des professionnels de la sécurité des applications sous la supervision de Gary McGraw, qui s'assure que les données recueillies sont cohérentes et précises et qu'elles donnent un aperçu de ce que font 300 000 développeurs au quotidien. Dans ma dernière présentation, je fais référence aux chiffres du BSIMM et je mentionne qu'en moyenne, il y a 2 professionnels de la sécurité des applications pour 100 développeurs.

Toutefois, ce n'est plus le cas depuis BSIMM4. Le BSIMM8 indique que ce chiffre est encore plus bas, à savoir 1,6 pour 100 développeurs. Embaucher davantage de professionnels de la sécurité des applications ne fonctionnera tout simplement pas, car il y a une pénurie de talents. Plus que jamais, nous devons donner aux développeurs les outils et la formation nécessaires pour écrire un code sécurisé qui soit pratique, facilement disponible et évolutif pour les organisations.

Le rapport montre également que l'activité la plus courante dans la pratique de la formation est la fourniture d'une formation de sensibilisation à tous les employés (67 %). J'ai commencé à cartographier ce que nous faisons à Secure Code Warrior (SCW) dans la pratique de la formation et j'ai réalisé que notre solution peut cocher les 12 activités de la pratique de la formation allant du niveau 1 (la plupart des entreprises le font) au niveau 3 (très peu d'entreprises le font).

Sur les 12 pratiques de formation, les pratiques les plus intéressantes pour la solution Secure Code Warrior sont les suivantes :

• Niveau 1 : Fournir une formation de sensibilisation
• Niveau 1 : Dispenser des formations individuelles à la demande
• Niveau 2 : Améliorer les satellites par la formation (mesures du SCW)
• Niveau 3 : récompenser la progression dans le programme (badges SCW)
• Niveau 3 : Fournir une formation aux vendeurs ou aux travailleurs externalisés (évaluations SCW)
• Niveau 3 : Accueillir des événements externes liés à la sécurité des logiciels (mode SCW Tournament )
• Niveau 3 : Identifier les satellites par le biais de la formation (mesures du SCW)

Êtes-vous sûr que votre solution actuelle tient compte de ces pratiques ?

Pourquoi un programme de formation à la sécurité des applications pour développeurs donne-t-il de meilleurs résultats qu'un autre ?

Depuis plus de dix ans que je suis formateur à la SANS et depuis trois ans que j'ai fondé et développé Secure Code Warrior (SCW), j'ai constaté qu'il était important d'investir du temps et des ressources pour que les programmes de formation produisent les meilleurs résultats.

Au cours de notre première année de vente, notre entreprise a fait participer plus de 10 000 développeurs à une formation sur le code sécurisé, et j'ai remarqué un certain nombre de tendances parmi ceux qui ont eu le déploiement le plus efficace. Leurs résultats sont réconfortants : un engagement fort, une sensibilisation à la sécurité accrue et un fort retour sur investissement du programme en détectant les faiblesses de sécurité plus tôt, avant qu'elles ne deviennent coûteuses.

Je n'aime pas l'admettre, mais il y a aussi eu quelques personnes qui ont adopté l'approche "sans effort" et qui ont essayé de déployer un programme en envoyant un courriel avec un lien vers la formation. Il n'est pas surprenant que cela ne fonctionne pas aussi bien et que nous ayons dû corriger ces déploiements.

Ci-dessous, je partage ce que je crois être cinq leçons importantes qui amélioreront de manière significative les niveaux d'engagement, l'impact et le succès de tout programme de formation à la sécurité des développeurs, y compris le nôtre.

1. Si vous voulez que votre programme ait un impact, il faut que le coup d'envoi soit amusant.

L'organisation d'un événement spécial le jour du lancement, ou le fait de donner à votre programme un thème lié au cinéma, aux jeux vidéo ou aux jeux de hasard, peut faire une grande différence dans le niveau d'enthousiasme et de participation dès le début. L'un de nos grands clients a créé tout un programme fantastique autour d'une série télévisée populaire, avec des t-shirts, des badges et des autocollants, faisant de l'ensemble du programme de formation une expérience qu'aucun développeur ne voudrait manquer. Un autre a thématisé son événement autour de la Guerre des étoiles, qui s'est tenu le 4 mai. Un peu d'amusement peut grandement aider les employés à s'impliquer, en faisant en sorte que les courtes périodes de formation sur les compétences en matière de code sécurisé pour les développeurs soient perçues comme une pause dans le travail, plutôt que comme une autre tâche à accomplir. L'étape n°1 est atteinte, nous avons attiré leur attention et ils sont au courant du programme.

2. Trouvez le bon champion de la formation à la sécurité des développeurs (indice : ils ont plus besoin de compétences en communication qu'en sécurité !)

Il est essentiel de trouver les bons champions de la sécurité dans chaque équipe de scrum pour assurer le succès du programme, en particulier dans les grandes organisations. D'après mon expérience, les experts en sécurité ou en développement hautement qualifiés n'ont pas tous des compétences humaines et/ou de communication très développées. Les meilleurs champions de la sécurité, ceux qui donneront à votre programme un impact positif continu, sont les personnes qui sont passionnées par la sécurité et qui ont de solides compétences en matière de relations humaines, d'influence et de communication. Choisissez judicieusement et tenez compte de la personnalité et des compétences en matière de communication.

3. Offrez des récompenses intéressantes qui reconnaissent les compétences

En général, tous les passionnés d'informatique - y compris les développeurs - aiment être reconnus pour leur intelligence et leurs compétences. Lorsque vous les récompensez avec des autocollants de statut spécifique, des gadgets de geek, des badges spéciaux ou des t-shirts imprimés personnalisés qui reconnaissent leurs compétences, ils les porteront ou les afficheront avec fierté. Si quelqu'un accomplit quelque chose d'important dans le cadre du programme de formation, il est important de réfléchir à des moyens de lui donner de la reconnaissance et de la visibilité. J'ai vu une excellente initiative chez un client qui prenait régulièrement des photos de ses champions Secure Code Warrior et les affichait avec une photo et un message du RSSI de l'entreprise dans le bulletin d'information des employés.

4. N'essayez pas de faire de vos développeurs des experts en sécurité.

Si vous souhaitez faire de vos développeurs la "première ligne de défense" de votre programme de sécurité en les aidant à coder en toute sécurité, cela ne signifie pas qu'ils doivent être les experts en sécurité les plus pointus de votre entreprise, ni que vous devez leur présenter en permanence de nouvelles vulnérabilités en matière de sécurité et des exemples d'atteintes à la protection des données. Bien que la sécurité soit importante, leur objectif premier est souvent de créer un produit ou un service de qualité et de suivre le rythme de l'entreprise. Si vous surchargez quelqu'un avec trop de sécurité, vous courez le risque de le désengager. Les principaux enseignements tirés sont les suivants : ils doivent comprendre les règles d'hygiène de base en matière de sécurité et disposer d'outils pour coder en toute sécurité, mais ils n'ont pas besoin d'être les experts de l'entreprise en matière de sécurité.

5. Ne mesurez pas la formation, mesurez l'impact

Ne mesurez pas le nombre d'heures de formation suivies par vos développeurs ou le nombre de vidéos qu'ils regardent, mais le nombre de faiblesses détectées au cours du cycle de développement par l'analyse du code, la recherche de bogues ou les tests de vulnérabilité classiques avant de lancer le programme dans chaque équipe. Si votre programme de formation fonctionne, le nombre de vulnérabilités identifiées diminuera. La deuxième chose à mesurer est le temps qu'il faut pour corriger une vulnérabilité. S'il faut un mois à un développeur pour la corriger, cela montre clairement qu'il ne comprend pas comment faire, mais s'il peut la corriger en une heure, vous savez qu'il maîtrise les compétences. Ce sont les deux paramètres que les entreprises intelligentes utilisent pour mesurer l'impact de leur formation au codage sécurisé des développeurs.

5 leçons importantes sur la façon de mettre en place une formation efficace à la sécurité des développeurs :

1. Si vous voulez que votre programme ait un impact, amusez-vous à donner le coup d'envoi.
2. Trouvez le bon champion de la formation à la sécurité des développeurs (indice : ils ont plus besoin de compétences en communication qu'en sécurité !)
3. Offrez des récompenses intéressantes qui reconnaissent les compétences
4. N'essayez pas de faire de vos développeurs des experts en sécurité
5. Ne mesurez pas la formation, mesurez l'impact

Des chercheurs du VirginiaTech ont publié un article après avoir analysé des centaines de messages sur le forum de développeurs le plus populaire (Stack Overflow). Ils ont examiné le type de questions posées sur la sécurité, les réponses les plus populaires données par la communauté et l'effet qu'elles ont sur le code des ingénieurs en logiciel.

Ce n'est pas vraiment une surprise pour les personnes qui travaillent dans le domaine de la cybersécurité depuis un certain temps, mais il est nécessaire de sensibiliser davantage les développeurs à ce problème :

• Les dispositifs de sécurité fournis par les cadres de codage (par exemple JAVA Spring) sont trop compliqués et mal documentés.
• Un nombre important de développeurs ne semblent pas comprendre les implications des options de codage en matière de sécurité, ce qui témoigne d'un manque de formation en matière de cybersécurité.
• De nombreuses suggestions et "corrections" sur ces forums ne sont pas sûres, mais elles recevaient des votes positifs et étaient donc mieux notées.

Le rapport propose les solutions suivantes :

• Recyclage de la main-d'œuvre
• Détection et correction semi-automatiques des bogues de sécurité

Nous devons faciliter la sécurité pour les développeurs et l'intégrer dès le départ afin de maintenir la vitesse à laquelle les entreprises fonctionnent aujourd'hui.

"L'importance de ce travail réside dans le fait que nous avons fourni des preuves empiriques d'un nombre important de problèmes alarmants de codage sécurisé, qui n'avaient jamais été signalés auparavant", indique l'article. "Ces problèmes sont dus à diverses raisons, notamment l'augmentation rapide des besoins en applications de sécurité d'entreprise, le manque de formation en matière de sécurité au sein de la main-d'œuvre chargée du développement des logiciels et des bibliothèques de sécurité mal conçues.

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

Au début de ce mois, le chasseur de bugs belge, Inti De Ceukelaire a révélé un piratage créatif qui affecte des centaines d'entreprises. L'astuce consiste à exploiter une logique commerciale dans les services d'assistance et les systèmes de suivi des problèmes les plus répandus pour accéder aux intranets, aux comptes de médias sociaux ou, le plus souvent, aux équipes Yammer et Slack. Vous pouvez lire les détails sur le blog d sur le blog d'Inti. J'ai été impressionné par la créativité nécessaire pour mettre au point cet exploit et curieux de connaître le processus impliqué, j'ai donc décidé de poser quelques questions à Inti, et je partage ses réponses avec vous.

Bonjour Inti, pouvez-vous vous présenter brièvement à nos lecteurs ?

Je suis Inti, chasseur de bugs chez Intigriti et Hackerone. Je vis à Alost (Belgique) et je passe mes journées à casser des trucs.

La semaine dernière, j'ai lu votre article de blog sur ce que vous avez appelé depuis "Ticket Trick" et j'ai été impressionné par la créativité dont vous avez fait preuve pour trouver cet exploit. Comment vous est venue l'idée d'essayer cette astuce ?

Je participe à des programmes de primes aux bugs, ce qui signifie que certains sites web offrent de l'argent aux chercheurs en sécurité responsables qui découvrent des vulnérabilités uniques. Comme il y a beaucoup de concurrence, vous devez continuer à chercher des choses que d'autres n'ont pas encore trouvées. J'ai pensé que Slack était un vecteur d'attaque intéressant parce qu'il contient souvent des informations sensibles et qu'il suffit parfois d'une adresse électronique valide de l'entreprise. J'ai donc pris une bière, je me suis allongé sur le canapé et j'ai commencé à réfléchir à tous les vecteurs d'attaque possibles. Soudain, j'ai eu une idée folle, qui s'est avérée efficace. En général, j'essaie tout ce qui me passe par la tête. Même si cela ne fonctionne que quelques fois, c'est payant ;-)

En tant que personne travaillant habituellement du côté opposé, essayant de sécuriser le code, je me demande souvent à quoi ressemble une session de pentesting. Où travaillez-vous ? Est-ce quelque chose que vous faites également pendant votre temps libre depuis votre canapé ? Ou travaillez-vous dans un bureau ?

Pendant la journée, je travaille comme codeur créatif numérique dans une station de radio appelée Studio Brussel. Cela implique un peu de programmation et un peu de médias sociaux, mais pas de sécurité. J'essaie de ne pas mélanger mon hobby avec mon travail professionnel. J'ai peur de perdre ma créativité si je le fais. Je ne pirate pas très souvent : au maximum quelques heures par semaine. Je peux le faire à la table, sur le canapé ou sur mon lit - ce qui me convient le mieux à ce moment-là.

Comment commencez-vous ? Disposez-vous d'une antisèche ? Disposez-vous de quelques données pour vérifier si la validation des entrées ou l'échappement des sorties sont suffisants ?

Je suis très chaotique, donc je n'ai pas vraiment de liste de contrôle, je me fie à mon intuition. La plupart du temps, je commence par ce que l'on appelle la reconnaissance : je répertorie toutes les informations intéressantes sur la cible, les sous-domaines, les adresses IP, tout ce que je peux trouver. J'essaie d'avoir une vue d'ensemble et de comprendre la logique de l'entreprise avant même de commencer à pirater. Si vous ne recherchez que les vulnérabilités classiques, vous passerez à côté des failles les plus intelligentes et les plus complexes. En ce qui concerne les données d'entrée, j'essaie de couvrir le plus grand nombre possible de vulnérabilités dans une seule charge utile. Chaque fois que je découvre quelque chose d'intéressant, je joue avec pendant un certain temps et j'y jette un tas d'absurdités, juste pour voir comment le système y réagit. Les meilleurs bugs se trouvent souvent dans les parties les plus éloignées d'une application web, c'est pourquoi j'essaie de creuser aussi profondément que possible.

Selon vous, qu'est-ce qui fait un bon pentester ? Avez-vous des astuces à nous faire partager ?

Je ne suis pas un pentester et je ne peux donc pas vraiment parler pour les pentesters en général, mais je pense que la motivation et la persévérance sont les atouts les plus importants. La plupart des gens n'envisagent même pas de chercher des failles de sécurité chez Google, qui dispose des meilleurs ingénieurs du monde, et qui paie pourtant des millions de primes aux bugs chaque année. Je travaille sur une cible depuis plus de deux ans et je commence maintenant à trouver les bogues les plus intéressants. Cela prend du temps. Le problème avec le pentesting normal est que les testeurs sont récompensés par un montant fixe, qu'ils trouvent des vulnérabilités critiques ou non. Je pense qu'il y a encore beaucoup de bogues dans Facebook, il suffit que quelqu'un soit prêt à creuser assez profondément.

Lorsque vous avez réalisé l'ampleur du Ticket Trick, quelle a été votre première réaction ?

Mes sentiments étaient partagés. J'ai été stupéfait et j'ai immédiatement pensé aux primes de bogues que je pourrais collecter avec cela, mais d'un autre côté, j'ai été choqué que cela soit possible. Chaque fois que vous trouvez quelque chose comme cela, vous possédez soudain un grand nombre d'informations précieuses qui pourraient intéresser des parties malveillantes. Le processus de divulgation est difficile : vous devez informer le plus grand nombre possible d'entreprises concernées, mais d'un autre côté, vous devez vous assurer que les informations ne font pas l'objet d'une fuite ou d'une utilisation abusive.

Pourquoi avez-vous décidé de divulguer ces informations avant de collecter d'autres primes ?

Il est plus important de faire ce qui est juste que de collecter des primes. Je pense que j'ai eu ma part du gâteau et je veux maintenant rendre à la communauté ce qu'elle m'a donné. En outre, j'ai informé les entreprises de ce problème pendant des mois, de sorte que de plus en plus de gens sont au courant. Je ne voulais pas qu'il y ait des fuites ou des abus de la part de personnes mal intentionnées.

Que pensez-vous des réponses des entreprises concernées ?

La plupart des réponses ont été satisfaisantes. Certaines entreprises ne s'en souciaient pas vraiment, mais en fin de compte, c'est leur perte. Être rejeté en tant que chercheur en sécurité fait partie du jeu. Au moins, je n'ai pas été poursuivi en justice. Il y a 10 ans, cela aurait probablement été le cas.

Une dernière question, sur reddit j'ai lu que vous avez réclamé 8000$ en bug bounties, avez-vous des plans sympas pour dépenser cet argent ?

Au total, ce bug m'a rapporté plus de 20 000 dollars. Plus de la moitié de cette somme est consacrée aux impôts. Je dépense le reste pour des choses normales comme des voyages, des sorties au restaurant, ... rien d'extraordinaire :-)

Merci beaucoup pour votre temps et bonne chance pour la chasse à l'avenir !

Le bogue existe toujours. Il ne peut pas être corrigé immédiatement. Au cours des derniers mois, j'ai contacté des dizaines d'entreprises et de fournisseurs concernés dans le cadre de leurs programmes de primes à la détection de bogues afin que leur installation soit corrigée.

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

Si nous observons n'importe quelle organisation, qu'elle soit publique ou commerciale, il y a deux choses que nous pouvons garantir. Premièrement, leurs produits et services sont de plus en plus numériques, ce qui signifie qu'ils impliquent des développeurs de logiciels qui créent des lignes de code. Deuxièmement, ces entreprises numériques sont soumises à la pression de concurrents traditionnels et non traditionnels, qui opèrent dans un monde plus dynamique et plus global.

Dans cet environnement, les DSI sont devenus les nouveaux innovateurs et occupent des positions de pouvoir et d'influence. Toutefois, la forte pression exercée pour accélérer la mise sur le marché, améliorer la qualité et accroître la flexibilité a conduit à la constitution d'équipes de développement complexes et distribuées, qui se concentrent sur le développement rapide de caractéristiques et de fonctions sans tenir compte des vulnérabilités qu'elles pourraient créer.

Plus que jamais, une nouvelle façon de travailler est nécessaire. Il suffit de voir les dégâts nucléaires subis par Equifax à la suite de leur récente violation, qui était le résultat d'un codage non sécurisé. Les DSI et les RSSI doivent se demander si leurs équipes de développement sont la première ligne de risque ou si elles sont les champions de la sécurité de l'entreprise, la véritable "première ligne de défense" de l'entreprise.

J'ai créé cette liste de contrôle du codage sécurisé pour aider les DSI et les RSSI à déterminer si leurs équipes de développement sont des champions du codage sécurisé qui peuvent vous aider à innover grâce à un code plus rapide, meilleur et plus sûr.

1. Votre cadre supérieur reconnaît-il que la sécurité traditionnelle des réseaux n'est pas suffisante ?

La sécurisation de la couche réseau à l'aide de mesures de sécurité traditionnelles n'est plus suffisante et n'a de toute façon que rarement réussi, même contre des pirates semi-professionnels. Parmi les nombreux rapports concordants, le rapport 2017 Data Breach Investigations Report de Verizon indique que 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.

2. Pensez-vous à la sécurité dès le départ ?

Les outils actuels de sécurité des applications se concentrent sur le passage de la droite à la gauche du cycle de vie du développement logiciel (SDLC). Cette approche favorise la détection et la réaction, ce qui signifie que les équipes de sécurité détectent les vulnérabilités dans le code écrit et réagissent pour les corriger. 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 lors de l'écriture du code dans l'IDE. Sans parler des délais nécessaires pour remédier au problème. Les champions du code sécurisé commencent à l'extrême gauche du cycle de développement durable, en mettant l'accent sur la formation continue de leurs développeurs au codage sécurisé, afin qu'ils puissent constituer la première ligne de défense de leur organisation, en prévenant les vulnérabilités dès le départ.

3. Développez-vous réellement des compétences en matière de sécurité au lieu de vous contenter de transmettre des connaissances ?

La plupart des solutions de formation (en ligne et en classe) se concentrent sur l'acquisition de connaissances plutôt que de compétences. Pour que les développeurs puissent écrire du code sécurisé, ils doivent avoir régulièrement accès à un apprentissage pratique qui les incite activement à apprendre et à développer leurs compétences en matière de codage sécurisé. Ils doivent se familiariser avec les vulnérabilités récemment identifiées, dans un code réel et dans leurs propres langages/cadres. Cette expérience d'apprentissage devrait les aider à comprendre comment localiser, identifier et corriger les vulnérabilités connues dans le code.

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

Il est important de créer des éléments qui prouvent au développeur et à son organisation que les compétences du développeur en matière de codage sécurisé s'améliorent. Vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer. Vos évaluations devraient permettre d'identifier les progrès de vos équipes de développement en temps réel et de comparer leurs forces et faiblesses en matière de codage sécurisé.

5. Êtes-vous sûr que vos fournisseurs externalisés appliquent des techniques de codage sécurisées ?

De nombreuses organisations décident de sous-traiter le travail de développement à de grandes sociétés de développement onshore ou offshore. Dans le meilleur des cas, la seule forme d'assurance qu'une organisation demande en matière de sécurité est une déclaration dans le contrat exigeant que le produit à livrer soit "sécurisé". Peu de gens vérifient réellement les compétences de ces sociétés de développement en amont et se retrouvent avec des logiciels qui ne respectent pas les bonnes pratiques de codage sécurisé. Dans le pire des cas, ils ne sont pas au courant de ces pratiques et mettent l'application en service. Le scénario le plus courant est qu'elles sont détectées par des spécialistes (que vous payez) et que vous êtes confronté à des retards dans la mise en service et à des discussions contractuelles sur la question de savoir qui doit payer pour corriger ces faiblesses en matière de sécurité. Faites preuve d'intelligence dès le départ et évaluez les compétences en matière de sécurité des développeurs qui vont construire votre prochaine application.

6. Vos développeurs connaissent-ils les faiblesses les plus courantes en matière de sécurité ?

85,5 % des vulnérabilités des applications web exploitées sont attribuées à seulement 10 vulnérabilités connues " le Top 10 de l'OWASP ". Votre formation à la sécurité des applications doit couvrir au minimum ces vulnérabilités et bien d'autres types de vulnérabilités. Les défis que vos développeurs doivent relever doivent être continuellement révisés et mis à jour avec de nouveaux défis pour de nouveaux cadres de codage ou de nouveaux types de vulnérabilités.

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

Toute organisation qui compte de nombreux développeurs devrait investir dans une personne qui défendra la sécurité au sein de ses équipes de développement. Son rôle est d'être un point de contact pour toute personne ayant des questions relatives à la sécurité, mais aussi de préconiser des pratiques de codage et d'architecture sécurisées au sein d'une équipe.

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

Dans un environnement où les applications subissent de nombreuses modifications ou dans lequel le développement agile est pratiqué, l'automatisation de certaines parties de la sécurité est essentielle pour suivre le rythme et le volume. Il existe des outils disponibles à chaque étape du cycle de vie du développement qui serviront de conseillers, de barrières de qualité ou d'outils de détection. Vous devriez disposer de plugins IDE qui se concentrent sur certains types de bogues de sécurité et agissent comme des correcteurs d'orthographe pendant que le développeur écrit son code. Il existe également des outils qui s'intègrent au processus de construction et qui détectent certains types de faiblesses lorsque le code est soumis à un dépôt de code. Il existe également des outils qui exécutent des tests automatisés sur le code, simulant des techniques 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'il n'y a pas de problèmes de sécurité. La règle d'or est la suivante : plus tôt vous pouvez détecter les faiblesses, plus il est rapide et moins coûteux d'y remédier avec le moins d'impact possible sur votre entreprise.

Alors que les DSI développent agressivement les capacités agiles de leur entreprise, les compétences en codage sécurisé seront une arme d'innovation et ne pas les avoir sera un instrument de destruction. Réfléchissez-y à deux fois avant de faire l'impasse sur cette capacité critique.

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

Alors que les DSI développent agressivement les capacités agiles de leur entreprise, les compétences en codage sécurisé seront une arme d'innovation et ne pas les avoir sera un instrument de destruction. Réfléchissez-y à deux fois avant de faire l'impasse sur cette capacité critique.