Comprender los resultados deseados: cómo seleccionamos el conjunto de funciones de Cloud Defense Free

Cuando decidimos lanzar una versión gratuita de FireMon Cloud Defense sabíamos que tendríamos que equilibrar dos desafíos clave:

• Ya sabíamos que nuestra plataforma podía escalar, pero ¿podríamos adaptarla para escalar de forma económica y dar soporte a grandes empresas a largo plazo? No hace falta decir que no podíamos simplemente lanzarla y esperar que nuestras facturas de AWS no nos llevaran a la quiebra.
• Con las limitaciones económicas, ¿podríamos ofrecer un conjunto de funcionalidades que entregara valor real a los usuarios? ¿Cuál sería ese valor? ¿Qué problemas resolvería?

La realidad es que lo “gratis” nunca es totalmente gratis, ya que usar cualquier cosa requiere tiempo y esfuerzo. No vemos el nivel gratuito de Cloud Defense como migajas que dejamos caer por el borde de la mesa; sabemos que si les pedimos a los usuarios que se registren, implementen y usen la plataforma, solo lo harán si los ayudamos a hacer su trabajo.

(¿Qué obtenemos nosotros? Bueno, sabemos que cierto porcentaje pasará a nuestros planes de pago, pero la plataforma gratuita nos ayudará a obtener comentarios sumamente valiosos sobre lo que la gente quiere de su CSPM y cómo lo usa, y nos permitirá poner a prueba nuevas ideas).

En próximas publicaciones hablaremos de la tecnología con mayor profundidad, pero hoy queremos repasar nuestro proceso para decidir cuáles funcionalidades incluir en el nivel gratuito. Dado que consideramos esta versión de la plataforma como un producto propio, decidimos usar el mismo enfoque metodológico que guía gran parte de nuestra estrategia.

Definición de los resultados deseados

En FireMon somos grandes seguidores del marco Jobs to be Done para la estrategia de producto. El nombre lo delata un poco, pero el marco guía las decisiones de producto enfocándose en qué trabajo intenta hacer el cliente y qué resultados específicos espera. Esta es una simplificación burda del marco JTBD, pero se entiende la idea. En lugar de enfocarse en funcionalidades, uno se enfoca en los resultados deseados de un posible cliente al usar un producto y luego los usa para diseñar funcionalidades.

Tras un proceso exhaustivo que incluyó investigación, experiencia y entrevistas, delimitamos un borrador con posibles resultados deseados para los profesionales de seguridad cloud:

• Mejorar mi conocimiento y comprensión de nuestra postura cloud en toda nuestra huella cloud. (visibilidad)
• Minimizar la probabilidad de que se configure una configuración cloud incorrecta en toda nuestra huella cloud. (prevención)
• Reducir nuestras exposiciones de seguridad y cumplimiento en cloud (volumen y tiempo) en toda nuestra huella cloud dentro de un entorno descentralizado. (remediación)
• Mejorar nuestra capacidad de comunicar los problemas de seguridad cloud a la dirección y a los reguladores.
• Reducir el potencial de pérdida y abuso del acceso IAM a nuestras implementaciones cloud.
• Mejorar nuestra capacidad de prevenir, detectar y responder a los ataques cloud
• Mantener nuestra seguridad actualizada frente a los cambios en los servicios y plataformas cloud de múltiples proveedores.
• Reducir la fricción y la carga de seguridad sobre los equipos de desarrollo y de cloud sin aumentar nuestros riesgos de seguridad.
• Reducir el riesgo de una brecha de seguridad cuando implementamos con contenedores.
• Reducir el tiempo que dedico a integrar la seguridad cloud con mi programa mediante APIs y estructuras de datos estándar.

Claramente hay muchas maneras de abordar cada uno de estos problemas, así que la pregunta para nosotros era: ¿cuáles podríamos ofrecer con las restricciones económicas de operar una plataforma gratuita y alojada? Es muy distinto de ofrecer software de código abierto que alguien debe implementar y ejecutar por su cuenta. Queríamos construir algo tan rápido y fácil de usar como un producto comercial (bueno, ojalá más rápido y fácil que muchos de los productos que ha usado en el pasado).

Traducción de los resultados en funcionalidades

Con esa lista llegó el momento de ver qué podíamos adaptar o construir:

• Mejorar mi conocimiento y comprensión de nuestra postura cloud en toda nuestra huella cloud. (visibilidad)

La postura no se refiere necesariamente solo a la seguridad; la postura es cómo están configuradas las cosas. Dado que entregar simplemente una lista de configuraciones incorrectas no comunicaría la postura, sabíamos que tendríamos que construir un inventario cloud, a escala empresarial, dentro de nuestras restricciones de costos. Nuestra plataforma ya soportaba un inventario en tiempo real, pero no era rentable escalarlo al nivel gratuito.

Decidimos que podíamos equilibrar los costos y aun así aportar valor con escaneos una vez al día y un historial de inventario de 30 días con seguimiento de cambios. Notará que todavía no hablamos de configuraciones de seguridad incorrectas, pero ya llegaremos a eso. Tras realizar algunos modelos de costos, nos dimos cuenta de que podíamos ejecutar esto a escala empresarial (miles de cuentas monitoreadas) dentro de nuestro presupuesto, así que cumplía ambos objetivos: aportar valor y controlar los costos.

Esto en realidad requirió bastante esfuerzo de ingeniería, ya que el producto comercial soportaba principalmente actualizaciones de inventario en tiempo real en lugar de escaneos periódicos. Sin embargo, agrupamos esas actualizaciones con otros cambios que queríamos hacer y que mejoraban la eficiencia general, así que encajaron bien y la decisión fue sencilla.

• Minimizar la probabilidad de que se configure una configuración cloud incorrecta en toda nuestra huella cloud. (prevención)

Prevenir configuraciones cloud incorrectas es un problema mucho más difícil que detectarlas. ¿Se bloquea en el pipeline de CI/CD si usan infraestructura como código? ¿Y los cambios manuales? ¿Cómo se manejan los flujos de trabajo sin añadir demasiada fricción ni romper cosas?

Sabíamos que por ahora no podíamos implementar una prevención completa dentro de un producto gratuito. Nuestra plataforma actual maneja esto mediante automatización, lo que sería demasiado costoso de ejecutar a escala de forma gratuita. Sin embargo, tenemos algunas ideas que podrían funcionar y que ya están en nuestro backlog de desarrollo.

• Reducir nuestras exposiciones de seguridad y cumplimiento en cloud (volumen y tiempo) en toda nuestra huella cloud dentro de un entorno descentralizado. (remediación)

Esto ha sido el pan de cada día de Cloud Defense desde las primeras versiones del producto. Si bien la remediación automatizada no funcionaría para nuestro nivel gratuito (de nuevo, equilibrando costo y complejidad), no había razón para no ejecutar nuestro conjunto completo de verificaciones de seguridad.

Pero obtener una larga lista de posibles problemas de seguridad no necesariamente ayuda a remediarlos. Otra de las capacidades centrales de nuestro producto es la profunda integración con ChatOps. De fábrica soportábamos Slack y Teams, pero Teams requeriría más soporte debido a… bueno… que es Teams. Así que tomamos la decisión de habilitar por completo nuestras notificaciones granulares de Slack (por cuenta o proyecto), ya que no suponía un costo material para nosotros y aportaba mucho valor a los usuarios.

• Mejorar nuestra capacidad de comunicar los problemas de seguridad cloud a la dirección y a los reguladores.

Nuestros costos internos para ejecutar un informe de cumplimiento son insignificantes, incluso en entornos grandes. Para el cumplimiento, las evaluaciones una vez al día suelen cubrir con creces este resultado deseado. Sí tuvimos que dedicar algo de desarrollo nuevo para soportar mejores informes en PDF en implementaciones más grandes (por ejemplo, cientos de cuentas), pero de todos modos lo necesitábamos para nuestros clientes comerciales.

• Mantener nuestra seguridad actualizada frente a los cambios en los servicios y plataformas cloud de múltiples proveedores.

Dado que nuestros productos gratuito y comercial usan la misma biblioteca de verificaciones, que actualizamos constantemente, esto quedó habilitado de fábrica. Nuestro esfuerzo inicial de ingeniería se centró en las optimizaciones de costos para AWS, así que decidimos lanzar sin soporte para Azure ni GCP al principio. Azure está casi listo, por lo que los usuarios eventualmente tendrán soporte multi-cloud completo de forma gratuita.

• Reducir el potencial de pérdida y abuso del acceso IAM a nuestras implementaciones cloud.

Tenemos una funcionalidad bastante impresionante llamada Authorization Control que mejora de forma sustancial la seguridad de IAM, pero las cifras simplemente no cuadraban para incluirla en el producto gratuito.

• Mejorar nuestra capacidad de prevenir, detectar y responder a los ataques cloud

Nuestro producto comercial soporta la detección de amenazas en tiempo real, pero esta fue otra funcionalidad en la que las cifras simplemente no cuadraban para soportarla en una plataforma gratuita, debido al alto volumen de actividad que debemos monitorear de forma continua.

• Reducir la fricción y la carga de seguridad sobre los equipos de desarrollo y de cloud sin aumentar nuestros riesgos de seguridad.
• Reducir el riesgo de una brecha de seguridad cuando implementamos con contenedores.
• Reducir el tiempo que dedico a integrar la seguridad cloud con mi programa mediante APIs y estructuras de datos estándar.

Todos estos resultados añadían costos o complejidad que no creíamos poder abordar adecuadamente en el producto gratuito, ya fuera por costos de infraestructura, de soporte o de desarrollo.

Definición del conjunto de funcionalidades

Los resultados deseados, combinados con nuestro análisis de costos, nos ayudaron a decidir qué funcionalidades incluir:

• Escaneos una vez al día
• Inventario de recursos con un historial de 30 días
• El conjunto completo de verificaciones de seguridad
• Informes de cumplimiento fundamentales
• Integración con Slack
• AWS por ahora; Azure y GCP a medida que actualicemos la plataforma

No siempre fueron decisiones fáciles. Por ejemplo, incluso un inventario de 30 días conlleva costos, pero no creíamos que limitarnos a entregar informes de configuraciones incorrectas cubriera adecuadamente las necesidades de visibilidad de un usuario. También decidimos que limitar nuestras verificaciones de seguridad o exigir que alguien pasara al producto comercial para obtener informes de cumplimiento daría como resultado un producto que en realidad no ofrecería un resultado suficiente.

Este conjunto aborda los resultados deseados centrales de visibilidad de seguridad, y los resultados de comunicación para mejorar los informes y reducir los plazos de remediación. Y sabemos que aquí hay valor, ya que estos son los resultados deseados que las primeras herramientas de código abierto de seguridad cloud se propusieron abordar, y fueron el origen de todo el mercado de Cloud Security Posture Management.

El marco JTBD realmente nos ayudó a mantener el enfoque en mejorar los resultados para el cliente, en lugar de simplemente desprender algunas funciones que, en conjunto, no realmente le sirven a nadie. Creemos que el resultado final es una plataforma gratuita que entrega valor real y, a la vez, es tan eficiente en costos que podemos mantenerla a largo plazo.

Pruébela y díganos qué opina. FireMon Cloud Defense es un trabajo en curso y una excelente manera de mejorar nuestra capacidad de ayudar a los profesionales de seguridad cloud a realizar su trabajo.