Centrarse en el personaje adecuado

10 de noviembre de 2022

Por Jim Beno - Director de Experiencia del Usuario, Skyhigh Security

Como empresa de seguridad, los usuarios de nuestro producto suelen trabajar en la organización de seguridad de la información (InfoSec). Pero cada vez más, nos damos cuenta de que nuestras funciones Security Service Edge (SSE) se dirigen a usuarios ajenos al equipo de seguridad: sobre todo en Tecnología de la Información (TI), pero también en Ingeniería / Operaciones. Estas son las personas que desarrollan y despliegan aplicaciones en la nube, controlan el acceso a ellas y garantizan el rendimiento de la red.

Existen al menos cuatro flujos de trabajo o funciones principales de la ESS dirigidos a funciones ajenas a la organización de seguridad:

• Concesión de acceso a las aplicaciones - A medida que las empresas trasladan más parte de su infraestructura a la nube pública, necesitan controlar el acceso a las aplicaciones alojadas en ella. Nuestra solución Zero Trust Network Access (ZTNA) proporciona esta capacidad. Gestionar estas políticas de acceso y responder a las solicitudes de acceso de los empleados no es tarea del Centro de Operaciones de Seguridad (SOC). Se trata de una responsabilidad que corresponde a TI y al servicio de asistencia de TI.
• Gestión de la política de cortafuegos - Con toda esta infraestructura en la nube pública, por motivos de seguridad, las empresas necesitan controlar el acceso no sólo especificando "quién" puede utilizar estas aplicaciones, sino también el "cómo", es decir, los detalles de qué protocolos, puertos, dispositivos, ubicaciones, etc.
• Supervisión de la experiencia digital - Con oficinas repartidas por todo el mundo y mucha gente trabajando desde casa, es inevitable que algunos empleados tengan problemas para acceder a una aplicación o servicio. Identificar el alcance y el origen de estos problemas puede ser una pesadilla. Cuando entran las llamadas del servicio de asistencia de TI, el equipo de seguridad no va a coger el teléfono.
• Solucionar errores de configuración y vulnerabilidades - Dentro de TI e Ingeniería, varios equipos pueden estar creando aplicaciones en Amazon Web Services (AWS), Google Cloud Platform (GCP) o Microsoft Azure. Nuestro trabajo consiste en ayudar a las empresas a proteger estas aplicaciones, ya sea el arquitecto de TI responsable de su infraestructura en la nube, los propietarios de cuentas que desarrollan y configuran las aplicaciones o el personal de DevOps / DevSecOps que las despliega. Si detectamos una vulnerabilidad o una configuración errónea, el equipo de seguridad no tiene "las llaves del castillo" para solucionarlo: tenemos que hacer llegar el problema al propietario de TI o de ingeniería que puede realizar el cambio.

Crear personas

En Skyhigh Security, contamos con investigadores de usuarios dedicados cuyo trabajo consiste en comprender a los clientes y generar ideas que informen sobre los requisitos y el diseño de los productos. Para cada nueva capacidad de producto, tenemos que asegurarnos de que nos dirigimos al usuario adecuado y aprender todo lo que podamos sobre él: ¿Qué les motiva? ¿Qué tareas realizan? ¿Qué aplicaciones o sistemas utilizan? ¿Cómo colaboran con los demás? ¿Cuáles son sus principales puntos de dolor?

Empezamos planteando estas preguntas a los miembros del equipo interno de gestión de productos y ventas. A menudo celebraremos una sesión de trabajo y plasmaremos nuestros conocimientos colectivos en una pizarra virtual. Una vez que sepamos a qué funciones debemos dirigirnos, entrevistaremos a los clientes y observaremos cómo trabajan. Tras unas cuantas de estas sesiones, empezarán a surgir algunos temas comunes. A continuación, sintetizamos todos los conocimientos creando un personaje ficticio -una "persona"- que se convierte en el punto central para redactar los casos de uso y el diseño.

Presentación de Fred y Kawika

Últimamente, nuestros investigadores han estado investigando dos nuevos personajes responsables de la supervisión de la experiencia digital y la política de cortafuegos: "Fred", que trabaja en el servicio de asistencia informática, y "Kawika", la administradora de la red. He aquí algunas de las conclusiones que hemos extraído de este dúo dinámico:

• Kawika es responsable del funcionamiento de la red. Cuando todo funciona, la vida es buena. Pero cuando las cosas van mal, debe dejarlo todo y entrar en acción. Para evitarlo, quiere supervisar de forma proactiva las aplicaciones críticas de la red: no puede esperar a que lleguen un montón de tickets de problemas.
• Al igual que el SOC, el departamento de TI tiene diferentes niveles para gestionar los problemas de asistencia. Cuando un empleado encuentre un problema para acceder a una aplicación, abrirá un ticket que será gestionado por el servicio de asistencia de TI. Esto significa que Fred será el primero en investigar el problema. Tiene un libro de jugadas que le guía en la resolución de problemas. Si parece un problema de red, entonces lo derivará al equipo de redes. Ahora es el turno de Kawika.
• Diagnosticar un problema de red no es fácil. La arquitectura de la red es compleja. Cuando se accede a un servicio en la nube, el tráfico del dispositivo del empleado viaja a través de muchas redes diferentes. Hay muchas variables que pueden afectar al rendimiento, y las condiciones pueden cambiar con el tiempo. Para investigar estos problemas, Kawika debe utilizar muchas herramientas y consolas para obtener la información que necesita.

Evitar la ambigüedad

Todas estas percepciones se resumen en hojas de datos de una sola página que hemos creado para Fred, Kawika y sus colegas. También organizamos sesiones de formación para presentar los personajes a los equipos interfuncionales. Cuando oímos a los jefes de producto y a los ingenieros referirse a un personaje por su nombre, ¡sabemos que hemos hecho nuestro trabajo!

Cada flujo de diseño de UX en Figma comienza con una mesa de trabajo que muestra la persona objetivo y el caso de uso. Así todos estamos en la misma página y evitamos referencias ambiguas a "el administrador" o "el arquitecto de seguridad". Si estamos revisando el diseño y alguien cuestiona la persona objetivo, ¡es estupendo! Agradecemos esa discusión. De hecho, así es exactamente como surgieron Fred y Kawika.

No hay nada peor que diseñar y construir una nueva función, sólo para descubrir después de su lanzamiento que sus suposiciones sobre el usuario objetivo eran erróneas. Podría tener implicaciones significativas en el flujo de trabajo y requerir una revisión completa. Es mucho mejor invertir en un poco de investigación sobre el usuario por adelantado para validar sus suposiciones y asegurarse de que está en el buen camino.