← Todas las entradas

13 min de lectura

Construye una cronología de incidentes de seguridad verificable sin hacerla pública

Cómo un equipo de seguridad puede poner un sello de tiempo a las pruebas de un incidente y sellarlas a medida que las recopila: una cronología duradera y verificable de forma independiente que demuestra qué existía y cuándo, sin publicar detalles sensibles.

Un equipo de seguridad puede construir una cronología de incidentes demostrable sin hacer público el incidente antes de estar listo. A medida que recopilas las pruebas, calculas el hash de cada artefacto importante y publicas el digest en Cardano bajo Label 309. Quien tú elijas podrá confirmar más adelante que esos bytes exactos existían en un momento de bloque público, o antes, sin tener que confiar en tus servidores, en tu dominio ni en tu palabra. El material sensible se puede sellar para que el texto plano permanezca cifrado y solo el compromiso sea público.

En la práctica, calculas el hash de informes, registros, exportaciones forenses, capturas de pantalla, avisos a clientes, borradores para el regulador y manifiestos de pruebas a medida que el incidente avanza. Cada publicación ancla un compromiso en un momento público. El texto plano se puede sellar para destinatarios concretos, de modo que la cadena demuestra cuándo sin revelar qué.

Esto es una capa de pruebas, no un sustituto de la respuesta a incidentes, de la asesoría legal, de las decisiones de divulgación ni de los informes regulatorios. Le da a la cronología que hay detrás de esas decisiones un anclaje externo y a prueba de manipulaciones.

¿Por qué la cronología se convierte en prueba durante un incidente?

Durante un incidente, el tiempo en sí mismo es una prueba.

Después, un equipo suele tener que responder preguntas como estas:

  • cuándo se observó por primera vez una actividad sospechosa;
  • cuándo se escaló el incidente;
  • cuándo se notificó a la asesoría legal;
  • cuándo empezó la contención;
  • qué registros existían antes de reconstruir los sistemas;
  • qué registros de clientes se creían afectados en cada etapa;
  • qué versión de un informe llegó al consejo;
  • qué aviso al regulador se redactó o presentó;
  • qué cambió entre la primera evaluación y el informe final.

El problema es que las pruebas de un incidente cambian rápido. Los registros rotan. Los tickets se editan. Los informes se revisan. Las capturas de pantalla se pegan en diapositivas. Las exportaciones se vuelven a ejecutar. Una secuencia de hechos que parecía obvia el primer día puede ser difícil de demostrar seis meses después.

Un compromiso con sello de tiempo le da a cada artefacto importante un anclaje externo que nadie —ni siquiera tú— puede antedatar.

¿Qué debería sellar en el tiempo un equipo de seguridad?

Sella en el tiempo los artefactos que importarían si alguna vez se cuestionara la cronología.

En el caso de un incidente de seguridad, eso suele incluir:

  • las notas de detección iniciales;
  • las exportaciones de alertas;
  • las búsquedas de tu herramienta SIEM (gestión de información y eventos de seguridad);
  • las exportaciones de tu herramienta EDR (detección y respuesta en endpoints);
  • los registros de cortafuegos y de acceso;
  • los registros del proveedor de identidad;
  • los registros de auditoría en la nube;
  • las muestras de malware o sus hashes;
  • los manifiestos de imágenes forenses de disco o memoria;
  • las listas de cuentas afectadas;
  • las estimaciones de clientes afectados;
  • las notas de contención y erradicación;
  • los tickets del incidente;
  • los informes internos de estado;
  • las actualizaciones al consejo;
  • los borradores para el regulador;
  • los borradores de notificación a clientes;
  • los informes finales del incidente.

No publiques secretos en texto plano. Un hash, una raíz de Merkle o un texto cifrado sellado casi siempre es más seguro que el texto público, e igual de demostrable.

¿Cómo encaja Label 309 en la respuesta a incidentes?

Úsalo como una capa de prueba junto a las herramientas que ya tienes en marcha.

Un equipo de respuesta a incidentes no necesita reemplazar su SIEM, su herramienta de gestión de casos, su sistema de tickets, su plataforma forense ni su repositorio de documentos. Exportas o capturas una instantánea de los artefactos importantes, calculas sus hashes y publicas los registros en puntos definidos de la respuesta.

Un flujo típico:

  1. El equipo de detección exporta el primer lote de alertas.
  2. El responsable del incidente arma un manifiesto de los archivos.
  3. Se calcula el hash del manifiesto.
  4. Un registro Label 309 ancla el hash, o una raíz de Merkle sobre el lote.
  5. Los archivos sensibles se sellan para la asesoría legal y la dirección de seguridad.
  6. La referencia de transacción se adjunta al caso del incidente.

Más adelante, cualquiera que tenga esa referencia de transacción puede confirmar que un archivo o manifiesto dado coincide con los bytes comprometidos en el sello de tiempo público, usando el verificador, la herramienta de línea de comandos de código abierto o cualquier implementación del estándar hecha por terceros. El código de publicación y verificación es de código abierto en github.com/cardanowall.

¿Por qué sellar los registros del incidente en lugar de publicar los bytes?

Los detalles de un incidente suelen ser peligrosos de publicar.

Pueden contener vulnerabilidades sin parchear, credenciales, direcciones IP, datos de clientes, datos de empleados, detalles del actor de amenaza, hechos sensibles para las fuerzas del orden o planes de remediación comercialmente sensibles.

Un registro sellado te permite publicar un compromiso mientras mantienes el archivo cifrado. El registro en la cadena lleva el hash del texto plano —la prueba del momento— más una clave envuelta que solo los destinatarios elegidos pueden abrir. El texto cifrado vive en una URI de almacenamiento direccionado por contenido, no en la cadena, y las claves públicas de los destinatarios tampoco aparecen nunca en la cadena. Un observador solo se entera de que existe un registro sellado, de su momento de bloque y de a cuántos destinatarios se selló; nunca de quiénes son ni de qué se selló.

Así puedes preservar las pruebas originales sin revelar el incidente a través del propio registro de prueba. Para más detalles sobre cómo sellar archivos para personas concretas sin exponer el contenido, consulta divulgación confidencial sin archivos públicos.

¿Cómo ayuda esto con los plazos del regulador?

Muchos regímenes de incidentes dependen del momento, y un registro a prueba de manipulaciones de cuándo supiste qué puede respaldar esas determinaciones.

  • En Estados Unidos, las normas de la SEC exigen a los emisores nacionales presentar un Formulario 8-K conforme al Punto 1.05 por un incidente de ciberseguridad material dentro de los cuatro días hábiles siguientes a determinar que el incidente es material: el plazo corre desde la determinación de materialidad, no desde el descubrimiento. La SEC también ha subrayado que la determinación de materialidad debe hacerse sin demora injustificada.
  • En la Unión Europea, la Directiva NIS2 establece un plazo de tres etapas para un incidente significativo: una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento de él, una notificación del incidente en un plazo de 72 horas y un informe final en el plazo de un mes.
  • Para las entidades financieras de la UE, el Reglamento sobre la Resiliencia Operativa Digital (DORA) introdujo obligaciones armonizadas de gestión de incidentes de TIC y de notificación de incidentes graves que empezaron a aplicarse el 17 de enero de 2025.

Las obligaciones exactas dependen de la empresa, el sector, la jurisdicción y el incidente, y cambian con el tiempo: esto es información general de contexto, no asesoramiento legal. Una prueba no decide si un informe es obligatorio, y no demuestra que cumpliste un plazo. Lo que sí puede hacer es preservar un registro a prueba de manipulaciones de los artefactos y las evaluaciones que hay detrás de esas decisiones, de modo que la cronología en la que te basaste pueda mostrarse más adelante. Trátalo como una prueba que puede respaldar un caso; no sustituye a la asesoría legal.

¿Cómo es un flujo de trabajo de prueba en la práctica?

Define un pequeño conjunto de momentos de prueba antes de necesitarlos.

Una empresa podría definir los puntos de control de prueba de un incidente así:

  • T0: primera señal detectada o primer lote de alertas;
  • T1: incidente declarado;
  • T2: evaluación inicial del alcance;
  • T3: acción de contención iniciada;
  • T4: borrador de evaluación de materialidad o de obligación de informar;
  • T5: actualización al consejo o a la dirección;
  • T6: borrador de aviso al regulador o al cliente;
  • T7: informe final del incidente;
  • T8: revisión posterior al incidente y plan de remediación.

Cada punto de control produce un manifiesto. Se puede calcular el hash del manifiesto directamente o incluirlo como una hoja de Merkle dentro de una raíz del incidente más amplia.

El resultado es una cronología fácil de explicar más adelante: aquí están los puntos de control, aquí están los artefactos, aquí están los sellos de tiempo públicos y aquí está cómo verificar que los archivos coinciden.

¿Cuándo deberías comprometer una raíz de Merkle en vez de un registro por archivo?

Usa una raíz de Merkle cuando el conjunto de pruebas es grande.

Un incidente serio puede implicar miles o millones de líneas de registro, alertas, paquetes, hashes de archivos, eventos de endpoints y actualizaciones de tickets. Publicar un registro por artefacto es caro y difícil de gestionar.

En su lugar, construye un manifiesto determinista, calcula el hash de cada entrada para obtener una hoja, construye un árbol de Merkle y publica una sola raíz de 32 bytes para el punto de control. Más adelante podrás demostrar que una exportación de registro, un evento o un hash de archivo concreto estaba en ese punto de control —con una prueba de inclusión compacta— sin revelar el resto del conjunto de pruebas.

Eso encaja de forma natural para:

  • los lotes diarios de pruebas del incidente;
  • los registros de la nube de gran volumen;
  • las listas de clientes afectados;
  • los inventarios de artefactos de endpoints;
  • los manifiestos de recopilación forense;
  • las instantáneas de análisis de vulnerabilidades;
  • las pruebas de parches y remediación.

Una advertencia: una raíz solo es útil si conservas el manifiesto, la lista ordenada de hojas y las pruebas de inclusión. La cadena almacena la raíz; tú almacenas todo lo necesario para demostrar que una hoja está bajo ella. El mismo patrón —un registro que representa a un conjunto enorme— se trata en un registro para miles de archivos.

¿Cómo funcionan las correcciones cuando los hechos cambian?

Los informes de incidentes cambian porque los hechos mejoran, y el estándar te permite dejarlo visible.

Las estimaciones tempranas suelen estar equivocadas. Un equipo puede creer primero que 200 cuentas estaban afectadas, luego descubrir que eran 2.000 y después excluir 150 falsos positivos. Esos cambios no deberían ocultarse: deberían poder explicarse.

Un registro puede llevar un puntero de sustitución: el hash de transacción de 32 bytes de un registro anterior al que reemplaza. El registro anterior permanece en la cadena y sigue siendo verificable de forma independiente; la cadena solo añade (append-only), así que sustituir no elimina ni invalida nada. El puntero simplemente dice, en efecto, esta es la versión posterior. No lleva ningún campo de motivo: cualquier significado humano pertenece al nuevo contenido, no al puntero.

Esa distinción importa: preserva la diferencia entre una revisión honesta y una reescritura silenciosa. El historial es visible, está en orden y es demostrable.

¿Quién debería recibir los registros sellados del incidente?

Mantén la lista de destinatarios pequeña y deliberada. Cada destinatario adicional es otra parte que puede descifrar —y, tras descifrar, filtrar— el texto plano.

Entre los destinatarios habituales están:

  • la asesoría legal externa;
  • el departamento jurídico interno;
  • el responsable del incidente;
  • el CISO o la dirección de seguridad;
  • un socio forense;
  • un contacto del regulador, cuando proceda;
  • la asesoría legal del seguro cibernético o un proveedor del panel;
  • un comité de seguridad del consejo;
  • una identidad de archivo de confianza que la empresa controle.

Cada destinatario debería proporcionar una dirección de recepción que hayas verificado realmente fuera de banda, confirmando que la clave pertenece de verdad a esa persona y no a alguien que la suplanta. Sellar para la clave equivocada sella para el lector equivocado, y la cadena no detectará ese error por ti; verifica a un destinatario antes de sellar un archivo explica paso a paso cómo hacerlo. Para pruebas sensibles y de larga duración, prefiere la dirección de recepción híbrida poscuántica opcional allí donde el flujo de trabajo la admita. Está diseñada para resistir un ataque de «recolectar ahora, descifrar después», en el que un adversario almacena hoy el texto cifrado y espera a que un futuro ordenador cuántico lo rompa.

¿Qué no debería entrar nunca en los metadatos públicos?

Mantén los secretos del incidente totalmente fuera del registro público.

No publiques:

  • detalles de exploits en texto plano;
  • credenciales;
  • claves privadas;
  • datos personales de clientes;
  • nombres de host o direcciones IP internas sensibles;
  • detalles de la infraestructura del atacante que deban permanecer confidenciales;
  • análisis jurídico privilegiado;
  • acusaciones sin fundamento;
  • información solo para el regulador que no debería ser pública.

La cadena pública debería llevar compromisos —hashes, raíces, sobres sellados—, no la narrativa del incidente. La narrativa se queda en tus sistemas y, cuando hace falta, dentro de un texto cifrado sellado.

¿Demuestra una prueba que la empresa gestionó bien el incidente?

No. Es más acotada que eso, a propósito.

Una prueba puede demostrar que ciertos archivos o manifiestos existían en un momento público o antes. Puede demostrar que una clave de firma concreta respaldó un registro, cuando está presente la firma de autoría opcional. Puede demostrar que un artefacto posterior coincide con un compromiso anterior.

No demuestra que la investigación estuviera completa, que la empresa tomara las decisiones correctas, que se cumplieran los plazos legales, que los controles fueran eficaces ni que se notificara correctamente a los clientes. Es una prueba sobre el momento y la integridad, no sobre la verdad, el criterio o el cumplimiento. Para la versión general de este límite, consulta qué no demuestra una prueba.

¿Qué puede salir mal?

Los fallos más habituales son operativos, no criptográficos.

Puedes sellar en el tiempo los archivos equivocados. Puedes perder las pruebas originales. Puedes no conservar las hojas de Merkle de las que depende una raíz. Puedes meter un hecho sensible en un campo público. Puedes sellar para una dirección de recepción que nadie verificó. Puedes dejar que descifre demasiada gente. Puedes empezar a tratar la capa de prueba como tu sistema de informes en lugar de como la capa de pruebas que hay detrás de él.

La mejor defensa es procedimental: define tus puntos de control de prueba antes de un incidente, automatiza las partes aburridas y mantén a la asesoría legal implicada allí donde haya posible exposición jurídica.

La versión corta

Los incidentes de seguridad necesitan una cronología que resista la presión.

Label 309 ancla los artefactos, los informes y los manifiestos del incidente a un momento público. Los registros sellados mantienen las pruebas sensibles cifradas para los destinatarios elegidos. Las raíces de Merkle comprometen conjuntos grandes de pruebas con un solo registro. Los punteros de sustitución hacen visibles las correcciones en lugar de silenciarlas, sin confiar en ningún servidor ni proveedor concreto.

Úsalo para demostrar qué existía y cuándo. No lo uses para reemplazar la respuesta a incidentes ni los informes legales, y no esperes que demuestre nada más allá del momento y la integridad.

Lecturas adicionales

securityincident-responseproof-of-existence