Concentrarsi sulla persona giusta

Di Jim Beno - Direttore della User Experience, Skyhigh Security

10 novembre 2022 4 Minuto letto

In quanto azienda che si occupa di sicurezza, gli utenti del nostro prodotto lavorano in genere nell'organizzazione della Sicurezza Informatica (InfoSec). Ma sempre più spesso ci accorgiamo che le nostre funzionalità di Security Service Edge (SSE) si rivolgono a utenti esterni al team di sicurezza: soprattutto nell'Information Technology (IT), ma anche nell'Engineering / Operations. Si tratta di persone che sviluppano e distribuiscono applicazioni nel cloud, controllano l'accesso alle stesse e garantiscono le prestazioni della rete.

Esistono almeno quattro flussi di lavoro o funzioni SSE principali che si rivolgono a ruoli esterni all'organizzazione della sicurezza:

• Concedere l'accesso alle applicazioni - Man mano che le aziende spostano una parte maggiore della loro infrastruttura nel cloud pubblico, devono controllare l'accesso alle applicazioni ospitate. La nostra soluzione Zero Trust Network Access (ZTNA) offre questa funzionalità. La gestione di queste politiche di accesso e la risposta alle richieste di accesso dei dipendenti non sono compito del Security Operations Center (SOC). Si tratta di una responsabilità che spetta all'IT e all'Help Desk IT.
• Gestione dei criteri del firewall - Con tutta questa infrastruttura nel cloud pubblico, per la sicurezza, le aziende devono controllare l'accesso non solo specificando "chi" può utilizzare queste applicazioni - ma anche il "come" - i dettagli di quali protocolli, porte, dispositivi, luoghi, ecc.
• Monitoraggio dell'esperienza digitale - Con uffici dislocati in tutto il mondo e molte persone che lavorano da casa, è inevitabile che alcuni dipendenti abbiano problemi di accesso a un'applicazione o a un servizio. Identificare la portata e la fonte di questi problemi può essere un incubo. Quando arrivano le chiamate all'Help Desk IT, il team di sicurezza non risponderà al telefono.
• Correggere le configurazioni errate e le vulnerabilità - All'interno dell'IT e dell'ingegneria, diversi team possono costruire applicazioni su Amazon Web Services (AWS), Google Cloud Platform (GCP) o Microsoft Azure. Il nostro lavoro consiste nell'aiutare le aziende a proteggere queste applicazioni, sia che si tratti dell'Architetto IT responsabile della loro infrastruttura cloud, sia che si tratti dei proprietari degli account che sviluppano e configurano le applicazioni, sia che si tratti del personale DevOps / DevSecOps che le implementa. Se rileviamo una vulnerabilità o una configurazione errata, il team di sicurezza non ha "le chiavi del castello" per risolvere il problema - dobbiamo portarlo davanti al proprietario dell'IT o dell'Engineering che può apportare la modifica.

Creazione di Personas

In Skyhigh Security, abbiamo ricercatori dedicati agli utenti, il cui compito è capire i clienti e generare intuizioni che informino i requisiti e la progettazione dei prodotti. Per ogni nuova funzionalità del prodotto, dobbiamo assicurarci di rivolgerci all'utente giusto e imparare tutto il possibile su di lui: Cosa li motiva? Quali compiti svolgono? Quali applicazioni o sistemi utilizzano? Come collaborano con gli altri? Quali sono i loro principali punti dolenti?

Iniziamo ponendo queste domande ai membri del team interno della gestione del prodotto e delle vendite. Spesso organizziamo una sessione di lavoro e catturiamo le nostre conoscenze collettive su una lavagna virtuale. Una volta che sappiamo a quali ruoli professionali rivolgerci, intervistiamo i clienti e osserviamo come lavorano. Dopo alcune di queste sessioni, inizieranno ad emergere alcuni temi comuni. Quindi sintetizziamo tutte le intuizioni creando un personaggio immaginario - una "persona" - che diventa il punto focale per la scrittura dei casi d'uso e del design.

Vi presentiamo Fred e Kawika

Ultimamente, i nostri ricercatori hanno studiato due nuove figure responsabili del monitoraggio dell'esperienza digitale e della politica del firewall: "Fred", che lavora nell'Help Desk IT, e "Kawika", l'amministratore di rete. Ecco alcune delle intuizioni che abbiamo appreso da questo dinamico duo:

• Kawika è responsabile delle prestazioni della rete. Quando tutto funziona, la vita è bella. Ma quando le cose vanno male, deve abbandonare tutto ed entrare in azione. Per evitarlo, vuole monitorare in modo proattivo le applicazioni critiche sulla rete - non può aspettare l'arrivo di un gruppo di ticket di problemi.
• Analogamente al SOC, l'IT ha diversi livelli per gestire i problemi di assistenza. Quando un dipendente incontra un problema di accesso a un'applicazione, apre un ticket che viene gestito dall'help desk IT. Ciò significa che Fred sarà il primo a indagare sul problema. Ha un libro di giochi che lo guida nella risoluzione dei problemi. Se sembra che si tratti di un problema di rete, lo inoltrerà al team Rete. Ora è il turno di Kawika.
• La diagnosi di un problema di rete non è facile. L'architettura di rete è complessa. Quando accede a un servizio cloud, il traffico dal dispositivo del dipendente viaggia attraverso molte reti diverse. Ci sono molte variabili che possono influenzare le prestazioni e le condizioni possono cambiare nel tempo. Per indagare su questi problemi, Kawika deve utilizzare molti strumenti e console per ottenere le informazioni necessarie.

Evitare l'ambiguità

Tutti questi dati sono riassunti in schede di una sola pagina che abbiamo creato per Fred, Kawika e i loro colleghi. Organizziamo anche sessioni di formazione per introdurre le personas ai team interfunzionali. Quando sentiamo i product manager e gli ingegneri fare riferimento a una persona per nome, sappiamo di aver fatto il nostro lavoro!

Ogni flusso di progettazione UX in Figma inizia con un artboard che mostra la persona target e il caso d'uso. In questo modo tutti sono sulla stessa pagina ed evitiamo riferimenti ambigui a "l'amministratore" o "l'architetto della sicurezza". Se durante la revisione del progetto qualcuno mette in dubbio la persona target, è fantastico! Accogliamo con piacere questa discussione. In effetti, è proprio così che sono nati Fred e Kawika.

Non c'è niente di peggio che progettare e realizzare una nuova funzionalità, per poi scoprire, dopo il rilascio, che le sue ipotesi sull'utente target erano sbagliate. Potrebbe avere implicazioni significative sul flusso di lavoro e richiedere una revisione completa. È molto meglio investire in una piccola ricerca sull'utente in anticipo per convalidare le sue ipotesi e assicurarsi di essere in linea con l'obiettivo.

Torna ai blog