Bug Bounty ? Un programme de Bug Bounty est une initiative de crowdsourcing dans laquelle des pirates informatiques éthiques sont récompensés par des entreprises pour avoir trouvé et signalé des vulnérabilités.

Dans le paysage en constante évolution de la cybersécurité, les secteurs bancaire et public ont de plus en plus adhéré à diverses initiatives de Divulgation des Vulnérabilités. En se penchant sur le rapport 2021 de Wavestone, il est essentiel de comprendre les trois approches clés qui ont façonné la recherche précédente :

• Canaux de Signalement des Vulnérabilités (CSVs) : Il s’agit de la première étape d’un programme de bug bounty, d’une page web fournissant des instructions de base aux pirates informatiques et d’un canal de signalement.
• Politiques de Divulgation des Vulnérabilités (PDVs) : Ces politiques décrivent la manière dont une organisation reçoit les vulnérabilités divulguées par des parties externes et y répond. L’existence d’un PDV implique la présence d’un CSV dans son cadre.
• Programmes de Bug Bounty (PBBs) : Forme avancée des PDVs, et parallèlement à la politique, les PBBs offrent des récompenses financières pour le signalement des failles de sécurité, incitant ainsi à la découverte et à la divulgation des problèmes de sécurité. Il peut être accessible à tout le monde (public) ou à un petit nombre de pirates informatiques (privé).

Ces initiatives ne se limitent pas à des procédures, elles apportent des avantages significatifs. Elles permettent de détecter plus rapidement les vulnérabilités, favorisent une culture de la transparence et de l’amélioration continue, et tirent parti de l’expertise de la communauté mondiale de la cybersécurité pour renforcer les mesures de sécurité. En encourageant le piratage informatique éthique, les organisations peuvent garder une longueur d’avance sur les menaces potentielles et protéger plus efficacement leurs données et leurs systèmes.

Présentation de la Recherche

Cette étude, qui s’appuie sur des données allant jusqu’au troisième trimestre 2023, examine l’adoption et l’impact de ces mesures de cybersécurité dans les secteurs bancaire et public. La méthodologie de recherche implique une analyse approfondie des tendances actuelles, des paysages réglementaires et de l’efficacité des PBBs dans le renforcement de la sécurité numérique.

Aperçu du secteur bancaire

Le secteur bancaire, qui constitue l’épine dorsale du système financier mondial, a fait preuve d’une transformation remarquable dans son approche de la cybersécurité. L’analyse des 100 premières banques mondiales entre 2020 et 2023 révèle des évolutions significatives dans l’adoption de mesures de cybersécurité. Voici quelques éléments clés :

• Augmentation des CSVs et PDVs: En 2023, 34% des 100 plus grandes banques mondiales avaient au moins un CSV actif et 26% avaient mis en place un PDV.
• Tendances géographiques 

• • Dominance en Europe et en Amérique du Nord : Les banques situées aux Etats-Unis et dans les pays Européens ont affiché un taux d’adoption plus élevés des CSVs et PDVs. En approfondissant l’analyse par continent, la Figure 1 montre que l’Amérique du Nord, avec 72% de banques mettant en œuvre des CSVs contre 49% en Europe, reste en tête pour l’adoption d’initiatives de cybersécurité.

• • L’Asie et l’Amérique du Sud : Bien qu’elles gèrent 46% des actifs de 43 banques mondiales, seulement une a implémenté un PDV, ce qui indique un rythme d’adoption plus lent pour ces programmes.

• Stagnation du nombre de PBBs publics : Les données ont mis en lumière une stagnation du nombre de PBBs publics, avec seulement 5% des banques opérant un PBB public en 2023. Cela suggère une approche prudente concernant l’invitation publique à divulguer les vulnérabilités.
• Pays remarquables : Les Pays-Bas se distinguent avec un taux d’adoption de 100% des programmes de divulgation des vulnérabilités parmi leurs principales banques. Cela témoigne d’un engagement national fort en faveur de la cybersécurité.
• Utilisation des plateformes : La plupart des banques ont préféré développer des programmes de divulgation des vulnérabilités internes, quelques-unes ayant opté pour des plateformes externes telles que BugCrowd, Snack et HackerOne. 

Luxembourg : Etude de cas

L’étude de cas du secteur bancaire luxembourgeois, qui porte sur 5 banques de détail et 17 banques privées, donne un aperçu des pratiques actuelles en matière de cybersécurité :

• Un taux d’adoption globalement faible : Seule une minorité des 22 banques a adopté des programmes structurés de cybersécurité. Plus précisément, seules 7 banques sur 22 ont mis en place des CSVs, dont seulement 5 banques qui ont adopté des PDVs et seulement 1 banque qui a mis en œuvre un PBB public.
• Intérêt des pirates informatiques externes : Certaines banques ont reçu des rapports externes par l’intermédiaire d’Opensugsountv.org, démontrant l’intérêt des pirates informatiques à montrer les vulnérabilités, malgré l’absence d’un programme actif formel.
• Tendance générale : Le secteur montre qu’il est nécessaire d’adopter de manière plus cohérente des stratégies structurées en matière de cybersécurité, surtout si l’on considère les enjeux élevés de la banque privée.

Analyse et réglementation du secteur public

L’approche du secteur public en matière de cybersécurité, en particulier au sein de l’UE27, présente un paysage complexe et évolutif. Les principaux aspects de cette analyse sont les suivants :

• Croissance de la divulgation coordonnée des vulnérabilités (DCV) : Par rapport à l’étude 2021 de l’ENISA, il y a eu une augmentation significative de l’adoption de politiques actives de divulgation des vulnérabilités. Le nombre d’États membres de l’UE27 ayant adopté une telle politique est passé de 4 à 11, ce qui témoigne de l’importance croissante accordée aux stratégies structurées en matière de cybersécurité.
• La position proactive du Royaume-Uni : Bien qu’il ne fasse pas partie de l’UE27, le Royaume-Uni a déployé des efforts remarquables pour mettre en œuvre des mesures de prévention actives. Cela souligne l’engagement du Royaume-Uni à maintenir des normes de cybersécurité solides.

Conclusion et perspectives

À mesure que le monde numérique progresse, l’importance des programmes de divulgation des vulnérabilités devient de plus en plus évidente. Ils ne représentent pas seulement une tendance, mais un changement fondamental dans la manière dont les organisations abordent la cybersécurité :

• L’essor de la divulgation des vulnérabilités : Domaine dynamique et en pleine expansion, ces programmes deviennent essentiels dans les secteurs bancaire et public.
• L’élan réglementaire européen : Avec la directive NIS2 de l’UE et les législations à venir comme la loi sur la cyberrésilience (CRA), il y a une forte pression pour les politiques nationales de DCV et les PDVs/PBBs des organisations.

Chez Wavestone, nous comprenons l’importance de prendre de l’avance dans ce scénario en évolution. Nous sommes là pour vous aider à naviguer efficacement dans ces changements. N’hésitez pas à nous contacter pour obtenir des conseils d’experts, afin de renforcer votre position en matière de cybersécurité.

Cet article Bug Bounty: Observations et benchmark sur les secteurs bancaire et public 2024 est apparu en premier sur RiskInsight.

Afin de lutter contre cette menace croissante sur un pied d’égalité, les équipes de réponse aux incidents – centres d’opérations de sécurité (SOC) et équipes de réponse aux incidents de sécurité informatique (CSIRT) – peuvent bénéficier d’un large éventail d’outils de sécurité automatisés. Les plates-formes SOAR (Security Orchestration, Automation and Response) attirent alors progressivement l’attention. Ces outils combinent des capacités de réponse aux incidents, d’orchestration et d’automatisation, ainsi que des capacités de gestion de la plate-forme de renseignement sur les menaces.

Malgré d’importants avantages accordés aux SOC et CSIRT, l’introduction d’un outil automatisé au sein des processus de réponse aux incidents existants reste complexe. Les plateformes SOAR présentent ainsi de nouveaux défis pour les équipes, notamment définir quelles tâches et décisions nécessitent une automatisation ou au contraire une expertise humaine.

Cet article vise à présenter une vue d’ensemble des plateformes SOAR en exposant les bonnes pratiques et recommandations sur la manière de répondre aux défis rencontrés par des équipes de réponse aux incidents utilisant ces solutions. Dans un premier temps, il décompose les utilisations potentielles des plates-formes SOAR en support sur l’ensemble des phases de réponse aux incidents. Dans un second temps, il approfondit certaines des considérations et des décisions que les équipes doivent prendre, offrant également des recommandations concrètes. Enfin, il compare brièvement le rôle des humains aux plates-formes améliorées par l’IA.

Prise en charge du processus de réponse aux incidents

Rassemblant l’ensemble des outils de sécurité, une plate-forme SOAR fonctionne à la manière d’un chef d’orchestre de l’écosystème de sécurité au sein d’une organisation, rationalisant le processus de réponse aux incidents. En effet, celle-ci peut soutenir et faciliter l’intégralité des phases clés de la réponse à l’incident, y compris le triage et la préqualification, l’enquête et l’analyse, ainsi que la dernière intervention et la correction.

Figure 1 : Vue d’ensemble du modèle d’intégration SOAR

Lors de la phase de triage et de préqualification, une plate-forme SOAR peut collecter des alertes provenant d’outils spécialisés de détection d’incidents, tels que les outils de gestion des informations et des événements de sécurité (SIEM). Bien qu’il s’agisse d’une activité bien établie et gérée par des outils robustes, deux problèmes majeurs demeurent ; la détection des faux positifs et la hiérarchisation des menaces sur la base d’informations contextuelles.

C’est au croisement de ces deux problématiques que les plates-formes SOAR peuvent être utiles, en enrichissant automatiquement les incidents, en filtrant les faux positifs, puis en mettant en évidence les incidents de sécurité critiques.

Les plateformes SOAR peuvent être alimentées par de nombreuses données issues de sources à la fois internes et externes. En effet, les indicateurs de compromission (IoC) pertinents peuvent être automatiquement intégrés à partir de sources fiables, telles que les fournisseurs de renseignements sur les cybermenaces (CTI) offrant des données hautement personnalisées issues de violations récentes survenues à des organisations similaires. D’autre part, les connaissances internes peuvent également être ingérées, en s’appuyant sur des résultats prédéfinis de classification des actifs ou d’analyses d’impact sur les entreprises (BIA) lisibles par machine. Cela permet ainsi aux analystes de gagner du temps en identifiant directement les incidents critiques et de disposer de toutes les informations nécessaires pour se concentrer sur la réponse aux incidents.

Lors de la phase d’investigation et de qualification des incidents, un CSIRT peut bénéficier du support SOAR en automatisant la gestion des cas d’utilisation de base. Alors que la première phase concernait des actions plus automatisées déclenchées par des alertes systèmes, par exemple l’enrichissement CTI basé sur des alertes SIEM, dans la phase d’enquête, la valeur ajoutée d’une plate-forme SOAR consiste principalement à soutenir l’analyse de l’équipe. Par exemple, lorsqu’un e-mail de phishing est signalé, la plateforme SOAR peut faciliter la collecte des informations nécessaires pour effectuer l’enquête et la qualification de l’incident, le rendant ainsi plus efficace. Cependant, l’évaluation de l’expert peut difficilement être automatisée pour des tâches plus complexes, telles que l’analyse approfondie et la qualification d’incidents complexes.

La phase de réponse et de correction reste la plus compliquée à automatiser, en raison à la fois de la nature des actions requises et du risque d’impact négatif sur l’entreprise si une correction est mal exécutée. L’automatisation d’une action de réponse doit permettre de capitaliser sur les gains d’efficacité, tout en tenant compte de l’évaluation coûts-bénéfices. 

Les plateformes SOAR peuvent donc considérablement faciliter le travail des analystes en cybersécurité, qui n’ont plus à traiter chaque incident manuellement d’outil en outil à chaque étape du processus de réponse aux incidents, et s’appuient plutôt sur des tâches automatisées mêlant différents outils de sécurité.

Après avoir vu différentes utilisations possibles des plateformes SOAR, il est intéressant de s’interroger de quelle manière choisir ce qu’il faut automatiser.

Décider quand automatiser en fonction du principe d’impact à faible regret

Pour chaque tâche de réponse à incident (IR), il existe trois approches différentes pour les plates-formes SOAR :

• Automatisation complète,
• Semi-automatisation,
• Pas d’automatisation.

Dans les cas d’automatisation complète, plusieurs étapes sont prédéfinies et automatisées en séquence sur la base de déclencheurs prédéfinis ou d’une activation manuelle. Des cas d’utilisation simples, comme les e-mails de phishing mentionnés précédemment, peuvent s’appuyer sur une automatisation complète et offrir des avantages substantiels pour minimiser les tâches longues et répétitives.

Dans les cas de semi-automatisation, certaines étapes – par exemple l’analyse initiale, la collecte de preuves ou l’enrichissement de l’information – sont automatisées afin de permettre à l’analyste de choisir le meilleur plan d’action. Cela pourrait être l’utilisation la plus courante de la plate-forme SOAR à l’heure actuelle.

Enfin, certaines situations ne permettent tout simplement pas l’automatisation et continueront d’être requises et exécutées par des opérateurs humains.

Alors que les équipes IR explorent les fonctionnalités et le potentiel des plates-formes SOAR, il est courant de se demander comment choisir quels cas d’utilisation peuvent et doivent être automatisés. Outre une évaluation de faisabilité, un facteur fondamental à adopter est le principe de l’impact à faible regret. Étant donné que la sécurité est toujours une fonction support des objectifs métiers, une analyse minutieuse des risques est nécessaire lorsque la possibilité d’affecter les services métiers existe. Une évaluation des avantages par rapport au regret encouru amène les organisations à changer leur perspective sur le problème en leur faisant choisir quand certaines actions peuvent être automatisées au lieu de savoir si elles peuvent être automatisées.

Afin de fournir une image plus sophistiquée et réaliste, deux observations s’imposent. Tout d’abord, ce choix est généralement non binaire (par exemple, regret élevé vs regret faible), car il devrait y avoir des niveaux croissants de risques et une confiance raisonnable en fonction de l’appétit pour le risque d’une organisation. Le regret est mieux quantifié sur une échelle. Deuxièmement, une telle analyse coûts-avantages est nécessairement contextuelle, ce qui signifie qu’elle doit tenir compte des conditions situationnelles dans lesquelles elle est effectuée. Pendant une crise en cours, les actions automatisées peuvent devenir plus ou moins attrayantes, compte tenu de l’évolution du calcul des risques.

Concrètement, les actions ayant très peu de chance de perturber les opérations métiers doivent être considérées comme des actions à faible regret, permettant une plus grande automatisation. Les actions susceptibles de provoquer des perturbations généralisées ou percutantes lorsqu’elles sont mal exécutées peuvent être évaluées comme des actions de regret moyen, nécessitant une confirmation humaine pour terminer le flux de travail. Enfin, les actions qui perturberaient les activités métiers d’une manière inacceptable (par exemple, la perturbation d’actifs hautement critiques) sont considérées comme des actions à grand regret, décourageant l’automatisation. Néanmoins, dans des circonstances particulières, ce barème peut être révisé et adapté.

Adopter une approche progressive

Une fois les concepts de base des solutions SOAR définis, les équipes IR sont confrontées à un autre défi majeur lié à la conduite du changement. Le passage de playbooks manuels à des workflows automatisés implique un processus fastidieux qui nécessite une hiérarchisation minutieuse. Un degré croissant d’automatisation peut être atteint grâce à une approche progressive et progressive.

Les tâches simples, chronophages et présentant un faible risque de regret peuvent être automatisées en priorité, réduisant la charge de travail à faible valeur ajoutée des analystes IR et augmentant leur efficacité. Cela peut être mis en place rapidement, compte tenu de la faisabilité technique de telles actions (ex : API existantes). En outre, la standardisation des tâches peut accélérer les étapes d’automatisation ultérieures en les rendant réutilisables dans différents playbooks ou branches. En effet, il est préférable de commencer à automatiser les branches des playbooks les plus simples, comme par exemple effacer les faux positifs, avant d’étendre l’automatisation à l’ensemble du playbook où toutes les possibilités d’alerte doivent être envisagées.

L’IA au service des activités humaines

Certaines solutions SOAR s’appuient sur l’intelligence artificielle (IA), grâce à laquelle un modèle d’apprentissage automatique (ML) peut être formé sur des données spécifiques qui lui sont fournies. Par exemple, un ensemble de données d’e-mails de phishing classées selon différentes valeurs (par exemple, légitime, malveillant, spam) peut alimenter le modèle ML.

Les solutions SOAR améliorées par l’IA peuvent aider à résoudre rapidement des incidents simples ou à identifier facilement des actions automatisables. Cependant, le raisonnement humain permettra de mieux contextualiser les choix en fonction de considérations commerciales et opérationnelles. A l’heure actuelle, aucune solution automatisée ne peut encore fonctionner sans l’intervention et la supervision des analystes. Au lieu de cela, l’IA est principalement destinée à effectuer efficacement une tâche spécialisée unique en traitant de grandes quantités de données. Cela améliore considérablement l’efficacité de l’équipe, travaillant aux côtés des humains, plutôt que de les remplacer.

Conclusion

Tout bien considéré, les plateformes SOAR sont des outils puissants. Bien qu’ils puissent soutenir les équipes IR à toutes les étapes de leur travail quotidien, y compris la collecte d’informations, l’analyse et la réponse active, il convient de souligner que les SOAR ne sont pas des outils magiques capables de résoudre tous les problèmes auxquels les équipes sont confrontées aujourd’hui. Au contraire, les achats qui ne sont pas suivis de projets de mise en œuvre bien définis entraîneront probablement des résultats inefficaces et de faibles retours sur investissement. Sur le plan technique, les SOAR ne peuvent pas effectuer des tâches que les systèmes backend ne permettent pas ; du côté organisationnel, ils s’appuieront toujours sur des processus et des procédures bien établis, standardisés et testés. Au fur et à mesure que les organisations évaluent leur adoption et, par conséquent, franchissent les étapes pour les intégrer et capitaliser sur leur potentiel, des principes directeurs tels qu’un principe d’impact à faible regret et une approche progressive déterminent le résultat final et les avantages que les équipes visent à obtenir.

Merci à Fabien Leclerc pour sa participation à la recherche et à la rédaction

Cet article Améliorer la réponse aux incidents grâce à l’automatisation : vue d’ensemble des plates-formes SOAR est apparu en premier sur RiskInsight.

Qu’est-ce qu’un Bug Bounty, et à quoi cela sert-il ?

De simples mots à la mode il y a quelques années, les programmes de primes à l’exploitation des bugs (Bug Bounty) et les initiatives de divulgation des vulnérabilités ont depuis imprégné le vocabulaire cybernétique d’un large éventail d’organisations, qu’il s’agisse de géants numériques, de grandes banques d’investissement ou d’organismes gouvernementaux. Le principe de base est le suivant : les entreprises offrent une incitation financière ou une récompense aux hackers bien intentionnés pour qu’ils trouvent et signalent les vulnérabilités découvertes dans leurs actifs. La complexité vient du fait que l’entreprise à l’origine de l’initiative fixe un délai pour que les hackers découvrent et corrigent ces vulnérabilités. Wavestone a étudié l’adoption de ces initiatives au sein du secteur bancaire et les bonnes pratiques à en tirer.

3 niveaux de maturité : dispositif de signalement, politique de divulgation des vulnérabilités et programme de Bug Bounty

En ce qui concerne la divulgation de la vulnérabilité, les initiatives sont diverses et la terminologie est large : divulgation coordonnée de vulnérabilités, divulgation responsable de vulnérabilités ou politique de divulgation de vulnérabilités. Toutes ces initiatives visent à fournir aux chercheurs un moyen sûr de signaler les vulnérabilités, mais le niveau de détail concernant le processus de signalement, les règles de recherche des vulnérabilités et les attentes de l’organisation en question varient considérablement d’un programme à l’autre. À la lumière de ces observations, nous avons identifié les trois niveaux de maturité suivants que sont : le dispositif de signalement, la politique de divulgation des vulnérabilités et les programmes de bug bounty.

Le premier niveau de maturité, le dispositif de signalement, consiste généralement en une simple page web fournissant des instructions très élémentaires et un dispositif dédié au signalement des vulnérabilités. Ce premier pas vers la divulgation des vulnérabilités agit comme un filet de sécurité au cas où quelqu’un découvrirait une vulnérabilité, mais il n’attire pas activement les hackers, notamment en raison du manque d’incitation financière. Le dispositif de signalement est le deuxième type d’initiative le plus courant, représentant 28 % des initiatives identifiées.

Le deuxième niveau de maturité, la politique de divulgation des vulnérabilités, prend également la forme d’une page web dédiée mais cette fois avec beaucoup plus de détails. Elle contient des informations avancées sur les processus de déclaration, les actifs concernés, ainsi que les préférences, règles et exceptions en matière de recherche sur la vulnérabilité. En outre, dans la plupart des cas (90 %), des informations concernant les attentes que les hackers peuvent avoir après avoir soumis un rapport, tant en termes de niveau de service (SLA) que de reconnaissance publique de leur travail, sont présentées. Dans nombre de ces initiatives (77 %), les entreprises s’engagent à fournir aux hackers une sphère de sécurité et à ne pas engager de poursuites judiciaires contre eux s’ils respectent les règles et agissent de bonne foi. Ce type d’initiative peut être géré en interne ou par une plateforme tierce (HackerOne, BugCrowd, Synack, …) qui communiquera avec les hackers et supervisera le triage des bugs.

Enfin, les programmes de Bug Bounty représentent le plus haut niveau de maturité, car ils comportent le même niveau d’information que la politique de divulgation des vulnérabilités, mais cette fois, les hackers sont financièrement récompensés pour avoir signalé des vulnérabilités. L’objectif est d’attirer des hackers talentueux et de faire des Bug Bounty un outil à part entière dans les cyber-écosystèmes des banques. Des plateformes tierces peuvent soit gérer ces programmes, soit mettre en place des programmes privés auxquels seuls des hackers contrôlés auront accès (après une vérification des antécédents et des compétences). Dans de nombreux cas, les programmes privés sont utilisés comme un tremplin vers les Bug Bounty, permettant aux entreprises d’acquérir de l’expérience avec le concept avant de passer à un programme public. Ils permettent également de mettre en place des dispositifs de sécurité avancés (surveillance complète de la recherche grâce aux VPN, accords de non-divulgation, contrôle avancé, recherche sur place, …) qui facilitent le respect des normes de sécurité et de confidentialité qui sont courantes dans le secteur bancaire.

Le secteur bancaire n’est pas dépassé par les autres secteurs

Ces initiatives ont été mises en œuvre par 18 % des banques étudiées, ce qui est 2,5 fois plus élevé que la moyenne rapportée dans le Forbes Global 2000. On peut donc dire que le secteur bancaire dispose de processus bien intégrés de divulgation des vulnérabilités dans le cadre de son cyber écosystème, le secteur des banques et des assurances se classant en troisième position en termes de nombre de programmes pour les services Internet et les logiciels informatiques. Cependant, il n’est pas le plus attractif d’un point de vue financier, se classant à la 12e place en termes de rémunération moyenne pour une vulnérabilité critique, les blockchains et les crypto-monnaies offrant une rémunération moyenne presque 3 fois plus élevée (source : HackerOne’s Hacker Powered Security Report 2019).

Les banques occidentales sont plus confiantes en s’engageant dans des processus de divulgation des vulnérabilités

Bien que l’adoption de dispositifs de divulgation des vulnérabilités dans le secteur bancaire semble être mondiale, cette recherche a constaté que les initiatives sont principalement adoptées par les banques européennes et américaines avec quelques spécificités. Ces observations peuvent s’expliquer par plusieurs facteurs.

Aux États-Unis, la divulgation des vulnérabilités fait depuis longtemps partie de la culture des géants de l’industrie technologique tels que Google et Facebook qui, entre autres, ont lancé leurs propres programmes avant 2012. Les États-Unis abritent également des acteurs qui comptent désormais parmi les principales plateformes de Bug Bounty au monde, dont BugCrowd (2011), HackerOne (2012) et Synack (2013). Il n’est donc pas surprenant de constater que ces plateformes gèrent la plupart des programmes de divulgation des vulnérabilités des banques américaines.

En Europe, la situation est différente et les acteurs clés sont moins nombreux. Après plusieurs incidents cybernétiques majeurs, les Pays-Bas ont été le premier pays d’Europe à lancer une initiative nationale en publiant les lignes directrices pour la divulgation coordonnée de vulnérabilités (2013) – un effort de collaboration entre le Centre national de cybersécurité du gouvernement néerlandais (NCSC) et diverses entreprises du secteur privé. Aujourd’hui, près de 70 % des grandes banques néerlandaises disposent d’un programme autogéré de Bug Bounty et le pays a joué un rôle clé dans l’élaboration des lignes directrices de l’UE en la matière. Il est également régulièrement cité en exemple par plusieurs autorités européennes. D’autres initiatives et plateformes ont également vu le jour ailleurs en Europe, comme YesWeHack, Intigriti, HackenProof, ou encore Yogosha. Cependant, il est difficile d’évaluer avec précision l’émergence des programmes de Bug Bounty en Europe, car plus de la moitié d’entre eux sont privés et ne disposent pas d’informations accessibles au public à des fins de confidentialité.

En Asie, les banques sont moins proactives en matière de divulgation des vulnérabilités en raison de réserves sur les programmes privés et d’autres facteurs culturels. Cependant, ces dernières années ont vu se multiplier les initiatives de la part des géants technologiques asiatiques et des institutions gouvernementales, notamment à Singapour et au Japon. Cela n’est pas surprenant, car de nombreuses institutions gouvernementales ont lancé ce type d’initiative par le passé (par exemple, Hack The Pentagon aux États-Unis ou le récent programme de Bug Bounty de l’application StopCovid géré par YesWeHack en France).

Se lancer dans la divulgation de vulnérabilités nécessite une préparation réellement efficace

Avec de nombreuses réussites et un nombre croissant d’entreprises de tous les secteurs qui lancent des programmes de divulgation des vulnérabilités, il est tentant de suivre la tendance. Cependant, pour assurer le succès de ce type d’initiative, il est crucial de se pencher sur quelques points clés.

Premièrement, un programme de divulgation des vulnérabilités ou des bugs doit s’inscrire dans une approche globale de la cybersécurité et compléter les mesures plus traditionnelles telles que les revues régulières du code, la sécurité by design, les audits de sécurité et les tests d’intrusion. Le signalement des bugs et des vulnérabilités n’est que la première étape du processus. L’entreprise doit ensuite disposer des compétences internes nécessaires pour analyser les rapports fournis et remédier aux vulnérabilités dès que possible.

Ensuite, pour éviter de faire perdre du temps aux hackers et à l’entreprise, la portée du programme doit être soigneusement conçue afin de maximiser son efficacité et d’empêcher l’intrusion des hackers sur des actifs indésirables. Les mêmes règles s’appliquent en ce qui concerne les règles de recherche et de signalement.

Enfin, il est crucial de s’intéresser aux motivations des hackers pour assurer le succès d’un programme de Bug Bounty. Les attentes relatives à la soumission d’un rapport doivent être clairement spécifiées et porter sur le processus, le temps de réponse et la récompense. Une communication constante avec la communauté des hackers ainsi qu’une évolution du programme ou des récompenses sont des éléments clés qui peuvent assurer la durabilité du programme et la motivation des hackers, contribuant ainsi au succès du programme.

L’image des hackers est encore souvent associée à des actions criminelles…

En ce qui concerne les Bug Bounty, l’une des principales préoccupations est la sécurité, les organisations se demandant si le fait d’exposer leurs plateformes aux hackers pourrait conduire à l’exploitation des vulnérabilités découvertes par la vente des données des utilisateurs ou des vulnérabilités elles-mêmes directement sur le marché noir.

Ces craintes sont en partie justifiées, car les données des utilisateurs peuvent désormais être facilement vendues sur le marché noir : les cartes de crédit, les passeports, les dossiers médicaux ou les informations d’authentification peuvent être vendus pour moins de 15 euros et le phishing ciblé utilisant ces informations peut générer encore plus de profits. Une vulnérabilité critique peut également être exploitée et donner lieu à une cyber-attaque beaucoup plus importante, comme l’ont montré les ravages causés par les cryptolockers ces dernières années. Toutefois, ces incidents sont rarement liés à des programmes de Bug Bounty, car les hackers malveillants n’attendent pas que les organisations lancent des programmes de Bug Bounty pour les attaquer. Au contraire, ces attaques peuvent se produire à tout moment.

Deuxièmement, des compétences et des niveaux de préparation différents sont nécessaires pour trouver les vulnérabilités et les exploiter.

Enfin, l’argent est la principale motivation des pirates participant à ces programmes dans moins de 15% des cas, selon HackerOne. Pour la majorité des hackers, le hacking est une passion et ils sont surtout à la recherche de défis et d’opportunités pour améliorer leurs compétences et rendre le web plus sûr – dans ce cas, les récompenses financières ne sont qu’un bonus et se mettre du mauvais côté de la loi n’en vaut pas la peine.

Politique de divulgation des vulnérabilités : une première étape pour améliorer la cybersécurité

La divulgation des vulnérabilités et les initiatives de Bug Bounty sont désormais un sujet dominant dans le domaine de la cybersécurité, et le secteur bancaire ne fait pas exception. Bien que les programmes de Bug Bounty ne soient pas des solutions miracles et qu’un certain effort soit nécessaire pour s’assurer qu’ils sont réellement efficaces, la mise en œuvre d’une politique de divulgation des vulnérabilités semble ajouter une grande couche de sécurité supplémentaire pour un faible investissement. Nous ne pouvons donc que recommander la mise en œuvre d’une telle politique dès que la maturité cyber d’une organisation le permet.

Cet article Bug Bounty: aperçu et benchmark du secteur bancaire à l’horizon 2021 est apparu en premier sur RiskInsight.