Solución innovadora para la gestión de secretos

Ante el enorme volumen de gestión de contraseñas que se genera en nuestra organización, hemos decidido automatizar una serie de procesos para ahorrar un tiempo muy valioso y mejorar la calidad de nuestro trabajo. ¿El objetivo? Gestionar los incidentes relacionados con las contraseñas de una forma diferente a como se haría con una herramienta convencional, como un SIEM o incluso un SOAR.

Introducción

Cada año, la empresa NordPass publica un informe con estadísticas sobre las contraseñas más utilizadas, clasificadas por categorías (comercio electrónico, redes sociales...) y en los 35 países que abarca el estudio. El resultado no es muy alentador... «123456» y sus variantes, «admin» y «password» se encuentran entre las 10 contraseñas más utilizadas [1]. Y, por desgracia, esto no ocurre solo en el ámbito privado, ya que las contraseñas analizadas también procedían de la dark web y de filtraciones de datos de empresas. El problema está, pues, planteado: las contraseñas no solo no son lo suficientemente seguras, sino que a veces se almacenan donde no deberían.

Contexto

Esta es la constatación que se hizo en la empresa para la que trabajé. Sin embargo, la política de contraseñas está bien definida, con normas básicas en materia de seguridad y almacenamiento cifrado. Además, el cliente proporciona a sus empleados los medios para almacenar e intercambiar estos datos de forma totalmente segura. Por lo tanto, es necesario instalar un sistema de vigilancia en torno a estos datos tan sensibles en los espacios de almacenamiento compartidos de la empresa. Ese fue el objetivo de mi misión: mejorar el proyecto Password Hunting, que en aquel momento aún se encontraba en una fase incipiente.

De hecho, cuando me incorporé al proyecto Password Hunting, este contaba con una herramienta de detección en la que se habían desarrollado unas reglas que se activaban en un ámbito definido de archivos «sin cifrar». También se había establecido un primer proceso de tratamiento. Sin embargo, ante el volumen de detecciones (¡100 000 al mes!), a pesar de que se había reducido el ámbito de aplicación, la carga de trabajo para procesar todas estas detecciones había desbordado al equipo. Es impensable que el RSSI pueda gestionar todo esto por sí solo, por lo que el primer proceso de tratamiento especificaba que los propietarios de los archivos detectados debían corregir ellos mismos las detecciones. Entonces surgió un problema: ¿cómo definir y automatizar al máximo la cadena completa de procesamiento para ganar el tiempo necesario para cubrir todos los espacios de almacenamiento compartidos?

Logros

Lo que llevaba mucho tiempo era el análisis y el procesamiento:

• Analizar las detecciones una por una y anotar el resultado en una hoja de cálculo (lo cual llevaba mucho tiempo),
• A continuación, extraer periódicamente los casos confirmados y, para cada uno de ellos, enviar un correo electrónico al empleado en cuestión,
• Hablar de vez en cuando con el colaborador para que encuentre el archivo que debe corregir y, finalmente, recabar su respuesta.

Todo eso no era sostenible y, de hecho, era imposible llevarlo a cabo al 100 % sin contar con un equipo numeroso, dado el volumen de trabajo. Por eso, trabajé en todo el proyecto partiendo de las cuestiones básicas:

• ¿Qué? O, dicho de forma más clara, ¿qué es lo que se detecta? A primera vista, la respuesta a esta pregunta es bastante sencilla: las contraseñas. Sin embargo, este concepto puede ampliarse a todo tipo de claves de acceso, ya que las contraseñas no se utilizan en todas partes (y menos mal). Están las contraseñas, las claves (API, nube...), los tokens, los certificados... Y, según las normas de la empresa, no todos tienen los mismos formatos. Detectar secretos en sentido amplio requiere una definición clara y precisa; de lo contrario, la tasa de falsos positivos es demasiado elevada. Como ya se había realizado un primer trabajo sobre este punto y se habían creado reglas de detección, dejé de lado la mejora de estas reglas y no las retomé hasta el final.
• ¿Dónde? En el sentido de: ¿dónde detectar esos datos sensibles? Esta cuestión es crucial porque, según la experiencia del equipo, el volumen generado podría ser demasiado grande como para llevar a cabo simultáneamente tanto la actividad de ejecución (es decir, procesar las detecciones) como la de desarrollo (automatizar y mejorar el proceso). Así que empecé por reducir aún más el primer perímetro que se había definido, con el fin de reservar tiempo para automatizar en paralelo, sin dejar de contar con una muestra representativa de lo que se puede detectar.
• La cuestión más importante aquí es el «cómo». Hay varias cuestiones subyacentes a este punto:
  • ¿Cómo se hace? En este sentido, el proceso se asemeja a los procesos de desarrollo clásicos:
    • Detectar
    • Analizar
    • Tratar
    • Solucionar
    • Vigilar
    • Mejorar
  • Y las preguntas para definir cada etapa del proceso:
    • ¿Cómo detectarlo?
    • ¿Cómo se analiza?
    • ¿Cómo tratarlo?
    • ...

Lo esencial: explicar el proceso completo.

1. Cómo detectar

Este punto es el más rápido. Como ya he dicho, a mi llegada ya existía una herramienta de detección, Netskope, con las reglas de detección implementadas. Sin embargo, se había previsto que la herramienta no se pudiera utilizar para los espacios de almacenamiento locales, para los que se utilizaría otra herramienta (Forcepoint). En el ámbito restringido definido, esta herramienta aún no se utilizaba, pero había que prever la integración de las detecciones procedentes de ella también.

Las reglas de detección se dejaron tal cual en un primer momento, a la espera de definir las siguientes etapas del proceso. Al final de mi misión, se revisaron teniendo en cuenta las normas del cliente, con el fin de poder priorizar las detecciones de forma más pertinente. Hasta ahora, ninguna detección tenía prioridad sobre otras, a pesar de que una contraseña no tiene la misma importancia que un token, por ejemplo. Para ello, fue necesario trabajar en la definición de un secreto y crear varias reglas con niveles de criticidad bien diferenciados para clasificar los tipos de secretos por orden de criticidad según el cliente. La idea de esta priorización es que, cuando el cliente amplíe el perímetro de detección, pueda hacerlo de forma progresiva centrándose primero en los tipos de secretos más críticos, sin que se dispare el volumen de detecciones.

2. Cómo analizar, tratar y solucionar

Dado que estaba previsto contar con varias herramientas de detección, no tenía sentido utilizar directamente dichas herramientas para el análisis, al menos no sin antes encontrar una forma de reunir las detecciones en un mismo lugar para tener una visión general de las alertas. Por lo tanto, se necesitaba una herramienta adicional para obtener esa visión general. Para ello, se compararon dos herramientas:

• La herramienta SIEM Splunk, una solución clásica y muy utilizada para recopilar todos los eventos en un mismo lugar, con la capacidad añadida de sintetizarlos en paneles de control y crear reglas,
• El ecosistema de herramientas de Microsoft PowerPlatform, compuesto por PowerAutomate, para crear procesos automatizados; PowerApps, para la creación de aplicaciones; y Power BI, para la visualización de datos. A diferencia de Splunk, que ofrece una aplicación básica, las herramientas de Microsoft permiten crear una herramienta «a medida», totalmente personalizable.

Se realizó una rápida comparación entre estas dos herramientas, lo que llevó a optar por las herramientas de Microsoft Power Platform. De hecho, estas permitían crear una aplicación más acorde con lo que se quería hacer, una aplicación que, además, podría evolucionar más rápidamente, dado que la herramienta solo la utilizaría el equipo de Password Hunting. El argumento decisivo fue también el hecho de que Splunk no permite (de forma sencilla) enviar notificaciones a los usuarios y recopilar sus respuestas de forma automática. Además, las herramientas de Power Platform están integradas en las herramientas de comunicación de la empresa (Outlook, Teams), y la herramienta ya se había empezado a utilizar antes de mi llegada.

El siguiente paso fue desarrollar la aplicación y los procesos con estas herramientas, lo que permitiría:

• Analizar las detecciones desde la aplicación (con posible redirección a las herramientas de detección si es necesario),
• Enviar campañas de notificaciones a los usuarios para gestionar los casos confirmados,
• Hacer un seguimiento de las medidas correctivas aplicadas por los usuarios observando cómo responden a las notificaciones que se les envían.

PowerApps nos ha permitido crear la interfaz desde la que el equipo analiza las detecciones y controla el envío de las campañas. La interfaz se ha personalizado para reducir al máximo el tiempo de análisis. El envío de las campañas se activa desde la aplicación (con solo pulsar un botón) y se gestiona mediante flujos de PowerAutomate (el equivalente a los scripts). Los flujos de PowerAutomate interactúan con la aplicación Microsoft Approvals, que permite enviar solicitudes a los usuarios a través de Teams u Outlook y recopilar sus respuestas. Los datos se almacenan en una base de datos de Microsoft (Dataverse), lo que permite que todas las aplicaciones de PowerPlatform tengan acceso ilimitado a ellos. Además, la base de datos se ha definido de manera que tenga en cuenta los diferentes orígenes de las detecciones, dado que existían potencialmente dos herramientas de detección.

3. Cómo supervisar

Este problema se resolvió utilizando Dataverse para almacenar los datos: de hecho, la herramienta PowerBI está conectada directamente a Dataverse y permite utilizar directamente esos datos para crear paneles de control automatizados que resumen la actividad de «Password Hunting» para la dirección. Bastó con crear los paneles de control en forma de informes de PowerBI y, a continuación, compartir dichos informes con la dirección.

Buenas prácticas al trabajar con Microsoft Power Platform

• El desarrollo se lleva a cabo en el entorno de desarrollo, las pruebas, en el entorno de pruebas, y la producción, en el entorno de producción. Hay que hacer esta distinción, como en cualquier proceso de desarrollo.
• Guarda copias del trabajo que funciona, por si acaso, aunque Microsoft PowerPlatform cuente con una herramienta de gestión de versiones.
• Evita dividir demasiado la base de datos en varias tablas: queda limpio, pero genera restricciones de «delegación». Esta funcionalidad de PowerPlatform permite realizar cálculos no autorizados por las fuentes de datos, pero limita el número de filas sobre las que se realiza el cálculo. No es posible eludir este límite, por lo que se recomienda limitarse en la medida de lo posible a las operaciones autorizadas por las fuentes de datos (SharePoint y Dataverse tienen operaciones autorizadas diferentes).
• Flujo de PowerAutomate: una ejecución del flujo tiene un límite de 30 días una vez iniciada. Para sortear este límite, se puede intentar reiniciar el flujo justo antes de que se cumplan los 30 días, por ejemplo, modificando el elemento de SharePoint que lo ha activado. En el flujo, habrá que encontrar entonces una forma de distinguir los pasos. Las aprobaciones (Microsoft Approvals) también tienen una fecha de caducidad predeterminada de 30 días a partir de la fecha de creación. Para modificarla, basta con modificar la aprobación en la tabla de aprobaciones una vez que se haya creado.
• Si la documentación de Microsoft no es suficiente, la comunidad de herramientas de PowerPlatform es muy amplia, así que no te quedes atascado si no encuentras la respuesta por tu cuenta: es muy probable que alguien ya haya planteado esa pregunta en un foro.
• Hay que tener cuidado con los límites de Microsoft: límite de caracteres en un campo de tabla, límite de ejecución de flujos, límite de recuperación de datos de una fuente...
• Hay que tener cuidado también con las fechas y las diferencias horarias: en la base de datos, las fechas se almacenan en UTC y se adaptan al usuario en función de su configuración (incluso con el cambio de hora de invierno a verano en Europa).

Conclusión 

La implantación de una herramienta creada por el equipo y para el equipo ha permitido ahorrar tiempo en el tratamiento de las alertas. De hecho, el tiempo de análisis para el mismo volumen de alertas se ha reducido a la mitad. El tiempo de procesamiento también se ha reducido considerablemente, lo que nos permite responder a las solicitudes cuando el empleado necesita ayuda, mientras que antes no atendíamos a los empleados de forma individualizada. Por último, el tiempo de preparación que se necesitaba para informar a la dirección sobre la actividad simplemente se ha eliminado, ya que hoy en día esta parte es totalmente automática. Además, la dirección ha valorado disponer de KPI mucho más completos que antes.

En cuanto a las detecciones, la vigilancia funciona: el número de detecciones ha disminuido notablemente, al igual que el número de casos confirmados tras el análisis. Por lo tanto, el impacto ha sido evidente: los empleados han aprendido, se han responsabilizado gracias a su participación en el proceso de corrección y, por lo tanto, prestan más atención. La dirección ha podido comprobarlo a través de los paneles de control automatizados que se les han facilitado. Además, el ámbito de detección que se había elegido ahora está bajo control y podrá ampliarse, lo que suponía un verdadero reto para el cliente.

Por mi parte, lo que más he aprendido es que un SIEM no es necesariamente la solución a todo, y he podido descubrir la suite Microsoft Power Platform, que es muy completa y fácil de manejar. He podido retomar un proyecto en su totalidad y desarrollarlo poco a poco, lo que también me ha proporcionado una visión más estratégica.

Lucille AUBRY

Consultora de ciberseguridad