La cobertura no debería depender del ciclo de publicación de un proveedor

Hay un momento en un examen forense digital que nadie escribe en el manual de procedimiento. Un analista abre una extracción, encuentra una aplicación que no reconoce y comprueba si su herramienta la soporta. No la soporta. Los datos están ahí, completos, en una base de datos cuyo nombre de archivo puede ver. Y la respuesta a la pregunta de si se pueden leer es: no este trimestre.

Ese momento suele tratarse como una incidencia de soporte. Alguien abre un ticket. Quizá el proveedor lo incluye en su lista de pendientes, quizá una versión llega dentro de seis meses, quizá la aplicación es lo bastante popular en la región como para merecer el tiempo de un ingeniero y quizá no lo es. Mientras tanto, el caso corre contra los plazos de custodia.

No es un problema de soporte. Es una propiedad estructural de la forma en que el sector decidió trabajar, y, una vez que se ve así, buena parte de la frustración diaria de un laboratorio resulta tener una sola causa.

La decisión se toma en otra parte

Todas las herramientas de análisis forense habituales funcionan igual. Alguien del proveedor aplica ingeniería inversa al formato de almacenamiento de una aplicación, escribe un analizador para él, lo prueba y lo publica en una versión. El analista recibe el resultado de ese trabajo como una capacidad.

Es una ingeniería genuinamente difícil, y quienes la hacen son buenos en ella. El problema no es la competencia. El problema es que pone la decisión más trascendente de un examen, qué datos pueden leerse en absoluto, en manos de alguien que no sabe que existe el caso.

Esa persona toma una decisión comercial razonable. Mira cuántos clientes se encontrarán con esta aplicación, lo estable que es su formato y cuánta ingeniería exigirá. Una aplicación de mensajería con doscientos millones de usuarios vale el trabajo, obviamente. Una plataforma social regional con cuatrocientos mil usuarios, concentrada precisamente en la región donde opera su grupo de delincuencia organizada, es un caso de negocio mucho más difícil. Desde la posición del proveedor, no implementarla es correcto. Desde la suya, con la extracción en su poder, es todo el caso.

Las versiones son la mitad mayor del problema

La historia de la aplicación sin soporte es la que se cuenta, pero minimiza el problema. El fallo más habitual es más sutil: una aplicación con soporte cuya estructura de almacenamiento cambió.

Una aplicación se actualiza. Reorganiza una tabla, mueve un archivo, cambia la forma de codificar una marca de tiempo. El analizador se escribió para la versión anterior y ahora no devuelve nada o, peor aún, devuelve algo verosímil pero erróneo. La herramienta indica la aplicación como con soporte, porque lo tiene, y el analista tiene que notar que el resultado es escaso.

Los ciclos de publicación de las aplicaciones se miden en semanas. Los de las herramientas forenses, en meses. Esa distancia nunca se cierra, y no es culpa de nadie. Es aritmética.

Lo que cuesta, en los términos que importan

El coste no suele aparecer como un examen fallido. Aparece como una reducción del alcance, sin hacer ruido.

Un analista con tres semanas y cuarenta precintos no dedica dos días a leer a mano una base de datos SQLite desconocida con un editor hexadecimal abierto a su lado, aunque podría. Examina lo que la herramienta decodificó, redacta el informe con eso y anota el resto como no analizado. Es una decisión profesional defendible. También es la forma en que una prueba que existe, en un dispositivo que el servicio ya tiene, en un caso que ya está abierto, acaba sin que nadie la mire nunca.

Multiplique eso por la carga de casos y obtendrá la cifra que realmente preocupa a los directores de laboratorio: la proporción de datos incautados que nunca se examina. No es un fallo de triaje. Es un fallo de cobertura que se ha reclasificado como triaje.

La alternativa es incómoda, pero sencilla

Si el cuello de botella es que los analizadores los escribe un proveedor, de antemano, para las aplicaciones que él elige, la solución es dejar de exigir que una persona del proveedor los escriba de antemano.

Hoy eso es técnicamente viable de una forma que hace cinco años no lo era. Reconocer para qué sirve una base de datos desconocida, qué contienen sus tablas y cómo se corresponden con los conceptos con los que trabaja un investigador (conversaciones, contactos, ubicaciones) es una tarea de razonamiento que combina rutas de archivo, esquema y contenido. Es exactamente el tipo de tarea en la que los modelos generativos son excepcionalmente buenos y los clasificadores no.

La objeción evidente es la correcta. No se puede dejar que un modelo decida cómo se interpreta una prueba y limitarse a confiar en el resultado. Así que no lo haga. Genere el mapeo, valídelo estructuralmente, ejecútelo sobre una muestra de los datos reales y muestre al analista una vista previa de registros reales antes de aplicar nada. Si el mapeo ha malinterpretado la fuente, eso se ve de inmediato, porque la vista previa está llena de disparates. El analista lo acepta, lo corrige en un editor visual o lo descarta.

Lo que cambia no es el estándar de prueba. El analista sigue verificando, y nada entra en un informe sin comprobar. Lo que cambia es quién tiene que hacer el trabajo de la primera comprensión, y cuándo puede hacerse. Puede hacerse el día en que el caso lo necesita, y no en el trimestre que un proveedor programó.

Por qué conviene decirlo en voz alta

Cada laboratorio con el que hemos hablado tiene una versión de la misma historia, y todos la cuentan como si fuera una molestia local. No es local. Es la misma restricción en cada servicio y en cada país, y existe por una decisión de arquitectura que toda la industria tomó pronto y nunca revisó.

Nombrarlo cambia lo que se pide. Un servicio que cree tener un problema de soporte pide a su proveedor versiones más rápidas, algo que nadie puede conceder. Un servicio que reconoce un problema estructural se hace otra pregunta: qué haría falta para que la cobertura deje de ser algo que hay que esperar.

Esa es la pregunta para la que se construyó VERA, y es la razón por la que preferimos defender la tesis antes que describir el producto.