Préparation

Cette section explique en détail comment préparer votre organisation au lancement et à la mise en œuvre d'un programme efficace de divulgation des failles. Vous y trouverez également des conseils pratiques pour combler les lacunes que vous avez identifiées.

Rechercher des bugs

Renforcer votre programme de sécurité existant avec des chercheurs en sécurité externes est un excellent moyen de détecter les problèmes complexes et d'obscurcir les failles. Cependant, l'utilisation d'un VDP pour identifier les problèmes de sécurité fondamentaux qui pourraient être découverts en interne est un gaspillage de ressources.

Gestion des composants

Pour identifier des bugs, le seul moyen de savoir par où commencer est de savoir par où commencer. Vous pouvez acheter une centaine d'outils de sécurité, mais cela ne change rien si les équipes mettent en place des applications, des systèmes et des services ad hoc à votre insu, en particulier si vous n'avez pas la possibilité de découvrir et d'effectuer des évaluations de sécurité sur ces éléments. Vérifiez auprès des personnes et des équipes chargées de l'aide à la mise en place des nouveaux systèmes, applications et services s'ils ont mis en place un processus permettant de créer et de maintenir un inventaire de ce qui est créé et de qui en est le propriétaire. S'il n'existe pas de processus actuel, c'est une excellente occasion de collaborer avec ces équipes pour en construire un. Pour identifier votre surface d'attaque, le mieux est de bien comprendre les ressources de votre organisation. Dans le cadre de ce processus, l'équipe de sécurité doit être impliquée dans le développement de la mise en œuvre d'une nouvelle infrastructure afin de proposer des examens de sécurité. Il est recommandé de disposer d'un vaste inventaire d'actifs et de propriétaires. Ce type d'inventaire est utile lors de l'application de nouveaux correctifs nécessitant l'arrêt temporaire de certains systèmes. Elle fournit une feuille de route des personnes ou des équipes à informer et des systèmes concernés. La mise en place d'un processus robuste de gestion des actifs garantit que les propriétaires sont identifiés plus tôt dans le processus, mis à jour régulièrement et que tous les systèmes de l'organisation fonctionnent comme prévu.

En plus de la gestion proactive des éléments, réfléchissez aux mesures réactives que vous pouvez également mettre en œuvre pour identifier les ressources qui appartiennent à votre organisation, mais qui ont échappé à vos processus standardisés de gestion des éléments. Il peut s'agir, par exemple, d'utiliser les mêmes processus de "reconnaissance" que ceux utilisés par les chercheurs en sécurité qui participent aux VDP et aux programmes de prime au bug. Par exemple, vous pouvez vous servir d'outils sans frais et Open Source qui analysent et énumèrent les plages d'adresses IP ou les domaines Web pouvant appartenir à votre organisation. Une recherche Google sur reconnaissance de primes de bug générera une variété de conseils et d'astuces pour vous aider à identifier les ressources de votre organisation que vous ignoriez.

Analyse des failles de base

Maintenant que vous disposez d'une base solide pour savoir où identifier les problèmes de sécurité, voyons comment procéder. Vous pouvez accéder à différents niveaux de profondeur en fonction des ressources de votre organisation, mais vous devez trouver un équilibre entre vos efforts de sécurité internes et la communauté de hackers externes via votre programme de divulgation des failles. Cet équilibre est différent pour chaque organisation, en fonction des ressources disponibles.

Choisissez vos outils

Il existe de nombreux outils différents pour vous aider à identifier les vulnérabilités. Certains outils d'analyse des failles sont disponibles sans frais, tandis que d'autres sont payants. Le choix des outils à utiliser dépend de vos besoins individuels.

• Les exigences de votre organisation
• Dans quelle mesure chaque outil répond-il à ces exigences ?
• Si les avantages de l'outil l'emportent sur les coûts (financiers et de mise en œuvre).

Vous pouvez utiliser ce modèle de configuration requise (OpenDocument .ods, Microsoft Excel .xlsx) pour évaluer divers outils en fonction de vos besoins. Le modèle inclut quelques exemples d'exigences, mais vous devez en discuter avec vos équipes chargées de la sécurité, de l'informatique et de l'ingénierie afin de définir les capacités requises. Avant de lancer un programme de divulgation des failles, vous devez au moins être en mesure d'effectuer des analyses des failles sur tous les éléments externes (tels que les sites Web, les API et les applications mobiles). Vous pourrez ainsi détecter et corriger les failles facilement visibles avant d'inviter des chercheurs en sécurité externes à effectuer des tests sur ces éléments et services.

Configuration de la recherche

Les analyses de failles automatisées peuvent détecter de nombreux problèmes, mais elles peuvent également produire des faux positifs. C'est pourquoi il est nécessaire de disposer de ressources pour valider les résultats avant de les partager avec les équipes concernées. Vous devez mettre en œuvre des processus pour vous assurer que les analyses sont exécutées régulièrement et que les résultats de ces analyses sont réellement pris en compte. Ce processus sera différent pour chaque organisation, mais vous devrez au minimum déterminer:

• Fréquence de recherche
  • Continue
  • Hebdomadaire
  • Une fois par mois
• Éléments analysés
• Identifiants
  • Analyses authentifiées et non authentifiées
  • Conseil: si vous n'analysez pas les données à l'aide d'identifiants, puis qu'un chercheur en sécurité effectue des tests avec ces identifiants lorsque vous démarrez votre VDP, vous risquez de rencontrer un pic de failles identifiées.
• Rôles et responsabilités
  • Identifier les membres de l'équipe responsables de l'exécution des analyses
  • Configurer une rotation si nécessaire
• Résultats de l'analyse
  • Vérifier les résultats d'analyse
  • Signalement des bugs liés aux failles vérifiées
  • Identifier les propriétaires chargés de corriger les bugs
  • Suivi auprès des propriétaires au sujet de la correction

Plus loin dans ce guide, nous verrons en détail comment vous assurer que les problèmes de sécurité identifiés sont résolus dans la section Corriger les bugs.

Processus d'examen de sécurité

Bien que l'analyse des failles soit un excellent moyen d'identifier de manière réactive les problèmes de sécurité dans votre organisation, la mise en œuvre de processus d'examen de la sécurité peut aider à éviter l'introduction de failles. Dans ce guide, le terme examen de sécurité désigne toute situation qui déclenche un examen manuel par un membre de votre équipe de sécurité. En règle générale, cela inclut le fait d'avoir le pouvoir de bloquer une modification si celle-ci est jugée trop risquée. Si votre équipe de sécurité n'est pas en mesure de bloquer les modifications risquées, vous devrez tout de même mettre en place des processus pour documenter le risque. Cela permet de s'assurer que la personne qui s'appuie sur le changement connaît le risque encouru et l'accepte de manière proactive.

Critères de l'examen de sécurité

Quand les examens de sécurité doivent-ils avoir lieu ? La création d'un ensemble de critères déclenchant un examen de sécurité permet de s'assurer que tout le monde est sur la même longueur d'onde. Vous trouverez ci-dessous quelques exemples de scénarios pouvant déclencher un examen de sécurité.

• Une nouvelle fonctionnalité liée aux données utilisateur sensibles est proposée
  • Une nouvelle fonctionnalité qui permet aux utilisateurs de partager leur position sur la carte
  • Demander aux utilisateurs des informations potentiellement sensibles, telles que l'adresse de leur domicile, leur date de naissance ou leur numéro de téléphone
• Des mises à jour importantes sont apportées aux fonctionnalités existantes.
  • Prendre des données utilisateur existantes et les utiliser d'une nouvelle manière à laquelle les utilisateurs ne s'attendraient peut-être pas, sans leur donner la possibilité de se désinscrire
  • Modifications apportées aux fonctionnalités liées à l'authentification, à l'autorisation et à la gestion des sessions
• Modifications apportées à l'environnement de production de l'entreprise
  • Les modifications de la configuration du réseau, en particulier celles pouvant entraîner une exposition des services en externe
  • Installation d'un nouveau logiciel qui gère les données utilisateur sensibles et qui, s'il est compromis, pourrait être utilisé indirectement pour accéder à ces données
  • Mettre en place de nouveaux systèmes ou services
• Interaction avec un nouveau fournisseur ou modification de votre façon de travailler avec un fournisseur existant
  • Intégrer un nouveau fournisseur qui gérera des données utilisateur sensibles
  • Modifications apportées à la façon dont vous travaillez avec un fournisseur existant qui entraîne la gestion des données utilisateur sensibles par le fournisseur

Cette liste n'est pas exhaustive, mais elle doit vous amener à réfléchir aux types de modifications nécessitant un examen de sécurité. Lorsque vous définissez les critères de ce qui nécessite ou non un examen de sécurité, discutez-en avec les principaux intervenants de l'entreprise pour vous assurer que:

• Les partenaires ont la possibilité d’examiner et de fournir leurs commentaires sur les critères
• Les partenaires acceptent les critères
• Les parties prenantes acceptent de demander de manière proactive des examens de sécurité

Documentez ces critères et expliquez comment demander un examen de sécurité (par exemple, en signalant un bug dans une file d'attente surveillée par l'équipe de sécurité) afin que votre organisation puisse suivre ce processus aussi facilement que possible.

Ressources pour l'examen de sécurité

Contrairement aux analyses automatisées, les examens de sécurité peuvent nécessiter davantage de ressources. Chaque équipe de sécurité dispose de peu de temps dans la journée pour accomplir une myriade de tâches. Vous devez donc estimer le nombre d'examens de sécurité qui peuvent être générés en fonction de vos critères. Si vous constatez que votre équipe est submergée et prend du retard, les personnes qui attendent le lancement de leurs fonctionnalités seront contrariées par l'équipe de sécurité. Cela peut entraîner un changement de culture dans l'organisation, et l'équipe de sécurité peut alors être considérée comme un obstacle et non comme un partenaire. Si le processus d'examen de la sécurité n'est pas efficace, de nombreux utilisateurs et équipes tenteront de le contourner complètement. Si les ressources sont limitées, envisagez d'assouplir vos critères de nécessité d'effectuer un examen de sécurité et soyez prêt à accepter un risque résiduel supplémentaire. Si des incidents se produisent en raison d'un manque de ressources pour effectuer des examens de sécurité, cela justifiera le besoin de ressources supplémentaires de sécurité.

Effectuer des examens de sécurité

Pour décider des examens de sécurité à effectuer et de la façon de les réaliser, vous avez besoin d'une file d'attente prioritaire à partir de laquelle extraire des données. Créez un moyen standardisé permettant aux autres membres de votre organisation de demander un examen de sécurité avec toutes les informations dont vous avez besoin pour les hiérarchiser en conséquence. Par exemple, prenons un questionnaire qui inclut des éléments tels que la nature de la modification, y compris un bref résumé de la modification et les types de données utilisateur qui peuvent être affectés. Vous pouvez catégoriser automatiquement les examens de sécurité potentiels selon qu'il s'agit de modifications à risque élevé, moyen ou faible, en fonction des réponses à ces questions. Si une modification présente un risque élevé, vous pouvez nécessiter un processus d'examen de sécurité plus approfondi. Si une modification présente un risque plus faible, vous pouvez peut-être mettre en œuvre un processus d'examen de sécurité plus léger pour réduire les ressources requises et accélérer le processus, ce qui contribue à améliorer l'activité de l'entreprise. Envisagez de mettre en place une rotation au sein de votre équipe pour être responsable de la gestion de la file d'attente des examens de sécurité, de la récupération des nouveaux examens de sécurité par les membres de votre équipe et du suivi de l'avancement des examens de sécurité existants. Le processus réel de l'examen de sécurité varie en fonction de ce qui est examiné. Par exemple, une nouvelle fonctionnalité de votre application mobile peut nécessiter qu'un ingénieur en sécurité examine le code et recherche des failles potentielles. Les nouveaux logiciels en cours d'installation peuvent nécessiter un examen pour s'assurer que le contrôle des accès est correctement configuré. Travailler avec des fournisseurs externes peut présenter un processus entièrement différent. Pour référence, lisez le questionnaire d'évaluation de la sécurité des fournisseurs de Google.

Corriger les bugs

Il est important de trouver les bugs, mais la sécurité ne s'améliore qu'une fois ces bugs corrigés. Il est bon de savoir quels risques existent pour votre organisation, mais il est préférable de les gérer efficacement.

Gestion des failles

Les failles proviennent de diverses ressources, y compris des efforts internes (par exemple, des analyses des failles et des examens de sécurité), des tests et des audits d'intrusion tiers, ou même des chercheurs en sécurité externes qui vous informent via des canaux d'assistance avant le lancement officiel de votre VDP. Votre organisation a besoin d'un moyen de catégoriser les failles nouvelles et existantes afin de s'assurer qu'elles sont communiquées aux bonnes personnes, hiérarchisées correctement et corrigées en temps opportun. Lorsque vous lancez votre VDP, un nouveau flux de failles entre dans vos processus de gestion des failles. La mise en place de processus robustes de gestion de ces failles vous permet de suivre l'évolution de la résolution des problèmes et de répondre aux demandes de mises à jour des chercheurs en sécurité externes. La possibilité de hiérarchiser rapidement une faille et de communiquer avec les participants au VDP au sujet du calendrier de résolution augmente l'engagement avec la communauté des chercheurs en sécurité, ainsi que la réputation de la sécurité de votre organisation. Les sections suivantes décrivent différents aspects de votre programme de gestion des failles que vous devez mettre en place avant de lancer votre VDP.

Établir des normes de gravité et des délais de résolution

La création d'un langage commun concernant la gravité des failles et les délais de résolution idéaux associés à chaque niveau de gravité facilite la définition des attentes standards avec votre organisation. Si chaque faille est traitée comme une urgence, votre organisation épuisera ses ressources et ressentira un ressentiment envers l'équipe de sécurité. Si chaque faille est considérée comme de faible priorité, elle ne sera jamais corrigée et le risque de violation augmente. Chaque organisation possède des ressources limitées. Vous devez donc établir un classement par niveau de gravité. Ce classement fournit des critères qui aident votre organisation à comprendre la gravité d'une faille et les délais de résolution attendus pour chaque gravité. Rédigez un ensemble de consignes relatives au niveau de gravité et partagez-le avec les principaux partenaires de votre organisation pour recueillir leurs commentaires. Par exemple, si l'équipe d'ingénierie participe à l'élaboration de vos normes de gravité, elle sera plus susceptible d'accepter ces normes et de les respecter lorsqu'il sera temps de corriger une faille dans un délai spécifié. Ces consignes peuvent varier en fonction des risques propres à votre entreprise. Vous pouvez envisager un exercice de modélisation des menaces pour identifier les menaces les plus probables et ayant un impact sur votre organisation, et inclure des exemples de problèmes relevant de chaque catégorie de gravité. Vous trouverez ci-dessous un exemple de normes de gravité et de délais de résolution pour un organisme financier.

Gravité	Description	Calendrier de résolution	Exemple(s)
Critique	Problèmes qui constituent une menace imminente pour nos utilisateurs ou notre entreprise.	Propriétaire : un propriétaire principal chargé de s'assurer que la faille est corrigée doit être identifié dans les huit heures. Appelez et consultez les ressources selon les besoins, même en dehors des heures de travail normales. Solution:le problème lui-même doit être résolu ou, au moins, atténué les risques, dès que possible ou au plus dans un délai de trois jours ouvrés.	Compromis d'une base de données de production incluant les documents financiers de tous les utilisateurs. Un pirate informatique accède à des secrets commerciaux, tels que nos algorithmes d'investissement propriétaires. Incident actif impliquant un pirate informatique ayant accès à notre réseau interne ou à des systèmes de production sensibles.
Élevé	problèmes qui, s'ils étaient exploités, pourraient causer des dommages considérables.	Propriétaire:un propriétaire principal doit être identifié dans un délai d'un jour ouvré. Solution:sous 10 jours ouvrés (environ deux semaines).	Failles pouvant entraîner l'accès à des données utilisateur ou à des fonctionnalités sensibles (par exemple, possibilité pour n'importe quel utilisateur de voler les fonds d'un autre utilisateur).
Moyenne	Problèmes plus difficiles à exploiter ou qui ne causent pas de dommages directs	Propriétaire:un propriétaire principal doit être identifié dans un délai de cinq jours ouvrés. Solution:dans un délai de 20 à 40 jours ouvrés (environ 1 à 2 mois).	Problèmes validés identifiés par des analyseurs automatisés, tels que des correctifs pour les mises à jour de sécurité sans failles connues. Problèmes de divulgation d'informations susceptibles de faciliter de nouvelles attaques. Problèmes de limitation du débit qui pourraient potentiellement être exploités (par exemple, possibilité de deviner en continu le mot de passe d'un utilisateur).
Faibles	Problèmes ayant un impact minimal ; principalement utilisé pour consigner les problèmes connus.	Aucune exigence pour trouver un propriétaire ou corriger dans un délai spécifié.	Divulgation d'informations ne présentant pas de risque probable, mais lorsque les informations n'ont pas besoin d'être accessibles en externe

Toilettage d'insectes

Nous ne parlons pas ici de coupes de cheveux, mais de s'assurer que les bugs sont correctement formatés afin qu'ils puissent être facilement corrigés. En vous appuyant sur le tableau précédent, établissez vos propres définitions de niveau de gravité. Ces définitions permettent de classer les bugs selon différents niveaux de gravité et de les communiquer aux propriétaires.

En plus d'attribuer une gravité à chaque faille, vous devez vous assurer que vos bugs sont dans un format standard qui facilite la réception des équipes à traiter. Les failles intègrent vos processus de gestion des failles dans divers formats (tels que les résultats d'analyse automatisés ou les bilans manuels issus d'examens de sécurité). En prenant le temps de convertir chaque faille dans un format standard, vous augmentez les chances que l'équipe destinataire soit en mesure de comprendre et de résoudre rapidement le problème.

Ce format ou modèle peut varier en fonction de votre organisation et des informations les plus pertinentes pour aider les propriétaires à corriger les bugs qui leur sont attribués. Voici un exemple de modèle que vous pouvez utiliser. Vous pourrez réutiliser ce modèle ultérieurement lorsque vous créerez le formulaire d'envoi de votre programme de divulgation des failles à l'intention des chercheurs.

Titre : <description du problème en une ligne : généralement le type de faille et quel élément/service/etc. est affecté ; éventuellement par rapport à la gravité ou à un champ de gravité dans votre suivi des problèmes> Résumé : <brève description de la faille et son importance> Reproduction : <instructions détaillées pour atténuer l'impact de cette faille, ou comment expliquer l'impact de cette faille, ou comment expliquer l'impact de cette faille, ou comment expliquer l'impact de cette faille, ou comment expliquer l'impact de cette faille

Voici un exemple de faille potentielle de gravité élevée:

Title: [HIGH] Référence d'objet direct non sécurisée (IDOR) dans les pages de profil Résumé: un IDOR a été détecté dans la fonctionnalité des pages de profil de notre application qui permettrait à tout utilisateur d'obtenir un accès non autorisé pour afficher et modifier le profil d'un autre utilisateur, y compris son nom complet, son adresse, son numéro de téléphone et sa date de naissance. Nous avons examiné les journaux et ce problème ne semble pas encore avoir été exploité. Ce problème a été détecté en interne. Étapes de reproduction:

1. Configurez un proxy (par exemple, la suite Burp) pour intercepter le trafic sur un appareil mobile sur lequel l'application est installée.
2. Accédez à votre page de profil et interceptez la requête HTTP associée.
3. Remplacez profileID=## par profileID=000000 (il s'agit d'un utilisateur test) et envoyez la requête HTTP.
4. L'application affiche le profil de l'utilisateur 000000. Vous pouvez alors consulter et modifier ses informations.

Scénario d'attaque / impact:tout utilisateur peut exploiter cette faille pour afficher et modifier le profil d'un autre utilisateur. Dans le pire des cas, un pirate informatique pourrait automatiser le processus de récupération des informations de profil de chaque utilisateur dans l'ensemble de notre système. Bien que nous ne soyons pas encore convaincus que cela ait été exploité, il est important que nous la traitions comme un problème standard de gravité élevée. Si nous constatons des preuves d'exploitation, la gravité est susceptible de s'aggraver. Procédure de résolution des problèmes:implémentez des vérifications côté serveur pour vous assurer que l'utilisateur à l'origine de la requête doit être autorisé à afficher/modifier le profil demandé via la valeur de profileID. Par exemple, si Alice est connectée et possède l'ID de profil 123456, mais qu'Alice a demandé l'ID de profil 333444, l'utilisateur devrait voir une erreur et cette tentative d'accès au profil d'un autre utilisateur devrait être consignée. Pour en savoir plus sur IDOR et découvrir comment le résoudre, veuillez consulter les documents de l'OWASP sur ce bug.

Vous pouvez économiser du temps et des efforts manuels en trouvant des moyens d'automatiser la conversion des failles provenant de diverses sources dans votre format standard. À mesure que vous créez des failles, vous pouvez rencontrer des thèmes communs dans les étapes de résolution. Au-delà de votre modèle de format de bug générique, vous pouvez créer des modèles supplémentaires pour les types de failles courants.

Recherche de propriétaires...

L'un des aspects les plus difficiles de la gestion des failles consiste peut-être à identifier les propriétaires pour les aider à corriger les bugs et à obtenir leur adhésion pour dédier des ressources à la correction des bugs dans les délais. Si vous avez mis en place des processus de gestion des éléments, cette opération est un peu plus facile. Si ce n'est pas le cas, cela peut être une motivation pour le faire. Selon la taille de votre organisation, trouver un propriétaire peut être assez simple, voire incroyablement complexe. À mesure que votre organisation se développe, il est de plus en plus nécessaire de déterminer qui est responsable de la résolution des nouveaux problèmes de sécurité découverts. Envisagez de mettre en œuvre une rotation opérationnelle des équipes. Les collaborateurs de service sont chargés d'examiner les failles non attribuées, de rechercher les propriétaires et de hiérarchiser les priorités en fonction de leur gravité. Même si vous êtes en mesure d'identifier le responsable de la correction d'une faille et de l'affecter au bug, vous devez également le persuader de consacrer du temps à la correction. Cette approche peut varier selon l'équipe ou l'individu et les autres éléments sur lesquels ils travaillent. Si vous avez réussi à obtenir l'adhésion de votre organisation concernant les normes de gravité et les délais de résolution, vous pouvez vous y référer, mais il faut parfois persuader quelqu'un de corriger un bug. Voici quelques conseils généraux pour corriger les failles:

• Expliquer pourquoi: lorsqu'une faille se voit attribuer une faille à corriger, il s'agit généralement d'un travail inattendu. Expliquez pourquoi il est important de résoudre ce problème dans les meilleurs délais (par exemple, en vous appuyant sur le scénario d'attaque / d'impact) et assurez-vous que le propriétaire en a compris le problème.
• Recueillez des informations contextuelles: dans certains cas, une seule personne dispose des connaissances nécessaires pour corriger un bug et peut se charger d'autres tâches. Prenez le temps de les découvrir, car il est possible que les autres tâches soient plus importantes que la correction de cette faille à court terme. Faire preuve d'empathie et de flexibilité concernant les délais de correction vous aidera à gagner de la bonne volonté et à renforcer votre relation avec les personnes dont vous avez besoin pour corriger les failles. Veillez simplement à ne pas accorder trop de marge de manœuvre, sinon votre organisation ne prendra pas vos délais de résolution au sérieux.
• Expliquez comment:même si vous incluez des conseils de résolution dans le bug, le propriétaire de la résolution du problème peut ne pas comprendre ou avoir besoin d'aide pour apprendre à corriger le bug. S'ils ont besoin d'aide pour trouver une solution, aidez-les à le faire. Le simple fait de signaler des bugs aux propriétaires sans les aider nuira à la relation de l'organisation avec l'équipe de sécurité. En aidant les autres autant que possible, vous leur donnerez les moyens de corriger les vulnérabilités présentes et futures, ainsi que d'enseigner aux autres.
• Adaptez votre demande: différentes équipes et personnes peuvent disposer de processus existants pour accepter et hiérarchiser les requêtes de travail entrantes. Certaines équipes peuvent souhaiter que toutes les demandes entrantes passent par leurs responsables. D'autres souhaiteront que les demandes d'aide soient envoyées dans un format standard. Certains ne travailleront que sur ce qui a été prédéfini dans un sprint. Quoi qu'il en soit, prendre plus de temps pour adapter votre demande au format que l'équipe ou la personne utilise habituellement pour accepter les demandes d'aide augmentera la probabilité que votre demande soit traitée en priorité et traitée.
• Escalader en dernier recours: si vous avez essayé toutes les solutions ci-dessus et que la personne ou l'équipe chargée de corriger une faille ne prend pas le temps de résoudre un problème de sécurité grave, envisagez de faire remonter le problème si nécessaire. Il doit toujours s'agir d'un dernier recours, car cela peut nuire à votre relation avec la personne ou l'équipe en question.

Analyse des causes fondamentales

En plus de détecter et de corriger les failles individuelles, l'analyse des causes fondamentales (RCA) peut vous aider à identifier et à résoudre les problèmes de sécurité systémiques. Les ressources étant limitées, vous pouvez être tenté de passer cette étape. Toutefois, consacrer du temps à l'analyse des tendances de vos données sur les failles, ainsi qu'à examiner plus en détail les bugs critiques et de gravité élevée, vous pouvez gagner du temps et réduire les risques à long terme. Par exemple, supposons que vous remarquiez que le même type de faille (par exemple, la redirection d'intent) apparaît encore et encore dans votre application. Vous décidez de parler aux équipes qui introduisent cette faille dans votre application et que la grande majorité d'entre elles ne comprennent pas ce qu'est la redirection d'intent, pourquoi elle est importante ou comment la prévenir. Vous préparez une présentation et un guide pour informer les développeurs de votre organisation de cette faille. Cette faille ne disparaîtra probablement pas complètement, mais sa fréquence d'apparition diminuera probablement. Lorsque vous lancez votre VDP, chaque faille qui vous est signalée par un tiers est un élément qui a échappé à vos processus de sécurité internes existants. L'analyse de données sur les bugs de votre VDP vous permettra de mieux comprendre comment améliorer systématiquement votre programme de sécurité.

Détection et réponse

Le terme "détection et réponse" fait référence à l'ensemble des outils et processus que vous avez mis en place pour détecter des attaques potentielles contre votre organisation et y répondre. Il peut s'agir de solutions achetées ou développées en interne qui analysent les données afin d'identifier les comportements suspects. Par exemple, dans la section Grooming Bugs (Bugs de manipulation), nous avons parlé de la journalisation chaque fois qu'un utilisateur tente d'obtenir un accès non autorisé au profil d'un autre utilisateur. Un signal ou une alerte peut être généré si vous remarquez qu'un utilisateur génère un grand nombre de tentatives infructueuses d'accès aux profils d'autres utilisateurs sur une courte période. Vous pouvez même automatiser le processus permettant d'empêcher cet utilisateur d'accéder à vos services pendant une certaine période, ou indéfiniment jusqu'à ce que la situation puisse être examinée et restaurer manuellement l'accès. Si vous ne disposez pas encore de mécanismes de détection et de réponse, envisagez de travailler avec un consultant expert qui vous aidera à créer un programme d'investigation numérique et de gestion des incidents (DFIR) pour votre organisation. Si vous avez déjà mis en place des mécanismes de détection et de réponse, vous devez tenir compte des conséquences du fait que cinq, dix, voire cent chercheurs en sécurité effectuent des tests sur vos surfaces d'attaque Web. Cela peut avoir un impact important sur tous les systèmes de détection et de prévention des intrusions (IDS/IPS) que vous avez mis en place.

Les risques potentiels comprennent:

• Surcharge d'alertes:avalanche d'alertes ou de signaux ressemblant à des attaques malveillantes, mais il s'agit en réalité de tests normaux et approuvés, effectués par des chercheurs en sécurité qui participent à votre VDP. Un tel bruit peut être généré qu'il devient difficile de distinguer les attaques réelles des tests de sécurité légitimes.
• Fausses alertes de gestion d'incidents : si vous avez mis en place des processus sur cette page à 2h du matin le samedi, ils ne seront pas ravis de se réveiller et d'enquêter sur une violation potentielle qui n'était en fait qu'un chercheur en sécurité effectuant des tests légitimes.
• Chercheurs en sécurité bloquants:si vous avez mis en place des IPS (systèmes de prévention des intrusions) agressifs, vous risquez de bloquer l'adresse IP d'un chercheur en sécurité qui tente d'effectuer des analyses, des tests manuels, etc. pour identifier les failles et vous les signaler. Surtout dans le cas d'un VDP, si un chercheur en sécurité est bloqué après cinq minutes de tests, il peut perdre son intérêt et se concentrer plutôt sur le programme d'une autre organisation. Cela peut entraîner un manque global d'engagement de la part des chercheurs en sécurité envers votre programme, ce qui augmente le risque que des failles restent non découvertes (et donc inconnues de votre organisation). Bien que vous ne souhaitiez peut-être pas restreindre votre IPS lui-même, il existe d'autres mesures que vous pouvez prendre pour atténuer le risque de désengager les chercheurs.

La manière de gérer ces risques dépend en grande partie de l'approche que vous souhaitez adopter par rapport à la collaboration avec des chercheurs en sécurité externes. Si vous souhaitez un style de test plus boîte noire qui simule des attaques réelles, vous pouvez ne rien faire. Dans ce cas, le trafic du chercheur générera des alertes, et votre équipe pourra prendre des mesures pour enquêter et répondre en conséquence. Cela aidera votre équipe à s'entraîner à répondre à ce qui ressemble à de véritables attaques, mais peut diminuer l'engagement des chercheurs en sécurité, en particulier s'ils ne peuvent pas effectuer de tests. Elle peut également passer à côté d'une attaque réelle alors que vous passez du temps à examiner des tests légitimes. Si vous souhaitez adopter une approche davantage basée sur des cases grises, vous pouvez envisager de collaborer avec des chercheurs en sécurité pour identifier eux-mêmes leur trafic de test d'une manière ou d'une autre. Cela vous permettra de mettre sur liste blanche ou d'exclure le trafic des tests et des alertes qui en résultent. Votre équipe sera en mesure de mieux distinguer les attaques réelles des tests approuvés, et les chercheurs seront en mesure de trouver et de vous signaler des failles sans être entravés par vos systèmes de prévention des intrusions. Certaines organisations demandent aux chercheurs en sécurité de soumettre un formulaire pour demander un identifiant unique qui peut être associé aux en-têtes des requêtes qu'ils génèrent. Cela permet à l'organisation d'ajouter le trafic du chercheur à la liste blanche et de déterminer si celui-ci commence à dépasser le champ d'application des tests convenu. Si cela se produit, vous pouvez contacter le chercheur et lui demander de patienter jusqu'à ce que vous puissiez travailler ensemble sur un plan de test.