Se concentrer sur le bon Persona

Par Jim Beno - Directeur de l'expérience utilisateur, Skyhigh Security

10 novembre 2022 4 Lecture minute

En tant qu'entreprise de sécurité, les utilisateurs de notre produit travaillent généralement dans l'organisation de la sécurité de l'information (InfoSec). Mais nous constatons de plus en plus que nos fonctionnalités Security Service Edge (SSE) s'adressent à des utilisateurs extérieurs à l'équipe de sécurité : principalement dans les technologies de l'information (IT), mais aussi dans l'ingénierie et les opérations. Ce sont eux qui développent et déploient les applications dans le nuage, qui en contrôlent l'accès et qui assurent la performance du réseau.

Il existe au moins quatre grands flux de travail ou caractéristiques de l'ESS ciblant des rôles en dehors de l'organisation de sécurité :

• Autoriser l'accès aux applications - À mesure que les entreprises déplacent une plus grande partie de leur infrastructure vers le nuage public, elles doivent contrôler l'accès aux applications qui y sont hébergées. Notre solution Zero Trust Network Access (ZTNA) offre cette possibilité. La gestion de ces politiques d'accès et la réponse aux demandes d'accès des employés ne sont pas du ressort du centre des opérations de sécurité (SOC). Cette responsabilité incombe au service informatique et au service d'assistance informatique.
• Gestion de la politique de pare-feu - Avec toute cette infrastructure dans le nuage public, les entreprises doivent, pour des raisons de sécurité, contrôler l'accès non seulement en spécifiant "qui" peut utiliser ces applications, mais aussi le "comment" - les détails concernant les protocoles, les ports, les appareils, les lieux, etc.
• Contrôle de l'expérience numérique - Avec des bureaux répartis dans le monde entier et de nombreuses personnes travaillant à domicile, il est inévitable que certains employés rencontrent des problèmes pour accéder à une application ou à un service. Identifier l'étendue et la source de ces problèmes peut être un cauchemar. Lorsque le service d'assistance informatique reçoit des appels, ce n'est pas l'équipe de sécurité qui va décrocher le téléphone.
• Corriger les erreurs de configuration et les vulnérabilités - Au sein des services informatiques et d'ingénierie, diverses équipes peuvent développer des applications sur Amazon Web Services (AWS), Google Cloud Platform (GCP) ou Microsoft Azure. Notre travail consiste à aider les entreprises à sécuriser ces applications, qu'il s'agisse de l'architecte informatique responsable de leur infrastructure cloud, des propriétaires de comptes qui développent et configurent les applications, ou du personnel DevOps / DevSecOps qui les déploie. Si nous détectons une vulnérabilité ou une mauvaise configuration, l'équipe de sécurité n'a pas "les clés du château" pour y remédier - nous devons présenter le problème au responsable informatique ou au responsable de l'ingénierie qui peut effectuer le changement.

Création de personas

À l'adresse Skyhigh Security, nous avons des chercheurs spécialisés dans l'étude des utilisateurs dont le travail consiste à comprendre les clients et à générer des idées qui influencent les exigences et la conception des produits. Pour chaque nouvelle capacité de produit, nous devons nous assurer que nous ciblons le bon utilisateur et apprendre tout ce que nous pouvons sur lui : Qu'est-ce qui les motive ? Quelles tâches accomplissent-ils ? Quelles applications ou quels systèmes utilisent-ils ? Comment collaborent-ils avec les autres ? Quelles sont leurs principales difficultés ?

Nous commençons par poser ces questions aux membres de l'équipe interne de gestion des produits et de vente. Nous organisons souvent une séance de travail et consignons nos connaissances collectives sur un tableau blanc virtuel. Une fois que nous savons quels rôles professionnels cibler, nous interrogeons les clients et observons leur façon de travailler. Après quelques séances de ce type, des thèmes communs commencent à émerger. Nous synthétisons alors toutes les idées en créant un personnage fictif - un "persona" - qui devient le point focal pour la rédaction des cas d'utilisation et de la conception.

Présentation de Fred et Kawika

Dernièrement, nos chercheurs ont étudié deux nouveaux personas responsables du suivi de l'expérience numérique et de la politique en matière de pare-feu : "Fred", qui travaille au service d'assistance informatique, et "Kawika", l'administrateur réseau. Voici quelques-uns des enseignements que nous avons tirés de ce duo dynamique :

• Kawika est responsable de la performance du réseau. Quand tout fonctionne, la vie est belle. Mais lorsque les choses tournent mal, il doit tout laisser tomber et passer à l'action. Pour éviter cela, il veut surveiller de manière proactive les applications critiques sur le réseau - il ne peut pas attendre qu'un tas de tickets d'incident lui parviennent.
• Tout comme le SOC, l'informatique dispose de différents niveaux pour traiter les problèmes d'assistance. Lorsqu'un employé rencontre un problème d'accès à une application, il ouvre un ticket qui est traité par le service d'assistance informatique. Cela signifie que Fred sera le premier à enquêter sur le problème. Il dispose d'un guide pour l'aider à résoudre les problèmes. S'il s'agit d'un problème de réseau, il le transmettra à l'équipe Réseau. C'est maintenant au tour de Kawika.
• Il n'est pas facile de diagnostiquer un problème de réseau. L'architecture du réseau est complexe. Lorsqu'il accède à un service en nuage, le trafic provenant de l'appareil de l'employé traverse de nombreux réseaux différents. De nombreuses variables peuvent affecter les performances, et les conditions peuvent changer au fil du temps. Pour étudier ces problèmes, Kawika doit utiliser de nombreux outils et consoles afin d'obtenir les informations dont il a besoin.

Éviter l'ambiguïté

Toutes ces informations sont résumées sur des fiches de données d'une page que nous avons créées pour Fred, Kawika et leurs collègues. Nous organisons également des sessions de formation pour présenter les personas aux équipes interfonctionnelles. Lorsque nous entendons les chefs de produit et les ingénieurs citer un persona par son nom, nous savons que nous avons fait notre travail !

Chaque flux de conception UX dans Figma commence par un artboard montrant le persona cible et le cas d'utilisation. De cette façon, tout le monde est sur la même longueur d'onde et nous évitons les références ambiguës à "l'administrateur" ou "l'architecte de la sécurité". Si, lors de l'examen de la conception, quelqu'un remet en question la personne cible, c'est très bien ! Cette discussion est la bienvenue. En fait, c'est exactement comme cela que Fred et Kawika ont vu le jour.

Il n'y a rien de pire que de concevoir et de réaliser une nouvelle fonctionnalité pour découvrir, après sa sortie, que vos hypothèses sur l'utilisateur cible étaient erronées. Cela peut avoir des conséquences importantes sur le flux de travail et nécessiter une refonte complète. Il est de loin préférable d'investir dans une petite étude sur les utilisateurs dès le départ pour valider vos hypothèses et vous assurer que vous êtes sur la bonne voie.

Retour à Blogs