Dekning bør ikke avhenge av en leverandørs utgivelsessyklus

Det finnes et øyeblikk i en digital kriminalteknisk undersøkelse som ingen skriver inn i prosedyrehåndboken. En analytiker åpner et uttrekk, finner en applikasjon vedkommende ikke kjenner igjen, og sjekker om verktøyet støtter den. Det gjør det ikke. Dataene ligger der, fullt til stede, i en database vedkommende kan se filnavnet på. Og svaret på om de kan leses, er: ikke dette kvartalet.

Det øyeblikket behandles vanligvis som en støttesak. Noen oppretter en henvendelse. Kanskje leverandøren legger den i et etterslep, kanskje en versjon kommer om seks måneder, kanskje applikasjonen er regionalt populær nok til å være verdt en ingeniørs tid, og kanskje er den det ikke. Saken har i mellomtiden en varetektsfrist.

Dette er ikke en støttesak. Det er en strukturell egenskap ved måten bransjen valgte å arbeide på, og når De ser det slik, viser mye av den daglige frustrasjonen i et laboratorium seg å ha én årsak.

Avgjørelsen tas et annet sted

Hvert vanlig kriminalteknisk analyseverktøy virker på samme måte. Noen hos leverandøren gjør omvendt utvikling av lagringsformatet til en applikasjon, skriver en parser for det, tester den og leverer den i en utgivelse. Analytikeren mottar resultatet av det arbeidet som en funksjon.

Dette er genuint vanskelig ingeniørarbeid, og menneskene som gjør det, er gode til det. Problemet er ikke kompetanse. Problemet er at det legger den mest konsekvensrike avgjørelsen i en undersøkelse, hvilke data som i det hele tatt kan leses, i hendene på noen som ikke vet at saken finnes.

Den personen gjør en rimelig kommersiell vurdering. Vedkommende ser på hvor mange kunder som vil møte denne applikasjonen, hvor stabilt formatet er, og hvor mye ingeniørarbeid det vil kreve. En meldingsapplikasjon med to hundre millioner brukere er åpenbart verdt arbeidet. En regional sosial plattform med fire hundre tusen brukere, konsentrert i nettopp regionen der den organiserte kriminelle gruppen Deres opererer, er et langt vanskeligere forretningsgrunnlag. Fra leverandørens posisjon er det riktig å la være å implementere den. Fra Deres posisjon, med uttrekket i hånden, er det hele saken.

Versjoner er den største halvdelen av problemet

Historien om applikasjonen uten støtte er den som blir fortalt, men den underslår problemet. Den vanligere svikten er mer subtil: en applikasjon med støtte der lagringsoppsettet er endret.

En applikasjon oppdateres. Den omorganiserer en tabell, flytter en fil, endrer hvordan den koder et tidsstempel. Parseren ble skrevet mot forrige versjon og returnerer nå ingenting, eller verre, returnerer noe som er plausibelt og feil. Verktøyet oppgir applikasjonen som støttet, fordi den er det, og analytikeren må merke at resultatet er tynt.

Utgivelsessyklusene til applikasjoner måles i uker. Utgivelsessyklusene til kriminaltekniske verktøy måles i måneder. Det gapet lukkes aldri, og det er ingen sin feil. Det er et regnestykke.

Hva det koster, i de termene som betyr noe

Kostnaden viser seg vanligvis ikke som en mislykket undersøkelse. Den viser seg som en stillferdig innsnevring av omfanget.

En analytiker med tre uker og førti segl bruker ikke to dager på å lese en ukjent SQLite-database manuelt med en hex-editor åpen ved siden av, selv om vedkommende kunne. Vedkommende undersøker det verktøyet dekodet, skriver rapporten om det, og noterer resten som ikke analysert. Det er en forsvarlig faglig avgjørelse. Det er også slik bevis som finnes, på en enhet tjenesten allerede har, i en sak som allerede er åpen, ender med aldri å bli sett på.

Gang det med en saksmengde, og De får tallet laboratorieledere faktisk bekymrer seg for: andelen beslaglagte data som aldri blir undersøkt. Det er ikke en svikt i grovsorteringen. Det er en dekningssvikt som er blitt omklassifisert som grovsortering.

Alternativet er ubehagelig, men enkelt

Hvis flaskehalsen er at parsere skrives av en leverandør, på forhånd, for applikasjoner den valgte, er løsningen å slutte å kreve at et menneske hos en leverandør skriver dem på forhånd.

Dette er nå teknisk gjennomførbart på en måte det ikke var for fem år siden. Å kjenne igjen hva en ukjent database er til, hva tabellene inneholder, og hvordan de svarer til begrepene en etterforsker arbeider med, samtaler, kontakter, posisjoner, er en resonneringsoppgave over filstier, skjema og innhold samlet. Det er nettopp den typen oppgave generative modeller er uvanlig gode på, og klassifikatorer ikke er.

Den åpenbare innvendingen er den riktige. De kan ikke la en modell avgjøre hvordan bevis tolkes, og bare stole på resultatet. Så la være. Generer mappingen, valider den strukturelt, kjør den mot et utvalg av de virkelige dataene, og vis analytikeren en forhåndsvisning av faktiske poster før noe tas i bruk. Hvis mappingen har misforstått kilden, er det synlig med en gang, fordi forhåndsvisningen er full av vrøvl. Analytikeren godtar den, retter den i en visuell editor, eller kaster den.

Det som endres, er ikke beviskravet. Analytikeren verifiserer fortsatt, og ingenting kommer inn i en rapport ukontrollert. Det som endres, er hvem som må gjøre arbeidet med å forstå først, og når det kan skje. Det kan skje den dagen saken trenger det, heller enn i det kvartalet en leverandør planla det.

Hvorfor dette er verdt å si høyt

Hvert laboratorium vi har snakket med, har en versjon av den samme historien, og hvert av dem forteller den som om den var en lokal irritasjon. Den er ikke lokal. Den er den samme begrensningen i enhver tjeneste i ethvert land, og den finnes fordi hele bransjen tidlig tok et arkitekturvalg og aldri gikk tilbake til det.

Å navngi den endrer det De ber om. En tjeneste som tror den har et støtteproblem, ber leverandøren om raskere utgivelser, noe som er et ønske ingen kan innfri. En tjeneste som kjenner igjen et strukturelt problem, stiller et annet spørsmål: hva som skal til for at dekning slutter å være noe vi venter på.

Det er spørsmålet VERA ble bygget for å svare på, og det er grunnen til at vi heller vil argumentere for tesen enn å beskrive produktet.