Gérer efficacement un système de ticketing des vulnérabilités avec Ostorlab

Découvrir des vulnérabilités n'est que le début d'un long parcours, souvent, pour les corriger, déployer les correctifs et les valider.

Ce parcours peut vite devenir fastidieux si vous n'avez pas les bons outils pour le rationaliser et intégrer la détection, la remédiation et la validation des correctifs dans le cycle de vie de la gestion de la remédiation.

Les systèmes de ticketing traditionnels exigent souvent un effort manuel considérable pour trier les nouveaux problèmes, identifier les doublons et gérer les faux positifs. Dans les grandes organisations, une personne ou une équipe est parfois dédiée à la seule tâche de trier les résultats des scanners et de veiller à la suppression des doublons. Une tâche glamour, que beaucoup redoutent immensément.

Selon une étude de ServiceNow de 2022, les organisations consacraient en moyenne 443 heures par semaine aux activités de gestion des vulnérabilités, soit l'équivalent d'environ 11 employés à temps plein.

L'une des fonctionnalités centrales de la plateforme Ostorlab est son système de ticketing complet, conçu pour la gestion des vulnérabilités. Il a été construit et pensé dès le départ pour répondre aux défis de la gestion du cycle de vie de la correction des vulnérabilités.

Le système de ticketing d'Ostorlab a été lancé en octobre 2021. Il a aidé plus de 10 000 organisations à automatiser et à rationaliser tout le processus de gestion et de remédiation des vulnérabilités de sécurité.

Les principales fonctionnalités du système de ticketing d'Ostorlab sont les suivantes :

• Générer automatiquement des tickets pour les vulnérabilités nouvellement détectées et y intégrer des informations détaillées comme le type, la sévérité et le contexte.
• Regrouper les vulnérabilités récurrentes dans un seul ticket grâce à un identifiant unique (DNA),
• Les vulnérabilités corrigées sont vérifiées automatiquement par des rescans, ce qui garantit que les problèmes sont réellement résolus.
• Application des politiques de correction avec des Service Level Objectives (SLO), comme la résolution des problèmes de sévérité élevée sous cinq jours.
• Une compatibilité transparente avec des outils comme Jira permet aux organisations de gérer les vulnérabilités dans leurs workflows existants.

En 2024, les clients d'Ostorlab avaient un délai moyen de remédiation (MTTR) de 17 jours, avec seulement 5 jours pour les problèmes critiques et 10 jours pour les problèmes de sévérité élevée.

Si la première version du système de ticketing a apporté une approche innovante pour regrouper les tickets sur la base d'un DNA unique, les retours continus des utilisateurs ont permis d'identifier de nouveaux défis auxquels les développeurs et les équipes sécurité font face pour gérer les vulnérabilités dans différents environnements et sur différentes plateformes.

Aujourd'hui, nous annonçons la sortie de la version 2 du système de ticketing d'Ostorlab, qui répond à ces défis et apporte plus de flexibilité dans la façon de regrouper les tickets entre environnements et plateformes.

Les défis

Suivre le statut d'une vulnérabilité sur plusieurs versions et plateformes est difficile et peut conduire à des efforts de remédiation incohérents.

Par exemple, si vous avez une application mobile sur Android et iOS, le cycle de vie de développement de l'application comporte généralement quatre étapes : version de développement, staging, pré-production et production.

Dans ce scénario, une seule vulnérabilité pourrait générer jusqu'à 8 tickets distincts (2 plateformes x 4 étapes du cycle de vie), ce qui crée un casse-tête logistique pour les équipes sécurité qui essaient de gérer et de corriger efficacement les problèmes.

Cette approche fragmentée aboutit souvent à des vulnérabilités corrigées de manière incohérente selon les environnements ou les plateformes. Par exemple, une faille de sécurité critique peut être corrigée dans la version de production Android mais passer inaperçue dans l'environnement de staging iOS.

Comment la version 2 du système de ticketing d'Ostorlab résout ces problèmes

Au lieu d'utiliser une logique prédéfinie pour regrouper les tickets, les utilisateurs peuvent désormais définir comment ils souhaitent regrouper les vulnérabilités entre différentes plateformes ou différents environnements.

Cas d'usage 1 :

• Nous avons une application mobile sur Android et iOS.
• Nous téléversons les fichiers APK ou IPA pour scanner nos versions de développement
• Nous scannons depuis le PlayStore et l'AppStore pour scanner la version de production.

-> Nous souhaitons avoir un ticket par environnement et par plateforme.

Pour cela, vous pouvez définir un regroupement par plateforme et placer chaque environnement dans un groupe distinct :

Cas d'usage 2 :

• Nous avons une application mobile sur Android et iOS.
• Nous téléversons les fichiers APK ou IPA pour scanner nos versions de développement
• Nous scannons depuis le PlayStore et l'AppStore pour scanner la version de production.

-> Nous souhaitons regrouper les tickets Android du Store ou du fichier. Il en va de même pour iOS. Toutefois, si un problème est corrigé dans le fichier Android, le ticket doit rester ouvert jusqu'à ce que nous ayons le correctif dans la version du Store.

Pour cela, vous pouvez définir un regroupement par plateforme et placer chaque environnement dans un groupe distinct :

Cas d'usage 3 :

• Nous avons une application mobile sur Android et iOS.
• Nous avons différents environnements pour les fichiers APK et IPA :
  • Dev: com.myapp.dev
  • QA: com.myapp.qa
  • Prod: com.myapp.prod
• Nous scannons depuis le PlayStore et l'AppStore pour scanner la version de production.

-> Nous souhaitons regrouper les tickets Android du Store ou du fichier pour toutes les versions d'environnement. Il en va de même pour iOS. Toutefois, si un problème est corrigé dans le fichier Android, le ticket doit rester ouvert jusqu'à ce que nous ayons le correctif dans TOUTES les versions.

Pour cela, vous pouvez définir un regroupement par identifiants d'application et placer chaque identifiant d'application dans un groupe :

Cas d'usage 4 :

• Nous commercialisons notre application mobile en marque blanche sur Android et iOS.
• Nous avons différents clients pour les fichiers APK et IPA :
• Android: com.android.myapp.customer
• iOS: com.ios.myapp.customer

-> Nous souhaitons regrouper dans un seul ticket les tickets Android des applications en marque blanche.

Ce cas d'usage est similaire au cas d'usage 3, puisqu'il suffit de définir un seul groupe contenant tous les identifiants d'application. Par exemple, ici, nous ajoutons un groupe avec l'expression régulière du client.

Conclusion

La version 2 du système de ticketing d'Ostorlab apporte de la flexibilité : les utilisateurs peuvent définir la logique de regroupement qui correspond à leur flux de travail interne.