Divulgation des vulnérabilités

La présente politique suit la norme ISO/IEC 29147:2018 pour la réception et la divulgation des informations de vulnérabilité, et la norme ISO/IEC 30111:2019 pour leur traitement. Elle couvre le parc web du groupe, et rien d’autre. Les actifs compris dans le périmètre sont :

• www.parousiagroup.com et parousiagroup.com.
• westafrica.parousiagroup.com, eastafrica.parousiagroup.com, europe.parousiagroup.com, americas.parousiagroup.com, middleeast.parousiagroup.com et apac.parousiagroup.com.
• Les points d’accès HTTP exposés par ces sites, dont ceux du formulaire de contact et de l’inscription à la lettre d’information, ainsi que les ressources qu’ils servent.

Tout ce qui ne figure pas sur cette liste est hors périmètre, et les points suivants sont nommés parce que ce sont ceux sur lesquels les chercheurs interrogent.

• Les domaines produits des six solutions — parmi lesquels netvoxintelligence.com, globaltechnologyafrica.com, afrikaplaza.com, pagexpress.com et pagpay.com — sont hors de la présente politique. Un rapport les concernant peut être adressé à l’adresse de signalement indiquée plus bas et sera transmis à l’exploitant, mais les délais et l’engagement de non-poursuite du présent document ne valent que pour les actifs du périmètre ci-dessus.
• Les services que le groupe n’exploite pas : fournisseurs de messagerie, de DNS, de certificats, d’hébergement et de diffusion de contenu, comptes de réseaux sociaux et toute plateforme tierce. Adressez-vous à leur exploitant ; les tester n’est pas autorisé ici, et le groupe n’a pas qualité pour l’autoriser.
• Les locaux, le personnel, les systèmes téléphoniques et le courrier postal. Rien dans la présente politique n’autorise l’accès à un bâtiment ou la prise de contact avec un salarié à titre de test.
• Tout constat qui suppose un compte déjà compromis, un appareil déverrouillé ou infecté, un appareil physiquement volé, ou un navigateur obsolète que l’utilisateur devrait installer délibérément.
• Les constats sans impact démontré : en-têtes de sécurité manquants, préférences de marquage des cookies, préférences de configuration TLS, divulgation de numéro de version, absence de limitation de débit sur un point d’accès non authentifié, injection de script sur soi-même, détournement de clic sur une page sans action modifiant un état, enregistrements de messagerie sur des domaines qui n’émettent pas de courrier, et sortie brute d’un outil d’analyse automatisé. Un impact démontré fait entrer chacun de ces cas dans le périmètre.

Les tests menés dans le respect des règles suivantes sont autorisés par le groupe. Ces règles sont la condition de l’engagement de non-poursuite énoncé plus bas ; une activité qui en sort échappe à cet engagement.

• Ne testez que les actifs du périmètre, et uniquement avec des comptes et des données qui vous appartiennent.
• Employez l’interaction minimale qui démontre le problème, et arrêtez-vous dès qu’il est démontré. Prouver qu’un enregistrement est lisible est un constat ; lire la table n’en est pas un meilleur.
• Consignez ce que vous avez fait : dates et heures en temps universel coordonné, adresses source utilisées, et requêtes déterminantes. Une chaîne User-Agent distinctive identifiant vos travaux permet de distinguer votre trafic d’une attaque et aide le groupe à vous répondre plus vite.
• Signalez sans tarder, et laissez au groupe la fenêtre de coordination énoncée plus bas avant toute publication.

• Le déni de service n’est pas autorisé, sous aucune forme : attaques volumétriques, tests de charge ou de résistance, épuisement de ressources, et requêtes automatisées massives dégradant le service pour autrui.
• L’ingénierie sociale n’est pas autorisée : hameçonnage, prétexte, ou toute approche du personnel, des clients, des partenaires ou des fournisseurs, par courriel, téléphone, message ou en personne.
• L’accès, la modification, la suppression ou l’exfiltration de données appartenant à un tiers ne sont pas autorisés. Si vous atteignez de telles données, arrêtez-vous au point de preuve, ne les copiez pas, et indiquez-le dans votre rapport.
• L’installation d’un accès persistant ou d’une porte dérobée, le rebond vers un autre système et l’abandon de tout artefact ne sont pas autorisés.
• La force brute et le bourrage d’identifiants contre des comptes réels, ainsi que l’usage d’identifiants issus d’une fuite, ne sont pas autorisés.
• Les attaques physiques, les attaques contre la chaîne d’approvisionnement du groupe et les attaques contre les appareils ou comptes personnels des salariés ne sont pas autorisées.
• Exiger un paiement, ou subordonner la communication du détail à un paiement, relève de l’extorsion et non de la recherche : l’engagement de non-poursuite ne s’y applique pas.

Lorsque vous agissez de bonne foi, dans le périmètre et selon les règles énoncés plus haut, le groupe prend les engagements suivants, qui constituent la partie opérante de la présente politique.

• Le groupe tient votre activité pour autorisée, et n’engagera, ne soutiendra ni n’encouragera aucune action civile ni plainte pénale à votre encontre à ce titre, et ne demandera à aucune autorité publique de vous poursuivre pour cela.
• Le groupe ne traitera pas cette activité comme une violation de ses conditions d’utilisation et, pour cette activité, renonce à toute stipulation de ces conditions qui l’interdirait ou la restreindrait.
• Si un tiers engage une action ou dépose une plainte contre vous pour une activité conforme à la présente politique, le groupe fera savoir — publiquement, et à la juridiction ou à l’autorité concernée si elle le demande — que cette activité était autorisée par l’exploitant des systèmes.
• Le groupe n’exigera pas la signature d’un accord de confidentialité comme condition de la réception ou du traitement de votre rapport, et ne subordonnera pas la suite donnée à votre silence au-delà de la fenêtre de coordination énoncée plus bas.
• Une erreur de bonne foi sur le périmètre — un sous-domaine que vous pouviez raisonnablement croire inclus, un test interrompu dès que vous en avez vu la portée — ne fait pas perdre le bénéfice de ces engagements, à condition que vous la signaliez.

Un rapport reproductible est traité plus vite qu’un rapport à interpréter. Voici ce dont le groupe a besoin ; un rapport auquel il manque certains de ces éléments est reçu et examiné tout de même.

• L’actif concerné : hôte, chemin et paramètre exacts, et la requête qui déclenche le comportement.
• La date, l’heure et le fuseau horaire de vos tests, ainsi que les adresses source utilisées.
• Une description de la vulnérabilité, les étapes permettant de la reproduire, et une démonstration non destructive.
• Votre appréciation de l’impact : ce qu’un attaquant obtient, et ce dont il a besoin pour l’obtenir.
• Le compte éventuellement utilisé, et si vous avez atteint des données appartenant à un tiers — y compris des données vues sans intention.
• Si le constat a été partagé avec d’autres, et s’il est déjà public ou soumis à un autre calendrier.
• Si vous souhaitez une reconnaissance publique, sous quel nom ou pseudonyme, et par quel moyen vous préférez être contacté.

Le traitement suit la norme ISO/IEC 30111:2019 : réception, vérification, appréciation de la gravité, élaboration et vérification d’un correctif, publication, puis surveillance. La gravité est cotée selon CVSS v4.0, et la cotation est communiquée à l’auteur du rapport avec son raisonnement, afin qu’un désaccord sur la gravité puisse se discuter sur les faits.

La fenêtre de coordination est de quatre-vingt-dix jours à compter de l’accusé de réception. Le groupe demande que le détail ne soit pas publié avant la mise à disposition du correctif ou avant la fermeture de cette fenêtre, selon ce qui intervient en premier. Passé ce terme, vous êtes libre de publier, que la vulnérabilité ait été corrigée ou non, et le groupe ne traitera pas cette publication comme une violation de la présente politique ni comme le fondement d’une action.

• Une prolongation n’est demandée qu’assortie d’un motif et d’une date, jamais comme un report indéfini, et vous êtes libre de la refuser.
• Lorsqu’une vulnérabilité fait l’objet d’une exploitation active, le groupe peut publier avant la fermeture de la fenêtre afin d’avertir les utilisateurs, et vous en informe au préalable.
• Le groupe publie ce dont un lecteur a besoin pour agir : ce qui était affecté, ce qu’un attaquant aurait pu faire, ce qui a été fait et à quelle date. Il crédite l’auteur du rapport lorsque celui-ci l’a demandé.
• Lorsque la vulnérabilité réside dans un composant tiers, le groupe la signale à son mainteneur et se coordonne avec lui, et vous indique que le calendrier ne dépend plus entièrement de lui.
• Lorsque des données à caractère personnel ont été exposées, les obligations de notification des articles 33 et 34 du RGPD s’appliquent et, lorsqu’une entité du groupe relève de la directive (UE) 2022/2555, ses obligations de notification d’incident s’appliquent également. Aucune des deux n’est affectée par un accord entre le groupe et un chercheur.

Ce que le groupe offre, c’est la reconnaissance, accordée sur demande et non par défaut : un chercheur qui ne demande pas à être nommé ne l’est pas. La mention indique le nom ou le pseudonyme que vous avez choisi, la date de réception du rapport et la gravité. Sur demande, le groupe délivre également une attestation écrite du constat et de son traitement, qui vaut davantage qu’un porte-clés pour qui se constitue un dossier professionnel. Le chercheur qui demande l’anonymat l’obtient, y compris dans la publication.

Le RFC 9116 définit un fichier servi à l’adresse /.well-known/security.txt qui indique à un chercheur où adresser un rapport, où trouver la politique, quelles langues sont lues et quand le fichier expire. Le groupe n’en publie pas encore. Lorsqu’il le fera, ce fichier portera les champs Contact, Expires, Policy, Preferred-Languages et Acknowledgments et renverra au présent document ; il deviendra alors la source de vérité lisible par une machine, à la place du présent paragraphe.

Deux autres éléments n’existent pas encore et sont nommés ici plutôt que sous-entendus : une clé publique de chiffrement, et toute politique de divulgation propre à un produit. Lorsque le groupe mettra sur le marché européen un produit comportant des éléments numériques au sens du règlement (UE) 2024/2847, ce produit sera accompagné de sa propre politique de divulgation coordonnée et de ses propres obligations de signalement ; le présent document couvre le parc web du périmètre et ne s’y substitue pas.