Cuentas huérfanas, privilegios acumulados y terceros sin vencimiento: las brechas que nadie ve hasta que alguien las usa
TÉCNICO-GERENCIAL · IDENTIDAD Y ACCESO · BRECHAS OPERACIONALES
Ayer planteé que la identidad es el perímetro que las organizaciones construyen con política y tecnología, y que luego dejan de administrar. Hoy quiero bajar eso a las brechas concretas: cuáles son, por qué aparecen, y por qué son particularmente peligrosas comparadas con vulnerabilidades técnicas del tipo CVE.
La diferencia más relevante entre una brecha de identidad y una vulnerabilidad de software es la siguiente: la vulnerabilidad de software, cuando es explotada, genera comportamiento anómalo que los sistemas de detección pueden identificar. La cuenta huérfana explotada genera comportamiento completamente normal desde la perspectiva de los sistemas de control, porque el acceso es técnicamente válido. Eso la hace más difícil de detectar y, en muchos casos, más costosa cuando finalmente se identifica el compromiso.
BRECHA 1: CUENTAS HUÉRFANAS
Una cuenta huérfana es cualquier cuenta de usuario activa cuyo titular ya no tiene una relación vigente con la organización: ex-empleados, ex-contratistas, proveedores cuyo contrato terminó. La cuenta existe, tiene credenciales válidas, tiene accesos asignados, y puede ser usada por cualquiera que tenga las credenciales, que pueden estar en manos del ex-titular o haberse filtrado.
La frecuencia con que aparece esta brecha en organizaciones medianas es llamativa. En auditorías de directorio de Active Directory en empresas de entre 50 y 300 empleados, es frecuente encontrar entre un 10 y un 20 por ciento de cuentas activas cuyos titulares ya no están en la organización. No por mala fe: por ausencia de un proceso formal de offboarding que incluya la revocación de accesos digitales como paso verificado.
El proceso de offboarding en muchas organizaciones se concentra en los aspectos visibles y urgentes: devolución del equipo, liquidación de haberes, traspaso de responsabilidades. La desactivación de cuentas en el directorio, la revocación de accesos a sistemas de negocio, la eliminación de claves de VPN, la desvinculación de cuentas de correo corporativo, todo eso suele tener menor urgencia y a veces no ocurre de forma sistemática. Especialmente cuando la salida del empleado es planificada y no conflictiva: nadie percibe urgencia en revocar el acceso de alguien que salió en buenos términos.
El problema es que las cuentas no distinguen entre salidas amistosas y no amistosas. La cuenta existe o no existe. Y mientras existe y está activa, es un vector de acceso.
BRECHA 2: PRIVILEGE CREEP, LOS PRIVILEGIOS QUE SE ACUMULAN
El privilege creep, la acumulación progresiva de privilegios, es quizás la brecha más silenciosa de las cuatro. Ocurre cuando una persona cambia de rol dentro de la organización y recibe nuevos accesos para sus nuevas responsabilidades, pero nadie retira los accesos correspondientes a su rol anterior.
El técnico de soporte que fue ascendido a administrador de sistemas sigue teniendo los accesos del técnico de soporte más los del administrador. El analista que rotó de área sigue con acceso a los sistemas de la unidad anterior. El jefe de proyecto que terminó un proyecto con acceso a sistemas específicos del cliente sigue con ese acceso activo. Cada transición suma. Nada resta.
Con el tiempo, algunas personas en la organización acumulan un conjunto de privilegios que no refleja ningún rol existente sino la suma de todos los roles que tuvieron. Ese perfil de acceso excesivo viola el principio de mínimo privilegio, que establece que cada usuario debería tener acceso únicamente a los recursos que necesita para sus responsabilidades actuales. Es un principio que la mayoría de las políticas de seguridad mencionan. Es un principio que muy pocas organizaciones aplican con consistencia porque requiere revisar activamente lo que se tiene, no solo lo que se agrega.
ERROR COMÚN
Gestionar los accesos únicamente en el momento del alta: cuando alguien entra, se le otorgan los accesos que necesita. Sin un proceso simétrico de revisión y depuración periódica, el modelo de acceso solo crece. Cada alta agrega. Ningún proceso resta. Con el tiempo, la distancia entre los accesos que el directorio registra y los accesos que las personas realmente necesitan para sus roles actuales se convierte en una superficie de ataque que nadie está midiendo.
BRECHA 3: ACCESOS DE TERCEROS SIN FECHA DE VENCIMIENTO
Los proveedores externos, consultores, empresas de soporte técnico, integradores de sistemas, todos ellos requieren en algún momento acceso a sistemas internos de la organización para hacer su trabajo. Ese acceso es legítimo durante la vigencia del proyecto o el contrato.
El problema es cuando ese acceso no tiene una fecha de vencimiento técnicamente configurada y vinculada al fin del contrato. En la práctica, lo que ocurre es que el acceso se otorga para el proyecto, el proyecto termina, y el acceso permanece activo indefinidamente porque nadie en la organización recibió la señal formal de que había que revocarlo. El equipo de TI no siempre sabe cuándo termina el contrato de un proveedor específico. El área que contrató al proveedor no siempre notifica a TI cuando el contrato vence. El proveedor ciertamente no va a reportar que su acceso sigue activo.
El resultado es una acumulación de accesos de terceros que en algunos casos lleva meses o años activos después de que la relación comercial terminó. Desde el punto de vista del directorio, esas cuentas son indistinguibles de accesos vigentes y justificados.
BRECHA 4: CUENTAS Y CREDENCIALES COMPARTIDAS
Las cuentas compartidas, especialmente las de administración, son una práctica que persiste en muchas organizaciones porque parece conveniente: un solo conjunto de credenciales para las tareas de administración, conocido por todos los técnicos que las necesitan. El problema es que eliminan la trazabilidad.
Cuando varios técnicos usan las mismas credenciales de administrador, el log de actividad muestra la cuenta, no la persona. Si esa cuenta hace algo que genera un incidente, no hay forma directa de saber quién estaba usando las credenciales en ese momento. Si uno de los técnicos sale de la organización, las credenciales compartidas siguen siendo válidas porque cambiarlas requiere notificar y actualizar a todos los que las usan. Esa fricción hace que el cambio se postergue.
En entornos con Fortinet, Cisco, WatchGuard o Ubiquiti, las credenciales de gestión compartidas son un vector de acceso que no requiere ningún exploit técnico: requiere que alguien que conocía esas credenciales, y que ya no tiene relación vigente con la organización, las use desde cualquier punto con conectividad.
DECISIÓN QUE DEBE TOMAR EL CIO
Antes de implementar cualquier herramienta de gestión de identidad, hacer el diagnóstico con los datos que ya existen: exportar el listado completo de cuentas activas del directorio y cruzarlo con el listado de empleados y contratistas vigentes de Recursos Humanos. Ese cruce, que puede hacerse en horas, ya identifica las cuentas huérfanas. El privilege creep requiere un paso adicional: revisar los grupos y roles asignados a cada cuenta contra el perfil actual de la persona. Esas dos acciones no requieren nueva tecnología. Requieren tiempo y voluntad de hacer el ejercicio.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
Lo que tienen en común estas cuatro categorías de brecha es que ninguna genera alerta por sí sola. El directorio no distingue entre una cuenta activa legítima y una cuenta huérfana. El sistema de autenticación no distingue entre un privilegio justificado y uno acumulado sin revisión. El firewall no distingue entre el acceso de un proveedor vigente y el de uno cuyo contrato terminó.
La única forma de identificarlas antes de que alguien las use es el proceso de revisión periódica. Mañana voy a ver cómo se hace esa revisión en condiciones reales de una organización mediana: qué pasos tiene, qué fricción genera, y cómo se estructura para que sea sostenible en el tiempo.
Una cuenta huérfana no necesita ser descubierta por un atacante sofisticado. Necesita existir. El tiempo hace el resto. Cada día que la cuenta permanece activa sin titular vigente es un día en que puede ser usada, y nadie lo va a saber hasta que el daño ya esté hecho.
Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra. Mañana: cómo hacer una revisión real del modelo de acceso.
#IdentidadYAcceso #IAM #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #Ubiquiti #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #ActiveDirectory #NISTCSF #ISO27001
Comentarios
Publicar un comentario