--- sourceDocument: Gestion de la sécurité Xanadu sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/xanadu/security-management Release : - xanadu ft:locale : - fr-FR ft:publication_title : - Gestion de la sécurité Xanadu ft:clusterId : - security bundleId : - security workflow : - Technology --- # Vue d'ensemble des règles d'exception # Vue d'ensemble des règles d'exception {#ariaid-title1} * Rversion finale: Xanadu * * Mis à jour 1 août 2024 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes de lecture Les règles d'exception vous Réponse aux vulnérabilités permettent d'automatiser le processus de report pour les éléments vulnérables (VI). Demandez une exception pour les éléments vulnérables (VI) qui ne peuvent pas être corrigés ou différés immédiatement, en identifiant les vulnérabilités, éléments de configuration (CI) ou VI impactés. Différer les éléments vulnérables correspondants en fonction de la règle lorsque le système les identifie en automatisant le processus de report des éléments vulnérables. Utilisation des règles d'exception dans votre organisation Utilisez les règles d'exception pour différer automatiquement les VI nouveaux et existants pour une période spécifique s'ils correspondent à la condition de règle approuvée. L'automatisation minimise le risque de manquer les accords sur les niveaux de service et facilite la gestion de plusieurs éléments, car vous éliminez les interventions manuelles. Les règles de report prennent en charge la fonction de classement, c'est-à-dire que la règle ayant la priorité la plus élevée est exécutée en premier. Lorsqu'une règle de priorité élevée est appliquée à un élément vulnérable, aucune règle subséquente n'est réappliquée à celui-ci, même si la condition correspond au élément vulnérable. Remarque : * Vous ne pouvez créer des règles que si vous les sélectionnez Réponse aux vulnérabilités dans la configuration Gestion des exceptions. Pour plus de détails, voir [Configurer la gestion des exceptions pour Réponse aux vulnérabilités](https://servicenow-prod.fluidtopics.net/_zQlaB4hTXah~Q4MPcsnRg "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 à un élément vulnérable (VI) ou à une tâche de rattrapage (RT) qui ne peuvent pas être corrigés conformément à la politique."). * Lorsque les VI sont différés par une règle d'exception, ils sont copiés dans le groupe de vulnérabilité de report (VG) créé. Les VI continuent de faire partie des groupes de vulnérabilité dont ils faisaient partie auparavant. {#vi-classification-rule-based__ul_ofx_r3h_kyb} Le cycle de vie d'une règle d'exception est le suivant : * Création d'une règle d'exception * Approuver une demande de règle d'exception * Activation d'une règle d'exception * Différer une règle d'exception * Expiration d'une règle d'exception {#vi-classification-rule-based__ul_mhc_1nn_2nb} Création d'une règle d'exception Vous pouvez créer une règle d'exception pour différer automatiquement les VI qui correspondent aux conditions définies pour la période spécifiée. Après avoir créé une règle d'exception, soumettez-la pour approbation. Approuver une demande de règle d'exception L'approbation d'une demande de règle d'exception est un processus à deux niveaux. Si seul l'approbateur de premier niveau est présent, la règle d'exception peut être évaluée et approuvée par une seule approbation. Toutefois, s'il n'y a pas d'approbateur de premier niveau, une approbation de règle d'exception ne peut pas être approuvée. Une fois la règle approuvée, une tâche de rattrapage (RT) est créée. Consultez [Approuver une demande de règle d'exception](https://servicenow-prod.fluidtopics.net/66IZ7ZIStG~2CCYZ5m95pg "évaluer les demandes de règles d’exception émanant des utilisateurs afin de pouvoir approuver ou rejeter ces demandes.") pour plus d'informations. Remarque : À partir de la Réponse aux vulnérabilités version 15.0, si vous déployez l'application VR pour la première fois, le concepteur de flux pour la gestion des exceptions est activé par défaut. Si vous utilisez déjà le workflow, vous pouvez effectuer une mise à jour vers Flow Designer. Dans les deux cas, vous ne pouvez pas le repasser en workflow. Pour configurer des règles d'approbation pour la gestion des exceptions et des faux positifs, reportez-vous à la section [Configurer les règles d'approbation pour la gestion des exceptions](https://servicenow-prod.fluidtopics.net/h7g17pFPY7z8NB9MnI59YA "À partir de la Réponse aux vulnérabilités version 15.0, utilisez le concepteur de flux pour approuver les demandes d’exception pour la gestion des exceptions, les règles d’exception et la gestion des faux positifs. Si vous déployez Réponse aux vulnérabilités (VR) pour la première fois, Flow Designer est activé par défaut."). Une fois qu'une demande de règle d'exception est approuvée, vous pouvez effectuer les actions suivantes : * Annuler * Supprimer {#vi-classification-rule-based__ul_h32_y22_4lb} Activation d'une règle d'exception Après l'approbation d'une règle d'exception, une tâche de rattrapage est créée à l'état Différé par défaut. À partir de la date de début de validité, la règle d'exception s'exécute sur tous les VI créés, ainsi que sur ceux qui passent de l'état Fermé à l'état Ouvert. Remarque : Si vous activez l'option Exécuter sur les données existantes, une tâche planifiée s'exécute une fois sur les données existantes à la date de début de validité. Différer une règle d'exception Vous pouvez différer les VI qui correspondent aux conditions définies dans cette règle d'exception, jusqu'à la date \<\< Reporté jusqu'à \>\> définie pour la règle. À cette date, la tâche de rattrapage que vous avez créée pour la règle d'exception est fermée et tous les VI de ce groupe reviennent à l'état Ouvert. Des règles de groupe leur sont à nouveau appliquées pour les allouer aux RT requis. Expiration d'une règle d'exception Une fois la règle d'exception expirée, elle ne s'exécute plus sur les VI nouveaux ou rouverts. Le RT associé reste dans l'état Différé jusqu'à la date \<\< Reporté jusqu'à \>\>. Figure 1. Flux de travail des règles d'exception antérieur à la version 15.0