Notre approche en matière de tests de sécurité externes
Les clients souhaitant avoir la certitude que nous avons mis en place des processus pour identifier (et corriger) les failles de sécurité dans les produits Atlassian et la plateforme Cloud nous demandent régulièrement des rapports sur les tests d'intrusion. Notre approche des tests de sécurité externes repose sur le concept d'« assurance continue » : plutôt que d'effectuer un test d'intrusion ponctuel, nous appliquons un modèle de test disponible en continu à l'aide d'un programme Bug Bounty crowdsourcé.
Notre philosophie et notre approche
Chez Atlassian, nous sommes bien connus pour nos valeurs, qui influencent véritablement toutes nos actions, y compris notre approche des tests de sécurité. Dans la pratique, nos valeurs nous ont conduits à adopter les philosophies et approches suivantes :
- Les bugs font inévitablement partie du processus de développement. La question n'est pas de savoir si nous en rencontrons, mais bien si nous sommes capables de les identifier et de les résoudre de façon efficace et rapide. Cela ne signifie pas pour autant que nous aimons les bugs ou que nous ne cherchons pas en permanence des moyens innovants pour réduire leur fréquence et leur gravité. Quand il est question de bugs logiciels, le déni n'est pas une approche efficace.
- En identifiant et en résolvant rapidement les problèmes, nous avons pour objectif d'augmenter le coût économique associé à l'identification et à l'exploitation de failles et de bugs de sécurité dans nos produits et services. L'exploitation d'une faille par des personnes mal intentionnées nécessitera ainsi plus de temps, de connaissances et de ressources, et le retour sur investissement associé sera moindre. Sous un certain seuil de rendement, l'exploitation des failles deviendra ainsi prohibitive ou peu intéressante.
- Nous prenons en charge et appliquons les normes du secteur. En standardisant notre terminologie et notre approche, nous avons la certitude de couvrir tous les points et nous aidons nos clients à comprendre nos activités. Par exemple, les évaluations communes des vulnérabilités à l'aide du système CVSS (Common Vulnerability Scoring System) garantissent une certaine clarté entre nos clients et nous-mêmes quant à la gravité d'une vulnérabilité donnée. Nous appliquons également les processus de gestion des vulnérabilités décrits dans la norme ISO 27001 et dans le programme CSA (Cloud Security Alliance).
- Les chercheurs en sécurité externes constituent un complément précieux pour notre équipe. Si un produit Atlassian présente une vulnérabilité, il en va de l'intérêt de tous (tant du nôtre que de celui de nos clients) de l'identifier et de la corriger aussi rapidement que possible. Atlassian incite les chercheurs externes à identifier les vulnérabilités dans ses produits grâce à des primes en espèces dans le cadre de son programme Bug Bounty. Avec leur aide, nous sommes en mesure de faire évoluer notre équipe bien au-delà des approches traditionnelles !
- Nous sommes ouverts et transparents sur notre programme de tests de sécurité. Notre programme Bug Bounty fournit des statistiques sur les bugs identifiés. Nous parlons ouvertement de la vitesse à laquelle nous nous efforçons de corriger les bugs de sécurité et nous publions des rapports de test synthétiques en bas de cette page dès que possible.
Assurance sécurité continue
Tests d'intrusion
Nous faisons appel à des sociétés de conseil spécialisées dans la sécurité pour effectuer des tests d'intrusion dans nos produits et notre infrastructure à haut risque. Ces tests peuvent concerner une nouvelle infrastructure configurée pour nous (p. ex., notre environnement Cloud), un nouveau produit (p. ex., Trello) ou un changement profond dans l'architecture (p. ex., l'utilisation extensive de microservices).
Dans ces cas, notre approche des tests d'intrusion est hautement ciblée. Voici la liste des tests que nous menons généralement :
- Boîte blanche : les testeurs reçoivent de la documentation sur la conception de nos produits et sont briefés par nos ingénieurs produit pour les aider dans leurs tests.
- Approche assistée par le code : les testeurs disposent d'un accès total à la base de code pertinente pour les aider à diagnostiquer les comportements inattendus du système durant les tests et à identifier les cibles potentielles.
- Approche basée sur la menace : les tests se concentrent sur un scénario de menace donné, comme l'existence supposée d'une instance compromise, et évaluent les mouvements latéraux possibles à partir de ce point.
Nous publions des lettres d'évaluation (LoA) de nos partenaires réalisant les tests d'intrusion. Celles-ci sont disponibles au bas de cette page pour une utilisation externe. En raison de l'exhaustivité des informations internes mises à la disposition des testeurs pour mener ces évaluations, nous ne fournissons pas les rapports complets. La majorité de ces systèmes et produits seront ensuite inclus à notre programme Bug Bounty public, offrant ainsi la garantie externe recherchée par nos clients. Tous les résultats de ces évaluations seront triés et corrigés selon notre SLO public pour les failles de sécurité.
Programme Bug Bounty
Notre programme Bug Bounty est hébergé par Bugcrowd. Il a pour objectif de s'assurer que nos produits sont constamment testés afin d'identifier d'éventuelles failles de sécurité. Il constitue la pierre angulaire de notre programme de tests de sécurité externes et découle de recherches, d'analyses et de comparaisons importantes menées sur plusieurs modèles de test.
Nous pensons que les nombreux chercheurs en sécurité indépendants qui participent à notre programme Bug Bounty constituent le processus externe le plus efficace, car :
- Un programme Bug Bounty est toujours disponible. Les tests d'intrusion sont généralement limités à quelques semaines. Dans un environnement de développement véritablement Agile, où les livraisons sont fréquentes, les tests continus sont indispensables.
- Un programme Bug Bounty implique plus de 60 000 testeurs potentiels. Les tests d'intrusion font généralement appel à une ou deux personnes. Quelle que soit leur compétence, ces personnes ne surpasseront jamais la capacité agrégée de l'équipe de participants au programme Bug Bounty.
- Les chercheurs participant au programme Bug Bounty développent des outils spécialisés et procèdent de façon verticale (types de bug spécifiques) et horizontale (primes spécifiques). Cette spécialisation offre la plus grande chance d'identifier les failles cachées, mais importantes.
Nous continuons d'avoir recours à des tests d'intrusion et des consultants spécialisés en sécurité à des fins de soutien interne, mais un système de Bug Bounty est bien plus approprié pour notre programme externe à vaste portée. Nous pensons que ces approches combinées maximisent nos chances d'identifier des vulnérabilités.
Plus de 25 de nos produits ou environnements (qu'il s'agisse de nos produits Server ou Cloud, ou encore de nos apps mobiles) entrent dans le champ d'application de notre programme Bug Bounty. Tous les détails relatifs au nombre de failles signalées, à notre temps de réponse moyen et à la rémunération moyenne sont inclus sur le site Bugcrowd, et plus de 800 testeurs se sont spécifiquement inscrits à notre programme.
Parmi les failles que nous cherchons à identifier grâce à notre programme Bug Bounty figurent les types communs répertoriés dans les listes de menaces OWASP (Open Web Application Security Project) et WASC (Web Application Security Consortium), notamment :
- Fuite de données/accès entre les différentes instances
- Exécution de code arbitraire (RCE)
- Server-Side Request Forgery (SSRF)
- Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF)
- SQL Injection (SQLi)
- Attaques XML eXternal Entity (XXE)
- Failles de contrôle d'accès (problèmes de références d'objet directes non sécurisées, etc.)
- Problèmes de type « Path/Directory Traversal »
Dans le cadre de nos efforts d'ouverture et de transparence, nous invitons toute personne intéressée à consulter la page dédiée à notre programme Bug Bounty, à s'inscrire au programme et à nous tester.
Apps du Marketplace : les apps du Marketplace sont exclues du programme Bug Bounty principal d'Atlassian. Cependant, elles sont couvertes dans des programmes Bug Bounty distincts hébergés par Atlassian, comme le Vulnerability Disclosure Program et le programme Bug Bounty pour les apps développées par Atlassian.
Tests à l'initiative du client : conformément à nos Conditions d'utilisation pour nos produits Cloud, nous autorisons désormais les tests à l'initiative du client. Nous nous engageons à être ouverts et à publier régulièrement les statistiques de notre programme Bug Bounty.
Nous pensons que notre programme Bug Bounty constitue une approche plus efficace et plus économique pour évaluer la sécurité de nos produits et services, mais nous comprenons que vous puissiez vouloir tester la sécurité par vous-même. Nous autorisons les clients à effectuer des évaluations de sécurité (tests d'intrusion, évaluations des vulnérabilités), nous vous demandons simplement de suivre quelques règles pour assurer notre sécurité à tous.
Signalement des failles
Si vous trouvez un problème que vous souhaitez signaler à Atlassian, veuillez consulter nos instructions sur les méthodes de signalement d'une vulnérabilité.
Chez Atlassian, l'une de nos valeurs est « Oui à la transparence, non au baratin » et nous sommes convaincus que la divulgation des vulnérabilités en fait partie. Notre but est de corriger les failles de sécurité dans le cadre des objectifs de niveau de service (SLO) pertinents. Nous acceptons les demandes de divulgation effectuées par l'intermédiaire de nos programmes Bug Bounty une fois qu'un problème a été corrigé et livré en production. Cependant, si le rapport contient des données client, la demande sera rejetée. Si vous prévoyez une divulgation en dehors de nos programmes Bug Bounty, nous vous demandons de nous en informer dans un délai raisonnable et d'attendre que le SLO associé soit terminé.
Exclusions de notre programme de tests de sécurité
Nous sommes ouverts et transparents quant aux tests que nous menons. Nous suivons également cette approche pour les tests que nous ne réalisons pas nous-mêmes ou que nous ne prenons pas actuellement en charge. Les éléments suivants sont exclus de notre programme de tests de sécurité :
Certains types de vulnérabilité à faible risque : nos produits sont développés de sorte à libérer le potentiel de toutes les équipes, et cela nécessite de la collaboration. Les vulnérabilités liées à l'énumération et à la collecte d'informations ne sont généralement pas considérées comme présentant un risque important.
Mesurer les bons facteurs
Nous disposons d'une politique de correction des bugs de sécurité qui indique les délais des objectifs de niveau de service (SLO) pour corriger les vulnérabilités en fonction de la gravité ainsi que du produit. Lorsque nous évaluons les vulnérabilités, nous utilisons le système CVSS (Common Vulnerability Scoring System), qui nous permet de communiquer la gravité des vulnérabilités à nos clients.
Par ailleurs, notre objectif est d'augmenter le coût associé à l'identification et à l'exploitation des vulnérabilités dans nos produits. Nous utilisons nos programmes Bug Bounty pour quantifier ce coût. À mesure que nos pratiques de sécurité s'améliorent, le nombre de bugs identifiés par nos programmes Bug Bounty devrait diminuer. Lorsque ce moment sera arrivé, nous devrons augmenter la prime que nous acceptons de verser pour ces bugs si nous voulons continuer de recevoir des rapports. Par exemple, si la quantité d'efforts requise pour identifier une vulnérabilité assortie d'une prime de 3 000 $ n'est plus assez intéressante (la valeur des efforts déployés étant supérieure à 3 000 $), nous aurons augmenté le coût associé à l'identification de cette vulnérabilité.
En d'autres termes, vous devriez vous attendre à voir vos primes augmenter au fil du temps.
En résumé
Atlassian a mis en place un programme de tests de sécurité externes mature, ouvert et transparent, qui repose sur son programme Bug Bounty.
Vous voulez aller plus loin ?
Ce bref article fait référence à de nombreux autres documents et ressources. Nous vous encourageons à les consulter en détail pour en savoir plus sur notre approche en matière de tests de sécurité.
- Atlassian Trust Center
- Pratiques de sécurité Atlassian
- Inscription d'Atlassian au registre STAR de CSA
- Politique de correction des bugs Atlassian
- Page de signalement des failles d'Atlassian
- Responsabilités d'Atlassian en cas d'incident de sécurité
- Page d'accueil du programme Bug Bounty d'Atlassian
- Programmes Bug Bounty d'Atlassian
- Programme Bug Bounty pour les apps du Marketplace développées par Atlassian
- Programme Bug Bounty pour les apps du Marketplace développées par des fournisseurs tiers
- Programme Bug Bounty pour Opsgenie
- Programme Bug Bounty pour Statuspage
- Programme Bug Bounty pour Trello
- Programme Bug Bounty pour Halp
- Programme Bug Bounty d'Atlassian pour tous les autres produits (Jira, Confluence, Bitbucket, etc.)
Téléchargez les derniers rapports Bug Bounty
Toute faille de sécurité identifiée dans les rapports ci-dessous est suivie dans notre instance Jira interne à mesure qu'elle est réceptionnée dans le processus Bug Bounty, et toutes les découvertes faites dans le cadre du programme sont triées et corrigées conformément à notre SLO public pour les failles de sécurité.
- Télécharger le dernier rapport du programme Bug Bounty d'Atlassian (janvier 2023)
- Télécharger le dernier rapport du programme Bug Bounty pour Halp (janvier 2023)
- Télécharger le dernier rapport du programme Bug Bounty pour Jira Align (janvier 2023)
- Télécharger le dernier rapport du programme Bug Bounty pour Opsgenie (janvier 2023)
- Télécharger le dernier rapport du programme Bug Bounty pour Statuspage (janvier 2023)
- Télécharger le dernier rapport du programme Bug Bounty pour Trello (janvier 2023)
Téléchargez les lettres d'évaluation (LoA)
Toutes les failles de sécurité identifiées dans les rapports ci-dessous font l'objet d'un suivi dans notre Jira interne à mesure qu'elles suivent le processus de reporting sur les tests d'intrusion, et toutes les découvertes faites dans le cadre de ces évaluations seront triées et corrigées selon notre SLO public pour les failles de sécurité.
- Lettre d'évaluation de Jira Align (avril 2022)
- Lettre d'évaluation pour Bitbucket Pipelines (mai 2022)
- Lettre d'évaluation de Trello (août 2022)
- Lettre d'évaluation pour Bitbucket Server et Data Center (septembre 2022)
- Lettre d'évaluation de Confluence Cloud (octobre 2022)
- Lettre d'évaluation pour Jira Service Management Data Center (octobre 2022)
- Lettre d'évaluation de Jira Cloud Google OAuth (octobre 2022)
- Lettre d'évaluation de la bibliothèque Atlassian Log4j pour Confluence et Jira (décembre 2022)
- Lettre d'évaluation pour Confluence Server (décembre 2022)
- Lettre d'évaluation pour Jira Work Management Cloud (décembre 2022)
- Lettre d'évaluation de Bitbucket Cloud (décembre 2022)
- Lettre d'évaluation de Statuspage Cloud (décembre 2022)
- Lettre d'évaluation pour Jira Software (Cloud) (février 2023)
- Lettre d'évaluation de Bambou (février 2023)