Le piège du N3 Sécu, j'aurais jamais dû accepter
Retour Terrain : comment j’ai accepté que l'équipe cybersécurité soit embarqué dans le N3 et les leçons apprises
Il a quelques temps, dans une entreprise, dont on ne donnera pas le nom et le secteur d’activité, je reçois un message Teams du Responsable Support.
** Disclaimer : Histoire un peu modifiée, inspirée de faits réels, vocation à partager l’expérience et la méthode appliquée et ses limites **
Il me dit, Téodor il faut que l’on discute ce serait pas mal d’intégrer l’équipe cybersécurité dans les tickets, je dis pourquoi pas, erreur je vous raconte.
Contexte
L’équipe support a pour objectif cette année, comme beaucoup d’équipes support j’imagine de diminuer le nombre de tickets et la durée de prise en charge. L’idée est globalement d’améliorer la performance de l’équipe support et d’augmenter aussi le niveau de service ressenti par l’équipe.
Un des axes de Travail est ce qu’ils appellent le N3 : niveau de support 3. Celui-ci est généralement réalisé par les IT Owner et les équipes Tech, donc en gros, soit les éditeurs / prestataire quand ce sont eux qui sont en charge soit par les équipe internes de la DSI, hors support.
En l’occurrence, il y a régulièrement des tickets en pratique qui concernent la cybersécurité, usurpation d’identité, signalement de phishing vol de poste de travail, etc … et le support gère plutôt bien ce premier niveau.
Sur certains sujets, l’équipes cybersécurité est sollicitée par l’équipe cybersécurité via Teams, appel téléphonique etc .. ce qui est n’est pas toujours optimal des 2 côtés.
Je suis donc à la base ultra favorable à l’intégration dans leurs workflow de l’équipe cybersécurité.
Ce qu’il s’est passé en pratique
Bon, en pratique, les premiers retours sont plutôt très bons. On est rapidement intégrés dans des tickets et sur des incidents que l’on ne connaissait pas et qui méritaient une attention particulière. Exemple vol d’un PC et d’un smartphone d’un DG d’une filiale à son domicile. On prend les actions qui vont bien.
Un nouveau workflow compliqué
L’outil principal de travail de l’équipe cybersécurité est finalement notre propre outil de suivi de sécurité. On a réussi avec le temps à intégrer les alertes de sécurité des outils tiers dans notre outil de sécurité, basique kanban mais qui marche bien.
Là on se retrouve à devoir consulter à la main d’autres alertes, les qualifier, avant de les prendre en charge. La gymnastique est honnêtement un peu compliqué.
Des tickets qui mettent trop de temps à fermer
C’est pas une surprise les tickets cybersécurité peuvent mettre plusieurs semaines voir mois à se résoudre, et du coup, de notre côté il n’est pas question de fermer un ticket tant que l’incident cybersécurité n’est pas clôturé.
Et là, on est rentré dans le cercle vicieux des tickets à fermer rapidement avec une pression du management pour que le N3 sécurité ne vienne pas pourrir les tickets de sécurité. Et normal, l’objectif initial était bien de réduire le temps par tickets et montrer une améliorer de la performance. On vient casser notre dynamique.
Des tickets pas du tout cybersécurité
Et là, ça a été le gros gros problème. L’objectif pour l’équipe support a été de rapidement montrer une amélioration de la prise en charge des tickets et la durée.
Sur les premières semaines, globalement, on a été sollicité que sur les cas réellement cybersécurité. Puis on a commencé à avoir des tickets de demande de validation de comptes d’administration ou d’applications.
En pratique, l’équipe support ne savait pas forcement qui devait valider ce genre de demande, et pas au niveau de la DSI, ce genre de demande n’était pas forcement traité systématiquement de la même manière.
Du coup, solliciter l’équipe cybersécurité pour des demandes où il y avait un doute et de toute façon il y a souvent sollicitation de la cybersécurité c’est pertinent. Mais du coup en pratique, on s’est retrouvé à devoir valider l’usage de logiciels ou de matériel sans que la DSI soit réellement informé.
Des tickets en débordement dans les périodes de pic
Le support, du fait de la nature de l’activité de l’entreprise, n’a pas une charge lisse toute l’année. Certains mois ont des pics, avec des personnes venant travailler juste l’été, ou en septembre par exemple, retour de vacances, beaucoup de tickets de personnes ayant oublié leur mot de passe.
Et donc, à certaines périodes de l’année, l’équipe support est en buffer over flow, avec un nombre de tickets qui explosent la capacité de traitement de l’équipe mobilisée.
Et dans ces périodes tendues, on a reçu des tickets qui n’avaient rien à voir avec la sécurité informatique. Des demandes de support de logiciel, des disfonctionnement de logiciel.
Ma vision est que le N2 avait besoin de l’appuie du N3 et a eu tendance à passer moins de temps à qualifier et envoyait les demandes le plus vite possible, quitte à se tromper et à maintenir un niveau de performance correct.
Plan d’Action
Du coup, avec le recul, nous n’aurions pas dû accepter d’être intégré dans le N3, malgré la bonne intention. Voici un plan d’actions qui a été mise en place pour aider à résoudre le problème initial.
Faire un point régulier sur le traitement des tickets cybersécurité
Il a été convenu qu’un analyste sécurité puisse faire un point mensuel avec le support pour vérifier s’il y a des tickets cybersécurité en souffrance.
Une revue assez simple par tickets qui sont ouvert depuis trop longtemps et vérifier le taggage du ticket sur le bon département.
Fermer les tickets cybersécurité en incident dans l’outil de support
Il a été convenu que lorsqu’un ticket concerne un incident cybersécurité, il est fermé dans le support. L’action du support étant effectivement terminée.
Et du coup, les incidents de sécurité sont bien suivies dans l’outil d’incidents cybersécurité, plus de doublons.
Sortir l’équipe cybersécurité du workflow support
L’équipe support a laissé des membres de l’équipe cybersécurité pour pouvoir consulter les tickets à la demande.
En revanche le N3 sécurité a disparu du workflow de prise en charge cybersécurité;
Conclusion
L’intégration de l’équipe cybersécurité en mode N3 n’a pas été forcement un grand succès de mon point de vue, et malgré la bonne intention les effets de bords sont trop complexes.
En revanche, je reste convaincu de la nécessité d’une collaboration rapprochée entre la cybersécurité et l’équipe support.
Ressources CyberLead
Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :
