Täckning bör inte bero på en leverantörs versionscykel

Det finns ett ögonblick i en digital forensisk undersökning som ingen skriver in i rutinen. En analytiker öppnar en extraktion, hittar en applikation som de inte känner igen och kontrollerar om deras verktyg stöder den. Det gör det inte. Data ligger där, helt närvarande, i en databas vars filnamn de kan se. Och svaret på om den kan läsas är: inte det här kvartalet.

Det ögonblicket behandlas vanligen som en supportfråga. Någon skapar ett ärende. Kanske lägger leverantören det i en kö, kanske kommer en version om sex månader, kanske är applikationen regionalt populär nog att vara värd en ingenjörs tid och kanske är den det inte. Under tiden har ärendet en förvarsfrist.

Det här är inte en supportfråga. Det är en strukturell egenskap hos hur branschen beslutade att arbeta, och när man ser det så visar sig en stor del av den dagliga frustrationen i ett laboratorium ha en orsak.

Beslutet fattas någon annanstans

Varje etablerat verktyg för forensisk analys fungerar på samma sätt. Någon hos leverantören bakåtkonstruerar en applikations lagringsformat, skriver en parser för det, testar den och skickar den i en version. Analytikern tar emot resultatet av det arbetet som en förmåga.

Det är genuint svårt ingenjörsarbete och de människor som gör det är bra på det. Problemet är inte kompetens. Problemet är att det lägger det mest avgörande beslutet i en undersökning, vilka data som alls kan läsas, i händerna på någon som inte vet att ärendet finns.

Den personen gör en rimlig kommersiell bedömning. De ser på hur många kunder som kommer att möta den här applikationen, hur stabilt dess format är, hur mycket ingenjörsarbete det kommer att ta. En meddelandeapplikation med tvåhundra miljoner användare är uppenbart värd arbetet. En regional social plattform med fyrahundratusen användare, koncentrerad till just den region där er organiserade brottslighetsgrupp verkar, är ett mycket svårare affärsfall. Från leverantörens position är det riktigt att avstå från att implementera den. Från er position, med extraktionen i handen, är det hela ärendet.

Versioner är den större halvan av problemet

Berättelsen om applikationen utan stöd är den som berättas, men den underskattar frågan. Det vanligare felet är subtilare: en applikation med stöd vars lagringslayout ändrades.

En applikation uppdateras. Den omorganiserar en tabell, flyttar en fil, ändrar hur den kodar en tidsstämpel. Parsern skrevs mot den föregående versionen och ger nu ingenting, eller värre, något plausibelt och fel. Verktyget rapporterar applikationen som stödd, eftersom den är det, och analytikern måste märka att resultatet är tunt.

Applikationers versionscykler mäts i veckor. Forensiska verktygs versionscykler mäts i månader. Det gapet sluter sig aldrig, och det är ingens fel. Det är aritmetik.

Vad det kostar, i de termer som betyder något

Kostnaden visar sig vanligen inte som en misslyckad undersökning. Den visar sig som minskat omfång, tyst.

En analytiker med tre veckor och fyrtio sigill ägnar inte två dagar åt att manuellt läsa en obekant SQLite-databas med en hexredigerare öppen bredvid, även om de kunde. De undersöker det som verktyget avkodade, skriver rapporten om det och antecknar resten som inte analyserat. Det är ett försvarbart yrkesbeslut. Det är också så bevis som finns, på en enhet som tjänsten redan har, i ett ärende som redan är öppet, till slut aldrig blir tittade på.

Multiplicera med en ärendebelastning och ni får den siffra som laboratoriechefer faktiskt oroar sig för: andelen beslagtagna data som aldrig undersöks. Det är inte ett misslyckande i triage. Det är ett misslyckande i täckning som har omklassats till triage.

Alternativet är obekvämt men enkelt

Om flaskhalsen är att parsers skrivs av en leverantör, i förväg, för applikationer som de valde, är åtgärden att sluta kräva att en människa hos en leverantör skriver dem i förväg.

Det är nu tekniskt genomförbart på ett sätt som det inte var för fem år sedan. Att känna igen vad en obekant databas är till för, vad dess tabeller innehåller och hur de mappas mot de begrepp som en utredare arbetar med, konversationer, kontakter, platser, är en resonemangsuppgift över filsökvägar, schema och innehåll tillsammans. Det är precis den sortens uppgift som generativa modeller är ovanligt bra på och klassificerare inte är.

Den uppenbara invändningen är den rätta. Ni kan inte låta en modell avgöra hur bevis tolkas och helt enkelt lita på resultatet. Så gör inte det. Generera mappningen, validera den strukturellt, kör den mot ett urval av de verkliga data och visa analytikern en förhandsgranskning av faktiska poster innan något tillämpas. Om mappningen har missförstått källan syns det omedelbart, eftersom förhandsgranskningen är full av nonsens. Analytikern godkänner den, rättar den i en visuell redigerare eller kastar den.

Vad som ändras är inte beviskravet. Analytikern verifierar fortfarande, och ingenting går in i en rapport utan att ha kontrollerats. Vad som ändras är vem som måste göra arbetet med den första förståelsen, och när det kan ske. Det kan ske den dag ärendet behöver det snarare än i det kvartal en leverantör planerade det.

Varför det här är värt att säga högt

Varje laboratorium vi har talat med har en version av samma berättelse, och var och en av dem berättar den som om den vore en lokal irritation. Den är inte lokal. Det är samma begränsning i varje tjänst i varje land, och den finns på grund av ett arkitekturval som hela branschen gjorde tidigt och aldrig tog upp igen.

Att benämna den ändrar vad ni ber om. En tjänst som tror att den har ett supportproblem ber sin leverantör om snabbare versioner, vilket är en begäran som ingen kan bevilja. En tjänst som ser ett strukturellt problem ställer en annan fråga: vad skulle krävas för att täckning ska sluta vara något vi väntar på.

Det är den fråga som VERA byggdes för att besvara, och det är skälet till att vi hellre argumenterar för tesen än beskriver produkten.