Vue d’ensemble de Gestion des exceptions

  • Rversion finale: Washingtondc
  • Mis à jour 6 févr. 2024
  • 2 minutes de lecture

    • Lorsque votre organisation n’est pas en mesure de se conformer à une politique, une norme ou une directive de sécurité ou de gestion des vulnérabilités publiée, vous pouvez demander une exception. La gestion des exceptions implique de demander, examiner, approuver ou rejeter des exceptions pour un élément vulnérable (VI) ou une tâche de rattrapage (RT) qui ne peuvent pas être corrigées conformément à la politique.

    Certaines vulnérabilités peuvent ne pas disposer d’un correctif, d’un correctif ou d’une solution existant. Lorsqu’une exception est approuvée, cela signifie également que vous acceptez un risque, car vous reconnaissez et acceptez les conséquences de ne pas remédier à la vulnérabilité.

    Cycle de vie d’une exception

    Définition d’une exception
    Une exception est une demande de report de la correction d’un VI ou d’un RT pour une période spécifiée. Par exemple, en tant que propriétaire de correction, vous pouvez demander une exception si un correctif n’est pas disponible pour une machine.
    Demande d’exception
    En tant que propriétaire du rattrapage, vous pouvez demander une exemption pour un VI ou un RT à l’aide du processus de gestion des exceptions. Une fois que l’approbateur d’exception a approuvé cette demande, le VI ou le RT passe à l’état Différé .
    Approbation d’une demande d’exception
    Les éléments vulnérables ou les éléments de configuration qui ne peuvent pas être corrigés immédiatement sont examinés par des analystes de vulnérabilité, leur risque est évalué et leur report est approuvé jusqu’à ce qu’ils puissent être corrigés. L’approbation d’une demande d’exception peut être un workflow à deux niveaux. Si seul l’approbateur de premier niveau est présent, l’exception peut être demandée et approuvée. Toutefois, s’il n’y a pas d’approbateur de premier niveau, aucune exception ne peut être demandée. Consultez Ajouter un approbateur d’exception pour plus d'informations.
    Remarque :

    À partir de la Vulnerability Response version 15.0, si vous déployez l’application VR pour la première fois, le Flow Designer pour la gestion des exceptions est activé par défaut. Si vous utilisez déjà le workflow, vous pouvez effectuer la mise à jour vers Flow Designer. Dans les deux cas, vous ne pouvez pas le repasser au workflow. Pour configurer des règles d’approbation pour la gestion des exceptions et les faux positifs, reportez-vous à la section Configurer les règles d’approbation pour Exception Management.

    Une fois qu’une demande d’exception pour un VI ou un RT est approuvée, vous pouvez effectuer les actions suivantes :
    • Rouvrir
    • Supprimer
    • Mettre à jour les champs Affectation à ou Groupes d’affectation
    Suivi d’une demande d’exception
    Après avoir émis l’exception, vous pouvez suivre son état à l’aide de l’onglet Approbations de changement d’état du VI ou du RT. Si une action est effectuée sur un RT, vous ne pouvez pas suivre l’état des VI individuels dans ce RT.
    Expiration d’une demande d’exception
    Lorsqu’une demande d’exception pour un VI ou un RT particulier expire, le VI ou le RT impacté revient à son état Ouvert .
    Figure 1. Processus d’approbation de gestion des exceptions avant VR v15.0
    Cycle de vie d’une exception demandée pour un VI ou une tâche de rattrapage. La demande d’exception commence par le propriétaire du rattrapage et se termine par l’approbateur d’exception L2.

    Si un seul VI ou tous les VI d’un RT passent lors de l’analyse suivante, les VI et, le cas échéant, le champ État RT passent à Fermé avec le sous-état Fixe.