Un proveedor de tecnología financiera tenía una política de contraseñas integral: aprobada por el consejo, revisada con regularidad y alineada con las recomendaciones de la NIST SP 800-63B. La política especificaba una longitud mínima de doce caracteres, requisitos de complejidad, la prohibición de contraseñas comunes y una antigüedad máxima de noventa días para las cuentas privilegiadas. Durante una evaluación técnica de seguridad, los evaluadores contrastaron la configuración real de la plataforma de identidad con la política. Encontraron lo siguiente: el Azure AD corporativo estaba configurado con un mínimo de ocho caracteres, porque la configuración no se había actualizado cuando se revisó la política dos años antes. La complejidad se aplicaba en Azure AD, pero no en los tres sistemas heredados de autenticación de aplicaciones que aún mantenían sus propios almacenes de usuarios. La rotación de noventa días se aplicaba a las cuentas humanas en Azure AD, pero las cuentas de servicio del mismo inquilino no tenían configurado ningún requisito de rotación. Las cuentas de servicio de las aplicaciones heredadas usaban contraseñas guardadas en un documento compartido de credenciales que no se había actualizado en catorce meses. Cada una de estas brechas tenía una causa común: la política se había actualizado para reflejar las buenas prácticas de seguridad, pero las configuraciones técnicas que la aplicaban no se habían actualizado en consecuencia. La política describía lo que debía aplicarse. Las configuraciones describían lo que se aplicaba. Divergían en cada punto medido.
¿Qué es realmente la brecha entre la política y su aplicación?
La brecha entre la política y su aplicación es la distancia entre los requisitos de seguridad documentados (las normas, los procedimientos y las directrices que definen cómo deben funcionar los controles de seguridad) y los mecanismos técnicos y operativos que realmente implementan esos requisitos en los sistemas en funcionamiento. Las políticas son documentos normativos: especifican lo que debería ser cierto. Las configuraciones, los ajustes de los sistemas y los procedimientos operativos son mecanismos de implementación: determinan lo que es cierto. Cuando las políticas se actualizan sin las actualizaciones correspondientes de los mecanismos de implementación, la política describe un estándar de seguridad mejorado que el entorno no aplica.
El desfase en la actualización de las políticas es la fuente más común de brechas entre la política y su aplicación. Las políticas se actualizan mediante procesos de gobernanza: ciclos de revisión, actualizaciones de marcos, cambios en la orientación regulatoria o maduración del programa de seguridad. Estos procesos producen documentos de política actualizados que reflejan con precisión requisitos de seguridad mejorados. Las configuraciones técnicas que implementan esos requisitos (ajustes de contraseñas de la plataforma de identidad, conjuntos de reglas de firewall, configuraciones de cifrado, matrices de control de acceso) se actualizan mediante procesos de gestión de cambios que exigen esfuerzo de ingeniería, pruebas y despliegue. El proceso de gobernanza que produce los documentos de política actualizados suele ser más rápido y consumir menos recursos que el proceso de ingeniería que actualiza las configuraciones técnicas. La política avanza hacia el nuevo estándar. La configuración se queda atrás.
El problema de la brecha de cobertura agrava el desfase de actualización. Incluso las políticas que se aplican de forma sistemática en los sistemas principales presentan con frecuencia brechas de cobertura en los sistemas secundarios: aplicaciones heredadas con autenticación independiente, sistemas adquiridos aún no integrados en el estándar corporativo, entornos de desarrollo con configuraciones distintas de las de producción y cuentas de servicio gobernadas por procesos distintos de los de las cuentas humanas. Una política de contraseñas que se aplica al proveedor de identidad corporativo se aplica a las cuentas gestionadas a través de ese proveedor. No se aplica a las cuentas de sistemas fuera del alcance de ese proveedor, salvo que esos sistemas se rijan explícitamente por configuraciones equivalentes.
- Política actualizada sin actualizar la configuración: el estándar revisado de la política no se refleja en las configuraciones de los sistemas
- Brechas de configuración en los sistemas heredados: la política se aplica a los sistemas principales y las aplicaciones heredadas mantienen configuraciones independientes
- Divergencia de la política en las cuentas de servicio: la política de las cuentas humanas no se aplica a las cuentas de servicio
- Sin mapeo entre políticas y configuraciones: políticas no vinculadas explícitamente a las configuraciones que las implementan
- Auditoría de la configuración no realizada: las configuraciones reales de los sistemas no se comparan con los requisitos de la política
Por qué es importante
La brecha entre la política y su aplicación es importante para TPRM porque las evaluaciones de seguridad de proveedores que confirman la existencia de una política confirman el estándar que el proveedor ha documentado, no el estándar que aplican sus sistemas. Un proveedor con una política de contraseñas sólida y configuraciones de contraseñas débiles presenta una postura de seguridad distinta de la que sugiere la confirmación de la política. La seguridad real la determina lo que aplica la configuración, no lo que exige la política.
La dimensión regulatoria es explícita y se hace cumplir cada vez más. Los reguladores que examinan a proveedores que operan en sectores regulados contrastarán la configuración con la política y no solo preguntarán “qué exige su política”, sino “qué aplica realmente su sistema y puede demostrar que la configuración se ajusta al requisito de la política”. Una brecha entre ambas (doce caracteres en la política, ocho en la configuración) es un hallazgo que la solidez de la política no mitiga. El control es la configuración, no el documento.
Dónde se equivocan la mayoría de los equipos
La falla más habitual es aceptar la documentación de la política como evidencia del estándar de seguridad vigente. Las políticas describen requisitos. Las configuraciones implementan requisitos. Son artefactos distintos que exigen solicitudes de evidencia distintas. Un documento de política de contraseñas confirma lo que debería aplicarse. Una exportación de la configuración o un informe de cumplimiento confirma lo que se aplica.
- Aceptar la documentación de políticas como evidencia de implementación
- Auditoría de la configuración no incluida en la evaluación
- Cobertura de los sistemas heredados no evaluada: configuración del sistema principal confirmada, sistemas heredados no evaluados
- Configuraciones de las cuentas de servicio no evaluadas por separado
- Mapeo entre políticas y configuraciones no revisado: no se verifica que las políticas estén vinculadas a configuraciones de implementación específicas
Cómo se ve una buena práctica
Los programas maduros de gobernanza de políticas mantienen mapeos explícitos entre los requisitos de la política y las configuraciones que los implementan, realizan auditorías periódicas de la configuración para verificar la alineación y cuentan con procesos de gestión de cambios que conectan las actualizaciones de la política con las actualizaciones de la configuración.
- Mapeo entre políticas y configuraciones: documentación explícita de qué configuraciones implementan qué requisitos de la política
- Frecuencia de auditoría de la configuración: comparación periódica de las configuraciones reales con los requisitos de la política
- Las actualizaciones de la política activan la revisión de la configuración: los cambios de política generan tareas de revisión y actualización de la configuración
- Inventario de la configuración de los sistemas heredados: configuraciones de todos los sistemas sujetos a la política documentadas y auditadas periódicamente
- Evaluación de la configuración de las cuentas de servicio: configuraciones de contraseñas y credenciales de las cuentas de servicio evaluadas por separado de las cuentas humanas
Herramientas
Cumplimiento de la configuración: AWS Config, Azure Policy, escáneres de referencia de CIS
Las herramientas de cumplimiento de la configuración comparan continuamente las configuraciones desplegadas de los sistemas con los requisitos de política definidos y señalan las configuraciones que no cumplen los estándares de la política. Los escáneres de referencia de CIS evalúan las configuraciones de los sistemas frente a los estándares de bastionado del Center for Internet Security. Para los profesionales de TPRM, preguntar si el proveedor utiliza herramientas de cumplimiento de la configuración para verificar continuamente que las configuraciones de los sistemas se ajustan a los requisitos de la política es una pregunta específica sobre la alineación entre la política y su aplicación.
Cumplimiento automatizado: Drata, Vanta
Las plataformas de cumplimiento automatizado recopilan evidencia de la configuración junto con la documentación de las políticas, lo que proporciona el emparejamiento entre los requisitos de la política y la verificación de la configuración que una evaluación manual no puede mantener de forma continua. Para los profesionales de TPRM, pedir a los proveedores los resultados de la plataforma de cumplimiento que confirmen el cumplimiento de la configuración junto con la documentación de la política aporta tanto el estándar de la política como la evidencia de su implementación.
Desafíos de gobernanza
El desafío de gobernanza de la brecha entre la política y su aplicación es la disciplina de gestión de cambios necesaria para mantener las configuraciones alineadas con las políticas a medida que ambas evolucionan. Las revisiones de las políticas se inician mediante procesos de gobernanza. Los cambios de configuración exigen esfuerzo de ingeniería. Ambos procesos funcionan con plazos distintos y con responsables distintos y, sin una conexión explícita entre ellos, la política avanza mientras las configuraciones se rezagan.
- Solicite evidencia de la configuración junto con la documentación de la política: los ajustes reales del sistema, no el documento de requisitos
- Pregunte por la cobertura de los sistemas heredados: qué sistemas están dentro del alcance de la política y cuáles tienen configuraciones independientes
- Pregunte por separado por la configuración de las cuentas de servicio: las configuraciones de las cuentas humanas y de máquina pueden diferir
- Pregunte cuándo se actualizó la política por última vez y cuándo se auditaron las configuraciones por última vez: la distancia entre ambas fechas es el indicador de obsolescencia
- Solicite los resultados de las herramientas de cumplimiento en lugar de documentos de políticas para los controles técnicos
Si usted forma parte de un equipo pequeño
A su proveedor de mayor riesgo, pídale la configuración real de contraseñas de su plataforma de identidad principal: no el documento de la política, sino la exportación de la configuración o una captura de pantalla que muestre la longitud mínima de la contraseña, los requisitos de complejidad y los ajustes de rotación que se aplican actualmente. Después, haga la misma pregunta sobre la configuración de sus cuentas de servicio. Compare ambas con su documento de política. Las brechas entre ellas son las brechas de aplicación que la evaluación de la política no puso de manifiesto.
- Solicite la configuración real de contraseñas: longitud mínima, complejidad y rotación tal como se aplican
- Pregunte por separado por la configuración de contraseñas y credenciales de las cuentas de servicio
- Compare las configuraciones con los requisitos de la política
- Pregunte por la configuración de contraseñas de los sistemas heredados
Qué exigir
Pregunte directamente:
“¿Puede proporcionar la configuración de contraseñas que se aplica actualmente en su plataforma de identidad principal? En concreto, la longitud mínima en caracteres, los requisitos de complejidad y los ajustes de rotación tal como están configurados en el sistema, no tal como se especifican en su política.”
“¿Se aplica su política de contraseñas a las cuentas de servicio de la misma manera que a las cuentas humanas? ¿Y cuál es la configuración actual de contraseñas de las cuentas de servicio, incluida la frecuencia de rotación?”
Evidencia que debe esperar
- Configuración de la plataforma de identidad que muestre los requisitos de contraseña que realmente se aplican
- Configuración de contraseñas de las cuentas de servicio documentada por separado
- Inventario de la configuración de contraseñas de los sistemas heredados
- Documentación del mapeo entre políticas y configuraciones
A un proveedor que presenta una política de contraseñas sólida se le debe pedir la configuración que la aplica. La política es el requisito. La configuración es la realidad. Una brecha entre una política de doce caracteres y una configuración de ocho caracteres no se resuelve con la solidez de la política.
Cómo demostrarlo
- Registros de evidencia de la configuración de los controles técnicos clave
- Registros de evaluación de las brechas entre políticas y configuraciones
- Registros de auditoría de la configuración
- Evaluación de la configuración de las cuentas de servicio
Conclusión clave
La política rige el estándar. La configuración rige el comportamiento. Pueden divergir, y con frecuencia lo hacen cuando los procesos de gobernanza actualizan las políticas más rápido de lo que los procesos de ingeniería actualizan las configuraciones. La política de doce caracteres con una configuración de ocho caracteres no es una falla de la política: la política es correcta. Es un desfase de la configuración que el proceso de la política no creó ningún mecanismo para cerrar. La evidencia de una política sólida es evidencia de un requisito sólido. La evidencia de la configuración que la implementa es evidencia del estándar que realmente se aplica. Solicite ambas. Acepte la documentación de la política como la especificación. Solicite la evidencia de la configuración como la implementación.