Cet article CERT-W Newsletter Février 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Janvier 2021 est apparu en premier sur RiskInsight.

Après avoir vu dans un premier article l’état de la menace et les problématiques actuelles liées à la gestion des vulnérabilités, nous verrons dans ce second article les nouvelles approches à prendre en compte pour mieux gérer les vulnérabilités, notamment via la priorisation de la remédiation proposée par Hackuity.

L’avènement du « Risk-Based Vulnerability Management » (RBVM)

La gestion des vulnérabilités basée sur le risque, « Risk Based Vulnerability Management » (RBVM) est une approche qui traite chaque vulnérabilité en fonction du risque qu’elle représente pour chaque entreprise.

Dans ce contexte, la formule classique de calcul d’un risque s’applique :

La première partie de la formule, vulnérabilité × menace, peut également être considérée comme une probabilité. Cette probabilité décrit les chances qu’une vulnérabilité donnée soit découverte et utilisée par un acteur de la menace dans le contexte technique spécifique de l’organisation concernée. La dernière partie de la formule décrit les conséquences, ou l’impact, d’une attaque réussie par un acteur de la menace dans le contexte métier de l’entreprise

C’est en synthèse l’approche retenue par CVSS, une norme développée par le FIRST (Forum of Incident Response and Security Teams), initialement pour quantifier la gravité technique d’une vulnérabilité. Au travers de 3 métriques (base, temporelle, environnementale), l’ensemble du score CVSS (aujourd’hui dans sa version 3.1) est censé refléter le risqué réel qui pèse sur chaque vulnérabilité, dans le contexte de chaque entreprise.

Source: FIRST (https://www.first.org/cvss/specification-document)

L’objectif n’étant cependant pas ici de décrire CVSS, nous supposons que le lecteur est familier avec ce concept. Le score CVSS comporte de nombreux avantages, parmi les principaux :

• Le seul standard du marché disponible pour mesurer la criticité d’une vulnérabilité,
• Un algorithme détaillé et transparent,
• Un scoring largement adopté par l’industrie,
• Des bases de référence mondiales (notamment pour qualifier la criticité des CVE).

Cependant, il comporte de nombreuses limitations, dont on peut lister les principales ici :

1. Sa faible granularité; chacune des métriques est composée de valeurs catégorielles avec des valeurs prédéterminées (ex : faible, moyenne, élevé) ce qui limite ses capacités de discrimination.
2. Sa vocation à qualifier unitairement les vulnérabilités : il est ainsi impossible d’évaluer la criticité d’un scénario complet d’attaque avec CVSS. Certaines cyberattaques vont par exemple exploiter plusieurs vulnérabilités de criticité modérée pour arriver à compromettre un périmètre entier. Cependant, l’évaluation CVSS ne portera que sur chacune des failles prise de façon indépendante ; il sera nécessaire pour l’auditeur de présenter le scénario dans sa globalité et de mettre en lumière le risque final, sans qu’il ne puisse s’appuyer sur un score CVSS, celui-ci n’ayant pas pour vocation d’être agrégé.
3. Son caractère arbitraire: les poids et l’algorithme semblent parfois être composés de chiffres arbitraires rendant l’interprétation de ces valeurs complexe. Finalement, on constate une marge d’erreur parfois significative dans la quantification CVSS d’une même vulnérabilité par deux professionnels.

D’autre-part, faut-il le rappeler (?) les scores CVSS publics, comme ceux référencés dans le NVD, ne sont que des scores de base. Ils représentent la gravité intrinsèque d’une vulnérabilité, mais ne reflètent pas le risque que cette vulnérabilité représente pour l’entreprise. En d’autres termes, ils répondent à la question « Est-ce dangereux ? », mais pas à la question « Est-ce dangereux maintenant pour mon entreprise » ?

Une gestion efficace des vulnérabilités doit tenir compte non seulement du score de base, mais aussi des facteurs temporels et environnementaux. Le FIRST fournit le cadre, mais le NIST ne peut pas calculer le score CVSS pour l’entreprise, car il nécessite une connaissance de la criticité des actifs, l’identification des contrôles en place, l’exploitabilité de la vulnérabilité dans ce contexte précis ou l’intensité de la menace réelle et actuelle.

Sur le terrain, pourtant, on constate que près de 45% des entreprises interrogées – toutes tailles confondues – n’utilisent pour seul métrique de quantification de la criticité des vulnérabilités que le score CVSS de base.

Au-delà de la pertinence de cette approche, l’utilisation de cette métrique unique ne résout pas la problématique majeure de l’industrie qui reste le volume de vulnérabilités à traiter.

Sur les 123 454 vulnérabilités (CVE) recensées au 15/01/2020, plus de 16 000 avaient un score CVSS de base (V2.0) jugé critique (soit plus de 13% du total).

Au-delà de CVSS ?

L’objectif de la priorisation est donc de réduire le stock de vulnérabilités à traiter en priorité en discriminant les plus critiques afin de permettre de concentrer les équipes et moyens de remédiation sur les vulnérabilités qui comptent réellement.

D’autre part, il ne fait aucun doute que l’avalanche quotidienne de nouvelles vulnérabilités remontées par l’arsenal de détection ne peut plus être gérée manuellement. Il est totalement irréaliste d’examiner manuellement toutes les vulnérabilités identifiées, de les analyser et de les classer par ordre de priorité.

L’automatisation de la pratique doit permettre aux équipes de travailler plus efficacement, en réduisant les tâches et les processus manuels répétitifs et/ou à faible valeur ajoutée.

Pour répondre à ces besoins et aux limites de CVSS, les acteurs du RBVM introduisent :

• De nouvelles métriques (scores) de mesure du risque – propriétaires – qui viennent compléter, surcharger ou remplacer CVSS,
• L’automatisation des tâches d’analyses et de mesure, et notamment la corrélation avec des sources de menaces (CTI) pour qualifier en continu l’intensité de la menace associée à chaque vulnérabilité.

Plus généralement, l’approche RBVM prend en compte de nombreuses métriques d’évaluation pour établir un score basé sur le contexte et la menace. 4 grandes catégories de critères semblent faire consensus :

1/ La vulnérabilité ou les caractéristiques individuelles – intrinsèques – de la vulnérabilité elle-même.

Au travers de ces critères il s’agit de mesurer la gravité d’une vulnérabilité en prenant en compte des métriques qui sont constantes dans le temps et quels que soient les environnements, comme par exemple les privilèges requis pour exploiter la vulnérabilité ou encore son vecteur d’attaque (à distance, sur le même réseau local, avec un accès physique, etc.).

Pour cette catégorie, le score CVSS de base (généralement pris dans sa version 2.0 pour assurer l’antériorité) est un point de départ solide pour l’analyse de la criticité intrinsèque de la vulnérabilité. C’est d’ailleurs le score repris par la plupart des solutions du marché.

2/ Les menaces externes qui vont servir à quantifier l’intensité – actuelle – de la menace associée à chaque vulnérabilité.

Les métriques utilisées reflètent des caractéristiques qui peuvent changer au fil du temps mais pas d’un environnement technique à l’autre.

« La vulnérabilité est-elle associée à des sujets d’actualité sur les forums de discussion, le darknet et les réseaux sociaux ? Un mécanisme d’exploitation a-t-il été publié ou est-elle actuellement exploitée par un ransomware particulièrement virulent ? »

La disponibilité d’un « exploit » associé à une vulnérabilité est par exemple un facteur important repris par la plupart des de solutions de gestion des vulnérabilités par les risques. Selon une étude Tenable Research, 76% des vulnérabilités avec un score de base CVSS > 7 n’ont pas d’exploit disponible.

Source: (https://fr.tenable.com/research)

Cela signifie que des entreprises qui s’attacheraient à corriger toutes leurs vulnérabilités de criticité « Haute » ou « Critique » selon CVSS consacreraient plus des trois quarts de leur temps à combler des failles qui ne représentent au final que peu de risques. Pour une meilleure efficacité opérationnelle, il est donc opportun de concentrer les efforts de remédiation sur les vulnérabilités pour lesquelles un exploit a déjà été publié.

Mais c’est loin d’être le seul critère pertinent. En l’absence d’exploit connu, l’âge de la vulnérabilité pourra être pris en compte pour calculer sa probabilité d’exploitation, par une approche statistique, en fonction des occurrences d’exploitation mesurées. Certaines initiatives comme EPSS (Exploit Prediction Scoring System)[1] s’essayent même à prédire la « weaponization » des vulnérabilités.

Tout comme l’âge de la vulnérabilité, l’ancienneté de l’exploit est également un facteur qui va influer sur la probabilité d’exploitation. On relève par exemple que le taux d’exploitation d’une CVE explose au moment de la publication de l’exploit pour ensuite progressivement diminuer.

Plus généralement, l’intensité actualisée de la menace est un critère déterminant dans l’algorithme de priorisation. Au-delà d’approches statistiques, elle peut être quantifiée en monitorant des sources de CTI, les réseaux sociaux ou encore des publications diverses comme par exemple en quantifiant le nombre d’occurrences de ces vulnérabilités dans les discussions de forums cybercriminels.

On pourra ainsi déterminer qu’un nouveau malware particulièrement actif exploite une vulnérabilité et donc pondérer à la hausse sa criticité.

Beaucoup d’autres indicateurs peuvent être intégrés pour affiner la pertinence de la priorisation des vulnérabilités. La solution Hackuity prend notamment en compte plus de 10 critères en complément des métriques du standard CVSS pour calculer son « True Risk Score » :

Outre la pertinence du choix de ces critères et de l’algorithme de calcul lui-même, la nature et la qualité des sources de CTI monitorées pour renseigner en continu ces métriques représentent un enjeu important.

Parmi les sources utilisées, citons les nombreuses sources ouvertes (OSINT) sur les vulnérabilités et les menaces (NIST-NVD, Exploit-db, Metasploit, Vuldb, PacketStorm, OpenCVE, …) dont certaines consolidées au travers d’initiatives Open-source comme VIA4CVE (https://github.com/cve-search/VIA4CVE).

On compte aussi de très nombreux acteurs privés qui proposent des sources de CTI commerciales plus ou moins spécialisées dans l’intelligence sur les vulnérabilités.

3/ Le contexte technique ou les caractéristiques uniques de l’environnement dans lequel se trouve l’actif.

Il s’agit au travers de cette catégorie de mesurer la probabilité / difficulté d’exploitation d’une vulnérabilité dans le contexte spécifique de chaque organisation.

« L’actif est-il exposé sur l’Internet ou hébergé au fin-fond du Datacenter de l’entreprise ? Quelles sont les mesures techniques (protection, détection) qui le rendent plus ou moins vulnérable aux attaques ? »

Si certains acteurs se limitent à déterminer qu’un actif est exposé sur internet sur la base de son plan d’adressage IP, d’autres comme Hackuity vont chercher à mesurer la profondeur des arbres d’attaques nécessaires pour exploiter la vulnérabilité dans le SI de l’entreprise.

Ces caractéristiques sont par définition propres à chaque environnement. Il est donc nécessaire de disposer, prélever ou déterminer ces informations notamment en alimentant la formule de priorisation avec des données contextuelles liées aux actifs, par exemple des extraits de référentiels internes, lorsqu’ils existent.

4/ La criticité business de l’actif.

Il s’agit de mesurer les conséquences, ou l’impact, d’une attaque réussie par un acteur de la menace dans le contexte métier de l’entreprise.

« L’actif concerné par la vulnérabilité est-il critique pour l’organisation d’une manière ou d’une autre ? Héberge-t-il des informations sensibles ou nominatives ? Quels sont les impacts pour l’entreprise en termes financier, de réputation ou de conformité en cas d’exploitation de la vulnérabilité ? »

Tout autant que pour le contexte technique, ces caractéristiques sont spécifiques à chaque environnement. Il peut s’agir d’informations renseignées manuellement ou bien issues de résultats d’analyse de risque tels que des Business Impact Analyses.

Pour conclure sur le RVBM, quel que soit le degré d’automatisation apporté par la Solution, celle-ci ne prendra sa pleine mesure qu’avec l’apport d’éléments contextuels que l’outil ne peut deviner (impacts métier, environnement technique des actifs, organisation, processus, etc.).

Au-delà du RBVM, les technologies de VPT (Vulnerability Prioritization Technology)

Si les grands leaders du marché de la détection de vulnérabilités du marché ont aujourd’hui adopté une approche de gestion des vulnérabilités par les risques, ils n’ont pas adressé le principal problème associé à l’approche « best-of-breed » de la détection : les entreprises utilisent plusieurs outils et pratiques de détection pour assurer une couverture complète et efficace de leur périmètre.

Nombre moyen d’outils de détection selon la taille de l’entreprise / Hackuity – Panel de 93 entreprises

Comme évoqué précédemment, ce recours – nécessaire – à un arsenal hétérogène favorise une perception morcelée et non consolidée de la situation, ce qui limite les capacités de passage à l’échelle et, avec le volume des vulnérabilités croissant, entraine une explosion des coûts.

Pour répondre à ce problème, les acteurs du marché émergeant que le Gartner appelle VPT (« Vulnerability Prioritization Technology »), comme Hackuity, exploitent de manière agnostique les sources de vulnérabilité.

Ils collectent et centralisent les vulnérabilités issues de l’arsenal de détection de l’entreprise quel qu’il soit : multiples pratiques (test d’intrusion, bug-bounty, red team, etc.), éditeurs de solutions de détection des vulnérabilités (scans de vulnérabilités, SAST, DAST, IAST, SCA, etc. ) et sources de veille en vulnérabilités. Les principales caractéristiques des solutions de VPT sont décrites ci-après.

Schéma de principe de la solution Hackuity

Une vision exhaustive de l’état du stock de vulnérabilités

L’automatisation de la collecte des vulnérabilités permet aux équipes de la filière sécurité de disposer, parfois pour la première fois, d’une vision consolidée et centralisée du stock de vulnérabilités de l’entreprise, indépendamment des solutions ou pratiques de détections mises en œuvre.

Une opération capitale – et très rarement réalisée – est la conversion des formats propriétaires dans un format normalisé, qui va permettre par la suite de dé-dupliquer des clones d’une même vulnérabilité qui aurait été identifiée par plusieurs sources différentes (ex. une même injection SQL identifiée dans le cadre d’un test d’intrusion et lors d’un scan de vulnérabilités).

Ainsi, le méta-référentiel des vulnérabilités d’Hackuity est une base de connaissances multilingue qui fournit une description unifiée et normalisée de toutes les vulnérabilités, y compris les mesures correctives, les correctifs, les coûts de remédiation ou l’exploitabilité, sans perte d’informations remontées par la source d’origine.

L’établissement et l’enrichissement d’un inventaire des actifs

Sur le terrain, il n’existe que de rares exceptions d’entreprises qui disposent d’un référentiel de leurs actifs jugé complet ou au moins fiable (CMDB, ITAM, …). C’est d’ailleurs un problème endémique à la pratique et parfois le principal frein à la mise en place d’une politique de gestion des vulnérabilités efficient dans les entreprises. Afin de résoudre ce problème, certaines solutions intègrent dans leurs fonctionnement l’établissement dynamique et continu du référentiel des actifs de l’entreprise. Cette cartographie est établie par analyse et corrélation des données techniques collectées (ex. la stack logicielle installée sur un serveur, ses différents alias, etc.) et permet de disposer d’une base d’actifs continuellement maintenue à jour avec des données en provenance de multiples sources.

La criticité des actifs est également un élément clé dans le processus de mesure des risques liés aux vulnérabilités et qui compte pour près de 50% dans une approche de priorisation. Sans un inventaire précis des actifs et une évaluation de leur criticité dans l’environnement « business » de l’entreprise, il est impossible de calculer avec précision le risque réel associé à chaque vulnérabilité. Certains acteurs, tel qu’Hackuity, vont pallier l’absence ou à la non-complétude des analyses de risques en évaluant automatiquement la criticité des actifs en s’appuyant sur leurs propriétés techniques et opérationnelles (types et familles d’outils installés, densité des interconnexions, bases de données hébergées, etc.).

Au final, pour disposer d’informations consolidées sur les vulnérabilités ou les actifs de l’entreprise, plus besoin de maîtriser des dizaines d’outils ou de formats : le coût et la charge de travail liés à la gestion d’outils disparates sont considérablement réduits.

Le chainon manquant entre la détection et la remédiation des vulnérabilités

Enfin, le lien bidirectionnel avec les équipes en charge de la remédiation ou de la supervision sécurité permet de disposer d’une approche collaborative pour la gestion du stock de vulnérabilités.

En effet, si l’automatisation est devenue un levier indispensable à la gestion des vulnérabilités, il n’en reste pas moins que le facteur humain reste au cœur du processus.

Dans la plupart des entreprises, la gestion des vulnérabilités voit en effet intervenir 3 acteurs qui doivent travailler de concert :

1. Les équipes sécurité en charge d’opérer les outils de détection et de piloter les plans de remédiation,
2. Les responsables business qui vont arbitrer ou éclairer les plans de remédiation à l’aune des contraintes métier,
3. Les opérationnels en charges de déployer les mesures correctives (patch management, configuration, développements, etc.)

L’efficience du processus ne se limite donc pas à l’automatisation du recueil des vulnérabilités. Dans la partie aval du processus (la gestion de la remédiation), des play-books permettent de mobiliser les ressources nécessaires à la mise en œuvre des correctifs : identification du porteur de la correction, création automatique de tickets d’incidents, génération de scripts pour les solutions Infrastructure as Code, etc.

En amont, le RSSI dispose enfin, et bien souvent pour la première fois, d’une perception en temps réel de l’avancée des plans de remédiation.

La solution de gestion des vulnérabilités est alors l’orchestrateur de l’écosystème visant à détecter, qualifier, corriger et suivre les vulnérabilités affectant l’entreprise.

Conçu comme un système ouvert, il permet également de nourrir les outils et processus tiers (SIEM, GRC, IR, Forensics, etc.) avec des données consolidées et structurées sur les vulnérabilités, actifs et menaces qui affectent l’entreprise.

Conclusion

Véritable pierre angulaire de la cybersécurité des entreprises, la gestion des vulnérabilités peut aujourd’hui (enfin) être synonyme d’une pratique scalable, efficace et pour laquelle il est possible de disposer d’indicateurs factuels traduisant les efforts déployés par les équipes sécurité et les équipes en charge de la remédiation.

Outre les retombées directes sur la posture sécurité de l’entreprise via la réduction de la fenêtre d’exploitation des vulnérabilités ou encore la mobilisation des experts sur des tâches à haute valeur ajoutée, l’intégration d’une solution d’orchestration de la gestion des vulnérabilités peut aussi se traduire par des retombées indirectes comme une meilleure connaissance du Système d’Information ou encore un engagement décuplé des équipes grâce à la quantification de l’impact de leurs actions sur la sécurité de l’entreprise.

[1] https://arxiv.org/pdf/1908.04856.pdf

Cet article Hackuity | Shake’Up – Le futur de la gestion des vulnérabilités: vers de nouvelles approches basées sur les risques et sur la priorisation (2/2) est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Décembre 2020 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.

Cet article CERT-W Newsletter Novembre 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Octobre 2020 est apparu en premier sur RiskInsight.

Les indicateurs du mois

Top attack – La compagnie française d’affraitement CMA CGM frappée par une attaque ransomware

Le transporteur français CMA CGM annonce avoir été touché par une attaque de type ransomware, qui a désactivé son système de réservation et affecté un certain nombre de ses bureaux chinois. Le groupe de cybercriminels RagnarLocker leur aurait demandé de les contacter dans les deux jours « via un chat en direct et de payer la clé de déchiffrement ». CMA CGM avait interrompu, par mesure de précaution, les accès externes à son réseau et à ses applications informatiques afin d’éviter la propagation du logiciel malveillant. Les opérations maritimes et portuaires, quant à elles, se sont poursuivies.

Top exploit – Zerologon: Microsoft signale des attaques

Microsoft annonce avoir détecté des attaques exploitant la faille Zerologon. Plusieurs Proof of Concept ont été publiés en ligne au cours des derniers jours. Le patch corrigeant cette importante vulnérabilité dans NetLogon est disponible depuis le mois d’août. La faille Zerologon, évaluée à une criticité de 10 sur 10 par le CVSS, permet de compromettre les contrôleurs de domaines Windows des entreprises comme Active Directory.

Top leak – Microsoft Bing subit une énorme fuite de 6.5TB de données utilisateur

La société WizCase a découvert un serveur non sécurisé contenant une vaste base de données de journaux de recherches effectuées via l’application officielle Bing. Ce serveur contenait 6,5 To de données, en hausse de 200 Go chaque jour, et était protégé par mot de passe dans le passé, mais ce dernier fut retiré durant la première semaine de septembre, laissant la possibilité à des pirates d’effectuer plusieurs attaques de type Meow.

Veille sur la cybercriminalité

Un rapport du CISA américain dévoile des détails sur les webshells utilisés par les pirates iraniens

L’Agence de Cybersécurité et Sécurité des Infrastructures américaine (CISA) a publié un MAR (Malware Analysis Report) divulguant des détails techniques sur les webshells utilisés par des cybercriminels iraniens. Selon ce rapport, ces pirates, d’un groupe APT encore non nommé, attaquent, à l’aide de plusieurs webshells connus, des entreprises gouvernementales, financières, d’assurance, d’IT et du domaine médical à travers les Etats Unis. Parmi ces malwares, on peut retrouver le ChunkyTuna, Tiny, et China Chopper.

Deux russes inculpés pour avoir dérobé 17 millions de dollars par attaque de phishing

Les autorités américaines ont annoncé des accusations criminelles et des sanctions financières contre deux hommes russes accusés d’avoir volé près de 17 millions de dollars de devises virtuelles lors d’une série d’attaques de phishing en 2017 et 2018 qui ont usurpé des sites Web pour certains des échanges de crypto-monnaie les plus populaires.

Des failles de Google Chrome ouvrent la porte aux attaques

La version 85.0.4183.121 de Google Chrome sur Windows, Mac et Linux corrige 10 vulnérabilités. Selon Google, on retrouve parmi les exploitations les plus graves, le fait qu’un attaquant pourrait exécuter du code arbitraire dans le contexte du navigateur. Les versions de Google Chrome antérieures à 85.0.4183.121 sont concernées par ces failles de sécurité.

Veille sur les vulnérabilités

CVE – 2020 – 1472 – Vulnérabilté dans Microsoft Netlogon

Score CVSS : 10.0 CRITICAL

L’exploitation de cette vulnérabilité peut entraîner une élévation de privilèges sur les contrôleurs de domaine ayant pour conséquence l’accès à l’ensemble des ressources gérées par les domaines Active Directory.

CVE – 2020 – 0922 – Vulnérabilité d’exécution de code a distance dans Microsoft COM pour Windows

Score CVSS : 8.8 HIGH

Il existe une vulnérabilité permettant l’exécution de code à distance quant à la manière dont Microsoft COM pour Windows traite les objets en mémoire. Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait exécuter du code arbitraire sur un système cible.

* Component Object Model (COM) est une technique de composants logiciels développée par Microsoft et DEC, Utilisée pour mettre en œuvre OLE et ActiveX, COM est dépassé depuis 2009 par le Framework .NET de Microsoft.

CVE – 2020 – 1380 – Vulnérabilité d’altération de mémoire dans le moteur de script

Score CVSS : 7.5 HIGH

Il existe une vulnérabilité permettant l’exécution de code à distance quant à la manière dont le moteur de script traite les objets en mémoire dans Internet Explorer. Cette vulnérabilité pourrait altérer la mémoire et permettre à un attaquant d’exécuter du code arbitraire dans le contexte de l’utilisateur actuel.

Cet article Revue de l’actualité par le CERT-W – Septembre 2020 est apparu en premier sur RiskInsight.

Veille sur la cybercriminalité

Le « Patch Tuesday » de Microsoft le plus conséquent depuis sa création

Microsoft a publié le 10/03/2020 des mises à jour afin de corriger pas moins de 115 failles de sécurité affectant ses différents systèmes d’exploitation Windows et logiciels associés. Parmi ces failles, 26 sont considérées comme « critiques », le niveau de sévérité le plus élevé, et l’exploitation de certaines d’entre elles permettent d’effectuer de l’exécution de code à distance et de prendre le contrôle d’ordinateurs vulnérables sans aucune action nécessaire de la part des utilisateurs.

Mukashi : la nouvelle variante du tristement célèbre botnet Mirai cible les NAS Zyxel

Le botnet Mukashi effectue des attaques de type brute-force sur des hôtes aléatoires en utilisant différentes combinaisons d’identifiants par défaut afin de tenter de s’y connecter et d’en prendre le contrôle. Or, il cible dorénavant les dispositifs de stockage en réseau (NAS) de Zyxel en exploitant la CVE critique récemment publiée « CVE-2020-9054 » permettant de réaliser de l’exécution de code à distance sur la version 5.21 du micrologiciel.

Le coronavirus : le leurre le plus utilisé de tous les temps

Durant la crise sanitaire due au COVID-19, le coronavirus devient le leurre le plus utilisé au sein d’innombrables attaques de type phishing. En effet, parmi celle-ci, le Internet Crime Complaint Center (IC3) du FBI indique qu’il peut s’agir de courriels prétendant offrir des informations sur le virus, des kits de test et des potentiels vaccins, ou encore ceux se faisant passer pour des associations caritatives encourageant à faire des dons pour la recherche.

Veille sur les vulnérabilités

CVE-2020-0684 – Vulnérabilité d’exécution de code à distance dans Microsoft Windows

Il existe une vulnérabilité d’exécution de code à distance dans Microsoft Windows lorsqu’un fichier de format .LNK est traité (analysé ou exécuté par exemple). Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait obtenir les mêmes droits que l’utilisateur local.

CVE-2020-3947 – Vulnérabilité de déni de service dans VMware Workstation

Certaines versions de VMware Workstation et Fusion contiennent une vulnérabilité de type « use-after-free » dans le service vmnetdhcp. L’exploitation réussie de la vulnérabilité peut conduire à réaliser un déni de service du service vmnetdhcp s’exécutant sur la machine hôte ou encore exécuter du code sur l’hôte.

CVE-2020-10887 – Vulnérabilité de contournement du pare-feu d’un routeur TP-Link

Une version du micrologiciel du routeur TP-Link Archer est vulnérable à un contournement sur son pare-feu. Cette vulnérabilité découle d’une implémentation insuffisante de filtrage approprié des connexions SSH IPv6, au niveau de la gestion des connexions IPv6. Elle peut être exploitée sans authentification au préalable et permet d’effectuer une escalade de privilège avec la possibilité d’exécuter du code en tant que « root ».

Les indicateurs du mois

Top leak – Fuite d’informations de plus de 5 millions de clients chez Marriott

Les cybercriminels ont réussi à obtenir les identifiants de connexion de deux employés sur un logiciel tiers que les propriétés hôtelières du Marriott utilisent pour fournir des services aux clients. Ainsi, ils ont eu accès à de nombreuses informations sur les clients (noms, prénoms, adresses mails, numéros de téléphone, etc.). C’est la seconde grosse fuite constatée pour Marriott depuis 24 mois !

Top exploit – CVE-2020-0796 – Vulnérabilité d’exécution de code à distance dans le protocole SMB

Il existe une faille dans la manière dont le protocole Microsoft Server Message Block 3.1.1 (SMBv3) traite certaines requêtes, SMB étant un protocole réseau de partage de fichiers, d’imprimantes et d’autres ressources réseau. En effet, sans authentification au préalable, un attaquant exploitant cette vulnérabilité lui permettrait d’exécuter du code à distance non seulement côté serveur mais également côté client.

Top attack – Un des plus grands hôpitaux tchèques neutralisé par une cyberattaque

L’hôpital universitaire de Brno, en République tchèque, a été frappé par une cyberattaque majeure en plein milieu d’une épidémie de COVID-19 forçant l’hôpital à arrêter ses ordinateurs et à neutraliser son réseau informatique. Par conséquent, des interventions chirurgicales urgentes ont dû être reportées et des nouveaux patients en phase aigüe transférés vers d’autres hôpitaux.

Veille sur les versions des logiciels

Cet article Revue de l’actualité par le CERT-W – Mars 2020 est apparu en premier sur RiskInsight.

Veille sur la cybercriminalité

La mise à jour de Google Chrome lutte contre la cybercriminalité

Google Chrome version 80 prend désormais en charge AES-256 pour les données utilisateur stockées localement. Le changement a eu un impact sur la capacité d’AZORult à voler les informations des utilisateurs. AZORult est un malware de profil utilisateur qui est apparu en 2016 en volant de grandes quantités d’informations, y compris les mots de passe, l’historique de navigation Web, les cookies, etc.

Bouygues Construction, victime d’un autre ransomware

Bouygues Construction a été victime d’une attaque de ransomware. Détectée pour la première fois le 30 janvier, la société a annoncé l’attaque sur Twitter quelques jours seulement avant que le groupe MAZE ne se déclare être derrière l’attaque.

Internet Complain Center reporting (FBI IC3 report)

Le Federal Bureau of Investigation (FBI) a publié le Internet Complaint Center (IC3) signalant une augmentation de 1 300 plaintes par jour. Le rapport montre comment le Business email compromise (BEC) a coûté 1,7 milliard de dollars aux entreprises en 2019. Depuis que les entreprises ont mis en œuvre des campagnes de «volume spam», les attaques deviennent plus sophistiquées et ciblent des individus de grande valeur tels que les PDG et les employés de la finance.

Veille sur les vulnérabilités

CVE-2020-0688 – Vulnérabilité d’exécution de code à distance dans Microsoft Exchange

Il existe une vulnérabilité d’exécution de code à distance dans Microsoft Exchange lorsque le logiciel ne parvient pas à gérer correctement les objets en mémoire («Vulnérabilité de corruption de mémoire dans Microsoft Exchange»).

CVE-2019-15126 – Clé de chiffrement nulle pour chiffrer une partie de la communication de l’utilisateur

Un problème a été découvert sur les appareils clients Wi-Fi Broadcom. Plus précisément, un trafic chronométré et artisanal peut provoquer des erreurs internes (liées aux transitions d’état) dans un appareil WLAN qui conduisent à un chiffrement Wi-Fi de couche 2 inapproprié avec une possibilité conséquente de divulgation d’informations par voie aérienne pour un ensemble discret de trafic.

CVE-2020-0022 – Vulnérabilité Bluetooth critique dans Android

La pile Bluetooth Android permet aux attaquants de diffuser silencieusement des logiciels malveillants et de voler des données sur les téléphones à proximité en connaissant simplement l’adresse MAC Bluetooth de la cible. En conséquence, possibilité de déni de service (DoS), si l’appareil fonctionne sous Android 8.0, 8.1 ou 9.0, puis exécution de code à distance (RCE).

Les indicateurs du mois

Top leak : fuite de 123 millions d’enregistrements chez Decathlon

Une mauvaise configuration de la base de données a permis à une équipe de vpnMentor de révéler 123 millions d’enregistrements comprenant des informations sur les clients et les employés. Une base de données de plus de 9 Go a été trouvée sur un serveur Elasticsearch non sécurisé, exposant des informations provenant de Decathlon – Espagne.

Top exploit: CVE-2020-6418 – Faille de confusion dans V8, Google Chrome

Faille de confusion dans V8 (moteur JavaScript utilisé par Google Chrome) permettant l’exécution de code arbitraire dans le sandbox du navigateur.

Top attack: une cyberattaque paralyse les ventes de laine en Australie

Une attaque de type ransomware a touché plus de 75% de l’industrie de la laine en Australie. Le secrétaire du Comité national de vente aux enchères (NASC) a confirmé la compromission de Talman. Talman est le principal fournisseur de logiciels de l’industrie.

Cet article Revue de l’actualité par le CERT-W – Février 2020 est apparu en premier sur RiskInsight.

Muscler la gestion de crise

Les crises cyber sont des crises particulières : souvent longues (plusieurs semaines), parfois difficiles à cerner (qu’a pu faire l’attaquant ? depuis combien de temps ? quels sont les impacts ?) et impliquant des parties externes elles-mêmes souvent peu préparées sur ce sujet (avocats, huissiers, autorités, fournisseurs, voire les clients…). Il est donc nécessaire d’ajuster les dispositifs existants qui n’ont pas été conçus pour intégrer la dimension cyber.

Acteur opérationnel de la gestion de la crise cyber, la DSI ne doit pas être sur-mobilisée sur l’investigation et la défense au détriment de la production et du secours. Cet aspect constitue un point d’anticipation important à ne pas négliger. Il s’agira donc d’identifier clairement les équipes à mobiliser sur la crise et d’organiser les interventions parallèles d’investigation et de construction de plan de défense.

Au-delà de l’aspect organisationnel, il faudra s’assurer de disposer également de l’outillage d’investigation (cartographie, recherche de signature de l’attaque, SI de gestion de crise indépendant, capacité d’analyse de malware inconnu…), d’assainissement (capacité de déploiement rapide de correctifs ou de « vaccin », isolation en urgence de portions non touchées du SI, isolation réseau…) et de reconstruction (accès rapide aux sauvegardes, accès aux documentations minimum de reconstruction, support des fournisseurs clés sur le SI, capacité à réinstaller massivement des postes de travail…) requis pour comprendre la position de l’attaquant, stopper sa propagation et faire repartir au plus vite l’activité.

La définition d’un guide de gestion de crise, définissant les étapes structurantes, les responsabilités macroscopiques et les points de clés de décision sera un plus. Et parce qu’il est primordial de s’exercer en amont afin d’être prêt le jour où il faut faire face à la crise, la réalisation d’exercice de crise sera un bon révélateur de la situation réelle.

Repenser les dispositifs de continuité

Les dispositifs de continuité doivent également évoluer pour s’adapter aux menaces cyber. Les solutions possibles sont nombreuses et peuvent toucher tous les types de dispositifs de continuité. Le plan de reprise utilisateur peut intégrer par exemple la mise à disposition de clés USB avec un système alternatif. Les collaborateurs pourraient l’utiliser en cas de destruction logique de leur poste de travail.

Certains établissements ont fait le choix de provisionner des volumes de postes de travail de remplacement directement avec leurs fournisseurs de matériel afin de les délivrer rapidement en cas de destruction physique.

Le plan de continuité informatique peut inclure de nouvelles solutions pour être efficace en cas de cyberattaque. La plus emblématique vise à construire des chaînes applicatives alternatives. Il s’agit de « dupliquer » une application sans utiliser les mêmes logiciels, systèmes d’exploitation et équipes de production. C’est une solution extrême, très coûteuse et difficile à maintenir, mais qui est envisagée pour certaines applications critiques dans le monde de la finance (notamment les infrastructures de paiement à caractère systémique).

D’autres solutions moins complexes sont envisagées. Il s’agit par exemple de l’ajout de contrôle fonctionnel d’intégrité dans le processus métier. Son concept repose sur la réalisation de contrôles réguliers, à différents niveaux et à différents endroits dans la chaîne applicative (« multi-level controls »). Ceci permet de détecter rapidement des attaques qui toucheraient par exemple les couches techniques (modification d’une valeur directement dans une base de données) sans avoir été réalisées par les actions métier classiques (via les interfaces graphiques). Ces mécanismes peuvent aussi s’appliquer aux systèmes d’infrastructures, par exemple en réconciliant les tickets de demande de création de compte d’administration avec le nombre de comptes réellement dans le système.

D’un niveau de complexité intermédiaire, il est possible d’envisager la définition de zone d’isolation système et réseau (« floodgate ») que l’on peut activer en cas d’attaques et qui vont isoler les systèmes les plus sensibles du reste du SI. Le SI industriel pourra, à ce titre, constituer à lui seul, une de ces zones d’isolation vis-à-vis du reste du SI.

Ces évolutions, souvent majeures, doivent s’inscrire dans une revue des stratégies de secours existantes afin d’évaluer leur vulnérabilité et l’intérêt de déployer des nouvelles solutions de cyber-résilience, en particulier sur les systèmes les plus critiques. L’évolution des Business Impact Analysis (BIA) pour inclure cette dimension est certainement une première étape clé.

Sans cybersécurité, la cyber-résilience n’est rien

Implémenter ces nouvelles mesures de cyber-résilience nécessite des efforts importants. Des efforts qui seront vains si ces solutions de secours et les systèmes nominaux ne sont pas eux-mêmes déjà sécurisés correctement et surveillés avec attention. Le RSSI est l’acteur clé pour faire aboutir ces démarches souvent entamées mais rarement finalisées. L’aide du Risk Manager (RM) – ou, s’il est désigné, son Responsable du Plan de Continuité d’Activité (RPCA) – sera alors un plus. Il est aujourd’hui communément acquis qu’il est impossible de sécuriser des systèmes à 100%, il faut donc accepter la probabilité d’occurrence d’une attaque et c’est à ce moment-là que le RM ou son RPCA prendra tout son rôle.

Cet article est issu de notre focus « Cyber-résilience : plier pour ne pas rompre« .

Cet article Cyber-résilience : plier pour ne pas rompre (2/2) est apparu en premier sur RiskInsight.

Face à une cyberattaque majeure, qu’elle soit destructive ou qu’elle entraîne une perte de confiance dans les systèmes clés, le premier réflexe pour une majorité d’entreprises est d’activer le plan de continuité d’activité (PCA). Celui-ci est un élément majeur de la stratégie de résilience des organisations ; afin d’en assurer la survie lorsque surviennent des sinistres d’ampleur entraînant l’indisponibilité de ressources informatiques, d’infrastructures de communication, d’immeubles voire de collaborateurs.

Or les cyberattaques majeures, destructives comme Wannacry ou NotPetya ou provoquant une perte de confiance dans les infrastructures (réseau, gestion des accès, gestion du parc…) comme les attaques ciblées en profondeur (APT), n’ont pas été prises en compte lors de l’élaboration de la majorité des PCA. Ces derniers, focalisés sur un enjeu de disponibilité, n’appréhendent pas les problématiques de la destruction simultanée et de la perte de confiance dans le SI induites par les cyberattaques.

En effet, les dispositifs de continuité du SI, le plus souvent liés aux ressources qu’ils protègent, sont également affectés par ces attaques. Depuis plus de dix ans, les dispositifs de continuité (utilisateurs ou informatiques) ont adopté les principes de mutualisation des infrastructures et de secours « à chaud » à la fois pour répondre aux exigences de reprise rapide et d’une meilleure exploitabilité. De fait, cette « proximité » entre le SI nominal et son secours rend vulnérables les dispositifs de continuité aux cyberattaques.

Quelles vulnérabilités pour les dispositifs de continuité ?

À titre d’exemple, lors d’une intervention de crise suite à l’attaque NotPetya, l’idée d’utiliser les postes de secours présents sur le site de repli a très rapidement été évoquée. Malheureusement ceux-ci avaient été détruits de la même manière que les sites nominaux car ils partageaient les mêmes systèmes de gestion de parcs et les mêmes vulnérabilités. Les investissements et les efforts investis dans les dispositifs de continuité ont semblé à ce moment très vains.

Enfin, les sauvegardes, établies sur une base souvent quotidienne, constituent pour la plupart des organisations le dispositif de dernier recours pour reconstruire le SI.

Malheureusement, en cas de compromission en profondeur, du fait de l’antériorité de l’intrusion (souvent plusieurs centaines de jours avant sa détection), ces sauvegardes embarquent de fait les éléments malveillants : malwares, camps de base, mais aussi les modifications déjà opérées par les attaquants. De plus, la continuité en tant que telle des systèmes de sauvegarde est souvent négligée. Lors de gestion de crise sur NotPetya, les serveurs gérant les sauvegardes ont eux-mêmes été détruits. Les restaurer a pris plusieurs jours vu leur complexité et leur imbrication dans le SI (nécessité de disposer d’un ActiveDirectory pour lancer des restaurations alors que la sauvegarde de l’AD était nécessaire pour le reconstruire, reconstruction de l’index des bandes de sauvegardes détruit avec le reste…).

S’agissant des SI industriels, les constats sont tout aussi manifestes. Les systèmes numériques industriels sont résilients à des pannes techniques ou des incidents mécaniques anticipés. En revanche, ils n’ont que rarement intégré, dès leur conception, les potentialités d’une malveillance humaine et ne disposent souvent pas de mécanismes de sécurité avancés. Du reste, leur cycle de vie long (plusieurs dizaines d’années) les expose à l’exploitation de vulnérabilités parfois anciennes. Enfin l’indépendance des chaînes de contrôle (Systèmes Instrumentés de Sécurité, cf. encadré ci-après) vis-à- vis des systèmes numériques qu’elles supervisent n’est pas toujours appliquée.

Des scénarios d’attaques majeures illustrés par des attaques récentes

La destruction logique ou l’indisponibilité d’une grande partie du système d’information.

Concrétisé par les attaques de vrai-faux rançongiciels Wannacry et NotPetya, ce type d’attaque entraîne une indisponibilité massive du fait du chiffrement des fichiers de données et/ou du système d’exploitation. Les sociétés touchées par ce type d’attaque (Merck, Maersk, Saint Gobain, Fedex… mais aussi Sony Pictures ou Saudi Aramco) ont perdu jusqu’à plus de 95% de leurs systèmes d’information (des dizaines de milliers d’ordinateurs et de serveurs) en un délai souvent inférieur à 1h. La situation au démarrage de la crise est très difficile car il n’y a plus aucun moyen de communication et d’échange au sein de l’entreprise, y compris au sein de la DSI. Les victimes ont communiqué sur des pertes de plusieurs centaines de millions d’euros suite à ces attaques.

La compromission et la perte de confiance dans le système d’information

Il s’agit d’attaques ciblées qui ne remettent en pas en cause le bon fonctionnement du système mais qui visent à donner aux attaquants l’accès à l’ensemble des systèmes de l’entreprise (messagerie, fichiers, applications métiers…), leur permettent d’usurper l’identité de n’importe quel employé et de réaliser des actions en leur nom. Les attaquants peuvent ainsi exfiltrer tout type de données ou réaliser des actions métiers demandant plusieurs validations successives. Ces attaques ont touché de très nombreuses entreprises dans tous les secteurs avec comme conséquences des fraudes massives, comme celles ayant touché la banque du Bangladesh, ou des vols de données financières et de paiements comme celles ayant touchés plusieurs groupes de distribution aux Etats-Unis dont Target ou encore Home Depot. La situation au démarrage de la crise est complexe en raison d’une conjugaison de plusieurs éléments aggravants : perte de confiance dans le système d’information et flou grandissant sur les actions et objectifs. Il s’agit alors d’investiguer discrètement jusqu’à pouvoir déloger l’attaquant et reconstruire un système sain. Les victimes touchées par ces attaques ont fait état d’impacts financiers de plusieurs centaines de millions d’euros.

Cet article est issu de notre focus « Cyber-résilience : plier pour ne pas rompre« .

Cet article Cyber-résilience : plier pour ne pas rompre (1/2) est apparu en premier sur RiskInsight.

Un concours digne d’une compétition sportive

Au Paris Hotel de Las Vegas, Nevada, s’est déroulé en août 2016 cet étrange concours digne d’une compétition sportive. Pendant près de 12 heures, d’imposantes machines, appelées Cyber Reasoning Systems se sont affrontées dans l’arène devant un public de 3000 personnes, auquel les présentateurs expliquaient les tentatives d’attaques et les corrections de vulnérabilités grâce à des représentations en 3D très parlantes. Organisé par la DARPA, ce concours avait un double but : valider le concept de cyberdéfense automatisée et stimuler la recherche en offrant 4 millions de dollars de prix, dont 2 à l’équipe vainqueur.

Selon Mike Walker, responsable du programme du Cyber Grand Challenge, les failles de sécurité exploitées dans la nature le seraient pendant 312 jours en moyenne avant leur détection et le temps médian de correction après détection serait de 24 jours. Un délai très long pendant lequel les systèmes restent vulnérables et que la DARPA souhaiterait voir réduit à quelques minutes ou secondes, en confiant aux machines la tâche de détecter et de corriger elles-mêmes ces failles de sécurité.

Depuis l’annonce du concours en 2013, la DARPA qui prend le sujet très au sérieux, y a investi 55 millions de dollars. 7 équipes aux propositions intéressantes ont été invitées à participer au concours en recevant une aide financière mais l’entrée restait ouverte à toute équipe auto-financée souhaitant relever le défi. En juin 2015, les qualifications ont eu lieu sur Internet pendant 24 heures au cours desquelles les équipes devaient trouver le maximum de vulnérabilités affectant 131 programmes. Sur plus de 100 équipes les 7 meilleures se sont qualifiées pour l’événement final, touchant 750.000$ au passage afin de s’y préparer. Parmi elles, 3 équipes financées par la DARPA et 4 équipes auto-financées.

Au bout de 12 heures de compétition acharnée, c’est Mayhem, le CRS de l’équipe ForAllSecure qui a remporté la victoire malgré une difficulté technique qui l’a empêché de soumettre des correctifs pendant une partie de l’épreuve. Mayhem a eu le privilège de pouvoir concourir au concours « normal » de la conférence DEFCON où s’affrontaient les meilleures équipes de hackers du monde entier. Mayhem est arrivé bon dernier de ce concours, mais à quelques points seulement de la dernière équipe humaine. Ce résultat peut être comparé à la progression des machines contre les humains aux échecs en conditions de tournoi : entre les premières victoires des machines contre des maîtres au début des années 80 et le moment où les machines parvenaient à battre des grands maîtres de façon régulière au milieu des années 2000, 25 ans se sont écoulés.

Si les machines talonnent aujourd’hui les meilleures équipes de hackers, de quoi seront-elles capables dans 10 ou 20 ans ?

Vers un monde plus sûr ?

David Brumley, CEO de ForAllSecure spinoff de l’université Carnegie Mellon, souhaite que dans le monde ultra connecté qui est le nôtre, chacun puisse avoir la garantie que les objets et les applications que nous utilisons soient sûrs, sans s’en remettre uniquement à leurs développeurs. Mais si le développement d’une cyberdéfense automatisée est une aubaine pour la société civile, on peut bien imaginer quelles implications offensives ces recherches pourraient avoir. Découvrir rapidement et en grande quantité des bugs dans des programmes fournirait autant de munitions à un état décidé à attaquer des systèmes d’organisations ou d’autres nations n’étant pas alignées avec ses intérêts. Et l’on peut être sûr que la DARPA, dont la vocation première est militaire, en a parfaitement conscience.

Cet article Et si les machines assuraient leur propre cyberdéfense ? est apparu en premier sur RiskInsight.

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr…

Cet article Le fardeau du pentesteur est apparu en premier sur RiskInsight.

Une sécurisation insuffisante, voire inexistante

Les automates programmables industriels (API), en charge de l’interface avec le monde physique, n’intègrent souvent que peu de fonctions de sécurité et les failles de sécurité publiques les concernant sont nombreuses. L’ICS-CERT a ainsi publié près d’une centaine de bulletins de vulnérabilités sur des composants industriels. Les protocoles de communication utilisés sont un des maillons faibles de la chaîne. Ces protocoles, parmi lesquels on peut citer Modbus, permettent l’échange de consignes ou de valeurs en clair, sans chiffrement.

De même, les possibilités d’authentification des actions sont souvent limitées, permettant à n’importe quel attaquant ayant accès au réseau de modifier les consignes des automates et ainsi d’influer sur leur comportement. Les interfaces d’administration des automates sont par ailleurs souvent protégées par des mots de passe par défaut, jamais changés, et qui parfois ne peuvent pas l’être. Les systèmes plus intégrés appelés SNCC (Systèmes Numériques de Contrôle-Commande) ne sont pas garants d’une sécurité accrue, les protocoles propriétaires utilisés n’apportant pas forcément une réelle couche de sécurité.

La situation est identique pour les PC de supervision ou de programmation qui sont souvent des équipements reposant sur des technologies standard, tels que des systèmes d’exploitation Microsoft Windows. Malheureusement, l’expérience sécurité acquise sur le SI de gestion pour ces équipements profite rarement à leur sécurisation sur la partie industrielle. Les étapes de durcissement sécurité sont rares, de même que l’application de correctifs de sécurité, ou encore la présence d’un antivirus. Il est fréquent de pouvoir prendre le contrôle de ces systèmes par l’exploitation d’une faille de sécurité datant de près de 6 ans.

Un cloisonnement tout à fait relatif

De plus, les équipements du SI Industriel sont très largement interfacés avec les SI de gestion. Le cloisonnement entre ces deux mondes est souvent permissif. Il arrive même que le filtrage autorise l’accès à certains équipements industriels depuis l’ensemble du réseau interne d’une entreprise, ce qui peut représenter plusieurs dizaines de milliers de machines.
Les postes de programmation et clés USB constituent également des vecteurs d’attaques puisqu’ils sont connectés à des réseaux de niveau de sécurité hétérogène, voire à des environnements non-maîtrisés (par exemple dans le cas de sous-traitants).

Pire encore, il arrive trop souvent que des équipements industriels soient accessibles directement sur internet. Il existe même des moteurs de recherche dédiés à la recherche d’équipements exposés sur internet, Shodan étant le plus connu. Près de 1500 équipements Modbus sont ainsi recensés en France sur Shodan et plus de 20 000 dans le monde.

Un constat d’échec ?

Il ne s’agit néanmoins pas de se lamenter. Bien que le niveau de sécurité actuellement constaté soit faible, il est possible de mener des actions d’amélioration. Au-delà des concepts d’architecture qui permettent de cloisonner ces équipements vulnérables, la vraie, seule solution à long terme consiste à développer de nouveaux produits, sécurisés by design. Bien sûr, les fruits de ce travail ne se verront que sur les nouvelles installations, et pas avant plusieurs dizaines d’années. On peut espérer que la prise de conscience globale des parties prenantes, ainsi que l’implication des instances gouvernementales accélèrent ce changement.
En attendant il semble aujourd’hui nécessaire de déporter les fonctions sécurité sur des équipements dédiés, comme des passerelles encapsulant le trafic réseau dans un tunnel chiffré, ou bien des pare-feu ou IPS disposant de modules spécifiques aux protocoles industriels.

Enfin, il faut également savoir tirer parti d’une des faiblesses des SI Industriels : leur durée de vie et la complexité de changements. En effet, la mise en place d’une supervision sécurité sera facilitée par le caractère figé des réseaux industriels : il est rare que de nouveaux équipements soient installés ou que la topologie réseau soit modifiée. De même, l’emploi d’une solution de contrôle d’exécution par liste blanche sera plus facile sur un PC industriel n’exécutant qu’un seul logiciel de supervision que sur un poste de travail bureautique.

1 – http://www.rapid7.com/db/modules/auxiliary/scanner/scada/modbusclient
2 – https://github.com/arnaudsoullie/metasploit-framework/blob/modicon_stux_transfer/modules/auxiliary/admin/scada/modicon_stux_transfer.rb
3 – https://github.com/arnaudsoullie/scan7

Cet article Niveau de sécurité des SI Industriels : les vulnérabilités les plus courantes est apparu en premier sur RiskInsight.

 Le Top 10 2013, dans la continuité des Top 10 précédents

La quasi-totalité des risques présents dans le top 10 2010 le sont encore dans le top 10 2013. De même, aucun réel nouveau risque n’est apparu : il ne s’agit que d’un remaniement.

 Evolutions du Top 10 entre 2010 et 2013

Cette mise à jour reflète néanmoins les évolutions constatées lors de nos audits, et notamment le recours de plus en plus fréquent à des framework de développement, mais dont les fonctionnalités de sécurité ne sont pas forcément (bien) utilisées ; ainsi, les failles applicatives sont souvent détectées dans les modules développés spécifiquement pour les besoins métiers. Par ailleurs, le trio de tête « Injection, XSS et gestion des sessions » reste présent dans la quasi-totalité des applications que nous auditons.

Quelques évolutions marquantes du Top10 2013

 Falsification de requête intersites (CSRF)

De plus en plus, des fonctions de protection contre le CSRF sont intégrées dans les framework de développement ainsi que dans les logiciels commerciaux, ce qui explique la diminution du risque associé. Cependant, ne prenons pas pour acquis cette protection : nous constatons très fréquemment des vulnérabilités de ce type, qui restent moins connues des développeurs que les vulnérabilités d’injection.

 Manque de contrôle d’accès au niveau fonctionnel

Les vulnérabilités de contrôle d’accès remontent dans le classement, non pas parce qu’elles sont plus fréquentes, mais parce qu’elles sont mieux détectées. Il s’agit effectivement de vulnérabilités que l’on retrouve très classiquement de nos audits. De plus, ces vulnérabilités sont souvent très difficiles, voire impossible à détecter à l’aide d’outils automatisés, car elles nécessitent une bonne compréhension du fonctionnement de l’application et de la logique métier : seul un auditeur humain saura comprendre et évaluer en détails ces mécanismes.

Utilisation de composants avec des vulnérabilités connues

Le recours à des frameworks de développement, ou plus simplement à des librairies externes, est de plus en plus fréquent. Cependant, les processus associés de veille sécurité et de mise à niveau régulière ne sont que rarement mis en place ; ainsi, nombreuses sont les applications à utiliser des composants pour lesquels des vulnérabilités sont connues, et exploitables.  De plus, les modifications apportées à certaines applications peuvent empêcher l’application des correctifs de sécurité ou la migration vers des versions nouvelles. Il est donc primordial d’assurer un suivi de l’ensemble des briques applicatives utilisées, comme suggéré par la règle d’hygiène n°6 de l’ANSSI.

 La sécurité applicative, un domaine que l’on ne peut plus ignorer

Malheureusement, il est très rare d’auditer une application web dont le niveau de sécurité est satisfaisant. L’évolution du niveau de sécurité reste lente, notamment au regard d’une forte tendance à la hausse des intrusions et défacements. Pourtant, l’intégration de la sécurité dans les projets, ainsi que la création de cellules de sécurité applicative sont des initiatives qui fonctionnent !

Alors, que faire ? Ne vous arrêtez pas à 10 ! Ce Top 10 n’a pas pour vocation de lister l’ensemble des vulnérabilités possibles et imaginables sur les applications web ! Il est primordial de savoir ajuster les mesures de sécurité aux besoins de sécurité propres à votre métier et à vos données, notamment par la réalisation d’une analyse de risques préalable.
 

Le Top 10 vient également d’être traduit en français par le chapitre français de l’OWASP, projet auquel Solucom a eu le plaisir de participer. La version française est disponible sous ce lien. 

 Pour être informé des prochains événements organisés par l’OWASP France, n’hésitez pas à rejoindre la mailing-list OWASP France.

 Pour en savoir plus sur les cellules de sécurité applicative (SecApp), n’hésitez pas à télécharger notre focus sur le sujet.

Cet article SecApp : que retenir du nouveau TOP 10 de l’OWASP ? est apparu en premier sur RiskInsight.