Observación, inferencia, hipótesis y conclusión

Una señal no llega acompañada de su explicación

Un SIEM muestra un inicio de sesión exitoso desde otro país. Dos minutos después registra una descarga grande. La interfaz marca el conjunto como «impossible travel» y asigna severidad alta. Es tentador escribir: «un atacante comprometió la cuenta y exfiltró datos».

Sin embargo, la pantalla no observó un atacante, una persona ni necesariamente un viaje. Recibió eventos de productores concretos, transformó campos, consultó una base de geolocalización, correlacionó entidades y aplicó una regla. La conclusión puede resultar correcta, pero contiene varios pasos de inferencia que deben hacerse visibles.

El trabajo analítico consiste en pasar de trazas parciales a una explicación sin borrar las transformaciones ni las alternativas. El proceso de análisis y reporte descrito por NIST SP 800-86 y el vocabulario de traza de OSAC Technical Series 0002R1 ofrecen el anclaje documental; el capítulo los convierte en una cadena pedagógica, no en una garantía universal. Esto exige separar observación, inferencia, hipótesis y conclusión; preguntar qué otras causas producirían señales parecidas; y buscar evidencia capaz de distinguirlas.

Pregunta antes que datos

Una investigación comienza mejor con una pregunta que con una acumulación de logs. «¿La identidad fue utilizada por una parte no autorizada?» orienta qué hechos permitirían decidir. «Revisar todo lo sospechoso» no define criterio de cierre ni qué diferencia práctica se intenta resolver.

La pregunta determina:

• unidad de análisis: cuenta, sesión, dispositivo, proceso u operación;
• horizonte temporal;
• fuentes pertinentes;
• precisión necesaria;
• consecuencias de falsos positivos y falsos negativos;
• nivel de atribución requerido;
• decisión que seguirá a la respuesta.

No toda investigación necesita saber quién es una persona. Para revocar un token puede bastar concluir que una sesión no corresponde al patrón autorizado. Para una medida disciplinaria o atribución pública se requiere evidencia mucho más fuerte y procedimientos adicionales.

Fenómeno, traza y observación

Un fenómeno es lo que ocurre en el sistema o entorno. Deja trazas: estados o cambios que un productor puede representar. Una observación es el resultado disponible para el investigador mediante colección e instrumentos.

La diferencia importa porque ningún log es una ventana transparente al mundo. El productor decide cuándo emitir, qué campos incluir, cómo nombrarlos y qué omitir. Un evento login_success puede significar que una etapa aceptó credenciales, no que el usuario humano esperado actuó ni que toda la transacción posterior terminó.

Los datos llamados raw ya están construidos por firmware, sistema operativo, aplicación o sensor. «Raw» suele significar anterior a determinadas transformaciones del pipeline, no libre de selección. Esto no los hace inútiles; obliga a describir su semántica y procedencia.

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

Transformar no es observar de nuevo

Parsing, normalización, enriquecimiento, deduplicación, agregación y correlación producen datos derivados. Son esenciales para operar a escala, pero cambian la relación con la fuente.

Una dirección IP puede enriquecerse con país y ASN. El país no estaba en el paquete ni prueba ubicación física; es un resultado de una base, fecha y método. Un timestamp puede convertirse a UTC, pero si representa recepción en vez de ocurrencia no recupera el orden real. Dos nombres pueden resolverse a una identidad canónica y fusionar accidentalmente sujetos distintos.

El analista debería poder responder:

1. ¿qué fuente originó el campo?
2. ¿qué transformaciones recibió?
3. ¿qué versión de reglas o datos auxiliares se usó?
4. ¿qué valores se descartaron o imputaron?
5. ¿puede recuperarse el registro original?
6. ¿qué error conocido posee la transformación?

La repetición de un resultado por dos dashboards que consultan el mismo pipeline no constituye confirmación independiente. Pueden compartir productor, parser, enriquecimiento y defecto.

Inferir es proponer una relación

Una inferencia conecta observaciones con un estado que no se observó directamente. «La IP pertenece a una VPN» infiere uso a partir de ASN, reputación o inventario. «La misma sesión realizó la descarga» relaciona eventos mediante un identificador. «La cuenta está comprometida» propone una explicación sobre autorización.

Las inferencias no son errores que deban eliminarse; son el corazón del análisis. El rigor consiste en marcarlas, justificar el puente y conservar alternativas. Una redacción útil separa:

• observamos: campos y eventos bajo procedencia conocida;
• interpretamos: significado según documentación o prueba;
• inferimos: relación que mejor explica el conjunto;
• no podemos determinar: estados no discriminados por la evidencia.

Esta estructura evita que un informe mezcle niveles dentro de una sola oración. También permite que otro analista acepte los hechos y discuta la inferencia sin rehacer toda la colección.

Una hipótesis debe arriesgarse a perder

Una hipótesis es una explicación contrastable. Debe predecir qué otras observaciones esperaríamos si fuera cierta y qué resultado reduciría su apoyo. «Algo raro ocurrió» no arriesga nada; puede acomodar cualquier evidencia.

Para el caso conductor:

• H1 — compromiso: un tercero obtuvo una sesión y descargó datos;
• H2 — VPN legítima: el usuario operó mediante un egress geolocalizado fuera de su país;
• H3 — automatización: una identidad o token de servicio realizó la descarga;
• H4 — correlación defectuosa: los eventos pertenecen a sesiones distintas;
• H5 — tiempo incorrecto: ingestión o desfase creó proximidad artificial;
• H6 — geolocalización obsoleta: el país asignado no representa la ruta actual.

Cada hipótesis predice diferencias. H1 podría mostrar device ID nuevo, token reutilizado, objetos inusuales y ausencia de cambio aprobado. H2 debería concordar con ASN o infraestructura VPN y dispositivo habitual. H3 tendría client credentials, patrón de servicio y autorización asociada. H4 produciría session IDs distintos. H5 mostraría divergencia entre event time e ingest time.

Hipótesis rivales antes de buscar confirmación

La primera explicación plausible obtiene ventaja cognitiva: empezamos a seleccionar evidencia que la apoya y reinterpretar contradicciones. Generar rivales temprano reduce ese anclaje.

No es necesario inventar alternativas infinitas. Deben ser plausibles bajo arquitectura y contexto. Conviene cubrir al menos:

• conducta adversarial;
• actividad legítima poco común;
• error o automatización operacional;
• defecto de colección o transformación;
• identidad o correlación equivocada.

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

El registro de hipótesis puede incluir predicción, evidencia a favor, evidencia en contra, supuestos y estado. Una hipótesis no se «cierra» sólo porque otra gane apoyo: se documenta por qué quedó menos compatible o qué información falta.

Diseñar una prueba discriminante

Una prueba discriminante cambia nuestra evaluación de manera distinta según la hipótesis. Consultar otra base de geolocalización quizá no discrimine si ambas derivan de fuentes parecidas. Comparar session ID entre login y descarga separa H1/H2/H3 de H4. Verificar el tipo de credencial puede distinguir usuario de workload.

Antes de consultar, conviene escribir resultados esperados:

Desliza horizontalmente para consultar todas las columnas.

La tabla no automatiza el veredicto. Hace visible por qué se obtiene una fuente y qué resultado modificaría la explicación. También evita buscar datos sin criterio y reinterpretarlos después.

Observaciones negativas y cobertura

«No apareció un evento MFA» sólo informa ausencia en la consulta. Para convertirla en evidencia contra una hipótesis hay que demostrar que el evento habría debido generarse, que la fuente cubría esa cuenta y período, que llegó al pipeline, que el parser lo reconoce y que la consulta no lo filtró.

Las observaciones negativas pueden ser fuertes cuando existe un control positivo. Si una acción de prueba equivalente produce siempre el evento bajo la misma configuración, la ausencia en el caso gana significado. Aun así, deben considerarse retención, muestreo, latencia y condiciones distintas.

El capítulo 6 desarrollará resultados negativos e incertidumbre. La regla aquí es sencilla: antes de interpretar silencio, validar que el instrumento podía hablar.

Herramientas: resultados, errores y validación

Una herramienta puede extraer, decodificar, clasificar o puntuar. Su salida combina datos y reglas. SWGDE recomienda probar herramientas forenses para saber si funcionan como se espera y conocer limitaciones; reconoce que ninguna prueba garantiza rendimiento correcto en toda situación. SWGDE, Minimum Requirements for Testing Tools

Validar no significa comparar dos productos que incorporan la misma biblioteca y celebrar coincidencia. Puede incluir datasets con resultado conocido, parsing manual de muestras, comparación de versiones, casos límite y documentación de discrepancias.

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

Etiquetas como malicious, success, deleted o user deben traducirse a condiciones técnicas. ¿Qué firma produjo malicious? ¿deleted significa marcado, ausente del índice o recuperado de espacio libre? ¿user es cuenta, subject ID o nombre mostrado? La etiqueta es una salida, no la conclusión final.

Línea temporal sin inventar simultaneidad

Los sistemas registran distintos relojes: evento, dispositivo, servidor, recepción, ingestión y procesamiento. Pueden tener zonas, precisión, desfase y latencia diferentes. Ordenar todo por una sola columna produce una secuencia visual que quizá no represente causalidad.

Una línea temporal rigurosa conserva:

• fuente y semántica de cada timestamp;
• zona y conversión;
• precisión y resolución;
• desfase estimado;
• tiempo de recepción/ingestión por separado;
• intervalos cuando el orden no puede determinarse.

«A ocurrió dos minutos antes que B» sólo es defendible si los relojes y campos permiten esa precisión. A veces la conclusión correcta es «los eventos son compatibles con este orden, pero también con superposición o inversión dentro del margen».

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

Correlación no implica causalidad

La proximidad temporal o la coincidencia de identidad pueden sugerir relación. No demuestran que un evento cause otro. Un login y una descarga pueden compartir cuenta y seguir pertenecer a sesiones diferentes; una alerta puede aparecer después de un cambio sin que el cambio la haya causado.

Para sostener causalidad se busca mecanismo, orden compatible, dependencia, especificidad y alternativas. En sistemas distribuidos, además, eventos intermedios pueden no registrarse. La conclusión debe corresponder a la evidencia: «asociados por session ID» es más fuerte que «cercanos en tiempo» y diferente de «la autenticación permitió la descarga».

Atribución por niveles

Atribuir significa asignar una acción a una entidad. Los niveles no son intercambiables:

1. proceso: determinado PID o workload emitió una operación;
2. sesión/token: una credencial o contexto autorizado la respaldó;
3. cuenta: el sistema la registró bajo un principal;
4. dispositivo: evidencia liga el contexto a un endpoint;
5. persona: controles y contexto ligan la acción a un individuo;
6. organización: múltiples evidencias sostienen control o dirección;

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

El salto de cuenta a persona suele ser crítico. Las cuentas se comparten, delegan, automatizan o comprometen. Incluso biometría o dispositivo administrado aportan evidencia bajo errores y controles, no identidad metafísica. Para contener una sesión puede bastar atribución técnica; para responsabilizar públicamente a una organización, no.

Contradicciones son evidencia, no inconvenientes

Dos fuentes pueden discrepar porque observan etapas distintas, usan relojes diferentes o una falla. Ocultar la discrepancia para producir una historia limpia reduce calidad.

La investigación debe registrar:

• qué afirmaciones entran en conflicto;
• procedencia y confiabilidad de cada fuente;
• si podrían ser verdaderas simultáneamente;
• qué transformación introduce la diferencia;
• qué prueba resolvería o limitaría el desacuerdo;
• cómo afecta la conclusión si permanece abierto.

Una contradicción puede revelar el punto decisivo: un IdP registra éxito, pero la aplicación niega la sesión; el control autenticó y otra capa autorizó distinto. El conflicto enseña arquitectura.

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

Redactar conclusiones calibradas

Una conclusión debe responder la pregunta y declarar alcance. Puede adoptar formas como:

• demostrado: la evidencia reproduce directamente la propiedad bajo condiciones conocidas;
• fuertemente respaldado: varias fuentes independientes discriminan rivales relevantes;
• compatible: la evidencia no contradice la hipótesis, pero otras explicaciones permanecen;
• no determinado: faltan observaciones o el poder discriminante es insuficiente;
• refutado bajo estas condiciones: una predicción necesaria no se cumple con cobertura validada.

Estas etiquetas necesitan definición local; no existe una escala verbal universal. Lo importante es no usar «confirmado» cuando sólo se observó compatibilidad.

Una conclusión completa incluye:

1. afirmación principal;
2. observaciones que la sostienen;
3. puente inferencial;
4. hipótesis rivales consideradas;
5. limitaciones y contradicciones;
6. nivel de confianza o estado;
7. evidencia que podría cambiarla.

Cuándo dejar de investigar

Una investigación no termina porque se agotaron los datos ni porque una narrativa parezca satisfactoria. Debe existir un criterio de suficiencia vinculado a la decisión. Para contener una sesión, puede bastar demostrar uso no reconocido y riesgo actual. Para declarar causa raíz, quizá deban excluirse rutas alternativas. Para atribuir responsabilidad, la exigencia será mayor.

Continuar recolectando tiene costes: tiempo, exposición de datos, alteración de sistemas y retraso de respuesta. Detener demasiado pronto conserva alternativas relevantes. El criterio puede formularse antes:

• qué decisión debe tomarse;
• qué hipótesis cambiarían esa decisión;
• qué evidencia tendría poder para discriminarlas;
• qué nivel de error es tolerable;
• qué límites impiden obtener más información;
• qué seguimiento comprobará la conclusión.

Si las hipótesis restantes conducen a la misma acción reversible —por ejemplo, revocar un token— puede decidirse sin resolver atribución completa. Si conducen a acciones irreversibles o públicas, la diferencia sigue siendo material.

El cierre tampoco congela conocimiento. Una conclusión puede ser válida «con la evidencia disponible al tiempo T» y reabrirse ante nuevos logs, cambios de parsing o contradicciones. Registrar qué resultado la modificaría hace la investigación auditable y evita defenderla por inercia.

Explicación útil no significa explicación única

Una hipótesis gana apoyo cuando explica observaciones con menos supuestos adicionales, predice evidencia nueva y resiste pruebas que podían refutarla. Esto no demuestra que sea la única explicación lógicamente posible. En sistemas complejos siempre pueden imaginarse escenarios ad hoc capaces de acomodar los datos.

El estándar práctico no es eliminar toda posibilidad concebible, sino comparar alternativas relevantes bajo el modelo, la arquitectura y la decisión. Una hipótesis que necesita asumir simultáneamente fallo de reloj, corrupción del parser y suplantación de inventario puede ser menos respaldada que otra que explica el conjunto con un token robado; aun así, el informe debe distinguir «menos compatible» de «imposible».

También debe evitarse premiar automáticamente la historia más simple. La simplicidad sólo ayuda entre explicaciones que respetan la evidencia y mecanismos conocidos. Un sistema distribuido puede fallar de forma compleja. El valor está en hacer explícitos los supuestos y buscar predicciones que no fueron usadas para construir la explicación.

Caso conductor resuelto sin fingir certeza

Supongamos que el session ID coincide, el device ID es nuevo, la IP no pertenece a la VPN corporativa, el usuario niega actividad y los objetos descargados no forman parte de su función. El event time del IdP y la aplicación difiere menos de un segundo y ambos productores muestran salud.

H4, H5 y H6 pierden apoyo; H2 resulta menos compatible. H1 gana apoyo, pero aún no identifica persona ni organización. Podría concluirse: «La evidencia respalda fuertemente que una sesión asociada a la cuenta fue utilizada desde un dispositivo no habitual para descargar objetos no autorizados por el usuario; es compatible con compromiso de sesión. No determina quién obtuvo o utilizó el token».

La frase permite contener, investigar origen y comunicar límites. «Actor extranjero exfiltró datos» excedería la evidencia: país de IP no atribuye actor, y descarga no prueba por sí sola que datos salieran del control del servicio ni fueran recibidos por un tercero.

Errores recurrentes

«La alerta dice malware». Una clasificación necesita regla, datos, versión y validación.

«Dos herramientas coinciden». Puede existir dependencia común; hay que evaluar independencia.

«La IP es de ese país». Geolocalización de red no equivale a ubicación ni nacionalidad del operador.

«Ocurrió después, por tanto fue causado por». Orden temporal es necesario en muchas causalidades, pero no suficiente.

«No hay logs, así que no pasó». Primero se demuestra cobertura y expectativa de registro.

«La cuenta lo hizo». El sistema atribuye al principal; la persona requiere evidencia adicional.

«La hipótesis explica todo». Una explicación que se adapta a cualquier resultado no es contrastable.

Síntesis operativa: un expediente que pueda cambiar

El modelo completo no es una lista de conceptos sino una secuencia de revisión. Primero se formula la decisión y el claim; después se identifica qué fenómeno podría producir la señal y qué productores lo representan. La colección conserva fuente, alcance y errores. Las transformaciones quedan separadas de la observación; la inferencia declara su puente; las hipótesis rivales hacen predicciones; las pruebas se diseñan antes de consultar; y la conclusión nombra tanto el apoyo como el límite. Esta secuencia evita tratar la interfaz como si fuese el sistema observado.

En un expediente práctico, cada afirmación tiene cinco campos: claim, fuente, operación, estado y condición de cambio. Por ejemplo: «El IdP registró aceptación del token en T» puede tener una fuente y semántica relativamente precisas. «La descarga pertenece a esa sesión» requiere un binding adicional. «Una persona exfiltró datos» requiere todavía atribución, autorización y evidencia de salida. Es válido actuar sobre el primer claim y dejar el tercero no determinado; una decisión operativa no transforma una hipótesis en hecho.

El proceso forense de NIST SP 800-86 debe conservarse en sus cuatro fases: Collection, Examination, Analysis y Reporting (SP 800-86, ES-1 y §3). La identificación de fuentes puede ocurrir dentro de Collection, pero no se presenta como quinta fase del estándar. En el análisis, las explicaciones plausibles reciben consideración explícita y el reporte debe mostrar limitaciones (SP 800-86, §3.4). OSAC Technical Series 0002R1 distingue traza, procesos forenses y tipos de razonamiento; ese vocabulario ayuda a no llamar «observación» a una inferencia (OSAC TS 0002R1, §§2, 5.1–5.2).

Procedimiento de contraste

Antes de extraer, se escribe qué resultado cambiaría la decisión. Para la señal login/descarga, el expediente puede pedir session_id, vínculo de dispositivo, autorización de job, event time e ingest time. Si el identificador difiere, se debilita la continuidad; si coincide pero la cuenta es compartida, no se completa la atribución humana. Si la consulta no discrimina rivales, el resultado es inconcluso, no un permiso para aumentar el lenguaje.

La prueba debe indicar cobertura: productores, período, retención, parser, filtros, versión de reglas y controles positivo/negativo. La prueba de una herramienta es local a sus datos y configuración. SWGDE exige conocer funcionamiento y limitaciones de las herramientas forenses, no asumir que una prueba en un caso garantiza todos los casos (SWGDE 18-Q-001 v2.1, §§1–4). Dos paneles que consultan el mismo índice no son fuentes independientes aunque tengan nombres distintos.

La ausencia necesita el mismo contrato. SP 800-92 describe pérdidas, retención y problemas de timestamps dentro de la infraestructura y operación de log management (SP 800-92, §§2.3.1, 3, 5). La pregunta no es «¿hay una fila?», sino «¿la acción habría generado una fila en esta fuente, con esta configuración, durante este período, y habría sobrevivido al pipeline?». Sin respuesta, el estado es no determinado. UTC facilita comparación textual, pero no repara que una columna sea hora de recepción; un intervalo puede ser más honesto que una precisión ficticia.

Caso de transferencia: EDR

En un endpoint, un EDR etiqueta credential_dumping a un proceso firmado que leyó memoria de un servicio de autenticación. El cambio corresponde a una herramienta de soporte recién desplegada, pero no hay ticket. Las hipótesis son: herramienta legítima; paquete sustituido o módulo no autorizado; despliegue automatizado aprobado; clasificación errónea; o cuenta comprometida que ejecutó el proceso. Las observaciones son hash, cadena de proceso, publisher, ruta, parámetros, versión de regla, memoria leída y marcas temporales. La etiqueta es una salida bajo contrato, no la intención.

Una prueba previa compara hash y cadena con el paquete aprobado, reproduce una operación no sensible en un entorno de prueba y revisa si la regla etiqueta también el control negativo. Si el hash coincide, se apoya identidad del paquete en ese momento; si la firma fue revocada posteriormente, cambia el estado actual de confianza, no retroactivamente lo que el proceso era. La conclusión inicial puede ser «se observó lectura de memoria clasificada por la regla; la causa y autorización no están determinadas». Es proporcionado contener o preservar mientras se investiga, pero no llamar maliciosa la operación sólo por la etiqueta o la revocación posterior.

Atribución y cierre

La escalera de proceso, sesión, cuenta, dispositivo, persona y organización es un modelo local de preguntas, no una norma. Una cuenta puede ser compartida, delegada, automatizada o comprometida. Una IP puede ser NAT, VPN o egress de servicio. La geolocalización describe una resolución de base con una fecha y método, no ubicación física ni nacionalidad; Poese et al. documentan la falta de fiabilidad de bases de geolocalización (DOI correcto 10.1145/1971162.1971171, artículo ACM). SP 800-63-4 separa subject, subscriber y claimant; una cuenta no equivale automáticamente a una persona (§2).

El cierre se relaciona con la decisión. Para revocar una sesión puede bastar un uso no reconocido bajo cobertura suficiente; para atribuir persona u organización se necesita otra evidencia y un procedimiento distinto. El reporte debe conservar contradicciones, hipótesis que permanecen abiertas, condiciones de revisión y efectos de cualquier contención. Una frase calibrada tiene esta forma: «Dentro de [alcance], [fuente] respalda [observación]; [relación] es compatible con [hipótesis], pero no permite afirmar [límite]. Se toma [acción] y se revisará cuando [condición]». El propósito no es parecer indeciso: es permitir que la decisión sobreviva a nueva evidencia.

La trazabilidad no sustituye el juicio profesional; lo vuelve inspeccionable y corregible.

Registro de incertidumbre y control del lenguaje

El expediente debe dejar claro cuándo una conclusión cambia de estado. «Respaldado» no significa universal: significa que, dentro del alcance, las observaciones y las pruebas discriminan suficientemente las alternativas relevantes para la decisión. «Compatible» significa que una hipótesis no contradice lo observado, aunque rivales siguen vivos. «No determinado» se usa cuando la cobertura, la semántica o el poder de la prueba no permiten ordenar alternativas. «Refutado bajo estas condiciones» sólo se escribe cuando una predicción necesaria falla en una ruta validada. Estas etiquetas son vocabulario local del capítulo, no una escala normativa de toda la profesión.

Un registro mínimo de actualización contiene la versión de cada fuente, el momento de la decisión, los supuestos que se adoptaron y la observación que podría debilitarla. Si después aparece que el parser descartó eventos, se reduce el alcance de la conclusión sin reescribir los hechos originales. Si un job aprobado explica la descarga, se actualiza el apoyo de la hipótesis legítima; no se borra que el token fue usado desde una ruta inusual. La historia de revisión importa porque el análisis es una actividad temporal: una decisión razonable en T1 puede quedar limitada en T2 sin que haya sido negligente en T1.

También debe distinguirse el peso de una evidencia de su sensibilidad. Una fuente muy específica puede observar sólo una fracción del sistema; una fuente amplia puede mezclar eventos y ser menos precisa. Un segundo registro producido por el mismo colector aumenta la redundancia, no necesariamente la independencia. Antes de sumar fuentes, se dibuja su dependencia: productor, canal, parser, enrichment y almacenamiento. Si comparten un punto de fallo, una sola causa puede explicar la concordancia. Esta práctica evita presentar volumen de datos como fuerza inferencial.

La decisión debe ser proporcional a reversibilidad y daño. Revocar una sesión o preservar un host puede ser reversible y proteger una ventana de investigación; publicar el nombre de una persona u organización es una acción con efectos duraderos y exige una escalera de atribución más alta. Si las hipótesis rivales conducen a la misma contención técnica, puede actuarse sin resolver intención. Si conducen a disciplinar, acusar o destruir evidencia, la incertidumbre restante es material y la investigación no debe ocultarla.

Qué debe quedar en el reporte

El reporte no necesita reproducir cada consulta, pero sí debe permitir reconstruir las decisiones que importan. Debe nombrar la pregunta y el alcance, separar fuentes primarias de derivados, indicar qué transformaciones se aplicaron, documentar las pruebas que se planearon antes de mirar el resultado y anotar las contradicciones que permanecen. También debe decir qué no se intentó determinar. «No se evaluó atribución de persona» es más informativo que omitirla y dejar que el lector interprete una cuenta como identidad.

Cuando una fuente falla, se registra el fallo junto con su consecuencia. Un colector caído durante una ventana no invalida todos los registros anteriores; limita la lectura del silencio en esa ventana. Un parser que cambió de versión no vuelve falsos los eventos fuente; obliga a recalcular sus derivados. Una firma posterior o una etiqueta EDR pueden apoyar identidad de bytes o clasificación bajo un alcance, pero no reemplazan la explicación del mecanismo. Esta granularidad mantiene el expediente útil para respuesta inmediata y para una revisión posterior.

La estructura del reporte debe conservar dos líneas separadas: la epistémica (“qué se puede sostener”) y la operacional (“qué conviene hacer ahora”). Una revocación puede ser prudente ante evidencia compatible con compromiso aunque el compromiso no esté demostrado; la acción se justifica por exposición y reversibilidad, no por inflar la conclusión. Al leer el reporte, otra persona debe poder aceptar la acción y, al mismo tiempo, cuestionar la hipótesis sin que ambas conversaciones se confundan.

Cierre

Una señal nunca llega acompañada de su explicación. El análisis profesional reconstruye cómo pasó de fenómeno a traza, colección, transformación, observación, inferencia, hipótesis rival, prueba y conclusión. Cada transición tiene una pérdida o supuesto que debe ser visible. Herramientas, timestamps, cuentas e indicadores aportan información, pero ninguno autoriza por sí solo una historia completa.

Comprobación de comprensión

1. ¿Qué diferencia existe entre fenómeno, traza y observación?
2. ¿Por qué un dato raw sigue siendo una representación construida?
3. Identifica tres inferencias ocultas en una alerta de impossible travel.
4. ¿Qué hace contrastable a una hipótesis?
5. ¿Por qué dos herramientas pueden no ser confirmación independiente?
6. ¿Qué necesitas antes de interpretar ausencia de un evento?
7. Distingue atribución a cuenta, dispositivo y persona.
8. ¿Cómo debería comunicarse una contradicción no resuelta?

Problema de transferencia

Un EDR etiqueta como «credential dumping» un proceso firmado que leyó memoria de un servicio de autenticación. El proceso pertenece a una herramienta de soporte recién desplegada, pero el cambio no aparece en el sistema de tickets. Construye al menos cuatro hipótesis rivales. Separa campos observados de interpretaciones del EDR, diseña pruebas discriminantes y redacta dos conclusiones: una con la evidencia inicial y otra si el hash coincide con el paquete aprobado pero la firma fue revocada después.

Referencias