Dækning bør ikke afhænge af en leverandørs udgivelsescyklus

Der er et øjeblik i en digital forensisk undersøgelse, som ingen skriver ind i proceduremanualen. En analytiker åbner et udtræk, finder en applikation, vedkommende ikke genkender, og kontrollerer, om værktøjet understøtter den. Det gør det ikke. Dataene ligger der, fuldt til stede, i en database, vedkommende kan se filnavnet på. Og svaret på, om de kan læses, er: ikke dette kvartal.

Det øjeblik behandles som regel som et supportspørgsmål. Nogen opretter en supportsag. Måske føjer leverandøren den til et efterslæb, måske kommer en version om seks måneder, måske er applikationen regionalt populær nok til at være en ingeniørs tid værd, og måske er den det ikke. Imens løber der en varetægtsfrist på sagen.

Dette er ikke et supportspørgsmål. Det er en strukturel egenskab ved, hvordan branchen besluttede at arbejde, og når De først ser det sådan, viser en stor del af den daglige frustration i et laboratorium sig at have én årsag.

Beslutningen træffes et andet sted

Ethvert gængst kriminalteknisk analyseværktøj arbejder på samme måde. Nogen hos leverandøren reverse-engineer’er en applikations lagringsformat, skriver en parser til det, tester den og leverer den i en udgivelse. Analytikeren modtager resultatet af det arbejde som en evne.

Det er reelt vanskeligt ingeniørarbejde, og de mennesker, der gør det, er gode til det. Problemet er ikke kompetence. Problemet er, at det lægger den mest konsekvensrige beslutning i en undersøgelse, hvilke data der overhovedet kan læses, i hænderne på nogen, der ikke ved, at sagen findes.

Den person træffer en rimelig kommerciel vurdering. Vedkommende ser på, hvor mange kunder der vil møde denne applikation, hvor stabilt dens format er, hvor meget ingeniørarbejde det vil tage. En beskedapplikation med to hundrede millioner brugere er åbenlyst arbejdet værd. Et regionalt socialt netværk med fire hundrede tusind brugere, koncentreret i netop den region, hvor Deres organiserede kriminelle gruppe opererer, er et meget sværere forretningsgrundlag. Fra leverandørens position er det korrekt at afstå fra at implementere det. Fra Deres position, med udtrækket, er det hele sagen.

Versioner er den større halvdel af problemet

Historien om applikationen uden understøttelse er den, der bliver fortalt, men den underdriver problemet. Den mere almindelige fejl er mere subtil: en understøttet applikation, hvis lagringsopbygning ændrede sig.

En applikation opdateres. Den omorganiserer en tabel, flytter en fil, ændrer måden, den koder et tidsstempel på. Parseren blev skrevet mod den foregående version og returnerer nu ingenting eller, værre, returnerer noget plausibelt og forkert. Værktøjet angiver applikationen som understøttet, fordi den er det, og analytikeren skal opdage, at outputtet er tyndt.

Applikationers udgivelsescyklusser måles i uger. Kriminaltekniske værktøjers udgivelsescyklusser måles i måneder. Det gab lukker sig aldrig, og det er ikke nogens skyld. Det er aritmetik.

Hvad det koster, i de termer der betyder noget

Omkostningen viser sig som regel ikke som en mislykket undersøgelse. Den viser sig som omfangsreduktion, stille.

En analytiker med tre uger og fyrre forseglinger bruger ikke to dage på manuelt at læse en ukendt SQLite-database med en hex-editor åben ved siden af, selv om vedkommende kunne. Vedkommende undersøger det, værktøjet afkodede, skriver rapporten om det og noterer resten som ikke analyseret. Det er en forsvarlig faglig beslutning. Det er også sådan, bevismateriale, der findes, på en enhed tjenesten allerede har, i en sag der allerede er åben, ender med aldrig at blive set på.

Gang med en sagsmængde, og De får det tal, laboratorieledere faktisk bekymrer sig om: andelen af beslaglagte data, der aldrig undersøges. Det er ikke en triagefejl. Det er en dækningsfejl, der er blevet omklassificeret som triage.

Alternativet er ubehageligt, men enkelt

Hvis flaskehalsen er, at parsere skrives af en leverandør, på forhånd, til applikationer, de valgte, så er afhjælpningen at holde op med at kræve, at et menneske hos en leverandør skriver dem på forhånd.

Det er nu teknisk muligt på en måde, det ikke var for fem år siden. At genkende, hvad en ukendt database er til, hvad dens tabeller indeholder, og hvordan de lægges over på de begreber, en efterforsker arbejder med, samtaler, kontakter, positioner, er en ræsonnementsopgave over filstier, skema og indhold sammen. Det er netop den slags opgave, generative modeller er usædvanligt gode til, og klassifikatorer ikke er.

Den indlysende indvending er den rigtige. De kan ikke lade en model afgøre, hvordan bevismateriale fortolkes, og blot stole på resultatet. Så lad være. Generér mappingen, validér den strukturelt, udfør den mod en prøve af de virkelige data, og vis analytikeren en forhåndsvisning af de faktiske poster, før noget anvendes. Hvis mappingen har misforstået kilden, er det synligt med det samme, fordi forhåndsvisningen er fuld af nonsens. Analytikeren accepterer den, retter den i en visuel editor eller smider den væk.

Det, der ændrer sig, er ikke beviskravet. Analytikeren verificerer stadig, og intet indgår uverificeret i en rapport. Det, der ændrer sig, er, hvem der skal gøre arbejdet med den første forståelse, og hvornår det kan ske. Det kan ske den dag, sagen har brug for det, frem for i det kvartal, en leverandør planlagde det.

Hvorfor dette er værd at sige højt

Hvert laboratorium, vi har talt med, har en udgave af den samme historie, og hvert af dem fortæller den, som om den var en lokal irritation. Det er den ikke. Det er den samme begrænsning i hver tjeneste i hvert land, og den findes på grund af et arkitekturvalg, hele branchen traf tidligt og aldrig tog op igen.

At nævne den ændrer det, De beder om. En tjeneste, der mener, den har et supportproblem, beder sin leverandør om hurtigere udgivelser, hvilket er en anmodning, ingen kan imødekomme. En tjeneste, der genkender et strukturelt problem, stiller et andet spørgsmål: hvad skulle der til, for at dækning holdt op med at være noget, vi venter på.

Det er det spørgsmål, VERA blev bygget til at besvare, og det er grunden til, at vi hellere vil argumentere for tesen end beskrive produktet.