Avertissement : L'original de cette page est rédigé en néerlandais. Cette page a été traduite automatiquement dans d'autres langues à l'aide de DeepL. Il peut en résulter des différences de nuances, de ton et de sens. En cas de doute, consultez toujours d'abord la version néerlandaise. En raison du coût élevé des traductions, le contenu de cette page peut être inférieur à celui de la version néerlandaise. Nous considérons la version néerlandaise de cette page comme la première.
L’Internet Cleanup Foundation dispose d’un code de conduite qui définit les principes de base concernant les mesures qui sont publiées et celles qui ne le sont pas.
Cette page approfondit cette question à l’aide d’exemples pratiques.
Mesures publiques à des fins publiques
En principe, la sécurité de base mesure la sécurité au niveau élémentaire. Elle peut être publiée librement sans augmenter le risque d’abus au-delà de ce qu’il est déjà. Envisagez de mesurer les lacunes des mesures de sécurité courantes.
La base de données de Basisbeveiliging.nl contient plus de 10 millions de mesures uniques. Toutes les mesures de la base de données peuvent être publiées intégralement à tout moment, ou faire l’objet d’une fuite, sans créer de nouveaux risques susceptibles d’être exploités par un pirate.
Une organisation dotée d’une politique de sécurité adéquate sera toujours dans le vert en matière de sécurité de base : les mesures en elles-mêmes ne sont pas nouvelles ou choquantes, mais le manque d’application peut parfois l’être.
Les mesures de la sécurité de base se situent dans le domaine du piratage éthique et des tests de sécurité. Il existe de fortes similitudes avec les premières étapes des tests de sécurité professionnels, telles que la cartographie de la surface d’attaque. Cela couvre les domaines, les ports et les logiciels. Il s’agit d’informations publiques faciles à collecter à grande échelle. De nombreuses entreprises se chargent de cette tâche et l’offrent à très bas prix, voire publiquement et gratuitement.
Basic Security ne publie jamais de vulnérabilités graves ou critiques. Elle laisse cette tâche à d’autres organisations, telles que des sociétés professionnelles de tests de sécurité comme Secura, Zerocopter ou des organisations bénévoles comme la DIVD.
Résultats publiables
L’Internet Cleanup Foundation publie des informations sur les vulnérabilités et les mesures de sécurité manquantes. Elle le fait dans le but de corriger ces vulnérabilités. Sur la base du code de conduite, il est déterminé si une vulnérabilité peut être publiée. L’intérêt public, la proportionnalité et la subsidiarité sont alors pris en compte.
Les vulnérabilités publiables sont accessibles à tous sur le site web de sécurité de base. Il est également possible d’y accéder automatiquement.
Les vulnérabilités publiables sont classées en fonction du risque. Il s’agit d’un classement différent, courant dans le monde de la sécurité, car le spectre des mesures est différent. Le spectre de la sécurité de base comporte quatre niveaux qui sont échelonnés en fonction de ce qui pourrait potentiellement mal tourner. Cela contraste avec les tests de sécurité habituels, qui confrontent les mêmes résultats à des choses qui tournent vraiment mal à l’heure actuelle. Alors que la sécurité de base attribue une valeur « élevée » à un élément, un test de sécurité professionnel lui attribuera une valeur « info », « faible » ou, dans un cas particulier, « moyenne », en fonction de l’objectif du test.
Les niveaux de sécurité de base évoluent au fil du temps, afin d’élever lentement la barre de la sécurité de base. Lorsqu’une mesure est orange cette année, elle peut devenir rouge l’année prochaine afin d’attirer l’attention sur elle. Par exemple, l’application de security.txt n’est pas obligatoire avant la mi-2023, de sorte qu’à cette date, toutes les organisations n’appliqueront pas cette norme. Toutefois, à la mi-2024, cela serait inacceptable car elles auront eu un an pour l’appliquer. Vous trouverez plus d’informations à ce sujet dans la politique de mesure.
Ce sont les quatre gradations que nous appliquons :
Rouge : il s’agit d’une vulnérabilité à haut risque. Il s’agit d’une imperfection qui doit être corrigée. Considérez, par exemple, un chiffrement faible. La fuite d’informations sur la version (lire : indiquer à un attaquant ce qu’il doit exécuter), etc.
Orange : il s’agit souvent d’institutions et de déficiences administratives. Il s’agit également de nouvelles mesures qui devraient être classées en rouge, mais qui sont classées en orange pour l’introduction : afin de rendre la mesure visible et exploitable par les organisations responsables.
Vert (faible) : Une mesure impliquant une déviation sur la sécurité qui a très peu d’impact (pour l’instant) parce que peu de personnes peuvent être confrontées à ce problème, et dans ce cas, elles sont souvent déjà exposées à un large éventail de problèmes plus graves. Ce niveau est également utilisé pour les mesures susceptibles d’entraîner des obligations légales à l’avenir, mais qui ne sont pas très courantes aujourd’hui.
Vert (ok) : Une mesure correcte : la sécurité est assurée à ce stade.
Les résultats sont toujours accompagnés d’une documentation, de références et, dans la mesure du possible, d’un lien vers un deuxième avis qui permet d’effectuer un nouveau test. Ces éléments figurent également dans la politique de mesure. Cela permet de connaître la pertinence d’une nouvelle découverte et de vérifier immédiatement que la vulnérabilité a été corrigée.
Exemples de vulnérabilités publiables : chiffrement manquant, DNSSEC manquant, security.txt manquant, emplacement physique du service, application de la RPKI, informations sur la version publique.
Toutes les informations figurant sur les sites web, y compris toutes les mesures, sont soumises à notre clause de non-responsabilité. Vous agissez donc toujours à vos frais et à vos risques et périls. Nous nous efforçons de toujours publier des mesures correctes et actualisées. Pour en savoir plus, consultez la politique de mesure.
Comment les nouvelles mesures sont-elles publiées ?
Avant qu’une nouvelle mesure ne soit publiée, elle est d’abord annoncée aux organisations faîtières afin qu’elles puissent prendre des mesures en conséquence. À ce moment-là, les résultats de l’évaluation eux-mêmes ne sont souvent pas encore clairs. Au moins un mois plus tard, la mesure devient visible et publique.
Elle sera suivie d’une période d’essai au cours de laquelle la mesure sera classée orange au maximum. Pendant cette période d’essai, chacun peut réagir à la mesure et celle-ci peut être renforcée. Cette période dure généralement un mois ou deux. Après cette période, la mesure est remise à l’échelle et éventuellement mise au rouge.
Exemple de scénario de vulnérabilité publiable
Une organisation a besoin d’un site web. Ce site est fourni par une agence de développement. Cette agence de développement utilise un logiciel standard et se concentre principalement sur la fonctionnalité et l’information.
Le site web est en train d’être mis en ligne, mais la question de la sécurité n’a pas encore été abordée. Par exemple, le site n’est pas encore accessible via une connexion cryptée (1 : https), il n’y a pas de garanties quant à l’appartenance du nom de domaine à l’adresse IP du site (2 : DNSSEC) et il y a un panneau de gestion public (3 : panneau de connexion) montrant qu’il s’agit de la version 7.0.2 du logiciel (4 : informations sur la version).
Ce cas offre à l’attaquant toutes sortes de possibilités qui peuvent être facilement évitées. Un attaquant n’a besoin que de peu ou pas d’efforts pour les trouver, et il a depuis longtemps et largement automatisé cette connaissance pour faire autant de dégâts que possible de cette manière.
Dans cette étude de cas, un attaquant peut exploiter les vulnérabilités de la manière suivante : il peut lire le trafic Internet sur le même réseau tel qu’un hotspot Wi-Fi parce que https est absent (1 : https), sur le même réseau l’attaquant peut rediriger le trafic vers une fausse page (2 : dnssec), il peut tenter de se connecter à la page de gestion n’importe où dans le monde (3 : panneau de connexion) et rechercher et appliquer des vulnérabilités connues du public n’importe où dans le monde (4 : informations sur la version).
Les attaquants disposent déjà de ces informations, il est donc important que les personnes qui doivent se défendre en disposent également. Dans toutes ces attaques, il y a une base d’ouverture et de bon professionnalisme.
Lorsque les cadres et les normes de sécurité connus sont respectés avec compétence, toutes ces vulnérabilités n’existent pas. Pensez à ISO27002, NEN7510, Baseline Information Security Government et autres. Notez que de tels cadres ne sont pas pratiques et permettent à chacun de mesurer et d’évaluer les solutions elles-mêmes. Par conséquent, dans une même situation, un novice rédigera un plan différent, en termes de contenu, de celui d’un professionnel. En matière de sécurité de base, nous plaçons une certaine barre qui est pertinente dans tous les cas. Certains trouvent cette barre trop haute, d’autres la trouvent trop basse. Dans tous les cas, c’est la base.
Vulnérabilités non publiables
La sécurité de base se concentre sur les exigences de base en matière de sécurité.
Les bénévoles de la fondation trouvent aussi parfois des failles importantes. Il s’agit d’un sous-produit et non de l’objectif de la fondation. Voici comment nous traitons ce problème. Les recherches actives de failles graves sont effectuées par l’organisation amie DIVD. La sécurité de la base ne recherche donc jamais activement les failles graves.
Si nous découvrons accidentellement une vulnérabilité grave, voici comment nous la traitons.
Lorsqu’une vulnérabilité grave est suspectée, l’approche qui offre la plus grande sécurité dans le délai le plus court est envisagée au cas par cas. Plusieurs options sont envisagées :
- S’il s’agit d’une nouvelle vulnérabilité qui n’est pas encore connue (pas un CVE), il existe un certain nombre d’options. Cela dépend de l’endroit où la vulnérabilité a été identifiée et de sa gravité. Les pistes suivantes sont envisagées :
- Passez le relais à l’Institut néerlandais pour la divulgation des vulnérabilités (Dutch Institute for Vulnerability Disclosure). Il dispose de l’infrastructure nécessaire pour identifier les victimes de cette vulnérabilité et les avertir de la fuite. Cette action est notre option préférée.
- Lorsque le créateur du logiciel dispose d’un processus coordonné de divulgation des vulnérabilités, cette vulnérabilité est également transmise directement au créateur. Cela ne se produit que lorsque cela peut être fait en toute confiance.
- Les règles de base relatives à la divulgation coordonnée des vulnérabilités sont appliquées pour informer la partie vulnérable.
- Lorsqu’il s’agit d’une vulnérabilité connue, les règles de base relatives à la divulgation coordonnée des vulnérabilités sont suivies. Il est examiné si l’organisation a mis en place un tel processus.
- S’il n’y a pas de processus CVD en place, l’organisation faîtière de sécurité à laquelle il appartient est contactée. Il s’agit, par exemple, du Service de sécurité de l’information pour les municipalités ou du Centre national de cybersécurité pour le gouvernement national.
- Il est envisagé de transmettre le rapport par l’intermédiaire de la ligne directe de sécurité.
- La communication autour de la vulnérabilité grave sera envisagée conformément aux règles de base de la CVD. La recherche et la publication de nouvelles vulnérabilités n’étant pas notre objectif, la communication sur les nouvelles vulnérabilités, si elle a lieu, se fera probablement par l’intermédiaire de la partie à laquelle la vulnérabilité a été signalée, la hotline de sécurité, la DIVD ou une organisation similaire.
Voici quelques exemples de vulnérabilités non publiables : injection SQL, script intersite, utilisation de mots de passe faibles, fuites de mots de passe, exécution de code à distance, débordements de mémoire tampon et CVE.
Exemple de scénario vulnérabilité grave
Cet exemple est basé sur un scénario réel et une vulnérabilité connue : la désactivation d’un module qui rendait les fichiers contenant des mots de passe directement lisibles sur la page d’accueil d’un site (désactivation de PHP). Il s’agit d’une erreur de configuration.
Un volontaire consulte des informations sur le site basicsecurity.co.uk. Il voit un site : « oud.belangrijkeoganisation.nl », dont la sécurité peut donc être faible. Le volontaire est intéressé et visite le site.
En visitant le site, il apparaît que quelque chose ne va pas dans la configuration : le code source du site est visible, au lieu d’un beau site web. Ce code source contient le mot de passe d’une base de données et des liens vers des fichiers sensibles.
Le volontaire sait que ce n’est pas son intention et consulte d’autres volontaires pour savoir ce qu’il est sage de faire. Il s’agit d’une personne dont la vulnérabilité est connue, les règles de la CVD sont respectées.
Le volontaire contacte l’organisation de sécurité qui appartient au site web. Des informations sur la vulnérabilité sont échangées et l’organisation suit les processus internes associés au CVD et à la résolution de la vulnérabilité.
L’organisation a résolu la vulnérabilité dans un délai prévisible. Parfois, l’organisation choisit de récompenser le journaliste en lui offrant un cadeau ou en l’inscrivant au temple de la renommée.