On sait que le tableau de bord ne fonctionne pas quand tout le monde le regarde et que la question qui suit est toujours : « Alors, qu'est-ce qu'on fait ? »
Cela arrive lors des revues du SOC. Cela arrive lors des points d'information de la direction. Cela arrive lorsqu'un analyste ouvre une fenêtre pendant une enquête et passe les premières minutes à essayer de comprendre ce que la page veut dire.
Le tableau de bord n'est pas vide. Ce n'est pas là le problème. Il contient les alertes, les détections, les vulnérabilités, les identités, l'activité d'cloud , le trafic réseau, les données de conformité, l'exposition et de nombreux graphiques nécessaires. Les chiffres évoluent. Les filtres fonctionnent. La page est peut-être même techniquement correcte.
Mais la décision se prend toujours ailleurs.
Il faut que quelqu'un interprète cette tendance. Il faut que quelqu'un sache si ce chiffre est bon ou mauvais. Il faut que quelqu'un détermine s'il s'agit de bruit, d'une dérive, d'une défaillance du système de contrôle ou d'un élément qui mérite d'être examiné dès maintenant.
C'est là que réside l'échec discret de nombreux tableaux de bord de sécurité. Ils n'échouent pas parce qu'ils manquent de données ; ils échouent parce qu'ils laissent à l'utilisateur le soin de mener sa réflexion à son terme.
La plupart des tableaux de bord de sécurité sont conçus à l'envers. On part des données : quelles requêtes peut-on effectuer ? Que peut-on visualiser ? Quel graphique faut-il utiliser ? Quels indicateurs faut-il inclure ?
Pour créer un meilleur tableau de bord, il faut commencer par se poser les questions suivantes : à qui s'adresse-t-il, que cherche-t-on à comprendre, et qu'est-ce qui devrait devenir plus simple après l'avoir consulté ?
Les équipes de sécurité disposent déjà d’une quantité de données bien trop importante pour pouvoir être analysée. Les outils réseau, les fournisseurs d’identité, les agents d’ endpoint , les plateformes d’ cloud , les pare-feu et les applications SaaS génèrent tous des signaux. Chez Vectra AI, nous analysons plus de 8 To d’activité réseau moderne chaque seconde. Si l’on ajoute à cela le reste de l’infrastructure de sécurité moderne, le problème apparaît clairement : obtenir les données n’est pas la partie la plus difficile.
Le plus difficile, c'est de transformer ces données en informations qu'une personne peut comprendre assez rapidement pour agir. Si un tableau de bord ne permet pas aux analystes de déterminer la marche à suivre, il n'apporte pas d'informations pertinentes. Il se contente de renvoyer la charge de l'analyse au lecteur.
Les tableaux de bord sont des expériences utilisateur, pas de simples conteneurs de données
Un tableau de bord est une expérience à laquelle on accède dans des conditions de pression.
Un analyste peut être amené à déterminer si une alerte est sans fondement. Un responsable peut vérifier si un contrôle fonctionne correctement. Un dirigeant peut chercher à comprendre si le risque évolue dans la bonne direction.
Ces personnes s'intéressent peut-être au même environnement, mais elles n'ont pas besoin de la même vue d'ensemble. Lorsque les équipes conçoivent un tableau de bord pour l'entreprise plutôt que pour l'utilisateur, chaque partie prenante se voit attribuer un indicateur, et chaque source de données dispose d'un widget. La page se remplit. Elle semble exhaustive, mais personne ne sait ce qui est le plus important.
Une bonne expérience utilisateur d'un tableau de bord commence par une question plus précise : à qui s'adresse-t-il, et quelle décision cette personne cherche-t-elle à prendre ?
Tous les problèmes de sécurité ne doivent pas nécessairement donner lieu à une alerte
Le secteur de la sécurité a une méthode bien connue pour rendre les données exploitables : générer une alerte. Cela fonctionne lorsqu'un événement est important, rare et relève de la responsabilité d'une équipe capable d'y répondre. Cela fonctionne moins bien lorsque le problème ne se résume pas à un seul événement. Parfois, le véritable problème réside dans la structure même de l'environnement.
Par exemple, la segmentation du réseau.
Une équipe peut souhaiter savoir si deux parties isolées du réseau communiquent entre elles. Une solution consiste à créer un ticket chaque fois qu'un hôte franchit une limite restreinte.
Si cela se produit une fois par semaine, ce ticket pourrait vous être utile.
Si cela se produit 1 000 fois par jour, ces 1 000 tickets ne rendent pas l'organisation 1 000 fois plus sécurisée. Ils imposent à une équipe déjà surchargée une pile de tâches répétitives, sans l'aider à comprendre si la barrière de sécurité présente une faille à un seul endroit, si elle est défaillante partout, ou si elle fonctionne globalement bien à quelques exceptions près.
Un tableau de bord permet de mieux mettre en évidence la situation. Il peut montrer qu’une limite de segmentation présente des défaillances généralisées, qu’une autre ne comporte que quelques exceptions suspectes et que plusieurs autres semblent tenir le coup. D’un seul coup d’œil, l’équipe peut identifier un problème de contrôle systémique, un petit nombre d’événements méritant d’être examinés de plus près, ainsi que des éléments indiquant que certains contrôles fonctionnent comme prévu.
La décision évolue. Au lieu de se demander « Quelle alerte dois-je traiter ensuite ? », l'équipe peut se demander « Quelle mesure de contrôle doit être traitée en priorité ? »
C'est là toute la différence entre le simple fait d'observer des incidents de sécurité et celui de comprendre l'état de la sécurité.
Les pièges courants liés aux tableaux de bord
Les tableaux de bord de mauvaise qualité ne se repèrent pas toujours facilement. Certains des pires ont même l'air impressionnants.
On retrouve ici le tableau de bord stéréotypé des salles d'exposition : un globe terrestre, des lignes qui défilent, des chiffres clignotants et suffisamment d'animations pour donner aux visiteurs l'impression qu'il se passe quelque chose d'important. Il semble prendre vie. Mais si personne ne change d'avis après l'avoir regardé, ce n'est qu'une simple décoration.
Voici ce qui induit en erreur : un tableau de bord qui était autrefois correct, mais qui s’est discrètement décalé. Un champ change. Une source de données cesse de fournir des informations. Une convention de nommage évolue. Les graphiques s’affichent toujours, mais le tableau de bord ne montre plus ce que les utilisateurs pensent qu’il montre. La confiance visuelle peut donner l’impression que des données obsolètes sont plus fiables, et non l’inverse.
On est face à une véritable surcharge : 200 tableaux de bord, dont la moitié sont des doublons, d’anciennes vues d’enquête, des expériences abandonnées et des noms tels que « Copie de Critical Insights ». Le problème n’est plus la visibilité. Il s’agit désormais de la facilité de recherche, de la responsabilité et de la confiance.
Et puis il y a le cas d’orphelin : un tableau de bord qui met en évidence un véritable problème, mais dont personne n’assume la responsabilité de l’analyse, de l’interprétation ou des mesures à prendre. Un tableau de bord n’améliore pas la sécurité par sa simple existence. Il faut que quelqu’un s’intéresse à la question à laquelle il répond et dispose d’un moyen d’agir lorsque la réponse change.
Chaque échec a la même cause profonde : le tableau de bord a été considéré comme un simple support d'informations plutôt que comme une expérience produit facilitant la prise de décision.
Le contexte transforme les chiffres en décisions
Un chiffre hors contexte laisse le lecteur dans le flou : est-ce un chiffre élevé ou faible ? La situation s'améliore-t-elle ou empire-t-elle ? Par rapport à quoi ? Faut-il agir dès maintenant ?
C'est pourquoi la rédaction UX joue un rôle essentiel dans les tableaux de bord. Les libellés, les titres de sections, les textes d'aide, les descriptions et les états vides ne sont pas de simples éléments décoratifs. Ils guident l'utilisateur dans la lecture de la page.
Un tableau de bord utile ne se contente pas d'afficher le volume des détections. Il explique si ce volume a évolué. Il indique où cette évolution est la plus marquée. Il permet à l'utilisateur de passer d'une vue d'ensemble à une analyse approfondie. Il utilise du texte enrichi pour expliquer ce qu'il faut rechercher, pourquoi c'est important et quelles sont les prochaines étapes.
Avant d'ajouter un widget, posez-vous la question suivante : quelle décision devient plus facile à prendre grâce à sa présence ?
Si la réponse n'est pas claire, c'est que ce widget n'a probablement pas sa place ici.
Concevez en vous appuyant sur des questions, et non sur des requêtes
Les meilleurs tableaux de bord ne commencent pas par la question : « Que pouvons-nous visualiser ? »
Ils commencent par des questions telles que :
- Quels sont les systèmes qui enfreignent les limites qui devraient être respectées ?
- Où observe-t-on une activité inhabituelle au sein des données réseau, d'cloud s et d'identité ?
- Quels sont les services et applications d'IA utilisés dans cet environnement ?
- Les mesures de contrôle dans lesquelles nous avons investi donnent-elles les résultats escomptés ?
Une fois que la question est claire, la structure s'impose d'elle-même.
Placez la réponse principale en premier. Présentez ensuite la situation actuelle. Utilisez les tendances pour expliquer si la situation s'améliore ou s'aggrave. Indiquez les points sur lesquels l'équipe doit se concentrer. Placez les tableaux d'analyse plus bas, de manière à ce qu'ils facilitent la prise de décision plutôt que d'obliger l'utilisateur à interpréter d'abord les données brutes.
C'est également là que l'IA peut transformer le flux de travail. Si un utilisateur peut formuler sa question en langage courant, la création de widgets assistée par l'IA peut aider à transformer cette question en requête sous-jacente au widget. L'utilisateur reste maître de la décision et de l'interprétation, mais il n'a plus besoin de partir d'un éditeur SQL vierge.
Choisissez la visualisation en dernier.
Les graphiques linéaires illustrent l'évolution dans le temps. Les graphiques à barres comparent différentes catégories. Les valeurs isolées indiquent un état. Les tableaux facilitent l'analyse. Le texte enrichi fournit du contexte, des conseils issus du guide pratique, des liens et des critères d'escalade.
Ce n'est pas le type de graphique qui importe. C'est la décision qui compte.
L'objectif n'est pas de créer un nouveau tableau de bord
Les équipes de sécurité n'ont pas besoin de tableaux de bord, car le monde manque déjà de graphiques.
Ils ont besoin de tableaux de bord car certaines questions sont trop vastes pour faire l'objet d'une seule alerte et trop complexes pour être traitées à partir de données brutes. Un bon tableau de bord offre un juste milieu. Il aide à identifier une tendance, à appréhender l'ampleur d'un problème et à concentrer les actions là où elles auront le plus d'impact.
Vectra AILes tableaux de bord personnalisés de [nom de la solution] facilitent cette démarche en regroupant les données relatives au réseau, aux identités, à l’ cloud et aux menaces dans des vues que les équipes peuvent adapter à leur propre environnement. La création de widgets assistée par l’IA aide les équipes à transformer des questions de sécurité formulées en langage courant en requêtes qui alimentent des widgets utiles, puis à affiner ces requêtes si nécessaire. Le contexte en texte enrichi et les parcours d’investigation permettent de transformer la vue en un véritable flux de travail, et non en un simple rapport.
Le meilleur tableau de bord n'est pas celui qui comporte le plus de widgets. C'est celui qui aide une équipe à identifier où les risques évoluent, où les contrôles sont efficaces et où une enquête aura le plus d'impact.
Lorsque les tableaux de bord s'appuient sur la décision, ils cessent d'être de simples éléments décoratifs et s'intègrent pleinement au processus de sécurité.
Pour obtenir des conseils pratiques sur la structure, le choix des widgets, le contexte de texte enrichi et la configuration des analyses, consultez le guide des bonnes pratiques pour la création de tableaux de bord.