Causalidad y causa raíz en sistemas complejos

Un incidente deja una secuencia visible: una credencial fue utilizada, un servicio cambió de estado, una alerta apareció y una operación falló. La tentación profesional es convertir esa secuencia en una historia causal demasiado pronto: «la causa fue la contraseña débil», «el atacante provocó la caída» o «el parche habría evitado todo». La secuencia puede ser cierta y la explicación, sin embargo, estar incompleta o ser falsa.

Investigar causalidad en ciberseguridad no consiste en encontrar una frase contundente para cerrar un informe. Consiste en reconstruir qué condiciones hicieron posible un resultado, distinguir lo que observamos de lo que inferimos y comprobar qué habría cambiado si una condición hubiera sido distinta. En sistemas complejos, un resultado suele depender de una configuración, decisiones, dependencias, controles, personas, tiempos y oportunidades que interactúan. La causa raíz no es necesariamente el primer evento, el último evento ni el defecto más fácil de corregir.

Este capítulo ofrece un modelo para razonar sobre causas sin caer en monocausas, retrospectiva o culpabilización. No sustituye la respuesta a incidentes ni el análisis forense; explica cómo esas evidencias pueden convertirse, con límites explícitos, en una explicación causal útil para corregir y aprender.

Una sucesión temporal no es todavía una causa

Que B ocurra después de A es una observación temporal. Para llamar causa a A necesitamos una relación más exigente: modificar A, manteniendo relevantes las demás condiciones, debería cambiar la probabilidad o el estado de B de una forma coherente con un mecanismo. Esta intuición contrafactual evita confundir precedencia con causalidad. Las afirmaciones sobre intervenciones requieren supuestos causales adicionales a la asociación observada. Pearl, 2009, §§2.1–2.4 y 3.2.1

Supongamos que un token de servicio aparece en un log y, minutos después, se crea una cuenta administrativa. La observación establece orden y coexistencia. Para sostener que el uso del token causó la creación habría que confirmar, entre otras cosas, que el token era válido para esa operación, que la identidad tuvo alcance suficiente, que no existía otra ruta de creación, que el log conserva el contexto y que la solicitud llegó al sistema que registró el cambio. Un reloj compartido y una similitud de nombres no bastan.

El mecanismo causal puede expresarse como una cadena de transiciones: una condición permite una acción; la acción produce un cambio de estado; el cambio habilita otra acción; finalmente aparece la pérdida. Cada flecha necesita una justificación. Si una flecha es sólo «después de», debe marcarse como hipótesis y no como hecho.

El error frecuente es dibujar una línea entre todos los eventos de una cronología. En una línea temporal, el orden comunica tiempo; no debe insinuar que cada evento produjo al siguiente. En un informe profesional conviene separar dos artefactos: una cronología de observaciones y un grafo de hipótesis causales. La primera admite timestamps y procedencia; el segundo incluye relaciones inferidas, condiciones alternativas y nivel de confianza.

La cronología ordena tres observaciones; las flechas entre política, permiso y operación son hipótesis que requieren evidencia.

Causa, condición, contribuyente y disparador

Una explicación mejora cuando asigna funciones distintas a los elementos que participan en un resultado.

• Disparador (trigger): evento próximo que inicia una transición observable, como una solicitud aceptada o un proceso que se ejecuta.
• Condición habilitante: estado previo que permite que el disparador tenga ese efecto, como una delegación excesiva o una ruta de red accesible.
• Factor contribuyente: elemento que aumenta la probabilidad, duración o impacto, pero no basta por sí solo, como la ausencia de una alerta relevante.
• Mecanismo: transformación que conecta una condición con un resultado, por ejemplo, la evaluación de una política que concede una operación.
• Causa en un sentido operativo: condición cuya modificación razonable cambiaría el resultado o reduciría de modo relevante su probabilidad.

Estas categorías no son etiquetas universales. Una misma condición puede ser disparador en una pregunta y contribuyente en otra. Su valor está en obligar a declarar la pregunta y el nivel de análisis. «La credencial fue robada» puede explicar cómo comenzó una sesión, pero no explica por qué el actor pudo acceder a una base de datos, por qué el uso no fue detectado ni por qué la recuperación tardó tanto.

El error habitual es elegir una sola causa que produzca una acción inmediata: rotar la credencial. Rotarla puede ser una contención correcta y aun así dejar intacta la condición que permitía reutilizar secretos, el privilegio excesivo, la ausencia de autenticación fuerte o la falta de detección. Una remediación debe indicar qué nodo causal modifica y qué resultado espera cambiar.

La causa raíz no es una sustancia escondida

«Root cause» es un término de trabajo, no una propiedad natural que siempre tenga una única respuesta. En el sentido operativo que adoptamos en este capítulo, una causa raíz es una condición seleccionada como punto de intervención para explicar y reducir la recurrencia de un resultado dentro de un alcance. El alcance importa: una organización puede llamar causa raíz a un cambio de proceso, mientras que un equipo de plataforma identifica como causa raíz una interfaz que permitió una configuración insegura.

Una causa útil cumple al menos cuatro requisitos: está respaldada por evidencia; conecta con el resultado mediante un mecanismo; señala una intervención realista sobre ella o sobre una condición mediadora; y explica por qué las barreras existentes no evitaron o no detectaron el resultado. Una explicación que sólo coincide con el resultado, sin evidencia ni mecanismo, sigue siendo una conjetura. Si una condición causal no puede modificarse directamente, puede conservarse en la explicación siempre que los otros requisitos estén sustentados y se elija un punto de control distinto sobre la cadena.

La crítica de las cadenas lineales y de una única «causa raíz» tiene un antecedente en el enfoque sistémico de Leveson, 2004, introducción y §2.5. Aquí lo aplicamos como marco de análisis, no como prueba causal del incidente.

El método de los «cinco porqués» puede ayudar a profundizar, pero no convierte una cadena lineal en verdad. Las preguntas «¿por qué?» deben abrir ramas: ¿qué permitió el cambio?, ¿qué decisiones lo hicieron probable?, ¿qué barreras fallaron?, ¿qué señales existían?, ¿qué alternativas estaban disponibles? El error frecuente es detenerse en la respuesta más cercana a una persona («alguien no revisó») o en un control ausente («faltaba una regla») sin preguntar qué sistema de decisiones hacía previsible esa ausencia.

Un grafo causal para sistemas complejos

Un grafo causal representa variables o estados como nodos y relaciones causales como flechas dirigidas. No es una decoración del informe: explicita supuestos. En un ejemplo sintético, configuración de identidad puede influir en privilegio efectivo; privilegio efectivo puede influir en alcance de la cuenta; y alcance puede influir en datos modificados. telemetría disponible no causa necesariamente la modificación, pero sí influye en la probabilidad de detectarla y en la calidad de la explicación posterior.

Las flechas no deben mezclar niveles sin marcarlo. Una flecha de «política organizativa» a «valor de un atributo» expresa una decisión y una implementación intermedia; una flecha de «valor de atributo» a «acceso aceptado» expresa evaluación de autorización. Si se ocultan las capas, el grafo parece mágico y no indica dónde intervenir.

El grafo también permite distinguir una causa común de dos efectos. Un cambio de despliegue puede producir simultáneamente una configuración insegura y una degradación de logs. Si se observa una cuenta utilizada y un hueco de telemetría, no es necesario afirmar que uno causó al otro: ambos pueden derivar del mismo cambio. Confundir la causa común con una relación directa conduce a remediaciones equivocadas.

Un cambio de despliegue puede ampliar permisos y degradar logs; una rama afecta la operación y otra la evidencia disponible, sin flecha directa entre ellas.

Confusión, mediación y selección

En relación con una pregunta y un modelo causal definidos, un confusor interviene en vías que mezclan la asociación observada con el efecto que queremos estimar. Una causa común de la exposición y del resultado es el ejemplo elemental, pero estar asociado con ambos no basta para clasificar automáticamente una variable. Hernán y Robins, cap. 7, §§7.1–7.4 En seguridad, la hora del despliegue, el tipo de activo o la exposición pública pueden influir tanto en una configuración como en la cantidad de alertas observadas. Comparar sin considerar esas variables puede atribuir al control un efecto que corresponde al entorno.

Un mediador está en el camino entre una condición y un resultado. Si una política permite una operación, y la operación produce un cambio de estado, la autorización puede ser causa y el cambio de estado un mediador entre identidad y pérdida. Ajustar por un mediador al evaluar el efecto total puede ocultar precisamente el mecanismo que se desea comprender. Ser posterior a la intervención no basta para ser mediador: hace falta la relación causal propuesta. Pearl, §5.1

La selección aparece cuando sólo observamos casos que llegaron a un sistema de detección o a un proceso de investigación. Los incidentes con mejores logs pueden parecer más frecuentes o más simples que los incidentes no detectados. El conjunto de casos analizados no es automáticamente representativo del universo de fallos. No toda selección produce sesgo; importa cómo se relaciona con las variables del modelo y la pregunta. Hernán y Robins, cap. 8, §§8.1–8.6 Un resultado negativo en un canal sin cobertura no reduce la incertidumbre del mismo modo que un negativo en un canal probado.

No hace falta convertir cada investigación en un estudio estadístico. Sí hace falta preguntar qué variables quedaron fuera, qué casos no pudieron observarse y si la forma de seleccionar evidencia favorece una explicación. El lenguaje debe reflejarlo: «en los casos observados» es distinto de «en el sistema».

Intervenir y pensar contrafactualmente

Una afirmación causal se vuelve útil cuando anticipa el efecto de una intervención. «Si revocamos la credencial, desaparecerá el riesgo» es más fuerte que «la credencial participó», porque predice qué ocurrirá al cambiarla. La predicción puede fallar si existen otras credenciales, sesiones ya emitidas, rutas alternativas o cambios de comportamiento.

La intervención no es simplemente observar que una variable cambia. Es una acción controlada o razonablemente aislada: revocar un permiso, deshabilitar una ruta, restaurar una versión, añadir una validación o aumentar cobertura de telemetría. Antes de intervenir, debe definirse el resultado esperado, la ventana temporal, los controles de seguridad y la posibilidad de rollback. En producción, no se experimenta sin autorización ni sin valorar impacto.

Un control positivo aporta evidencia local de que la ruta y su observación producen la señal prevista bajo una condición conocida. El negativo usa un caso dentro del alcance donde la condición buscada está ausente y comprueba si aparece una señal espuria. Una condición fuera de alcance no sustituye ese control negativo. Ninguno demuestra el mecanismo completo ni excluye rutas alternativas. Comparar antes y después tampoco identifica por sí solo un efecto causal si cambiaron simultáneamente otras condiciones relevantes.

El error de retrospectiva consiste en evaluar una decisión pasada con información que sólo se obtuvo después. Para evitarlo, reconstruya qué señales, opciones y restricciones eran visibles en ese momento. Esto no elimina responsabilidad ni impide aprender; separa el análisis del sistema de la ficción de que el resultado era inevitable.

De un incidente a un argumento causal

Un flujo profesional puede organizarse así:

1. Definir el resultado: qué pérdida, cambio de estado o incumplimiento se explica y durante qué intervalo.
2. Fijar la frontera: activos, servicios, identidades, dependencias y procesos incluidos; declarar lo que no se investiga.
3. Preservar observaciones: logs, configuraciones, artefactos, entrevistas y timestamps con procedencia, integridad y contexto.
4. Normalizar eventos: unificar identificadores, relojes, zonas horarias y estados sin borrar valores originales.
5. Proponer hipótesis rivales: al menos una explicación alternativa que también pueda acomodar parte de la evidencia.
6. Mapear mecanismos: conectar condiciones, transiciones, barreras y resultado; etiquetar cada relación por estado de evidencia.
7. Buscar predicciones discriminantes: qué observaríamos si una hipótesis fuera cierta y qué esperaríamos si no lo fuera.
8. Evaluar intervenciones seguras: probar o simular cambios aprobados, conservando positivos, negativos y regresión.
9. Calibrar la conclusión: distinguir confirmado, altamente compatible, plausible, no determinado y descartado con la evidencia disponible.
10. Elegir acciones: vincular cada remediación a un nodo causal, dueño, condición de éxito y señal de regresión.

La respuesta a incidentes debe permitir detectar, responder y recuperarse; NIST SP 800-61 Rev. 3 integra la respuesta en la gestión del riesgo y destaca la mejora continua. NIST SP 800-61r3 El análisis causal se inserta en ese ciclo, pero no debe retrasar la contención cuando todavía existe daño activo. Primero se reduce la pérdida dentro de la autorización; luego se preserva y analiza la evidencia suficiente para explicar.

Caso conductor: un despliegue que amplía permisos

Consideremos un caso sintético. Un equipo despliega una nueva versión de un servicio. Horas después, un proceso de integración modifica registros de clientes que no pertenecen a su ámbito. Hay un log de autorización, pero no conserva todos los atributos de la política evaluada.

La observación permite afirmar: hubo un despliegue; se ejecutó un proceso; existieron operaciones de modificación; el resultado superó el ámbito esperado; la telemetría está incompleta. Aún no permite afirmar que el despliegue fue la causa única, que el proceso actuó de forma maliciosa ni que el hueco de logs produjo la modificación.

Una hipótesis es que el despliegue cambió el valor por defecto de una política y amplió el privilegio del proceso. Otra es que una credencial ya privilegiada fue usada por un actor externo; una tercera, que el servicio de autorización estaba correcto pero el identificador de tenant se transformó mal en la aplicación. Cada hipótesis predice evidencia distinta: diferencias de configuración, trazas de identidad, evaluación de políticas, payloads y pruebas de transformación.

El grafo podría incluir cambio de despliegue → política efectiva → autorización aceptada → consulta amplia → registros modificados. En paralelo, cambio de despliegue → esquema de logs incompleto → menor capacidad de adjudicar. El primer camino describe daño; el segundo describe observabilidad. Revocar la credencial puede contener, pero no discrimina entre hipótesis. Comparar la configuración antes/después, reproducir la evaluación en un entorno controlado y revisar una solicitud sintética con tenant conocido sí puede aumentar la evidencia.

Una conclusión calibrada sería: «La evidencia confirma que el proceso realizó modificaciones fuera del ámbito esperado y es altamente compatible con un cambio de privilegio durante el despliegue; la atribución causal final permanece abierta porque faltan atributos de autorización y existe una hipótesis alternativa de transformación de tenant». Esta conclusión es accionable: conserva la contención, asigna la recuperación de logs y evita declarar culpabilidad sin fundamento.

Barreras y causas sistémicas

Una barrera es una condición destinada a prevenir, detectar, responder o limitar un resultado. Las barreras pueden ser técnicas, humanas, procedimentales o institucionales. Un fallo no implica que una persona «sea la causa»: hay que preguntar qué diseño, información, carga de trabajo, interfaz, incentivo o autoridad hizo probable la decisión.

Sin embargo, «factor humano» tampoco debe convertirse en una explicación que cierre la investigación. Si un operador selecciona un ámbito incorrecto, revise si la interfaz hace indistinguibles dos entornos, si existe validación independiente, si el cambio se puede probar antes y si la urgencia modifica el proceso. El objetivo no es eliminar la responsabilidad individual cuando corresponde, sino evitar que una sanción sustituya el aprendizaje sobre barreras.

Las causas sistémicas no son excusas ni entidades vagas. Deben conectarse con mecanismos observables: un proceso que no exige revisión; una política que permite una excepción permanente; una métrica que premia velocidad sin medir reversibilidad; una dependencia cuya degradación no tiene comportamiento seguro. Una acción como «mejorar la cultura» no es remediación hasta traducirse en diseño, autoridad, práctica y evidencia de eficacia.

Una política demasiado amplia motiva un cambio acotado y una comprobación posterior; desplegarlo no demuestra causa única ni eficacia histórica.

Límites de la explicación

Toda explicación causal tiene dominio de validez. Puede explicar por qué una operación ocurrió en una versión y entorno, sin explicar todos los incidentes de la organización. Puede identificar una condición necesaria en ese caso sin que sea suficiente en otros. Puede mostrar que una barrera habría reducido probabilidad sin demostrar que habría evitado el resultado.

Declare al menos: intervalo temporal, sistemas y datos observados, calidad y huecos de telemetría, hipótesis alternativas evaluadas, intervenciones realizadas, supuestos y grado de confianza. Si una relación depende de un proveedor externo o de una identidad no adjudicada, manténgala como dependencia o incertidumbre, no como hecho.

También hay que evitar la causalidad retrospectiva de controles: que una remediación se implemente después no demuestra que habría prevenido el incidente. Para sostenerlo se necesita un mecanismo, un caso de prueba y una condición de éxito. Si no se puede probar en el incidente pasado, puede evaluarse en escenarios representativos con límites explícitos.

Cómo leer una conclusión causal

Una buena conclusión responde cinco preguntas: ¿qué resultado se explica?, ¿qué mecanismo lo conecta con las condiciones?, ¿qué evidencia sostiene cada relación?, ¿qué alternativas quedan abiertas?, ¿qué intervención modifica qué nodo y cómo se sabrá si funcionó? Si no responde la segunda, es una correlación narrada. Si no responde la cuarta, es una certeza inflada. Si no responde la quinta, es una lista de tareas disfrazada de aprendizaje.

Las palabras importan. «Confirmado» debe reservarse para una observación o relación con evidencia suficiente según el alcance. «Compatible» comunica que la hipótesis explica los datos, pero puede compartirlos con alternativas. «Probable» requiere describir la base de comparación o juicio. «No determinado» es un resultado válido cuando la cobertura no permite discriminar. «Causa raíz» debe ir acompañado de la pregunta, el alcance y el punto de intervención al que se refiere.

Síntesis

La causalidad profesional exige más que orden temporal: requiere mecanismo, contraste con alternativas y una predicción sobre qué cambiaría mediante una intervención. En sistemas complejos, el resultado surge de condiciones y barreras que pueden actuar en paralelo; una línea única de culpa o un «porqué» aislado oculta esa estructura.

La causa raíz no es necesariamente el primer evento ni el defecto más visible. Es una selección explicativa dentro de un alcance, respaldada por evidencia y conectada con una intervención que puede reducir recurrencia. Para elegirla hay que distinguir disparadores, condiciones habilitantes, contribuyentes, mediadores y causas comunes, declarar confusores y reconocer la selección de evidencia.

El producto final no es una historia perfecta. Es un argumento trazable: observaciones con procedencia, hipótesis rivales, mecanismos etiquetados, límites, acciones vinculadas a nodos y pruebas de regresión. Esta disciplina permite contener sin esperar certeza total, aprender sin inventar inevitabilidades y mejorar sistemas sin convertir la investigación en una búsqueda de culpables.

Comprobación de comprensión

1. ¿Qué diferencia lógica existe entre que un evento preceda a otro y que sea una causa? Construya un ejemplo de seguridad en el que la precedencia engañe.
2. Distinga disparador, condición habilitante, contribuyente y mecanismo en una autenticación aceptada desde un dispositivo no gestionado.
3. ¿Por qué la causa raíz depende del alcance y del punto de intervención elegido?
4. En un grafo causal, ¿cómo distinguiría una causa común de una relación directa entre dos observaciones?
5. Explique cómo un confusor o la selección de casos puede sesgar una conclusión sobre la eficacia de un control.
6. ¿Qué hace que una intervención sea informativa y segura en una investigación de producción?
7. Reformule «el error humano causó el incidente» en una conclusión que examine barreras y conserve límites.
8. Diseñe dos hipótesis rivales para el caso de permisos ampliados y describa qué evidencia las discriminaría.

Problema de transferencia

Un equipo observa que, después de un cambio de proveedor de identidad, aumentan las denegaciones de acceso y también los avisos de bloqueo de cuentas. La organización concluye que «el nuevo proveedor está causando ataques de fuerza bruta». Elabora una investigación causal sin asumir esa conclusión. Define el resultado y la frontera; separa observaciones de inferencias; propone un grafo con al menos un confusor, un mediador y una causa alternativa; especifica qué datos preservarías; y diseña una intervención o prueba segura que discrimine entre credenciales atacadas, cambio de política, error de sincronización y aumento de telemetría. Termina con una plantilla de conclusión calibrada, incluyendo lo que no podría afirmarse.

Fuentes principales

• NIST. SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025.
• NIST. SP 800-115: Technical Guide to Information Security Testing and Assessment, 2008.
• Judea Pearl. Causal inference in statistics: An overview. Statistics Surveys, 2009.
• Miguel A. Hernán y James M. Robins. Causal Inference: What If. Chapman & Hall/CRC, 2020.
• Nancy G. Leveson. A New Accident Model for Engineering Safer Systems. Safety Science, 2004.