Système de remédiation Ostorlab

Ce guide complet est conçu pour vous accompagner à travers les étapes essentielles, vous permettant de naviguer efficacement et d'exploiter les multiples capacités du système de remédiation d'Ostorlab.

Remédiation

Ostorlab fournit des capacités de remédiation pour corriger les vulnérabilités identifiées de manière urgente, diligente et efficace. Ces capacités sont gérées via un système de tickets qui agrège et associe toutes les vulnérabilités à un ticket.

Le système de remédiation peut être utilisé comme un système autonome ou intégré de manière transparente à des systèmes de billetterie tiers comme Jira.

Le système de remédiation offre les capacités suivantes :

• Gérer automatiquement le cycle de vie d'une vulnérabilité pour s'assurer que les correctifs sont vérifiés et permettre le suivi de leur progression.
• Fournir des capacités de gestion des tickets pour définir des priorités, assigner un propriétaire (Owner) et mettre à jour les statuts.
• Collaborer avec les membres de l'équipe au sein de la même organisation ou en invitant des utilisateurs dans votre organisation.
• Définir des politiques (Policies) pour s'assurer que les correctifs sont appliqués en temps opportun et détecter les correctifs manqués pour le suivi et les escalades.
• Collecter des métriques sur la santé de votre programme de sécurité et permettre une prise de décision stratégique basée sur les données.

Cycle de vie des tickets

Ostorlab automatise le cycle de vie des tickets liés aux vulnérabilités détectées. Le cycle de vie des tickets offre les capacités et garanties suivantes :

• Un ticket est automatiquement créé dans le cas d'un problème de sécurité nouvellement détecté. Les détails du ticket contiennent des informations sur la vulnérabilité.

• La plateforme agrégera les occurrences futures de la même vulnérabilité dans le même ticket. L'agrégation se fait par les détails du ticket ; par exemple, toutes les injections SQL auront un ticket unique ou un attribut interne appelé ADN (DNA) qui identifie de manière unique chaque vulnérabilité. L'ADN est calculé en fonction du type de vulnérabilité pour s'assurer qu'elle est identifiée de manière unique.

• Les tickets peuvent être marqués comme corrigés (Fixed).

Pour les tickets corrigés, la plateforme marquera automatiquement le ticket comme vérifié (Verified) si les vulnérabilités sont effectivement absentes des analyses (Scan) futures.

Ou rouvrira le même ticket.

• Les tickets peuvent être marqués comme une exception ou comme un faux positif (False Positive). Les tickets avec exception et les faux positifs sont conservés tels quels lorsque de nouvelles occurrences de la même vulnérabilité sont trouvées.

Les tickets créés manuellement bénéficient également des mêmes capacités de gestion de tickets si une vulnérabilité est assignée au ticket.

Gestion des tickets

Un ticket possède plusieurs paramètres pour refléter l'urgence, la priorité, la propriété, ou la facilité de recherche et de filtrage.

Toutes les modifications apportées à un ticket sont suivies dans la section d'activité (Activity) pour voir qui a fait quoi et quand.

Urgence et priorité

Le ticket a un paramètre de priorité allant de P0 à P3. P0 est le plus urgent et P3 est le moins urgent.

Propriété

Un ticket créé manuellement aura un rapporteur (Reporter). De plus, vous pouvez assigner un propriétaire qui s'assure généralement que les vulnérabilités sont corrigées.

Vous pouvez assigner un ticket à un utilisateur existant qui fait déjà partie de l'organisation, ou à une adresse e-mail externe. Si l'adresse e-mail n'est pas sur la plateforme, elle recevra une invitation à rejoindre l'organisation.

Seul un ADMIN peut approuver l'invitation de l'organisation. Pour ce faire, vous pouvez aller dans la section Organisation / Invitation.

Une fois que l'utilisateur crée un compte et voit son invitation approuvée, les tickets lui seront automatiquement assignés.

Balises

Les tickets peuvent avoir plusieurs balises (Tags) assignées. Un tag a à la fois un nom et une valeur. La séparation des noms de tags et de leurs valeurs permet d'ajouter une signification supplémentaire au ticket. Par exemple, l'ajout d'un tag env avec des valeurs comme prod, qa et test, ou l'ajout d'un tag workstream avec des valeurs comme featureXYZ.

Recherche

Les sections de remédiation offrent de multiples capacités de recherche. La recherche se fait en spécifiant un mot-clé supporté mappé avec la valeur de recherche.

Les mots-clés supportés sont :

• recherche par priorité (Priority), les valeurs vont de P0 à P3.

• recherche par statut de ticket, les valeurs sont OPEN, REOPEN, FIXED, FIXED VERIFIED, EXCEPTION et FALSE POSITIVE.

• recherche par adresse e-mail assignée ou adresse e-mail du rapporteur.

• recherche par le raccourci booléen pour trouver des tickets qui vous sont assignés ou que vous avez signalés, les valeurs sont true et false.

• recherche par nom de tag et valeur de tag.

• recherche par dates de création, de modification, de début et de fin.

La remédiation offre une collaboration à l'échelle de l'organisation. Tout au sein d'une organisation est accessible et visible par tous les membres de la même organisation. Cela inclut l'accès aux analyses, l'accès aux données de vulnérabilité, l'accès aux données de ticket, etc.

La collaboration sur les tickets peut se faire via la section des commentaires ; les commentaires peuvent être mis à jour ou supprimés. Une trace de l'action est enregistrée dans la section d'activité.

Si vous ne pouvez pas partager certaines données entre plusieurs équipes, vous pouvez créer des organisations dédiées pour confiner toutes les interactions au sein de la même organisation. Cela s'applique généralement lorsqu'une application est développée par un tiers externe tandis que d'autres applications sont développées en interne.

Pour ce faire, accédez à votre tableau de bord (Dashboard) et cliquez sur les paramètres (Settings) pour les développer, puis choisissez accès (Access).

Cliquez sur ajouter une organisation, et remplissez les informations de l'organisation.

Pour ajouter un utilisateur, cliquez sur les trois points et choisissez l'option ajouter un utilisateur.

Et remplissez l'adresse e-mail de l'utilisateur.

De plus, l'un des cinq piliers de la sécurité autonome est celui des politiques (Policies).

Il existe plusieurs types de politiques, tels que :

• Politique de correctifs (Patching policy) pour définir quand les vulnérabilités de différentes sévérités doivent être corrigées.

• Politique de fraîcheur (Freshness policy) pour définir le niveau d'obsolescence toléré des logiciels ou matériels exécutés en production.

• Politique d'application (Enforcement policy) pour définir sous quelles conditions un système dangereux peut être mis en quarantaine ou déconnecté.

Ce ne sont là que des exemples de politiques de remédiation. À ce stade, Ostorlab prend uniquement en charge la définition et l'application de la politique de correctifs.

La politique de correctifs définit les SLO (Service Level Objectives) pour gérer les vulnérabilités confirmées et les recommandations de durcissement (Hardening). Un exemple serait de corriger un problème de sévérité élevée (High) dans un délai de cinq jours.

La politique est appliquée par le système de billetterie qui compare l'heure de création du ticket avec la sévérité la plus élevée de la vulnérabilité par rapport à la politique définie.

Bien que la billetterie aide à gérer les routines quotidiennes et garantisse que les éléments soient corrigés et non abandonnés, elle est insuffisante pour avoir une vue holistique des performances d'un programme de sécurité.

Pour cette raison, le système de billetterie est complété par un pilier de métriques et de tableau de bord, le 5ème pilier des programmes de sécurité autonomes.

Le module de métriques collecte plusieurs métriques qui sont soit basées sur le temps, comme le nombre de problèmes de sévérité élevée, le nombre de problèmes corrigés, soit des métriques globales, comme le taux de réouverture, le % d'actifs sécurisés, etc. Ces métriques sont accessibles dans le tableau de bord de l'organisation.

Pour une compréhension plus approfondie de toutes les métriques liées aux tickets, veuillez consulter la documentation disponible via le lien suivant.