Acoperirea nu ar trebui să depindă de un ciclu de versiuni al furnizorului

Există un moment într-o examinare de criminalistică digitală pe care nimeni nu îl scrie în manualul de procedură. Un analist deschide o extracție, găsește o aplicație pe care nu o recunoaște și verifică dacă instrumentul lui o acoperă. Nu o acoperă. Datele sunt chiar acolo, pe deplin prezente, într-o bază de date al cărei nume de fișier îl poate vedea. Iar răspunsul la întrebarea dacă pot fi citite este: nu în trimestrul acesta.

Momentul acela este tratat de obicei ca o problemă de asistență. Cineva deschide un tichet. Poate că furnizorul îl adaugă la o restanță, poate că o versiune sosește în șase luni, poate că aplicația este destul de populară regional încât să merite timpul unui inginer, și poate că nu. Între timp, cazul are un termen de custodie care curge.

Aceasta nu este o problemă de asistență. Este o proprietate structurală a felului în care industria a decis să lucreze, și, odată ce o vedeți astfel, o mare parte din frustrarea zilnică dintr-un laborator se dovedește a avea o singură cauză.

Decizia este luată în altă parte

Fiecare instrument curent de analiză criminalistică funcționează la fel. Cineva de la furnizor face inginerie inversă asupra formatului de stocare al unei aplicații, scrie un parser pentru el, îl testează și îl publică într-o versiune. Analistul primește rezultatul acelei munci ca pe o capacitate.

Aceasta este cu adevărat o inginerie dificilă, iar oamenii care o fac sunt buni la ea. Problema nu este competența. Problema este că pune decizia cea mai plină de consecințe dintr-o examinare, anume care date pot fi citite, în mâinile cuiva care nu știe că cazul există.

Persoana aceea face o judecată comercială rezonabilă. Se uită la câți clienți vor întâlni aplicația aceasta, cât de stabil îi este formatul, câtă inginerie va lua. O aplicație de mesagerie cu două sute de milioane de utilizatori merită în mod evident munca. O platformă socială regională cu patru sute de mii de utilizatori, concentrată exact în regiunea în care operează grupul dumneavoastră de criminalitate organizată, este un caz de afaceri mult mai greu. Din poziția furnizorului, a refuza să o implementeze este corect. Din poziția dumneavoastră, cu extracția în mână, este întregul caz.

Versiunile sunt jumătatea mai mare a problemei

Povestea aplicației neacoperite este cea care se spune, dar subestimează problema. Eșecul mai frecvent este mai subtil: o aplicație acoperită a cărei dispunere a stocării s-a schimbat.

O aplicație se actualizează. Reorganizează un tabel, mută un fișier, schimbă felul în care codifică un marcaj temporal. Parserul a fost scris pentru versiunea anterioară și acum nu întoarce nimic sau, mai rău, întoarce ceva plauzibil și greșit. Instrumentul raportează aplicația ca acoperită, pentru că este, iar analistul trebuie să observe că rezultatul este subțire.

Ciclurile de versiuni ale aplicațiilor se măsoară în săptămâni. Ciclurile de versiuni ale instrumentelor criminalistice se măsoară în luni. Intervalul acela nu se închide niciodată, și nu este vina nimănui. Este aritmetică.

Ce costă, în termenii care contează

Costul nu apare de obicei ca o examinare eșuată. Apare ca o reducere de domeniu, în liniște.

Un analist cu trei săptămâni și patruzeci de sigilii nu petrece două zile citind de mână o bază de date SQLite necunoscută, cu un editor hexazecimal deschis lângă el, chiar dacă ar putea. Examinează ce a decodat instrumentul, scrie raportul pe aceea și notează restul ca neanalizat. Aceasta este o decizie profesională defensabilă. Este și felul în care o probă care există, pe un dispozitiv pe care serviciul îl are deja, într-un caz care este deja deschis, sfârșește prin a nu fi privită niciodată.

Înmulțiți cu un volum de cazuri și obțineți numărul de care se preocupă de fapt directorii de laborator: proporția de date sechestrate care nu este examinată niciodată. Nu este un eșec de triaj. Este un eșec de acoperire care a fost reclasificat ca triaj.

Alternativa este incomodă, dar simplă

Dacă blocajul este că parserele sunt scrise de un furnizor, dinainte, pentru aplicațiile pe care le-a ales el, atunci remedierea este să se înceteze a se cere ca un om de la un furnizor să le scrie dinainte.

Aceasta este acum fezabilă tehnic într-un fel în care nu era acum cinci ani. A recunoaște la ce servește o bază de date necunoscută, ce conțin tabelele ei și cum se pun ele în corespondență cu conceptele cu care lucrează un investigator, conversații, contacte, locații, este o sarcină de raționament asupra căilor de fișier, a schemei și a conținutului, împreună. Este exact genul de sarcină la care modelele generative sunt neobișnuit de bune, iar clasificatorii nu.

Obiecția evidentă este cea corectă. Nu puteți lăsa un model să decidă cum este interpretată o probă și să credeți pur și simplu rezultatul. Așadar nu o faceți. Generați maparea, validați-o structural, executați-o pe un eșantion al datelor reale și arătați analistului o previzualizare a înregistrărilor reale înainte ca ceva să fie aplicat. Dacă maparea a înțeles greșit sursa, aceasta este vizibil imediat, pentru că previzualizarea este plină de nonsens. Analistul o acceptă, o corectează într-un editor vizual sau o aruncă.

Ceea ce se schimbă nu este standardul probei. Analistul verifică în continuare, și nimic nu intră într-un raport neverificat. Ceea ce se schimbă este cine trebuie să facă munca primei înțelegeri, și când poate avea loc. Poate avea loc în ziua în care cazul are nevoie de ea, nu în trimestrul în care un furnizor a programat-o.

De ce merită spus cu voce tare

Fiecare laborator cu care am vorbit are o versiune a aceleiași povești, și fiecare o spune ca și cum ar fi o iritare locală. Nu este locală. Este aceeași constrângere în fiecare serviciu, în fiecare țară, și există din cauza unei alegeri de arhitectură pe care întreaga industrie a făcut-o devreme și nu a revizuit-o niciodată.

A o numi schimbă ceea ce cereți. Un serviciu care crede că are o problemă de asistență îi cere furnizorului versiuni mai rapide, ceea ce este o cerere pe care nimeni nu o poate acorda. Un serviciu care recunoaște o problemă structurală pune o altă întrebare: ce ar fi nevoie ca acoperirea să înceteze să fie ceva ce așteptăm.

Aceasta este întrebarea la care a fost construit VERA să răspundă, și este motivul pentru care am prefera să argumentăm teza decât să descriem produsul.