Dekking hoort niet af te hangen van een releasecyclus van een leverancier

Er is een moment in een digitaal forensisch onderzoek dat niemand in het procedurehandboek schrijft. Een analist opent een extractie, vindt een applicatie die hij niet herkent, en controleert of zijn hulpmiddel haar ondersteunt. Dat doet het niet. De gegevens staan daar, volledig aanwezig, in een database waarvan hij de bestandsnaam kan zien. En het antwoord op de vraag of ze kunnen worden gelezen, is: niet dit kwartaal.

Dat moment wordt doorgaans als een ondersteuningskwestie behandeld. Iemand maakt een ticket aan. Misschien zet de leverancier het op een achterstand, misschien komt er over zes maanden een versie, misschien is de applicatie regionaal populair genoeg om de tijd van een ingenieur waard te zijn en misschien niet. Ondertussen loopt de bewaartijd van de zaak.

Dit is geen ondersteuningskwestie. Het is een structurele eigenschap van de manier waarop de sector heeft besloten te werken, en zodra u het zo ziet, blijkt veel dagelijkse frustratie in een laboratorium één oorzaak te hebben.

De beslissing wordt ergens anders genomen

Elk gangbaar hulpmiddel voor forensische analyse werkt op dezelfde manier. Iemand bij de leverancier reverse-engineert het opslagformaat van een applicatie, schrijft er een parser voor, test die, en levert hem in een release. De analist ontvangt het resultaat van dat werk als een mogelijkheid.

Dit is werkelijk moeilijke engineering, en de mensen die het doen, zijn er goed in. Het probleem is niet de bekwaamheid. Het probleem is dat het de meest gevolgrijke beslissing in een onderzoek, welke gegevens überhaupt kunnen worden gelezen, legt bij iemand die niet weet dat de zaak bestaat.

Die persoon velt een redelijk commercieel oordeel. Hij kijkt naar hoeveel klanten deze applicatie zullen tegenkomen, hoe stabiel haar formaat is, hoeveel engineering ze zal kosten. Een berichtenapplicatie met tweehonderd miljoen gebruikers is vanzelfsprekend het werk waard. Een regionaal sociaal platform met vierhonderdduizend gebruikers, geconcentreerd in precies de regio waar uw groep van georganiseerde criminaliteit actief is, is een veel moeilijker businesscase. Vanuit de positie van de leverancier is het juist om de implementatie te weigeren. Vanuit uw positie, met de extractie in handen, is het de hele zaak.

Versies zijn de grotere helft van het probleem

Het verhaal van de niet-ondersteunde applicatie is het verhaal dat wordt verteld, maar het onderschat de kwestie. Het vaker voorkomende falen is subtieler: een ondersteunde applicatie waarvan de opslagindeling is veranderd.

Een applicatie werkt bij. Ze herindeelt een tabel, verplaatst een bestand, verandert hoe ze een tijdstempel codeert. De parser is geschreven tegen de vorige versie en geeft nu niets terug, of erger, iets aannemelijks en onjuists. Het hulpmiddel meldt de applicatie als ondersteund, omdat ze dat is, en de analist moet opmerken dat de uitvoer dun is.

Releasecycli van applicaties worden in weken gemeten. Releasecycli van forensische hulpmiddelen worden in maanden gemeten. Die kloof sluit nooit, en het is niemands schuld. Het is rekenkunde.

Wat het kost, in de termen die ertoe doen

De kost verschijnt doorgaans niet als een mislukt onderzoek. Ze verschijnt als een inperking van de reikwijdte, stilletjes.

Een analist met drie weken en veertig zegels besteedt geen twee dagen aan het handmatig lezen van een onbekende SQLite-database met een hex-editor ernaast, ook al zou hij dat kunnen. Hij onderzoekt wat het hulpmiddel heeft gedecodeerd, schrijft daarover het rapport, en noteert de rest als niet geanalyseerd. Dat is een verdedigbare professionele beslissing. Het is ook de manier waarop bewijs dat bestaat, op een apparaat dat de dienst al heeft, in een zaak die al open is, uiteindelijk nooit wordt bekeken.

Vermenigvuldig met een werklast en u krijgt het getal waar laboratoriumdirecteuren werkelijk over wakker liggen: het aandeel in beslag genomen gegevens dat nooit wordt onderzocht. Het is geen falen van de triage. Het is een falen van de dekking dat als triage is geherclassificeerd.

Het alternatief is ongemakkelijk maar eenvoudig

Als het knelpunt is dat parsers door een leverancier worden geschreven, vooraf, voor applicaties die zij hebben gekozen, dan is de oplossing om niet langer te eisen dat een mens bij een leverancier ze vooraf schrijft.

Dit is nu technisch haalbaar op een manier die vijf jaar geleden niet bestond. Herkennen waar een onbekende database voor dient, wat haar tabellen bevatten, en hoe ze overeenkomen met de begrippen waarmee een onderzoeker werkt, gesprekken, contacten, locaties, is een redeneertaak over bestandspaden, schema en inhoud samen. Het is precies het soort taak waar generatieve modellen ongewoon goed in zijn en classificatoren niet.

Het voor de hand liggende bezwaar is het juiste. U kunt een model niet laten beslissen hoe bewijs wordt geïnterpreteerd en het resultaat eenvoudig vertrouwen. Doe dat dus niet. Genereer de mapping, valideer haar structureel, voer haar uit op een steekproef van de echte gegevens, en toon de analist een voorbeeld van werkelijke records voordat er iets wordt toegepast. Als de mapping de bron verkeerd heeft begrepen, is dat onmiddellijk zichtbaar, omdat het voorbeeld vol onzin staat. De analist aanvaardt haar, corrigeert haar in een visuele editor, of gooit haar weg.

Wat verandert, is niet de bewijsnorm. De analist verifieert nog steeds, en niets komt ongecontroleerd in een rapport. Wat verandert, is wie het werk van het eerste begrip moet doen, en wanneer het kan gebeuren. Het kan gebeuren op de dag dat de zaak het nodig heeft, en niet in het kwartaal dat een leverancier heeft ingepland.

Waarom dit de moeite waard is om hardop te zeggen

Elk laboratorium waarmee wij hebben gesproken, heeft een versie van hetzelfde verhaal, en elk ervan vertelt het alsof het een lokale ergernis was. Het is niet lokaal. Het is dezelfde beperking in elke dienst in elk land, en ze bestaat vanwege een architectuurkeuze die de hele sector vroeg heeft gemaakt en nooit opnieuw heeft bekeken.

Haar benoemen verandert wat u vraagt. Een dienst die denkt een ondersteuningsprobleem te hebben, vraagt zijn leverancier om snellere releases, en dat is een verzoek dat niemand kan inwilligen. Een dienst die een structureel probleem herkent, stelt een andere vraag: wat zou ervoor nodig zijn dat dekking ophoudt iets te zijn waarop wij wachten.

Dat is de vraag die VERA is gebouwd om te beantwoorden, en het is de reden waarom wij liever de stelling beargumenteren dan het product beschrijven.