En la mitología de la antigua Roma se asociaba al dios Portuno con la protección de los puertos, pero también de las llaves y las puertas. Con el devenir del mundo digital, hemos convertido a nuestros CISOs en los custodios de las llaves de todas las puertas de las infraestructuras IT: las contraseñas. No vamos a negar que muchas veces hacen milagros con los recursos que disponen, pero en el fondo es esa falta de poderes divinos lo que nos obliga a tener que ceder esas llaves a los usuarios.

Siguiendo la analogía mitológica tendríamos en los usuarios con cuentas privilegiadas a modernos semidioses. El problema del semidios es que también es semihumano y aquí es cuando aparecen las flaquezas, los comportamientos “inoportunos” y, por tanto, los riesgos. No va a quedar más remedio, entonces, que poner en marcha medidas de protección de sus accesos, no sea que haya que acabar lanzando rayos castigadores. En este momento entran en juego las soluciones de gestión de accesos privilegiados (PAM, por su acrónimo en inglés)

Como punto de partida veremos para qué se usan las cuentas privilegiadas, quién las usa, dónde se almacenan sus credenciales y cómo están protegidas, y cuáles son los riesgos que implica el hecho de que caigan en manos inadecuadas. A partir de aquí estableceremos un proceso de madurez que nos llevará por cuatro estadios:

• Analógico: las contraseñas no se rotan y apenas hay políticas de creación y uso.
• Básico: con almacenamiento seguro de contraseñas, descubrimiento de cuentas privilegiadas, capacidades de automatización de creación y rotado de contraseñas complejas, así como implantación de autenticación multi-factor.
• Avanzado: en el que los usuarios no sean capaces de ver cuáles son sus contraseñas, se monitorice su actividad, se permita el control de sus sesiones y se generen informes detallados de su actividad.
• Inteligencia adaptativa: con detección y remediación automática de anomalías de comportamiento, gestión automática del ciclo de vida de las cuentas privilegiadas e integración en entorno DevOps.

El objetivo final habrá sido el establecimiento de un proceso continuo y vivo de gestión de cuentas privilegiadas que incluye varias etapas:

1. Definición de cuentas privilegiadas, que será diferente en cada empresa o entidad, atendiendo a lo que nos preguntábamos más arriba de quién, cuándo y para qué.
2. Descubrimiento de cuentas privilegiadas, humanas y no humanas (por ejemplo, cuentas de servicio).
3. Gestión y protección de credenciales, incluyendo rotado de contraseñas y establecimiento de políticas que indiquen lo que los usuarios pueden y no pueden hacer.
4. Monitorización de actividad y control de sesiones.
5. Detección de comportamientos anómalos y abusos en tiempo real.
6. Respuesta ante incidentes, más allá de un simple cambio de contraseña o inhabilitación de una cuenta.
7. Auditoria de actividad y revisión de comportamiento, que nos pueda llevar a una redefinición de lo que debe ser una cuenta privilegiada y nos lleve de vuelta al punto 1.

Avanzar en un modelo como este no es tarea exclusiva de los responsables de seguridad que, recordémoslo, no son Portuno; ni siquiera de los administradores de seguridad. Es un trabajo colectivo, en el que debe participar también la alta dirección, como responsables últimos ante sus clientes, accionistas y órganos de regulación varios. Pero también:

• Auditoría: ya que la implantación de políticas PAM es una de las principales consecuencias de normativas como GDPR, ENS, CNPIC, ISO, PCI, SOX, etc.
• Sistemas y operaciones: no solo como mantenedores de cualquier solución PAM, si no como garantes de la correcta administración y aplicación de políticas en sistemas IT. No deben permitirse puertas traseras o atajos.
• Desarrollo: la velocidad requerida de entornos Agile o Devops no puede servir como excusa para circunvenir políticas de seguridad. O, dicho de otra manera, eliminemos las contraseñas escritas “a fuego” en el código de aplicaciones.
• Negocio: deben ayudar a definir qué aplicaciones, sistemas y usuarios deben tener cuentas privilegiadas y cuáles no.
• Recursos Humanos y Legal: para aplicación de políticas de privacidad y concienciación de las consecuencias del mal uso de cuentas privilegiadas.

Y una vez controlado el uso de cuentas privilegiadas, Portuno podrá dedicarse al resto de los mortales, es decir, a los usuarios a los que dejamos que tengan privilegios de administración locales (lo que acaba siendo un puerto de entrada de ransomware y todo tipo de malware en general). Si delimitamos lo que pueden instalarse, lo más probable es que nuestros equipos de soporte o helpdesk acaben colapsados por solicitudes de instalación de drivers, updates y todo tipo de aplicaciones en general. Pero si utilizamos soluciones de mínimo privilegio, mediante la generación de whitelists y un correcto workflow de aprobación, se elimina ese colapso y el usuario puede instalarlo mediante el escalado de privilegios para ese software (solo para ese software y solo durante el proceso). Y así, el protector de las llaves cumplirá su misión sin necesidad de alcanzar la divinidad.

Juan Navarro

Enterprise Account Manager de Thycotic

by