Evidencia técnica: procedencia, integridad y contexto

Una traza no habla por sí sola

Un equipo recibe una alerta: una cuenta administrativa inició sesión desde una dirección asociada con otro país y, dos minutos después, descargó varios gigabytes. El informe preliminar dice: «La cuenta fue comprometida y los datos fueron exfiltrados». La frase puede terminar siendo correcta, pero todavía no sabemos qué registro la sostiene, quién lo produjo, si fue transformado por el pipeline, si su reloj es comparable con los demás ni si la descarga pertenece a la misma sesión.

El capítulo anterior enseñó a separar observación, inferencia, hipótesis y conclusión. Este capítulo aborda una pregunta previa y más material: ¿qué hace que una observación pueda conservarse, revisarse y reutilizarse como evidencia técnica? La respuesta no es «tener un log» ni «calcular un hash». Una evidencia profesional necesita al menos tres dimensiones conectadas:

• procedencia: de dónde proviene, qué agente o sistema la produjo, cómo fue capturada y qué transformaciones recibió;
• integridad: qué fundamento permite afirmar que el artefacto no cambió desde un punto definido, o que cualquier cambio quedó detectado;
• contexto: qué significan sus campos, a qué activo, versión, operación, tiempo y alcance corresponden, y qué condiciones rodeaban la observación.

Estas dimensiones no convierten un dato en verdad absoluta. Hacen posible formular qué parte del dato se conoce, qué se interpreta y qué conclusión está autorizada. NIST SP 800-61 Rev. 3, publicado en abril de 2025, pide registrar las acciones de investigación y preservar la integridad y procedencia de esos registros; también pide recoger datos y metadatos del incidente preservando esas propiedades. NIST SP 800-61 Rev. 3, RS.AN-06 y RS.AN-07

Qué llamamos evidencia

En este capítulo, evidencia técnica es un artefacto, registro, medición, configuración, declaración o derivación que puede servir como fundamento para aceptar o rechazar una proposición dentro de una investigación. No es sinónimo de «dato interesante», «salida de una herramienta» ni «prueba judicial». La misma evidencia puede respaldar una decisión operativa sin cumplir los requisitos de un procedimiento legal, o puede ser irrelevante para el claim que se intenta sostener.

La definición importa porque desplaza la pregunta. En lugar de «¿tenemos muchos datos?», preguntamos: «¿qué afirmación debe adjudicarse y qué artefacto permite hacerlo?». Un evento de autenticación puede apoyar que un componente aceptó credenciales en un momento determinado. No prueba por sí solo que una persona actuara, que la sesión fuese legítima, que la cuenta estuviera comprometida o que los datos posteriores salieran de esa sesión.

La evidencia siempre es evidencia para algo. NIST define evidence como fundamentos para creer o no creer y como datos sobre los que se basa una prueba o se establece verdad o falsedad; SP 800-61 Rev. 3 usa esa definición al distinguir la recolección ordinaria de un procedimiento formal de cadena de custodia. La distinción evita prometer que todo incidente exige el mismo tratamiento jurídico.

Conviene registrar una evidencia como una relación entre cuatro elementos:

1. artefacto: el objeto disponible, como un archivo de log, una captura, una imagen de disco, una consulta o una nota de entrevista;
2. afirmación: lo que se quiere sostener o descartar;
3. operación: cómo se obtuvo, transformó, comparó o interpretó;
4. alcance: sistema, versión, tiempo, actor, datos y condiciones cubiertos.

Un informe que sólo adjunta el artefacto deja al lector reconstruir los otros elementos. Esa reconstrucción suele ser imposible semanas después, cuando el servicio cambió o el analista ya no recuerda qué filtro aplicó.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Procedencia: seguir la historia del artefacto

La procedencia describe la historia relevante de una entidad: quién o qué la generó, qué actividad la usó, qué transformación produjo una nueva versión y quién asumió responsabilidad por esas actividades. El modelo PROV del World Wide Web Consortium (W3C) separa entities, activities y agents. Una entidad puede ser un log, una captura o una tabla; una actividad puede ser la ingestión, el parsing o una consulta; un agente puede ser un sensor, un servicio, una persona o una organización. W3C PROV Primer, §§2–3

El vocabulario evita dos errores. El primero es tratar un archivo exportado como si fuese la ocurrencia original. El segundo es atribuir una decisión a «el sistema» sin saber qué proceso, regla o persona intervino. En una cadena sencilla:

agente de aplicación → evento generado → colector → parser → índice → consulta del analista → extracto del informe.

Cada flecha es una actividad que puede conservar o alterar significado. El evento generado por la aplicación no es idéntico al documento que un analista copia desde el SIEM. El extracto del informe puede ser correcto y, aun así, depender de una consulta cuya versión, zona temporal o filtro ya no se recuerdan.

La procedencia mínima de un registro debería incluir, según el caso, identificador del productor, activo y versión, tipo de fuente, ubicación o tenant, intervalo temporal, método de adquisición, operador o cuenta de servicio, herramienta y versión, transformaciones, exportación y relación con el original. No se trata de rellenar un formulario por costumbre. Cada campo responde a una pregunta de reproducibilidad: ¿podría otra persona localizar el mismo objeto y entender cómo pasó a esta forma?

Original, copia y derivación

«Original» es una palabra peligrosa en sistemas distribuidos. Un log escrito localmente, una copia enviada al colector y una exportación CSV pueden representar el mismo evento, pero son entidades distintas con diferentes metadatos, tiempos de recepción y posibilidades de pérdida. NISTIR 8387 distingue medios físicos, imágenes o archivos digitales y otros objetos digitales, y advierte que el contenido puede estar en sistemas remotos o cloud cuya localización física no sea evidente. NISTIR 8387, §1.1

La práctica conservadora es mantener un artefacto de referencia cercano a la fuente y separar sus derivados: una copia normalizada para buscar, una muestra anotada para explicar y una tabla agregada para comparar. Cada derivado debe apuntar al identificador de entrada, registrar el comando o consulta, conservar reglas y versión de enriquecimiento y declarar los campos descartados.

«Raw» tampoco significa «sin interpretación». Un sistema operativo ya decidió qué eventos producir; un agente puede truncar campos; un colector puede descartar mensajes si se llena una cola. Raw significa, como mucho, anterior a determinadas transformaciones conocidas. La procedencia debe nombrar qué transformaciones aún quedan fuera.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Cadena de custodia y cadena de procedencia

La cadena de custodia es el registro de movimiento y control del activo: quién lo recibió, cuándo, dónde se almacenó, para qué se transfirió y quién lo entregó después. CISA la presenta como una práctica para aumentar transparencia y accountability sobre sistemas, datos y evidencia, no sólo como un requisito de laboratorio policial. CISA, Chain of Custody and Critical Infrastructure Systems, pp. 1–2

La cadena de custodia es una parte de la procedencia, no su sinónimo. Puede documentar que Alice entregó un disco a Bob, pero no explicar qué proceso generó un log, qué versión de parser lo transformó o si el reloj de la fuente estaba sincronizado. Inversamente, una tubería puede tener una procedencia técnica excelente y un procedimiento de transferencia informal que no satisface una obligación legal. Elegir el nivel depende del claim, las consecuencias y la política aplicable.

Integridad: detectar cambios no autorizados

La integridad de un artefacto es una afirmación temporal y relativa: «este objeto es el mismo que el objeto de referencia en el momento de comparación» o «los cambios ocurridos entre dos estados están registrados y explicados». No significa que el contenido sea correcto, completo, benigno o verdadero. Un log falsificado antes de ser almacenado puede tener una integridad perfecta desde el momento en que se calculó su hash.

Un hash criptográfico calcula una representación de longitud fija del contenido. Si el archivo cambia, normalmente cambia el digest; comparar ambos permite detectar diferencias cuando el valor de referencia está protegido. Pero un hash no identifica quién produjo el archivo, no demuestra que el archivo fuera auténtico antes del hash y no protege el valor de referencia si una persona con acceso puede reemplazar ambos. NISTIR 8387 recomienda documentar la fuente y creación del archivo, calcular hashes cerca de la recolección y guardar los valores en un lugar protegido separado del objeto; también describe copias, hashes por bloques y qué hacer ante una comparación fallida. NISTIR 8387, §3.2.1 y §9

Una firma digital añade una relación con una clave y una política de confianza. NIST la describe como una transformación que, cuando se implementa con infraestructura y política de apoyo, puede proporcionar autenticación del origen, integridad y soporte para no repudio del firmante. NIST, glosario «digital signature» La firma no prueba que el firmante dijera la verdad ni que el documento describa correctamente el mundo. Prueba que alguien con la clave asociada firmó determinados bytes, siempre que la clave y la validación sean confiables.

Un código de autenticación de mensajes (MAC) también detecta cambios y autentica a quien comparte la clave, pero no ofrece la misma propiedad de atribución frente a terceros: cualquiera con la clave puede generar un MAC válido. En evidencia operativa puede ser apropiado; la elección es una decisión de threat model, no una medalla de sofisticación.

La preservación útil exige además disponibilidad y legibilidad, pero esas propiedades no son sinónimos de integridad. Un archivo puede conservar exactamente sus bytes y resultar inaccesible por una clave perdida; también puede conservarlos en un formato que ya no puede interpretarse. Son fallos de disponibilidad o de interpretabilidad, no prueba de alteración. Por eso el plan de preservación debe considerar copias, controles de acceso, registro de lecturas, almacenamiento aislado o inmutable cuando sea proporcional y pruebas de recuperación.

Integridad del registro y del significado

Una firma o hash protege una secuencia de bytes, no el significado de cada campo. Si un exportador cambia event_time por ingest_time sin modificar el contenido firmado, el objeto puede ser íntegro como archivo y engañoso como representación temporal. Por eso conviene validar dos planos:

• integridad de contenido: los bytes o registros no cambiaron desde el punto de referencia;
• integridad semántica: el esquema, unidades, codificaciones, claves, zona temporal y reglas de interpretación siguen siendo los que el claim presupone.

RFC 5848 muestra la diferencia en un caso concreto. syslog-sign añade autenticación de origen, integridad de mensajes, resistencia a replay, secuenciación y detección de mensajes faltantes mediante bloques de firma y hashes. RFC 5848, §1 Eso mejora la evidencia del transporte de syslog, pero no convierte un evento emitido por una aplicación defectuosa en una descripción completa del mundo. La garantía cubre propiedades del canal y del conjunto de mensajes definido por el protocolo.

Contexto: qué significa el artefacto aquí

El contexto es el conjunto de condiciones necesarias para interpretar una evidencia sin extenderla a otro sistema, tiempo o significado. Incluye al menos:

• identidad, versión y configuración del productor;
• activo, tenant, región y frontera de la investigación;
• semántica de campos y unidades;
• hora de ocurrencia, hora de recepción, zona y estado de sincronización;
• identidad o proceso al que se atribuye la acción;
• controles, cambios y mantenimiento concurrentes;
• cobertura, retención, filtros, pérdidas y límites conocidos;
• baseline o comportamiento esperado con el que se compara.

El contexto no es un apéndice narrativo. Cambia lo que el artefacto puede sostener. login_success en una API puede registrar la aceptación de un token, mientras que el usuario humano aparece en otro servicio. Una dirección IP puede identificar un egress compartido y no una persona. Un delete puede ser una operación administrativa legítima, una tarea automática o un reintento de la aplicación. Sin esquema y arquitectura, el texto del evento induce más certeza de la que contiene.

El tiempo merece tratamiento propio. Dos eventos con la misma marca pueden no ser contemporáneos si una fuente registra hora local, otra UTC y otra hora de ingestión. La sincronización no corrige por sí sola una diferencia entre «evento iniciado» y «evento completado». Un buen expediente conserva las marcas disponibles, la precisión declarada, la fuente del reloj y cualquier corrección aplicada, en vez de sustituir silenciosamente todos los tiempos por una columna normalizada.

La cobertura también es contexto. NIST SP 800-61 Rev. 3 indica que los logs son importantes para registrar y preservar información vital para detección, respuesta y recuperación, y pide correlacionar información y contexto de múltiples fuentes. NIST SP 800-61 Rev. 3, PR.PS-04 y DE.AE-03 «No aparece un evento» tiene un significado distinto cuando la fuente registra todos los intentos y cuando sólo registra éxitos, retiene siete días o perdió mensajes durante una caída.

Caso conductor: reconstruir una descarga administrativa

Volvamos a la alerta de inicio de sesión y descarga. El objetivo no es atribuir públicamente a una persona, sino decidir si hay base suficiente para revocar la sesión y preservar datos adicionales sin perder la oportunidad de investigar.

La pregunta y los claims

La pregunta operativa es: «¿La sesión s-481 realizó la descarga d-902 en el servicio de informes, y qué parte de esa actividad requiere contención?». De ella se derivan claims más pequeños:

1. el servicio aceptó un inicio de sesión para la cuenta administrativa en un intervalo concreto;
2. una operación asociada a una sesión descargó un conjunto y volumen concretos;
3. los dos eventos pertenecen al mismo principal, sesión o token;
4. la operación estaba o no estaba autorizada en ese entorno y ventana;
5. existen señales que distinguen compromiso, automatización legítima, VPN o error de correlación.

El quinto claim no se resolverá con una sola traza. El capítulo 4 ya enseñó a formular hipótesis rivales; aquí diseñamos el expediente que permite compararlas.

El paquete de evidencia

El equipo conserva, en modo de sólo lectura, el evento de autenticación del proveedor de identidad, el registro de acceso del servicio de informes, el inventario de dispositivos y tokens, el cambio aprobado de la cuenta, la configuración de retención y una exportación del SIEM. Para cada objeto registra productor, versión, identificador, rango temporal, consulta de extracción, operador, formato, hash y ubicación de la copia de referencia. El CSV del SIEM es una derivación; no reemplaza los registros fuente.

Desliza horizontalmente para consultar todas las columnas.

La tabla no produce el veredicto. Hace visible la deuda. Si el servicio sólo conserva user_id y no session_id, no debe afirmarse que la descarga pertenece a la misma sesión sólo porque ocurrió dos minutos después. Si el SIEM añadió geolocalización de una base actualizada después del evento, el país es un dato derivado con fecha propia. Si el hash se calculó después de editar un CSV, protege esa edición, no la fuente.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Desliza horizontalmente para leer el diagrama a tamaño completo.

De los bytes a una decisión

Tras verificar copias y reconstruir el esquema, el equipo confirma que el IdP aceptó un token para la cuenta y que el servicio registró una descarga del volumen indicado. También observa que el dispositivo coincide con uno administrado, el egress pertenece a la VPN corporativa y existe una tarea aprobada para esa ventana. La evidencia reduce el apoyo a «compromiso», pero no prueba que la actividad fuese legítima: todavía podría existir una sesión robada desde un dispositivo válido o una autorización mal usada.

La conclusión proporcional es: «Los registros conservados sostienen que el servicio aceptó el token y que una operación de descarga ocurrió en la ventana indicada. La asociación entre ambos eventos es compatible con la sesión s-481 según el identificador disponible. El expediente no determina por sí solo quién operó el dispositivo ni si la tarea fue autorizada en su finalidad». Esta frase distingue observación, relación técnica y límite de atribución. Permite revocar el token como medida prudente sin llamar «intrusión confirmada» a una hipótesis aún abierta.

Cómo construir un expediente revisable

Un expediente útil no consiste en acumular archivos. Debe permitir que otra persona responda cinco preguntas: ¿qué se afirmó?, ¿qué se observó?, ¿cómo llegó hasta aquí?, ¿qué cambió?, ¿qué no se sabe? Un formato mínimo puede contener:

1. identificador y objetivo: claim, sistema, versión, alcance y decisión que depende del resultado;
2. inventario de fuentes: productor, propietario, ubicación, retención, cobertura y semántica;
3. adquisición: fecha, zona, operador, herramienta, versión, permisos, consulta y errores;
4. integridad: hash o firma, momento de cálculo, ubicación del valor de referencia, copias y verificaciones;
5. transformaciones: parsing, normalización, deduplicación, enriquecimiento, agregación y filtros;
6. contexto operativo: cambios, mantenimiento, identidades, relojes, configuración y baseline;
7. transferencias y acceso: quién recibió, almacenó, consultó o derivó cada objeto;
8. resultado y límites: qué claim apoya, qué alternativas siguen vivas y qué queda fuera de alcance.

La conservación debe ser proporcional. NIST SP 800-61 Rev. 3 recomienda retener evidencia conforme a procedimientos y políticas, considerando la posibilidad de proceso, el coste y la capacidad futura de acceder a hardware y software. No significa guardar todo indefinidamente: antes de borrar hay que decidir qué preguntas deben seguir siendo respondibles y qué datos sensibles proteger.

Hay una tensión real entre disponibilidad para revisar y confidencialidad. Los registros pueden contener secretos, datos personales, vulnerabilidades explotadas o acciones de usuarios. El acceso debe ser autorizado, auditable y mínimo; una copia de evidencia no debe convertirse en una nueva superficie de exposición. CISA subraya que una cadena de custodia incompleta permite manipulación y debilita la capacidad de demostrar lo ocurrido. La respuesta no es crear una base central con todos los datos sin límites, sino asignar propietarios, controles, retención y criterios de transferencia.

Lo que la evidencia no puede hacer por sí sola

Un hash no prueba veracidad. Una firma no prueba intención. Una cadena de custodia no corrige un reloj equivocado. Un registro completo no prueba que el productor capturara el evento correcto. Dos dashboards no son fuentes independientes si comparten colector, parser y almacenamiento. Una copia idéntica no conserva los campos que nunca fueron registrados.

Tampoco conviene confundir preservación con análisis. Preservar un artefacto protege la posibilidad de examinarlo más tarde. Analizarlo asigna significado y lo relaciona con un claim. Mezclar ambas actividades puede contaminar la referencia: el analista abre, normaliza o anota el mismo archivo que luego presenta como «original». La separación entre copia de referencia, derivados de trabajo y reporte hace visibles esas operaciones.

La procedencia puede estar incompleta sin que el dato sea inútil. El estado correcto no es convertir cada defecto en «evidencia inválida», sino acotar la conclusión y registrar la deuda: «se conserva el archivo exportado y su hash; no se pudo recuperar el log local anterior al colector». El capítulo 6 desarrollará cómo esa información afecta incertidumbre y confianza. Aquí basta no borrar el límite.

Revisar la evidencia sin fabricar independencia

La trazabilidad también debe responder una pregunta menos visible: ¿cuántas observaciones independientes tenemos? Tres paneles que reciben el mismo evento desde el mismo colector no son tres confirmaciones. Si el parser transforma un campo y después sus tres salidas lo repiten, la duplicación aumenta la disponibilidad para leer, no la fuerza inferencial. El expediente debe conservar la relación entre fuentes y derivaciones para que el analista no cuente copias como corroboración.

Una revisión práctica empieza por dibujar el grafo de dependencias. Cada nodo es una entidad —evento, archivo, consulta, tabla, captura o nota—; cada arista declara una actividad —generación, adquisición, parseo, normalización, correlación, exportación o lectura— y el agente que la ejecutó. El grafo no necesita adoptar toda la notación de PROV para ser útil, pero sí debe permitir recorrerlo en ambos sentidos: desde una afirmación hasta los bytes o registros que la sostienen, y desde una fuente hasta todos los claims que dependen de ella. Cuando una arista no tiene operador, versión o parámetros, se registra como una laguna, no como una transformación desconocida que se presume inocua.

El mismo método separa errores de adquisición de errores de interpretación. Una cola llena puede perder eventos antes de que exista un archivo; una exportación con un filtro equivocado puede conservar perfectamente el subconjunto equivocado; una tabla correcta puede recibir una explicación que confunde ingest_time con event_time. Cada caso cambia la pregunta que todavía puede responderse. La integridad del archivo sólo aborda el segundo momento si el archivo ya existía y su referencia estaba protegida.

Reconciliar fuentes que discrepan

La discrepancia entre dos fuentes no se resuelve eligiendo la que “parece más completa”. Primero se registra el desacuerdo como un hecho: identificadores, intervalos, precisión, zona horaria, versiones, cobertura y transformaciones. Después se formula una hipótesis sobre el mecanismo de divergencia: relojes desincronizados, retries, duplicación del colector, pérdida selectiva, reglas de muestreo, caché o semánticas distintas del campo. Sólo entonces se decide qué prueba podría distinguir las hipótesis.

Una fuente puede tener mayor resolución temporal y menor cobertura; otra puede tener menor precisión pero conservar todos los intentos. No hay una jerarquía universal que sustituya el análisis del claim. Para ordenar una descarga, por ejemplo, un registro del servicio puede probar aceptación del endpoint mientras que una traza de red pruebe transmisión; ninguna prueba por sí sola intención del operador. Si una fuente contradice al resto, el resultado provisional debe mantener ambas posibilidades hasta revisar su procedencia y alcance.

La corroboración también requiere independencia de controles. Un hash calculado dos veces sobre la misma exportación sólo confirma estabilidad de esa exportación. Un segundo cálculo en un host distinto puede reducir el riesgo de error de lectura, pero no repara que el archivo se haya generado después de un filtro destructivo. Para fortalecer un claim de ocurrencia conviene buscar una fuente producida por un componente distinto con una ruta de generación independiente y explicar qué parte del fenómeno observa cada una.

Preservar cuando el tiempo es limitado

Durante una respuesta, preservar no significa congelar toda la infraestructura sin criterio. Significa proteger primero los artefactos cuyo retardo de adquisición o pérdida de retención alteraría decisiones inmediatas. El equipo debe anotar la razón y el alcance de cada acción: qué fuente se preservó, desde cuándo, con qué permisos, qué impacto operacional tuvo y qué datos no se pudieron obtener. Una adquisición urgente puede preceder a la documentación completa; en ese caso el expediente conserva el hueco y la fecha en que se cerró o quedó pendiente.

Las acciones de contención pueden cambiar la evidencia. Revocar un token, reiniciar un proceso o rotar una clave reduce exposición, pero puede borrar memoria, cerrar una sesión o alterar futuros registros. Eso no vuelve incorrecta la contención. Exige registrar la secuencia para que una observación posterior no se interprete como estado previo. El claim “no hubo más actividad después de las 14:00” sólo es defendible si se conoce qué controles cambiaron a esa hora y qué fuentes siguieron funcionando.

La retención es una decisión de arquitectura y de riesgo. Debe considerar sensibilidad, acceso, costes de almacenamiento, formato, capacidad de reproducir herramientas y obligaciones aplicables. Una política que conserva sólo el CSV final puede satisfacer una métrica de espacio y destruir la capacidad de contestar qué filtro produjo el resultado. Otra que guarda cada secreto o payload sin redacción crea un daño nuevo. Preservar una referencia con acceso limitado, hashes, metadatos, consultas y un registro de transformaciones suele dar mejor equilibrio que copiar indiscriminadamente.

Redactar decisiones que sobrevivan a una revisión

Una conclusión profesional debe poder descomponerse en tres capas. La primera es observacional: “el servicio emitió el evento E en el intervalo T”. La segunda es relacional: “E y D comparten el identificador S y la consulta conservada los vincula”. La tercera es decisional: “por esa evidencia, se revoca provisionalmente el token y se solicita una comprobación adicional”. Cada capa puede tener confianza y límites distintos. La decisión puede ser razonable incluso si la atribución humana sigue abierta; no hace falta inflar la observación para justificar una acción reversible.

Una plantilla útil es: “Dentro de [alcance], [fuente] permite afirmar [claim] porque [mecanismo y evidencia]. No permite afirmar [límite], debido a [laguna o precondición]. La acción [decisión] se toma para [objetivo], y será revisada cuando [prueba o condición]”. La plantilla no reemplaza el razonamiento: obliga a no saltar de un artefacto a una historia completa. También permite comunicar incertidumbre a un responsable que no necesita leer cada byte, pero sí necesita saber qué está confirmado y qué podría cambiar.

El expediente debe conservar las decisiones rechazadas o alternativas relevantes. Eliminar una hipótesis porque no encaja con el primer dashboard hace imposible entender por qué se descartó. Registrar “VPN legítima” como hipótesis y luego anotar qué observación la debilitó es distinto de afirmar que la geolocalización “demostró” una identidad. La documentación de una decisión negativa es evidencia sobre el proceso de investigación, no un sustituto de la evidencia del incidente.

Síntesis

La evidencia técnica es un fundamento situado, no un archivo que adquiere autoridad al adjuntarse a un informe. Su procedencia explica la historia del artefacto: productores, actividades, agentes, copias y transformaciones. Su integridad ofrece razones para detectar cambios desde un punto de referencia, sin convertir bytes intactos en verdad. Su contexto fija el significado operativo: sistema, versión, tiempo, esquema, identidad, cobertura y condiciones.

La cadena de custodia registra control y transferencias; la procedencia describe además cómo se generó y transformó la información. Los hashes detectan diferencias cuando el referente está protegido; las firmas vinculan bytes con una clave y una política; ninguno demuestra por sí solo que la narración del registro sea completa. Un expediente revisable conserva fuente y derivados, registra operaciones, protege valores de referencia y declara límites.

En el caso de la descarga administrativa, esta disciplina permite afirmar que ciertos servicios aceptaron eventos concretos y que algunas relaciones técnicas son compatibles con una sesión. No permite atribuir automáticamente intención humana, compromiso o impacto máximo. Esa precisión no debilita la respuesta: hace que una revocación, una escalada de investigación o una comunicación ejecutiva puedan defenderse y revisarse.

Comprobación de comprensión

1. ¿Por qué un log con un hash válido no demuestra que el evento descrito sea verdadero?
2. Distingue procedencia, integridad y contexto usando una exportación de SIEM.
3. ¿Qué relación existe entre cadena de custodia y procedencia? ¿Por qué no son sinónimos?
4. ¿Qué puede detectar un hash y qué queda fuera de su alcance?
5. ¿Por qué un event_time normalizado no garantiza que dos eventos ocurrieran en el orden que muestra una tabla?
6. En el caso conductor, ¿qué afirmación queda debilitada si sólo se conserva user_id y no session_id?
7. ¿Qué diferencia hay entre el artefacto de referencia y un derivado de trabajo? Da un ejemplo de transformación que deba registrarse.
8. ¿Qué condiciones justificarían una firma digital o un MAC para proteger registros, y qué claim adicional no autorizarían?

Problema de transferencia

Un proveedor entrega un archivo alerts.csv con 40 alertas de acceso privilegiado y afirma: «El sistema detectó 40 intrusiones». El archivo tiene un hash SHA-256 calculado al enviarlo, pero no incluye zona temporal, versión del parser, identificador de sesión ni los eventos descartados. El proveedor conserva los logs fuente durante siete días y la cuenta de exportación tiene permisos de administrador.

Redacta un expediente mínimo para decidir si se revoca una credencial y si se escala la investigación. Debes separar al menos tres claims, identificar las fuentes y derivados, enumerar los controles de integridad y procedencia que pedirías, y señalar qué contexto falta. Explica qué conclusión provisional sí podrías comunicar y qué parte de «40 intrusiones» quedaría fuera de alcance. No conviertas la ausencia de esos campos en una acusación: describe cómo cambiaría la fuerza y el alcance de la evidencia.

Fuentes principales

• National Institute of Standards and Technology. SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, abril de 2025; especialmente PR.PS-04, DE.AE-03, RS.AN-06 y RS.AN-07.
• Barbara Guttman, Douglas R. White, Shannan Williams y Tracy Walraven. NISTIR 8387: Digital Evidence Preservation: Considerations for Evidence Handlers, septiembre de 2022; §§1.1, 3.2 y 9.
• Cybersecurity and Infrastructure Security Agency. Chain of Custody and Critical Infrastructure Systems, 2023.
• World Wide Web Consortium. PROV Model Primer, Recommendation family, 2013; §§2–3.
• R. Kelsey et al. RFC 5848: Signed Syslog Messages, mayo de 2010; §1.
• National Institute of Standards and Technology. Digital signature, CSRC Glossary, consultado el 3 de octubre de 2026.