Réponse aux vulnérabilités Règles de cibles de remédiation
Les règles de cibles de rattrapage définissent le délai prévu pour le rattrapage des éléments vulnérables (VI), tout comme les SLA fournissent un délai pour le rattrapage de la vulnérabilité elle-même. Par exemple, si un actif contient des données PCI (données de carte de crédit), la vulnérabilité de cet élément doit être corrigée dans les 30 jours, conformément à la norme PCI DSS.
- La cible de remédiation
- Cible de rappel
- Destinataires des rappels et des notifications : qui doivent être notifiés lorsque les éléments vulnérables (VI) ont dépassé la date cible de rappel ou de rattrapage et n’ont pas été corrigés.
- Méthode de recalcul : comment le système met à jour la date de la cible de rattrapage (RT) lorsque la cote de risque d’un élément vulnérable change.
Les analystes et les gestionnaires de vulnérabilité peuvent voir la date cible de remédiation dans le formulaire d’élément de vulnérabilité et les vues de liste, tant que les éléments vulnérables ne sont pas à l’état Différé, Résolu ou Fermé. Les règles de cibles de rattrapage sont exécutées lors de l’importation et réexécutées si un VI est rouvert.
- Les éléments vulnérables qui n’ont pas encore atteint leur date de notification sont affichés en vert.
- Les éléments vulnérables approchant de la date cible de rattrapage sont affichés en orange.
- Les éléments vulnérables dépassant la date cible de rattrapage sont affichés en rouge.
Un e-mail récapitulatif, par règle de cible de rattrapage, est envoyé lorsqu’un ou plusieurs éléments vulnérables approchent de leur date cible de rattrapage ou que la date cible de rattrapage est dépassée.
Recalcul de la date cible de rattrapage
À partir de la version 30.1.4 d’Unified Security Exposure Management et de la version 26.4.4 de Vulnerability Response, les administrateurs peuvent configurer la façon dont le système recalcule la date cible de rattrapage lorsque la cote de risque d’un résultat change.
- Dans des conditions normales, le système calcule la date RT comme suit :
Cible de rattrapage = (date) + cible (jours) à partir de la cible
- Lorsque la cote de risque change, le système calcule une nouvelle date de RT à l’aide de la formule ci-dessous. La méthode de recalcul sélectionnée détermine si cette nouvelle date remplace la date de tâche de rattrapage existante.
Date RT recalculée = heure du changement de champ + cible (jours)
L’heure de changement de champ capture le moment où la cote de risque a changé. La cible (jours) utilise le SLA de la nouvelle cote de risque.
| Méthode de recalcul | Description |
|---|---|
| Calcul par défaut | Conserve la date de RT existante. La date recalculée n’est pas appliquée. |
| Recalculer à partir de la date de changement de risque | Met à jour la date cible de rattrapage sur : heure du changement de champ + cible (jours) en fonction de la nouvelle cote de risque. |
| Recalculer depuis la date de changement du risque et tjs définir sur la date cible la plus proche | Compare la date RT existante avec l’heure du changement de champ + la cible (jours) et applique la date antérieure. |
| Recalculer dep. date de changmt du risque et déf. sur date cible la + proche qd cote de risque monte | Si le risque augmente : Compare la date de tâche de rattrapage existante et la date de tâche de rattrapage recalculée et applique la date la plus ancienne. Si le risque diminue : Applique Heure de changement de champ + Cible (jours) sans comparaison. |
Pour connaître les étapes de configuration, reportez-vous à la section Recalculer une date cible de rattrapage.
Les règles de cibles de rattrapage peuvent être désactivées ou supprimées
Lorsqu’une règle est désactivée, les dates cibles de rattrapage actuelles pour les éléments vulnérables auxquels elle a été appliquée sont effacées. Si un VI satisfait à une règle active, cette règle est appliquée, sinon le VI n’a pas de règle ou de date cible, et son état est Aucune cible.
Lorsque des règles sont supprimées, la date cible de rattrapage et les champs associés sur les VI fermés, différés ou résolus sont conservés. La date cible de rattrapage et les champs connexes sur les VI non fermés sont effacés, et toutes les règles dépendantes sont réappliquées.
Scénario de règle de cible de remédiation
À partir de la version 17.1, les cibles de rattrapage sont calculées à partir de la cible à partir du (date). La valeur par défaut reste Dernière date d’ouverture.
Par exemple, si un élément vulnérable remplit la condition de deux règles de cibles de rattrapage :
- Règle de cible de rattrapage 1 : Dernière ouverture le 03/07/2018 ; la cible de rattrapage est de 15 jours depuis sa dernière ouverture ; La date cible de rattrapage calculée est le 16/03/2018 10:00:00.
- Règle de cible de rattrapage 2 : Dernière ouverture le 03/10/2018 ; la cible de rattrapage est de 10 jours depuis sa dernière ouverture ; La date cible de rattrapage calculée est le 03/11/2018 10:00:00.
À propos de la tâche planifiée Évaluer les cibles de remédiation
Evaluate remediation targets s’exécute une fois à 4:00:00 tous les jours.
- ne sont pas à l’état Fermé, Différé ou Résolu .
- N’ont pas de date cible de rattrapage.
- Avoir une date cible de rattrapage ultérieure à la date de la règle de cible de rattrapage.
Evaluate remediation targets Ajoute une date cible de rattrapage, s’il n’en existe pas ou, si une règle aboutit à une date antérieure à celle de l’enregistrement, il met à jour la date cible existante. Enfin, il met à jour les champs Cible de rattrapage et État du rattrapage dans le formulaire d’élément vulnérable.
Une fois le processus Evaluate remediation targets exécuté, les notifications disponibles sont envoyées.
Evaluate remediation targets efface les champs de rattrapage sur le VI et arrête d’envoyer des notifications.
Lorsqu’elle est activée, cette sn_sec_cmn.evaluate_targetmissed_records propriété empêche la tâche planifiée d’évaluer Remediation Target Rules les VI manqués. Cette propriété est activée par défaut.
Réapplication des règles de cibles de rattrapage
Si la tâche planifiée Evaluate remediation targets est en cours d’exécution, vous ne pouvez pas lancer un processus de nouvelle demande. Toutefois, si un processus de réapplication est déjà en cours d’exécution et que la tâche planifiée qu’il a déclenchée s’exécutent en parallèle.
Les processus Réponse aux vulnérabilitésRéponse aux vulnérabilités des applications de réapplication sont indépendants et peuvent s’exécuter en parallèle.