Aplicaciones sin soporte: el cuello de botella silencioso de los laboratorios forenses

Las métricas de un laboratorio miden el rendimiento: precintos tratados, días por examen, tamaño de la acumulación pendiente. Lo que no pueden medir es la prueba que estaba presente, que nunca se leyó y que, por tanto, nunca llegó a ser un hallazgo.

Esa cifra no existe en ninguna parte. No puede existir, porque registrarla exigiría saber qué había en la parte que nadie abrió. Pero no es pequeña, y su causa más importante son las aplicaciones que una herramienta no decodificó.

Cuatro maneras de que una aplicación acabe siendo ilegible

Es regional. Una aplicación de mensajería o una red social con unos cientos de miles de usuarios en un solo país no es una prioridad para un proveedor que vende en cuarenta mercados. Puede ser muy relevante si ese país es donde está su investigación.

Es nueva. La distancia entre que una aplicación se vuelve popular y que aparezca en las notas de versión de una herramienta forense se mide en trimestres. La adopción delictiva de un nuevo canal de comunicación se mide en semanas, y suele ser más rápida que la adopción legítima, porque el incentivo para cambiar es mayor.

Cambió. Es la categoría más numerosa y la menos comentada. Una aplicación con soporte publica una actualización que reorganiza su almacenamiento, y el analizador escrito para la versión anterior devuelve resultados parciales o ninguno. La herramienta sigue indicando la aplicación como con soporte. El analista tiene que notar que el resultado es más escaso de lo que debería, y para eso hace falta saber de antemano, más o menos, qué esperar.

Nunca fue prioridad de nadie. Aplicaciones de actividad física, aplicaciones de notas, historial de transporte con conductor, aplicaciones de reparto, monederos de pago, notas de voz. Rara vez son centrales, a veces son decisivas y, individualmente, nunca justifican un trimestre de trabajo de un ingeniero.

Por qué sigue siendo invisible

Tres cosas hacen que esto no aparezca como un problema del que alguien se haga responsable.

La primera es que el informe es exacto. Un analista que escribe que ciertos datos de una aplicación no fueron analizados ha documentado correctamente la limitación. Nada en una revisión de calidad lo señalará.

La segunda es que la regla informal de alcance es sensata. Examinar lo que la herramienta decodificó, examinar lo que el investigador pidió expresamente y anotar el resto. Con una carga de casos real, esa es la decisión profesionalmente correcta, y produce la misma reducción del alcance cada vez.

La tercera es que nadie sabe qué se pasó por alto. Un investigador que nunca se entera de que existía una conversación no puede preguntar por qué no figuraba en el informe. La ausencia es estructuralmente imposible de observar.

Qué hacen en realidad los analistas al respecto

Los buenos hacen algo, y eso no escala.

Algunos abren la base de datos a mano, deducen el esquema y escriben una consulta. Otros mantienen una colección personal de scripts. Algunos conocen a un colega de otro servicio que ya se ha topado con esa aplicación y le escriben un correo. En algunos laboratorios hay una persona, normalmente una sola, que tiene fama de estar dispuesta a hacerlo, y su cola de trabajo es el verdadero cuello de botella.

Todas estas formas de proceder tienen los mismos dos problemas. Cuestan horas que el caso no puede permitirse, y la comprensión que producen no es duradera. Vive en la cabeza de una persona o en un archivo de trabajo provisional, y cuando esa persona se marcha, se va con ella. El siguiente analista, en el siguiente servicio, se topa con la misma aplicación dentro de seis meses y empieza de nuevo.

La forma de una solución

Si la restricción es que alguien tiene que entender un formato de almacenamiento desconocido antes de poder leer su contenido, solo hay dos salidas. Hacer que esa comprensión sea más barata de producir, o hacerla duradera una vez producida.

Las dos están al alcance, y se refuerzan entre sí.

Producirla a bajo coste es hoy un problema abordable. Deducir para qué sirve una base de datos desconocida, a partir de su ruta de archivo, de los nombres de sus tablas y columnas y de una muestra de su contenido, es una tarea de razonamiento y no de reconocimiento de patrones, y es el tipo de tarea que los modelos actuales resuelven excepcionalmente bien. El resultado es un mapeo: una descripción de cómo leer esta fuente en los campos que espera una vista.

Ese resultado no puede fiarse sin más, y no tiene por qué ser así. Valídelo estructuralmente, ejecútelo sobre una muestra de los datos reales y muestre al analista una vista previa de registros reales. Un mapeo que ha malinterpretado la fuente produce una vista previa llena de disparates, y eso se ve en segundos. El analista lo acepta, lo corrige en un editor visual o lo descarta.

Hacerla duradera es la mitad más fácil y la más valiosa. Un mapeo validado es un pequeño artefacto que no contiene pruebas, solo la descripción de cómo leer una estructura. Puede compartirse. Cuando otro laboratorio abre un precinto que contiene la misma aplicación, se aplica automáticamente.

Ahí es donde cambia la economía. Hoy, el esfuerzo de entender una aplicación se repite en cada servicio que se la encuentra, y se pierde cada vez. Compartido, se paga una sola vez.

La afirmación que conviene manejar con cuidado

Hay una versión de este argumento que va demasiado lejos, y conviene marcar la línea.

El mapeo automático no significa que un analista no tenga nunca que mirar nada. Significa que la primera comprensión la produce el software y que el papel del analista pasa a ser de revisión y no de construcción. Algunos mapeos serán incorrectos. Algunas fuentes son realmente ambiguas, y ningún razonamiento sobre un esquema resolverá qué significa una columna cuyo nombre es f4 y cuyo contenido son enteros.

Lo que cambia no es el estándar. Es quién hace la primera pasada y cuánto tiempo espera un laboratorio por ella. En lugar de un trimestre, lleva minutos, y el resultado es algo que el servicio conserva.