Informations concernant le code sécurisé

C'est exactement ce que signifie le tapjacking, une combinaison de « tap » et de « hijacking ». Il s'agit d'une attaque au cours de laquelle l'attaquant détourne les tapotements de l'utilisateur et l'incite à faire quelque chose dont il n'avait pas l'intention. Alors, comment cela fonctionne-t-il et comment l'éviter ?

Nous allons commencer notre histoire avec des superpositions d'écran. Superpositions d'écran ou, comme les appelle Google, fenêtres utilisant le type TYPE_APPLICATION_OVERLAY. Il s'agit de fenêtres dessinées au-dessus d'autres applications et qui ne masquent généralement qu'une partie de l'écran. Elles sont souvent utilisées (comme l'exemple d'image ci-dessous) lorsqu'une application demande de nouvelles autorisations.

Il s'agit en fait d'une fonctionnalité intéressante et amusante et de plus en plus d'applications commencent à l'utiliser. Pensez aux bulles de discussion de Facebook ou à la navigation sur Google Maps dans un coin de votre écran, comme dans la capture d'écran ci-dessous.

Cependant, ces superpositions présentent certains risques de sécurité. Toute superposition d'écran active peut écouter les tapotements. Sinon, comment Facebook pourrait-il savoir que nous avons tapé ou fait glisser la bulle ? Cela permet aux applications de vous espionner et de voler potentiellement des mots de passe et des données de carte de crédit.

Une étape plus loin, et c'est de là que vient le terme tapjacking, les superpositions peuvent dessiner des éléments au-dessus d'autres applications en incitant l'utilisateur à effectuer différentes actions. L'utilisateur pense qu'il interagit avec la superposition, mais en réalité, ses touches exécutent également des actions dans l'application sous-jacente. De cette façon, la superposition peut vous inciter à activer certaines autorisations ou à modifier certains paramètres dangereux, comme illustré dans ce ancienne vidéo YouTube.

La vidéo de démonstration ci-dessus a été mise en ligne sur YouTube en 2010, elle a donc été réalisée sur une ancienne version d'Android. Mais l'attaque est toujours d'actualité aujourd'hui, car vulnérabilités a été découvert qui permet le tapjacking dans les nouvelles versions d'Android telles que Nougat et Marshmallow.

Alors, que peux-tu y faire ? En tant qu'utilisateur, il est important de prendre conscience des conséquences de ces superpositions et de connaître les applications qui les utilisent. À partir du niveau d'API 23 (Android 6.0 Marshmallow), c'est devenu une autorisation qui doit être explicitement accordé par l'utilisateur. Cependant, cela laisse 50 % d'Androidles utilisateurs restent vulnérables. Vous pouvez toujours vérifier quelles applications utilisent cette autorisation dans les paramètres sous « Afficher sur d'autres applications ».

En tant que développeurs, il nous appartient de nous assurer que les actions des utilisateurs sont effectuées en toute connaissance de cause et avec leur consentement. Android fournit un paramètre pour vos vues qui font exactement cela, appelé Le filtre touche lorsqu'il est masqué. Lorsqu'il est activé, le framework supprime les touches reçues chaque fois que la fenêtre des vues est masquée par une autre fenêtre visible. C'est aussi simple que cela, réglez Le filtre se touche lorsqu'il est masqué à true, et votre application est protégée contre le tapjacking.

Bonne chance et à la semaine prochaine !

Il est parfois essentiel qu'une application soit en mesure de vérifier qu'une action est effectuée en toute connaissance de cause et avec le consentement de l'utilisateur, par exemple en accordant une demande d'autorisation, en effectuant un achat ou en cliquant sur une publicité. Malheureusement, une application malveillante pourrait tenter d'inciter l'utilisateur à effectuer ces actions sans le savoir, en dissimulant l'objectif de la vue.

https://developer.android.com/reference/android/view/View.html

Publié à l'origine sur Blogue DevSecCon.

Ayant été des deux côtés de la barrière, je ne connais que trop bien les tensions qui peuvent survenir entre l'équipe de développement et les spécialistes AppSec lorsqu'il s'agit de faire respecter les meilleures pratiques en matière de sécurité.

C'est difficile ; en fin de compte, la principale priorité d'un développeur est de fournir des fonctionnalités logicielles. Ils doivent être beaux, fonctionnels et permettre de mettre en valeur la puissance de l'application. Les pratiques de développement agiles étant généralement utilisées de nos jours, ces fonctionnalités doivent être mises en œuvre dans des délais stricts... et la sécurité figure rarement en tête de liste des préoccupations alors que d'autres enjeux sont en jeu.

La sécurité est considérée comme le domaine de compétence de l'équipe AppSec, qui a la tâche peu enviable de scanner le code (ou pire encore, de le réviser manuellement, ligne par ligne) et de signaler à l'équipe de développement que son code n'est pas sécurisé, voire totalement inutilisable. Ce sont les bâtons dans la boue qui permettent de distinguer leur bon travail, de stopper l'innovation et, en général, de créer un casse-tête pour les développeurs. En fin de compte, de nombreux problèmes de sécurité ne peuvent être résolus que très simplement. Une seule ligne de code pourrait peut-être renforcer une porte dérobée vulnérable en quelques minutes.

Mais voici le problème. La « sécurité » étant synonyme d'expérience négative, les développeurs ne s'y intéressent tout simplement pas aussi étroitement qu'ils le devraient. Ces correctifs en une ligne ne se produisent pas : après tout, les gars d'AppSec rencontrent continuellement les mêmes problèmes. Cela doit être assez exaspérant pour eux de continuer à signaler des failles d'injection SQL, plus de vingt ans après leur découverte (et leur correction ultérieure).

Ce que nous avons fait jusqu'à présent ne fonctionne pas aussi efficacement que nous l'espérions. Nous devons nous concentrer sur la réparation du lien entre les développeurs et les spécialistes de la sécurité des applications, en nous efforçant de créer une culture de sécurité positive dans laquelle les développeurs reçoivent les outils et la formation nécessaires pour avoir un réel impact dans l'espace.

Qui sait ? Ils pourraient même en tomber amoureux comme moi !

La sécurité positive est le moyen le plus rapide et le plus simple d'améliorer la sécurité des applications

Ville « et non, il ne s'agit pas d'une question de résultats intangibles. Il s'agit d'un ingrédient absolument essentiel à la recette du succès du codage sécurisé.

Les développeurs détiennent la clé pour améliorer la sécurité dès le début de la production, en écrivant du code sécurisé en premier lieu. En créant une culture de sécurité positive et en suscitant l'intérêt des développeurs pour la sécurité des applications, les vulnérabilités courantes peuvent être supprimées avant même qu'elles ne soient numérisées ou révisées manuellement dans AppSec Land.

C'est il est trente fois plus coûteux de corriger des vulnérabilités dans un code déjà validé, donc trouver une formation qui tire parti des points forts des développeurs, qui suscite de l'intérêt et qui fonctionne réellement constitue une étape importante dans la réduction des coûts futurs liés à l'identification et à la correction de ces vulnérabilités récurrentes.

Les initiatives positives, centrées sur les développeurs, favorisent la mise en place d'une culture de sécurité adaptée.

Lorsque tout le monde est sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité, une culture de sécurité positive est un sous-produit positif et vital.

Les initiatives positives et évolutives axées sur les développeurs favorisent la mise en place d'une culture de sécurité adaptée. Il est essentiel de faire appel à l'esprit créatif et à la résolution de problèmes des développeurs pour les convaincre, ainsi que pour garantir que les nouvelles recrues puissent répondre rapidement aux attentes de l'équipe en matière de sécurité. Entrer en contact pour un aperçu de l'évolution de la relation entre les développeurs en matière de sécurité et des idées pour déployer un programme de sensibilisation à la sécurité efficace dans vos propres organisations.

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

Alors que le nombre de cybermenaces ne cesse de croître, les entreprises font des compromis quotidiens entre sécurité, praticité et rapidité, s'exposant ainsi à des risques. De nouvelles approches de codage sécurisé sont nécessaires, donc Secure Code Warrior a collaboré avec Evans Data Corp. pour mener des recherches primaires sur les attitudes des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité (télécharger le livre blanc) ici).

Ce rapport a révélé que si la pensée réactive « à l'ancienne » domine toujours, il existe une prise de conscience croissante de la nécessité de solutions plus proactives, qui font des développeurs eux-mêmes la première ligne de défense.

Toute exploration de l'adoption de pratiques de codage sécurisées doit commencer par une compréhension des humains impliqués dans leur mise en œuvre, de leur perception de celle-ci et de leur capacité à les mettre en œuvre. Cela nous amène à la pièce la plus importante du puzzle : comment leur donner les moyens de coder de manière plus sécurisée dès le départ et d'envoyer du code de qualité plus rapidement et en toute confiance ?

Codage sécurisé : où en sommes-nous aujourd'hui et qu'est-ce qui doit changer ? Télécharger l'infographie « L'élément humain » maintenant.

Perspectives actuelles : réactives ou proactives

Lorsque les développeurs et les responsables du développement ont été interrogés sur les activités qu'ils associent au codage sécurisé, les trois réponses les plus fréquentes ont été les suivantes :

• Utilisation d'outils d'analyse sur les applications déployées.
• Vérification manuelle du code pour détecter les vulnérabilités.
• Pratique active et continue de l'écriture de logiciels protégés contre les vulnérabilités.

Comme nous pouvons le constater, deux des trois réponses les plus fréquentes se concentraient toujours sur les approches réactives : la première dépendait de l'outillage (scanners) et la seconde du développeur (c'est-à-dire humain) effectuant des vérifications manuelles.

Dans le même temps, deux des trois activités nominées font appel à l'élément humain. Cela montre que la sécurité est de plus en plus perçue comme une question humaine. Mais de toutes les activités nominées, la plus révélatrice est la troisième, qui identifie le facteur humain un logiciel écrit qui est protégé contre les vulnérabilités en premier lieu. Cela met en évidence un changement vers la gauche : une approche proactive et préventive qui intègre la sécurité dans les logiciels dès le début du SDLC.

Quelle est la place de la sécurité dans le SDLC ?

Lorsqu'on demande aux développeurs et aux responsables du développement comment ils envisagent l'intégration de pratiques de code sécurisées dans le SDLC, les avis divergent. 55 % des responsables pensent que le codage sécurisé est intégré à l'ensemble du processus de développement, contre seulement 43 % des développeurs. La différence pourrait refléter les rôles différents de ces deux groupes au sein du SDLC. La direction est généralement moins impliquée dans le travail de programmation proprement dit et a tendance à avoir une vision plus globale, tandis que les développeurs peuvent être plus préoccupés par les détails.

Mais du point de vue de la sécurité globale et de la qualité du code, ce qui est alarmant, c'est que seuls 13 % des développeurs et 10 % des responsables déclarent que les pratiques de code sécurisées devraient être intégrées dès les étapes de conception, dès le début du SDLC. Il s'agit d'une opportunité énorme et non exploitée. Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités présentes dans le code après la publication que si elles étaient détectées et corrigées au début.1 Cela constitue une puissante incitation à une nouvelle défense proactive et dirigée par l'homme en matière de sécurité logicielle, qui donne aux développeurs les moyens de coder de manière plus sécurisée, dès le départ. La sécurité des logiciels ne peut pas être résolue en se fiant uniquement à l'outillage : elle doit tenir compte de l'élément humain.

L'élément humain est-il préparé ?

97 % des développeurs interrogés estiment avoir reçu une formation suffisante en matière de codage sécurisé, et 95 % ont reconnu que la formation au codage sécurisé avait été précieuse pour leur carrière. Mais avant d'accepter ces affirmations pour argent comptant, nous devons nous demander : pourquoi les vulnérabilités du code sont-elles toujours aussi répandues ? Les affirmations des développeurs concernant leur expertise en matière de code sécurisé ne sont-elles qu'un cas d'ego humain ? Les preuves vont certainement dans ce sens. Plus modestement, plus de 88 % des développeurs interrogés admettent que le codage sécurisé est difficile à apprendre, et 91 % des responsables du développement reconnaissent que les pratiques de codage sécurisé sont difficiles à mettre en œuvre. Lorsqu'on leur demande d'identifier leurs principales préoccupations personnelles concernant la mise en œuvre de code sécurisé, 28 % des développeurs trouvent le processus d'apprentissage difficile, tandis que 24 % le trouvent ennuyeux. Cela montre que la formation des développeurs doit être améliorée.

De quoi a besoin l'élément humain ?

Pour surmonter le facteur « difficile », une formation sécurisée intéressante nécessite un processus « d'échafaudage » qui aide le développeur à acquérir des compétences de codage sécurisé étape par étape. Pour une pertinence maximale et une applicabilité immédiate, cette formation doit être dispensée dans le langage spécifique : cadre qu'ils utilisent au quotidien.

Pour surmonter le facteur « ennui », la formation au code sécurisé doit être dispensée de manière pratique, ce qui s'est avéré bien plus intéressant pour les développeurs que les modèles obsolètes en classe ou « regardez cette vidéo ». Celles-ci devraient inclure des simulations en direct qui permettent aux développeurs de relever des défis de sécurité parfois risqués dans un environnement sûr. L'objectif devrait être d'apprendre aux développeurs à détecter et à corriger les vulnérabilités dans le code pendant qu'il travaille et à intégrer le codage sécurisé à leur flux quotidien. Un autre facteur clé est le linting et le coaching à l'intérieur de l'IDE, qui aident les développeurs à constamment apprendre et à améliorer leurs compétences au fur et à mesure qu'ils codent, tout en prévenant et en éliminant les vulnérabilités au fur et à mesure.

Si vous souhaitez savoir comment fournir à vos développeurs ce nouveau niveau d'outils et de formations centrés sur les développeurs, réservez une démo maintenant.

Vous pouvez également téléchargez votre copie du livre blanc Passer de la réaction à la prévention : le nouveau visage de la sécurité des applications

‍

Les cyberattaques sont, sans aucun doute, en augmentation. Selon le rapport d'enquête sur les violations de données 2021 de Verizon, le paysage des menaces est plus dangereux aujourd'hui plus que jamais. Les organisations de toutes tailles sont confrontées à un volume d'attaques de plus en plus important et à un niveau de sophistication accru de la part des acteurs malveillants qui les ciblent. Et les taux de réussite des attaquants montent également en flèche.

L'analyse des attaques les plus récentes permet de révéler certaines des vulnérabilités et techniques les plus courantes utilisées par les pirates informatiques lors de cette campagne sans précédent contre les cyberdéfenses. Certaines des attaques les plus populaires, telles que celles qui ont permis à l'Open Web Application Security Project (OWASP) Les 10 principaux risques et vulnérabilités de sécurité pour 2021, impliquait le vol ou la compromission d'informations d'identification. Et selon des recherches sur la sécurité menée par Akamai, l'écrasante majorité (près de 75 %) ciblait directement les informations d'identification détenues par les API.

L'essor et la possible ruine des API

Il n'est pas étonnant que les interfaces de programmation d'applications, pour la plupart simplement appelées API, soient en plein essor au sein des réseaux de presque toutes les organisations. Ils constituent un élément essentiel de la plupart des services basés sur le cloud, qui prennent rapidement en charge les fonctions des actifs sur site dans la plupart des entreprises, organisations et agences gouvernementales. De nos jours, il est quasiment impossible de gérer une activité ou une tâche sans le cloud, en particulier celles qui sont destinées au public. Cela signifie que les API seront certainement le ciment qui permettra à de nombreux services de fonctionner ensemble sur chaque réseau.

L'avantage des API est qu'elles sont pour la plupart petites et discrètes en termes d'allocation des ressources réseau. Et ils sont totalement flexibles, de sorte qu'ils peuvent être chargés d'effectuer presque tous les travaux. À la base, les API sont des logiciels individuels conçus pour contrôler ou gérer un programme particulier. Ils peuvent être utilisés pour exécuter des fonctions très spécifiques, telles que l'accès à des données à partir d'un système d'exploitation, d'une application ou d'un service hôte.

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

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

La principale raison pour laquelle les attaquants veulent compromettre les API n'est pas pour s'emparer d'une fonction spécifique exécutée par l'API, mais pour voler les informations d'identification qui y sont associées. L'un des plus gros problèmes des API, en plus d'être truffées de vulnérabilités, est qu'elles sont souvent manière trop autorisée en ce qui concerne leurs fonctionnalités de base. Par souci de simplicité, la plupart des API disposent d'un accès proche du niveau administrateur sur un réseau. Si un attaquant prend le contrôle d'un réseau, il peut souvent utiliser ses autorisations pour lancer des incursions plus profondes et plus importantes dans un réseau. Et comme l'API est autorisée à effectuer toutes les tâches vers lesquelles l'attaquant le redirige, ses actions peuvent souvent contourner la surveillance traditionnelle de la cybersécurité, car l'API n'enfreint aucune règle grâce à son pass VIP d'accès aux coulisses.

Si les entreprises ne font pas attention, la montée en puissance des API au sein de leur réseau et de leurs clouds peut également poser de gros problèmes si elles sont la cible d'attaquants.

Défendre les API

Aussi dangereuse que soit la situation en matière d'API, elle est loin d'être désespérée. Il y a un gros effort à travers les mouvements comme DevSecOps pour sensibiliser les développeurs à la sécurité et pour intégrer la sécurité et les meilleures pratiques à tous les aspects de la création de logiciels, du développement aux tests et au déploiement. L'inclusion de la sécurité des API dans cette formation sera essentielle pour toute organisation qui souhaite inverser la tendance de l'exploitation des API d'ici 2022 et au-delà.

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

La première chose à faire est d'inclure des contrôles d'identité stricts pour toutes les API. Vous devriez presque les considérer comme des utilisateurs humains lorsque vous attribuez des autorisations. Tout simplement parce qu'une API est conçue uniquement pour exécuter une fonction spécifique, vous devez réfléchir à ce qui pourrait se passer si un attaquant parvenait à la compromettre. Envisagez d'utiliser un contrôle d'accès basé sur les rôles. Idéalement, vous devriez au final appliquer les principes de confiance zéro à vos API et à vos utilisateurs, mais le chemin est souvent long. Une bonne gestion des identités est un bon point de départ. Assurez-vous simplement d'inclure des API dans ce programme.

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

Les menaces qui pèsent sur les API peuvent certainement sembler insurmontables. Mais en mettant en œuvre les meilleures pratiques tout en aidant et en récompensant les développeurs qui deviennent des champions de la sécurité, la situation peut sembler bien moins désespérée. Avec une bonne formation et de l'entraînement, vous pouvez mettre en place un programme de sécurité robuste qui laisse peu de marge de manœuvre aux attaquants, même s'ils devaient d'une manière ou d'une autre compromettre l'un de vos outils d'API, minuscules mais essentiels.

En tant que professionnel de la sécurité des applications, il est de votre devoir de garantir la cybersécurité des applications de votre organisation. Vous n'êtes toutefois pas responsable de l'écriture du code sur lequel l'application s'exécute. Les ingénieurs de l'équipe de développement sont. Alors, comment s'assurer qu'ils développent ces systèmes en tenant compte de la sécurité ?

Il est fort probable que vous fassiez certaines ou même la totalité des opérations suivantes :

• Examiner tout le code pour détecter les failles de sécurité et les signaler à l'équipe de développement pour qu'elle les corrige.
• Appliquer un processus d'évaluation par les pairs strict tout au long de votre cycle de développement sécurisé.
• Faire effectuer régulièrement des tests d'évaluation et d'intrusion des applications par des équipes de sécurité internes ou externes.
• Mise en œuvre d'outils d'analyse pour détecter les vulnérabilités.
  

Ce sont d'excellentes pratiques exemplaires, mais elles sont également coûteuses et similaires à la prise d'antibiotiques chaque fois que vous tombez malade. Non seulement cela a un coût élevé, mais cela perd de son efficacité et peut affaiblir votre système immunitaire au fil du temps.

Comment faites-vous pour vous assurer que le code fourni par les développeurs est écrit de manière sécurisée en premier lieu ?

Au-delà du codage sécurisé, pensez d'abord à la façon dont les gens apprennent. La plupart d'entre nous sont des apprenants visuels et nous apprenons par la pratique. Pourtant, la formation au code sécurisé est souvent proposée sous la forme d'une activité à cocher et n'est pas pertinente pour le travail quotidien des développeurs. Il est conçu pour prouver que les développeurs ont souvent suivi une formation en matière de sécurité pour se conformer aux normes du secteur, et non pour que les développeurs conservent ces connaissances, et encore moins pour profiter du processus d'apprentissage.

Les humains ont également tendance à apprendre en faisant des erreurs, de la même manière que notre système immunitaire. Les lymphocytes T se souviennent des types d'agents pathogènes qu'ils ont rencontrés et qu'ils ont réussi à éradiquer dans le passé, afin de pouvoir s'en protéger à l'avenir. C'est exactement le rôle que les développeurs devraient jouer dans votre sécuriser SDLC.

Il est irréaliste de s'attendre à ce qu'ils ne commettent pas d'erreur, mais vous pouvez les préparer de manière à être en mesure de reconnaître les modèles de codage qui se traduiront par des failles de sécurité à l'avenir.

C'est également ainsi qu'un solide processus d'évaluation par les pairs devient si puissant. Ce n'est pas parce qu'un développeur ne remarque pas de faille de sécurité qu'un autre ne le remarquera pas. Et plus l'équipe de développement est formée dans son ensemble, plus les vulnérabilités ont de chances d'être détectées et de ne jamais être mises en production.

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

Les vulnérabilités logicielles sont comme des agents pathogènes dans le sens où vous devez vous en souvenir pour les combattre. En ce qui concerne les agents pathogènes, notre système immunitaire doit souvent être exposé à plusieurs reprises avant de se rappeler comment les combattre afin d'éviter une maladie grave ou pire encore.

Une cyberattaque réussie à partir d'un logiciel vulnérable peut gravement paralyser ou tuer une organisation. Mais si les développeurs découvrent d'abord les vulnérabilités logicielles dans un environnement contrôlé, ils peuvent renforcer leur immunité contre les menaces en améliorant et en mettant régulièrement en pratique leurs connaissances et compétences en matière de codage sécurisé.

Exposez les développeurs à des failles de sécurité dans un environnement contrôlé

Nous ne pouvons jamais nous protéger complètement contre la maladie, mais nous pouvons prendre certaines mesures pour renforcer notre système immunitaire et rester en aussi bonne santé que possible. Faire de l'exercice régulièrement, manger sainement et dormir suffisamment font partie des choix de vie généralement associés à un système immunitaire fort. Mais toutes ces choses demandent un peu d'effort et doivent être continues. Faire du jogging tous les jours pendant une semaine ou arrêter de boire pendant un mois ne nuira guère à votre état de santé général. Il est également déconseillé de sortir et de courir un 10 km le premier jour où nous commençons à courir. Nous devons d'abord exposer notre cœur et nos muscles à l'exercice. Nous savons également qu'il faut un peu d'expérimentation pour trouver un bon équilibre entre notre corps et des aliments sains et des exercices que nous aimons.

Il n'en va pas autrement lorsqu'il s'agit de développer des logiciels sécurisés. L'apprentissage se fait au fil du temps et de la pratique, et les développeurs ont besoin de la même formation continue pour améliorer régulièrement leurs compétences en matière de codage sécurisé. Sans oublier que le développement de logiciels évolue et s'adapte constamment, ce qui signifie que les vulnérabilités le sont également. C'est pourquoi une simple formation ne suffit pas. Les développeurs doivent régulièrement améliorer leurs compétences afin de se familiariser suffisamment avec les menaces potentielles et d'être correctement équipés pour s'en défendre.

Objectif : atteindre l'immunité collective au sein de l'équipe de développement

Une seule personne ne peut prévenir tous les problèmes de sécurité. C'est formidable d'avoir des champions de la sécurité au sein de l'équipe, mais pour bénéficier de la meilleure protection possible, plus il y a de personnes qui connaissent les failles de sécurité et savent comment les prévenir, meilleures sont les chances de votre organisation de les prévenir. Encore une fois, ce n'est pas très différent de la façon dont le système immunitaire possède différents types de lymphocytes T à des fins différentes. Chaque développeur fait partie d'une équipe qui garantit la sécurité. S'ils sont habilités à prendre leurs responsabilités, à bien le faire et même à aimer le faire, vous pouvez ainsi créer une immunité collective contre les cybermenaces au sein de l'équipe de développement.

Faites de la sécurité une priorité grâce à une exposition répétée

Notre cerveau apprend de la même manière que notre système immunitaire. Psychologue allemand Hermann Ebbinghaus a été un pionnier dans le domaine de la mémoire et de l'apprentissage. Il en a déduit que l'apprentissage doit se faire au fil du temps et au cours de plusieurs sessions d'apprentissage. Lorsque nous sommes à l'école, on ne s'attend jamais à ce que nous maintenions de nouvelles connaissances après la première introduction. Les informations nous sont d'abord présentées, puis nous les mettons en pratique avec des conseils, puis nous les pratiquons nous-mêmes. Et même une fois que nous l'avons suffisamment bien apprise pour réussir un examen, l'information a tendance à être oubliée peu de temps après si nous n'utilisons pas régulièrement les connaissances que nous avons consacrées au temps et aux efforts nécessaires pour acquérir. Combien d'entre nous peuvent dire qu'ils se souviennent du français de leur lycée ?

Alors, comment pouvons-nous croire qu'une seule journée passée à regarder des diapositives et à écouter quelqu'un parler de sécurité conduirait les développeurs présents à coder de manière plus sécurisée ?

Les modèles de vulnérabilités récurrentes nous montrent que cela ne fonctionne tout simplement pas.

Comment parvenir à une immunité développementale sûre ?

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

Pour garantir la sécurité de vos applications, vous devez commencer par améliorer les compétences des développeurs pour qu'ils puissent écrire du code sécurisé. Dans le cas contraire, AppSec continuera à passer tout son temps à examiner tout le code pour détecter les failles de sécurité et à signaler les mêmes vulnérabilités récurrentes au développement, pour être rapidement corrigées sans aucune leçon. Et recommencez pour la prochaine version.

Réitérons donc.

Si vous travaillez en collaboration avec vos responsables du développement pour y parvenir, vous ne vous contenterez pas de mettre en œuvre un SDLC sécurisé et de cocher la case relative aux exigences de formation en matière de sécurité pour la conformité, vous aurez également un impact réel sur le processus de développement. Cerise sur le gâteau, AppSec ne rencontrera plus de vulnérabilités récurrentes et ne les signalera plus aux équipes de développement, et les développeurs passeront moins de temps à les corriger. Cela signifie qu'ils peuvent consacrer plus de temps à créer et à améliorer les logiciels incroyables qui améliorent notre monde.

Êtes-vous prêt à améliorer les compétences de votre équipe de développement ? Allez-y et réservez une démo avec nous.

Bien que cela puisse sembler contre-intuitif pour quiconque travaille en dehors du développement logiciel, de nombreux professionnels employés dans le domaine de la sécurité des applications au fil des ans ont occupé ces postes critiques avec peu ou pas d'expérience en programmation. Ces professionnels de la sécurité des applications font partie de l'équipe chargée de s'assurer qu'aucune vulnérabilité ne s'infiltre dans les applications qui sont devenues la pierre angulaire de nombreux secteurs et organisations. Pourtant, peu d'entre eux peuvent évaluer directement ou corriger le code eux-mêmes.

Au lieu d'avoir une formation en programmation, de nombreux professionnels de la sécurité abordent leurs rôles du point de vue des connaissances clés concernant les vecteurs d'attaque, les menaces, les exploits et les risques commerciaux ; ils ont une vision limitée du code. Bien que tous les experts de la sécurité des applications ne possèdent pas les mêmes compétences, une journée typique consiste pour beaucoup à travailler avec des réviseurs de code et des outils d'analyse pour s'assurer que les programmes et les systèmes sont sécurisés conformément aux normes organisationnelles ou aux cadres industriels et gouvernementaux pertinents. Ils rédigent ensuite des rapports sur leurs découvertes et renvoient des informations sur le vecteur d'attaque susceptible de déchiffrer le code. Il appartient ensuite aux développeurs d'apporter les correctifs nécessaires, même si cela perturbe le travail en cours.

Si la situation a évolué de cette façon, c'est parce que la logique qui a prévalu au fil des ans était que la tâche de protéger les réseaux et les applications était si vaste qu'il n'était pas logique de s'attendre à ce que tous les acteurs de la cybersécurité jouent tous les rôles. Des compétences approfondies en matière de codage ont été laissées aux développeurs, et peu d'importance a été accordée à la capacité d'écrire ou de modifier du code plus loin dans le pipeline de développement.

Cet état d'esprit évolue rapidement, ce qui représente une opportunité unique pour les développeurs de faire le saut lucratif et de réorienter leur carrière dans l'AppSec. Tous les développeurs ne voudront pas adopter ce que l'on appelle le côté obscur, et de nombreux développeurs n'ont pas une opinion particulièrement positive à l'égard des équipes AppSec. Mais pour ceux qui le font, il n'y a jamais eu de meilleur moment pour s'emparer de cette bague en laiton de plus en plus tentante.

DevSecOps est au cœur de presque tous les secteurs

L'un des principaux facteurs qui contribuent à augmenter la valeur des programmeurs et des développeurs soucieux de la sécurité dans toute organisation est la tendance quasi universelle à adopter des pratiques de développement plus agiles. comme DevSecOps. Lorsque le développement, la sécurité et les opérations sont combinés, la cybersécurité devient une responsabilité partagée intégrée au développement de nouveaux logiciels de bout en bout. Dans cet environnement, la capacité à coder est de plus en plus considérée comme un atout précieux à tous les niveaux, et cela est particulièrement vrai pour les ingénieurs qui comprennent également la sécurité de manière inhérente.

Un professionnel de la sécurité des applications qui comprend non seulement la cybersécurité à un niveau élevé, mais aussi le code qui fait que tout fonctionne, est intrinsèquement plus précieux pour toute organisation qu'une personne dont les connaissances sont concentrées sur la théorie. La capacité de découvrir et d'évaluer rapidement les vulnérabilités détectées dans le code, puis d'atténuer ces problèmes, est au cœur de la popularité de DevSecOps.

Les développeurs travaillant dans AppSec apportent également un autre avantage important à toute organisation qui les emploie. En venant du côté développement de la maison, ils peuvent facilement discuter avec les développeurs de la sécurité et des vulnérabilités. Cela permet également de devenir beaucoup plus facilement des entraîneurs pour les équipes de développement, les aidant ainsi à devenir de meilleurs codeurs. Au fil du temps, ils pourraient même être en mesure de supprimer la stigmatisation du « côté obscur » de l'AppSec et de contribuer à unifier les équipes chargées du développement logiciel au sein d'une organisation.

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

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

La pénurie de personnel est ressentie de manière aiguë presque partout. Dans un enquête récente menée par le Center for Strategic and International Studies, 82 % des décideurs informatiques ont déclaré que leur organisation souffrait d'une pénurie de compétences en cybersécurité, et 71 % ont déclaré que cette pénurie avait entraîné des dommages directs et mesurables pour leurs organisations. Pour mettre cette crise dans une perspective encore meilleure, le rapport a souligné que rien qu'aux États-Unis, il y avait plus de 520 000 emplois vacants dans le domaine de la cybersécurité en 2020, dans un domaine où seulement 940 000 personnes environ sont employées.

La pénurie de personnel en cybersécurité est une mauvaise nouvelle pour les organisations qui tentent de protéger leur infrastructure, leurs activités et leurs données contre un paysage de menaces de plus en plus dangereux. Mais c'est une bonne opportunité pour les développeurs qui souhaitent se familiariser avec AppSec et la sécurité. Il y a de fortes chances que des postes en cybersécurité et en AppSec soient disponibles presque partout. Et avec des positions en matière de cybersécurité qui occupent en moyenne 21 % de temps en plus pour occuper ces journées, les salaires augmentent dans tous les domaines.

Passer à AppSec

Il n'y a peut-être jamais de meilleur moment pour les développeurs de faire le saut lucratif vers le côté ensoleillé de la sécurité. Les développeurs soucieux de la sécurité ne sont plus considérés comme faisant partie d'une méthode de sécurité provisoire, mais jouent plutôt un rôle à part entière et respecté en tant que défenseurs de la cybersécurité. Cela est particulièrement vrai pour les organisations qui ont adopté DevSecOps et d'autres méthodologies de développement plus agiles. Et la pénurie de talents en cybersécurité signifie que des postes sont disponibles dans presque toutes les entreprises, agences gouvernementales ou organisations. Les personnes possédant les compétences requises peuvent choisir l'endroit où elles souhaitent travailler.

Le passage à AppSec ne convient peut-être pas à tout le monde et, bien entendu, la plupart des développeurs continueront à se concentrer sur la création de fonctionnalités exceptionnelles. Mais pour ceux qui envisagent de faire le saut, investir dans une formation à la sécurité afin d'améliorer leurs compétences de codage existantes peut ouvrir de nombreuses portes. Les meilleurs spécialistes de l'AppSec sont issus de l'ingénierie, car ils comprennent parfaitement la technologie et ont de l'empathie pour le sort de leurs collègues développeurs. DevSecOps signifie que tout le monde est désormais responsable de la sécurité de toute façon, alors pourquoi ne pas profiter de la pénurie de compétences critique actuelle pour faire avancer votre carrière dans la sécurité des applications ? Il n'y a jamais eu de meilleur moment pour prendre une décision positive pour vous-même, votre famille et votre carrière.

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)

L'importance des compétences des développeurs en matière de sécurité est soulignée dans le rapport Gartner Cool Vendors in Software Engineering 2022. Lisez le rapport complet ici.

Secure Code Warrior a été reconnu comme l'un des quatreDes fournisseurs renommés en génie logiciel : améliorer la productivité des développeurs', par Gartner. Selon Gartner, « la définition d'un vendeur cool est une petite entreprise proposant une technologie ou un service innovant, percutant ou intrigant ». Les trois éléments d'un Cool Vendor sont les suivants :

Innovant — Permet aux utilisateurs de faire des choses qu'ils ne pouvaient pas faire auparavant.

Percutant — A ou aura un impact commercial, et pas seulement sur la technologie en soi.

Intriguant — A suscité l'intérêt de Gartner au cours des six derniers mois.

Comme indiqué dans le rapport, « les ingénieurs logiciels ont du mal à naviguer dans des environnements de code complexes et à améliorer la sécurité des systèmes qu'ils développent tout en restant productifs. Ces fournisseurs intéressants proposent des solutions innovantes qui aident les leaders de l'ingénierie logicielle à améliorer la productivité des développeurs et à atténuer les risques de sécurité. »

En tant que seule société cotée à se concentrer sur la sécurité pilotée par les développeurs, cette reconnaissance témoigne de notre stratégie visant à fournir aux développeurs les compétences en matière de sécurité et les outils contextuels appropriés afin qu'ils puissent rapidement apprendre, développer et appliquer leurs compétences pour fournir du code sécurisé rapidement, afin d'améliorer la sécurité logicielle.

Alors que les vertus du virage vers la gauche sont vantées depuis un certain temps déjà, de nombreuses organisations ont encore du mal à garantir que la sécurité soit prise en compte au début du cycle de vie du développement logiciel. Notre récent « »Enquête sur l'état de la sécurité menée par les développeurs » a souligné que le manque de temps est le principal obstacle à surmonter lors de l'adoption de pratiques de codage sécurisées, comme en témoigne également ce récent rapport de Gartner. En raison de la pénurie importante d'ingénieurs qualifiés, de dépôts de code vastes et complexes et de plus de la moitié de la pile d'exécution composée de logiciels open source, les développeurs ont à peine le temps de gérer le code existant, sans parler de garantir sa sécurité.

Chez Secure Code Warrior, nos solutions répondent à la nécessité d'améliorer la productivité tout en garantissant la sécurité des logiciels. Bien qu'ils aient cité le manque de temps pour adopter des pratiques de codage sécurisées dans l'enquête susmentionnée, 76 % des personnes interrogées ont convenu qu'une bonne formation en matière de codage sécurisé permettrait améliorer la productivité avec moins de tickets de sécurité et des retouches à gérer. Lorsqu'elles disposent des compétences et des outils de sécurité appropriés, les équipes de développeurs peuvent facilement atténuer les risques et envoyer rapidement un code sécurisé et de qualité, doté de fonctionnalités innovantes.

Merci donc à Gartner pour cette reconnaissance, non seulement pour Secure Code Warrior, mais aussi pour avoir souligné le rôle important que les développeurs doués en sécurité peuvent jouer en matière de cybersécurité.
‍

Accédez au Gartner Cool Vendors en ingénierie logicielle : améliorer la productivité des développeurs signalez maintenant.

‍