Planning : tout ce qui a une date
La page Planning (navigation, sous Alertes) répond à une seule question : qu’est-ce qui arrive à échéance, et quand ? Elle réunit dans une même chronologie tout ce qui a une date dans TechWatchAlert, quel que soit l’écran où cela se traite.
La chronologie
Section intitulée « La chronologie »| Type | D’où vient la date | Où cela se traite |
|---|---|---|
| Échéance de correction | la politique de correction du projet (voir plus bas) | la fiche d’alerte |
| Engagement d’équipe | l’échéance fixée par l’équipe sur une action de correction | la fiche d’alerte |
| Action de correction | l’échéance la plus proche d’un geste (« Passer openssl 3.0.11 → 3.0.15 ») | Alertes › Par action de correction |
| Fin de vie | la fin de vie d’un composant de la stack, ou son plan de sortie | la vue Fin de vie, ci-dessous |
| Revue d’inventaire | la prochaine revue due du projet | la page Stack |
| Exception qui expire | l’échéance d’une atténuation ou d’un risque accepté | Alertes › Exceptions |
| Échéance d’incident | la prochaine étape de déclaration (24 h, 72 h, un mois), si l’organisation suit NIS2 | Incidents |
Les éléments sont groupés par période : En retard, Cette semaine (les 7 prochains jours), Ce mois (jusqu’à 30 jours), Plus tard. Le sélecteur de période les filtre, avec le nombre d’éléments de chacune. Les puces de type et la liste des projets filtrent aussi la chronologie ; une action de correction qui touche plusieurs projets reste visible sous chacun. Une icône rouge signale ce qui presse : CVE exploitée, échéance escaladée, revue en retard, incident important. Un clic ouvre l’écran où l’élément se traite.
Là où la politique de correction tourne, deux vues détaillées complètent la chronologie : Échéances de correction et Fin de vie (le badge de la seconde compte les composants hors support).
Échéances de correction
Section intitulée « Échéances de correction »
- Vulnérabilités / Fin de vie : les deux vues.
- Indicateurs par état, qui sont aussi des filtres, et le taux de respect.
- Filtres : projet, sévérité, criticité.
- Comment l’échéance est-elle calculée ? : l’explication, en bulle.
- Politique de correction : ouvre les Réglages, section Délais de correction.
- Le tableau des CVE ouvertes.
Un clic sur un indicateur filtre le tableau sur cet état ; un second clic retire le filtre. Les chiffres continuent d’annoncer tous les états. Les filtres vivent dans l’adresse de la page : les liens des notifications y arrivent déjà filtrés, et la page se partage telle qu’on la voit. Effacer les filtres apparaît dès qu’un filtre est posé.
Le calcul, tel que l’écran l’explique :
- échéance = première alerte du projet pour la CVE + délai de sa sévérité, multiplié selon la criticité de l’actif (la plus haute des éléments de stack concernés, à défaut celle du projet) ;
- jamais au-delà du plafond exploitation avérée si la CVE est exploitée ; ce plafond est absolu, aucun facteur ne le dépasse ;
- une CVE pas encore notée prend le délai de la sévérité moyenne ;
- une CVE reste ouverte tant que son dossier, commun à l’équipe du projet, n’est pas clos (une alerte que personne n’a encore ouverte compte comme ouverte) ;
- une acceptation de risque approuvée suspend l’échéance ; une demande en attente n’excuse aucun retard.
Avec la politique par défaut (modèle Standard) : critique 7 jours, élevée 30, moyenne 90, faible 180, exploitée 2 jours ; facteurs de criticité vitale × 0,5, importante × 0,75, standard × 1, faible × 1,5. Ces délais sont indicatifs et se règlent dans Réglages.
| Colonne | Contenu |
|---|---|
| CVE | identifiant, sévérité, score, pastille « Exploitée » ; dessous, le projet et la date de détection |
| Criticité | celle de l’élément de stack (pastille pleine) ou, à défaut, celle du projet (pastille atténuée) ; le survol le précise |
| Échéance | la date et le délai appliqué (« Délai 5,25 j », « plafonné (exploitée) ») ; pour un risque accepté, « Risque accepté jusqu’au … » |
| Reste | J-N avant l’échéance, J0 le jour même, J+N de retard |
| État | voir ci-dessous |
| Porteur | la personne assignée au dossier (ligne Assigné à de la fiche d’alerte, voir Assigner le dossier), ou « Non affectée » |
Les états, jugés en jours de calendrier à l’heure de Paris (l’état bascule à minuit) :
| État | Règle (réglages par défaut) |
|---|---|
| Dans les temps | plus de 3 jours avant l’échéance |
| Proche | dans les 3 jours qui précèdent l’échéance, jour de l’échéance compris |
| Dépassée | dès le lendemain de l’échéance |
| Escaladée | dépassée depuis 7 jours ou plus : le responsable de la sécurité est prévenu |
| Risque accepté | une acceptation approuvée suspend l’échéance |
Les 3 et 7 jours sont le rappel avant l’échéance et l’escalade après de la politique de correction. Le taux de respect compte les CVE closes sur les 90 derniers jours et la part closes dans les délais (« 2 sur 2 clôtures, 90 derniers jours »).
Un clic sur une ligne ouvre la fiche d’alerte si vous êtes membre du projet, sinon la fiche de la CVE.
Rappels : le porteur (à défaut les administrateurs du projet) est prévenu quand une échéance devient proche, puis quand elle est dépassée ; le responsable de la sécurité reçoit l’escalade. Chaque étape n’est annoncée qu’une fois par échéance, en une synthèse par projet (workflows NIS2 · Échéances de correction et NIS2 · Escalades au RSSI).
Fin de vie
Section intitulée « Fin de vie »Une version que l’éditeur ne corrige plus n’aura jamais de CVE pour vous prévenir : sa fin de vie est son échéance. Cette vue applique aux composants de la stack le même traitement qu’aux corrections.
- Indicateurs par état (qui filtrent le tableau) : Escaladés, Hors support, Fin de vie sous 180 j (avec le nombre « sans plan de sortie »), Sorties planifiées, Supportés.
- Filtre par projet.
- Catalogue des fins de vie : ouvre la page Fin de vie.
- Le tableau : composant et version en service, criticité, fin de vie, reste (J±N), état, sortie.
- Planifier : ouvre le plan de sortie du composant.
| État | Règle |
|---|---|
| Supporté | fin de vie dans plus de 180 jours |
| Fin de vie proche | fin de vie dans les 180 jours |
| Sortie planifiée | fin de vie passée, plan de sortie daté à venir |
| Hors support | fin de vie passée, sans plan tenu |
| Escaladé | hors support depuis au moins le délai d’escalade de la politique de correction |
Un produit de la stack est rattaché à son cycle par sa version (« 1.1.1t → 1.1.1 ») ; un élément sans version exploitable est compté à part, avec un lien Compléter la stack.
Le plan de sortie dit quand la version sera remplacée, par qui et comment : Sortie prévue le (raccourcis 1, 3 et 6 mois), Porteur (un membre du projet, prévenu si la date est dépassée), Note. Jusqu’à la date prévue, le composant n’est plus compté en retard ; au-delà, il l’est de nouveau et l’escalade reprend. Le plan est journalisé et figure dans le rapport pour la direction ; Effacer le plan le retire. Planifier demande le droit « Attester une revue d’inventaire » sur le projet.
Avis : composant hors support → le porteur (à défaut les administrateurs), escaladé → le responsable de la sécurité (workflows NIS2 · Composants en fin de vie et NIS2 · Escalades au RSSI). Pas d’avis « proche » ici : les abonnements de la page Fin de vie s’en chargent.
La vue Échéances n’a pas d’export ; ses chiffres figurent dans le rapport pour la direction.
Disponible selon votre offre
Section intitulée « Disponible selon votre offre »Le Planning a sa propre fonction d’offre, Planning, incluse dans toutes les offres par défaut. Si l’administration la retire d’une offre, l’entrée porte un cadenas et la page présente l’offre qui l’ouvre. Les actions de correction et les exceptions n’y figurent que si l’offre inclut aussi ces vues. Voir aussi : Abonnement › pages, vues et éléments.