El programa de gobernanza de la seguridad de una empresa tecnológica incluía un proceso formal de gestión de excepciones: un flujo de trabajo estructurado para solicitar, revisar y aprobar excepciones a los requisitos de la línea base de seguridad. El proceso se había diseñado con el rigor adecuado: las excepciones requerían una justificación de negocio documentada, una evaluación de riesgos que confirmara que el riesgo residual era aceptable, un límite de tiempo con revisión obligatoria y una autoridad de aprobación a nivel de CISO. Durante una revisión del programa de seguridad, un analista examinó el registro de excepciones y encontró cuarenta y una excepciones activas, de las cuales treinta y siete eran de MFA en cuentas de acceso administrativo. La justificación de negocio de las treinta y siete era una variante de “la implementación de MFA en este sistema requiere un trabajo de ingeniería que no se ha programado”. Los límites de tiempo de las excepciones iban de tres a doce meses, pero cuatro se habían aprobado, habían vencido, se habían vuelto a aprobar y estaban ya en su segundo o tercer ciclo anual. El proceso de excepciones funcionaba correctamente: cada excepción tenía una justificación de negocio, una evaluación de riesgos, un límite de tiempo y la aprobación del CISO. Las excepciones no se estaban usando para restricciones operativas reales. Se estaban usando para aplazar trabajo de ingeniería que resultaba incómodo programar. El proceso de excepciones se había convertido en el camino de menor resistencia para eludir la línea base de seguridad.
¿Qué es realmente el abuso de la gestión de excepciones?
La gestión de excepciones es el mecanismo de gobernanza que permite reconocer que determinadas circunstancias operativas crean restricciones reales que impiden implementar un requisito de la línea base de seguridad, y gestionar formalmente esas situaciones con controles compensatorios, una aceptación documentada del riesgo residual y plazos definidos para resolver la restricción o aceptarla formalmente como una limitación permanente. Existe para tratar la complejidad real de la implementación de la seguridad: sistemas heredados con limitaciones de autenticación, herramientas gestionadas por proveedores que no pueden configurarse para cumplir todos los requisitos de la línea base y escenarios operativos en los que aplicar estrictamente la línea base crearía un riesgo operativo inaceptable.
El abuso se produce cuando el proceso de excepciones no se usa para tratar restricciones reales, sino para aplazar implementaciones técnicamente viables pero incómodas para la organización, cuando el verdadero motivo de la excepción son prioridades de ingeniería en competencia, la escasez de recursos o la reticencia de la dirección a priorizar el trabajo de implementación, y no una restricción técnica u operativa real. Una excepción de MFA en un sistema de autenticación heredado que, por su arquitectura, no puede admitir métodos de autenticación modernos es una excepción por restricción real. Una excepción de MFA en un sistema moderno cuya implementación requiere un sprint de trabajo de ingeniería que no se ha programado es una excepción de aplazamiento: usa el proceso de excepciones para eludir un requisito de la línea base que es difícil de cumplir, no realmente imposible de cumplir.
El problema de la normalización es lo que convierte el abuso de excepciones individuales en una erosión sistemática de la línea base. Cuando varios equipos observan que el proceso de excepciones produce aplazamientos aprobados para implementaciones técnicamente viables pero incómodas, la excepción se convierte en el camino esperado para los requisitos difíciles de cumplir a tiempo. Los equipos de ingeniería aprenden que solicitar una excepción es más rápido que implementar el control. El registro de excepciones se llena de aplazamientos. La línea base existe como norma documentada. La tasa de implementación refleja los requisitos que resultaba fácil cumplir sin excepciones. El proceso de excepciones no ha fallado: se ha aprendido y explotado.
- Excepciones de aplazamiento: implementaciones técnicamente viables aplazadas mediante el proceso de excepciones
- Registro de excepciones lleno de aplazamientos de ingeniería: patrón de la misma justificación en varias excepciones
- Excepciones recurrentes: las mismas excepciones se vuelven a aprobar durante varios ciclos sin corrección
- Erosión de la línea base: disminuye el porcentaje de sistemas dentro del alcance que cumplen realmente los requisitos de la línea base
- Proceso de excepciones normalizado como alternativa a la implementación de requisitos incómodos
Por qué es importante
El abuso de la gestión de excepciones es importante para TPRM porque las líneas base de seguridad de los proveedores confirmadas mediante cuestionarios pueden tener registros de excepciones extensos que excluyen sistemáticamente partes significativas del entorno de los requisitos de la línea base. Un proveedor cuya línea base de seguridad exige MFA para todo acceso administrativo y que tiene treinta y siete excepciones activas por aplazamientos de MFA tiene una línea base que se aplica a algunas cuentas administrativas. La confirmación en el cuestionario de que la política exige MFA es precisa. La realidad operativa de cuántas cuentas administrativas están realmente protegidas con MFA puede ser considerablemente más reducida.
El patrón de excepciones recurrentes es la señal concreta que produce el abuso de excepciones. Una excepción que se concedió con un límite de seis meses, se renovó, se volvió a conceder y está ahora en su tercer ciclo de aprobación se ha convertido de hecho en una excepción permanente por repetición procedimental y no por aceptación formal. Cada renovación se aprobó con la expectativa de que la implementación se haría en el ciclo siguiente. Dos o tres ciclos después, la implementación no se ha hecho y la excepción se ha convertido en una exclusión permanente de facto de la línea base. Identificar las excepciones recurrentes en el registro de excepciones de un proveedor pone de manifiesto las implementaciones que se han aplazado sistemáticamente mediante el mecanismo de excepciones.
Dónde se equivocan la mayoría de los equipos
El error más habitual es aceptar el número de entradas del registro de excepciones y la calidad formal del proceso como prueba de una gobernanza sólida de las excepciones, sin revisar sus justificaciones ni sus patrones de recurrencia. Un proceso de excepciones bien gobernado del que se abusa produce la misma documentación de gobernanza que un proceso bien gobernado que se usa de forma adecuada: la diferencia está en los patrones de justificación y recurrencia.
- Aceptar la documentación del registro de excepciones como gobernanza sólida sin revisar los patrones de justificación
- Excepciones recurrentes sin identificar: no se señalan las mismas excepciones aprobadas en varios ciclos
- Las justificaciones de aplazamiento no se distinguen de las justificaciones por restricción real
- Tasa de cobertura de la línea base sin calcular: porcentaje de sistemas dentro del alcance que cumplen la línea base sin excepciones
- Sin seguimiento de la corrección de excepciones: si las excepciones conducen a la implementación o a una renovación perpetua
Cómo se ve una buena práctica
Los programas maduros de gestión de excepciones distinguen en su diseño entre las excepciones por restricción real y las excepciones de aplazamiento, y exigen para cada una normas de justificación y un tratamiento distintos. Las restricciones reales reciben una gestión adecuada a largo plazo. Las excepciones de aplazamiento reciben un escrutinio creciente y un escalamiento obligatorio en cada ciclo de renovación.
- Distinción por tipo de justificación: las excepciones por restricción real y las de aplazamiento se tratan de forma distinta
- Requisitos de aprobación escalonados para excepciones recurrentes: la segunda renovación requiere la aprobación de la alta dirección
- Tasa de cobertura de la línea base con seguimiento: porcentaje de sistemas dentro del alcance que cumplen la línea base sin excepción
- Informes de antigüedad de las excepciones: el comité de excepciones revisa las excepciones ordenadas por antigüedad
- Ninguna renovación sin pruebas de avance en la implementación: la nueva aprobación requiere pruebas de que la implementación avanza activamente
Herramientas
GRC con flujo de trabajo de excepciones: ServiceNow GRC, Archer
Las plataformas GRC con flujos de trabajo de gestión de excepciones admiten requisitos de aprobación escalonados para las excepciones recurrentes e informes de antigüedad de las excepciones para su revisión por el comité de gobernanza. Para los profesionales de TPRM, preguntar si la plataforma de gestión de excepciones del proveedor hace seguimiento de la recurrencia de las excepciones y eleva el nivel de aprobación de las renovaciones ofrece una pregunta concreta sobre la prevención del abuso.
Cumplimiento de la línea base de seguridad: Qualys, Tenable
Las herramientas de cumplimiento de la línea base de seguridad informan del porcentaje de sistemas dentro del alcance que cumplen cada requisito de la línea base, lo que pone de manifiesto la tasa de cobertura real que reducen los registros de excepciones. Para los profesionales de TPRM, solicitar la tasa de cumplimiento de la línea base para los requisitos de seguridad críticos (MFA, cifrado, parches) en lugar del registro de excepciones aporta la métrica de cobertura de la implementación que ocultan los recuentos de excepciones.
Desafíos de gobernanza
El desafío de gobernanza de la gestión de excepciones es el incentivo de aprobación. La aprobación a nivel de CISO convierte cada excepción en una decisión de alto impacto. Cuando la decisión está entre aprobar una excepción de aplazamiento o bloquear un proceso de negocio a la espera de la implementación, el camino de la aprobación produce aplazamientos aprobados. Una gobernanza que genere presión hacia la implementación y no hacia el aplazamiento (exigir hojas de ruta de implementación con seguimiento trimestral de hitos como condición para aprobar la excepción) convierte el proceso de excepciones de un mecanismo de aplazamiento en un mecanismo de compromiso de implementación.
- Solicitar la tasa de cumplimiento de la línea base, no el registro de excepciones: porcentaje de sistemas que cumplen la línea base sin excepción
- Preguntar por la antigüedad y la recurrencia de las excepciones: cuántas excepciones activas están en su segundo o tercer ciclo de aprobación
- Exigir hojas de ruta de implementación como condición para aprobar las excepciones de aplazamiento
- Revisar los patrones de justificación de las excepciones: si el mismo tipo de justificación se repite en varias excepciones
- Preguntar qué porcentaje de las excepciones termina en implementación frente a renovación perpetua
Si usted forma parte de un equipo pequeño
Haga a su proveedor de mayor riesgo dos preguntas sobre su registro de excepciones. Primera: de sus excepciones activas, ¿cuántas se han renovado al menos una vez, es decir, están en su segundo ciclo de aprobación o posterior? Segunda: en el caso concreto de las excepciones relacionadas con MFA, cifrado o control de acceso, ¿cuál es su antigüedad media y qué porcentaje tiene una fecha objetivo de implementación definida con trabajo de ingeniería activo en curso? Esas dos preguntas distinguirán un registro de excepciones bien gestionado de uno que se ha convertido en un mecanismo sistemático para eludir la línea base.
- Preguntar cuántas excepciones activas están en su segundo ciclo de aprobación o posterior
- Solicitar la antigüedad de las excepciones y las fechas objetivo de implementación para las excepciones de controles de seguridad críticos
- Solicitar la tasa de cumplimiento de la línea base para los requisitos de mayor riesgo, no el número de entradas del registro de excepciones
- Preguntar si se exigen hojas de ruta de implementación para las excepciones de aplazamiento
Qué exigir
Pregunte directamente:
“En cuanto a sus excepciones activas a la línea base de seguridad, en concreto a los requisitos de MFA, cifrado o control de acceso, ¿cuál es la antigüedad media de las excepciones y cuántas están en su segundo ciclo de renovación o posterior? ¿Y qué porcentaje de los sistemas dentro del alcance de esos requisitos los cumple sin excepción?”
Evidencia que debe esperar
- Distribución de la antigüedad de las excepciones y número de recurrencias
- Tasa de cumplimiento de la línea base para los requisitos críticos
- Hojas de ruta de implementación para las excepciones de aplazamiento
- Desglose de las excepciones por tipo de justificación: restricción real frente a aplazamiento
A un proveedor cuyo proceso de excepciones está formalmente gobernado se le debe pedir la tasa de cumplimiento de la línea base que reducen las excepciones y el número de excepciones que se repiten en varios ciclos de aprobación. El proceso está gobernado. Los patrones revelan si se está usando de forma adecuada.
Cómo demostrarlo
- Registros de revisión de los patrones de justificación de las excepciones
- Seguimiento de la tasa de cumplimiento de la línea base
- Identificación de excepciones recurrentes
- Requisito de hoja de ruta de implementación para las excepciones de aplazamiento
Conclusión clave
El proceso de excepciones está gobernado. Cada excepción tiene documentación, evaluación de riesgos, aprobación del CISO y un límite de tiempo. Treinta y siete de las cuarenta y una excepciones activas son para implementaciones de MFA que requieren un trabajo de ingeniería que no se ha priorizado. Cuatro están en su segundo o tercer ciclo de aprobación. El proceso funciona según su diseño. La línea base de seguridad se está eludiendo sistemáticamente a través de él. La gestión de excepciones existe para tratar restricciones reales. Cuando se usa para aplazar implementaciones difíciles, el registro de excepciones crece y la tasa de cobertura de la línea base disminuye. Haga seguimiento de la tasa de cumplimiento de la línea base, no de la calidad del registro de excepciones. Identifique las excepciones recurrentes. Exija hojas de ruta de implementación como condición para aprobar aplazamientos. La excepción es el mecanismo de gobernanza para las restricciones. La implementación es la obligación. El proceso debe generar presión hacia la obligación, no una vía para alejarse de ella.