Un investigatore riceve tre file, cinque link, uno screenshot e una vecchia esportazione in formato CSV. All’inizio sembra tutto gestibile. Dopo due giorni, però, il problema non è più trovare dati: è capire quali dati siano affidabili, quali siano duplicati, quali vadano esclusi e quali possano essere conservati senza violare privacy, legge o metodo.

È qui che nasce l’idea di un database OSINT portatile. Non un archivio clandestino di “leak”, non una collezione disordinata di dati personali, ma una base locale, cifrata e controllata, costruita per lavorare su materiale lecito, fonti aperte, dataset autorizzati, documenti pubblici, export interni consentiti, report, evidenze già acquisite e note di verifica.

L’idea di partenza è un archivio fisico indicizzato, conservato su HDD o SSD, capace di rendere rapide le ricerche anche senza connessione, riducendo la dipendenza dai motori di ricerca e dalla rete. Il punto operativo è: la priorità non è accumulare dati. La priorità è costruire un sistema che permetta di cercare, verificare, escludere e documentare senza trasformare l’indagine in un rischio legale.

Il problema: troppi file, poca tracciabilità

Nel lavoro OSINT l’errore più comune è confondere “avere molti dati” con “avere una base utile”. Un disco pieno di file non è un database. Una cartella con nomi casuali non è un archivio investigativo. Un insieme di dump, screenshot e tabelle senza origine documentata non vale quasi nulla quando arriva il momento di spiegare come si è arrivati a una conclusione.

Un database portatile serve a tre cose: velocizzare la consultazione, lavorare anche offline e mantenere una catena di provenienza leggibile. Ogni file deve rispondere a quattro domande: da dove arriva, quando è stato acquisito, perché è stato conservato, quali limiti ha.

Senza queste risposte, l’archivio diventa un deposito fragile. Può far perdere tempo, generare falsi positivi, esporre dati personali non necessari o spingere l’analista a confermare un’ipotesi solo perché il materiale sembra abbondante.

Come costruire un archivio OSINT portatile senza uscire dal perimetro legale

1. Definisci prima il perimetro dell’archivio

Prima di comprare un disco o creare cartelle, scrivi una regola semplice: cosa entra e cosa resta fuori.

Dentro possono entrare:

• documenti pubblici scaricati da fonti lecite;
• report tecnici o giornalistici salvati per analisi;
• export autorizzati;
• dataset aperti con licenza compatibile;
• screenshot contestualizzati;
• note investigative;
• file redatti o anonimizzati quando servono solo pattern, non identità.

Restano fuori dati acquisiti senza autorizzazione, credenziali, materiale ottenuto da canali opachi, informazioni personali non pertinenti, archivi scaricati “perché potrebbero servire”.

Il risultato atteso è un archivio più piccolo, ma difendibile. Meno rumore, meno rischio, più chiarezza.

2. Scegli il supporto fisico in base al lavoro reale

Consideriamo un dispositivo esterno da almeno 4 TB, con preferenza per tagli più grandi se il volume cresce. È un’indicazione sensata solo se esiste un motivo concreto: grandi raccolte documentali, archivi multimediali, copie forensi autorizzate, dataset pubblici pesanti.

Per un lavoro editoriale o investigativo ordinario, un SSD cifrato è spesso più utile di un HDD enorme. Legge più velocemente, resiste meglio agli spostamenti, riduce i tempi di ricerca. L’HDD ha senso quando il costo per gigabyte pesa più della velocità.

Errore comune: comprare spazio prima di progettare l’ordine. Un disco da 8 TB senza struttura peggiora il caos. Un SSD più piccolo, con naming coerente e indice aggiornato, lavora meglio.

3. Cifra tutto prima di inserire il primo file

La cifratura non va aggiunta alla fine. Va impostata all’inizio. Il disco deve essere protetto con cifratura completa, password robusta e backup separato. Se l’archivio contiene documenti sensibili, anche se acquisiti legalmente, la perdita fisica del supporto diventa un incidente.

Regola pratica: se non sei in grado di spiegare serenamente cosa contiene quel disco in caso di smarrimento, il disco non è pronto.

Il risultato atteso è semplice: chi trova il supporto non deve poter leggere nulla. Chi lavora sull’archivio deve poter dimostrare di aver adottato misure minime di protezione.

4. Crea una gerarchia di cartelle prima della raccolta

La gerarchia: organizzare le cartelle prima dell’indicizzazione evita di cercare dentro una massa indistinta.

Una struttura utile può essere questa:

1. 00_README_ARCHIVIO
2. 01_FONTI_PUBBLICHE
3. 02_DATASET_AUTORIZZATI
4. 03_SCREENSHOT_EVIDENZE
5. 04_NOTE_ANALISI
6. 05_EXPORT_LAVORO
7. 06_MATERIALE_DA_VERIFICARE
8. 99_ESCLUSO_NON_USARE

La cartella più importante è l’ultima. Serve a separare ciò che non va usato: duplicati, file non verificabili, materiale fuori perimetro, dati personali non necessari. Non tutto ciò che si trova merita di entrare nell’indagine.

5. Registra la provenienza con un file indice

Ogni cartella dovrebbe contenere un file SOURCE_LOG.csv o SOURCE_LOG.md con campi minimi:

• nome file;
• fonte;
• URL o riferimento interno;
• data di acquisizione;
• motivo della conservazione;
• livello di attendibilità;
• limiti noti;
• eventuali restrizioni d’uso.

Questo passaggio sembra burocratico, ma salva l’indagine. Quando un dato torna utile dopo tre settimane, il log evita la domanda peggiore: “Da dove veniva?”

Caso concreto: stai lavorando su una rete di domini collegati tra loro. Salvi WHOIS storici autorizzati, screenshot delle pagine, esportazioni DNS lecite e note. Senza source log, dopo dieci giorni rischi di non distinguere una pagina attiva da una copia archiviata, un dato primario da una nota personale, un indizio da una prova.

6. Indicizza solo materiale pulito e classificato

L’indicizzazione trasforma i file in un archivio interrogabile. Esistono programmi capaci di creare una “mappa” dei documenti per cercare velocemente stringhe, frammenti e formati diversi. La logica è utile, ma va applicata con cautela.

Prima si pulisce. Poi si indicizza.

Non indicizzare cartelle temporanee, file non verificati, dati personali non pertinenti o materiale escluso. L’indice amplifica tutto: anche gli errori. Se entra rumore, usciranno risultati confusi.

La ricerca locale può servire per:

• trovare una stringa esatta già autorizzata;
• controllare ricorrenze tra documenti;
• individuare duplicati;
• confrontare nomi di domini, indirizzi email aziendali, numeri di protocollo, hash, riferimenti pubblici;
• verificare se un’informazione compare in più fonti.

Attenzione: trovare una corrispondenza non significa dimostrare un fatto. Significa solo che una stringa appare in un certo insieme di file.

7. Usa query controllate, non ricerche impulsive

Un buon archivio locale permette ricerche esatte, parziali, booleane e con maschere. Il testo di partenza cita proprio questo tipo di possibilità: email, telefoni, identificativi, operatori AND/OR/NOT, espressioni regolari .

Il metodo difensivo richiede un passaggio in più: scrivere la query prima di lanciarla.

Esempio:

• domanda: “Questo dominio compare in documenti raccolti da fonti pubbliche?”
• query: dominio esatto;
• cartelle incluse: fonti pubbliche e screenshot;
• cartelle escluse: materiale da verificare, escluso, export non pertinenti;
• risultato atteso: elenco dei file in cui compare il dominio;
• limite: la presenza non prova proprietà, controllo o responsabilità.

Errore comune: cercare un nome proprio e costruire una storia intorno ai risultati. È il modo più rapido per confondere omonimie, vecchi dati, copie e riferimenti indiretti.

8. Documenta ogni passaggio rilevante

Ogni ricerca utile dovrebbe lasciare una traccia interna: query, data, cartelle incluse, numero di risultati, file rilevanti, esclusioni.

Non serve trasformare ogni controllo in un verbale. Serve poter ricostruire il percorso logico.

Un formato minimo:

Data:
Domanda investigativa:
Query:
Cartelle incluse:
Cartelle escluse:
Risultati rilevanti:
Cosa prova:
Cosa non prova:
Prossima verifica:

Questa scheda impedisce all’archivio di diventare una macchina per confermare sospetti. Costringe a separare risultato tecnico e interpretazione.

Implicazioni pratiche: velocità, riservatezza, responsabilità

Un database OSINT portatile riduce la dipendenza dalla connessione e dai motori di ricerca. Può velocizzare il lavoro su archivi grandi, permettere ricerche offline e proteggere meglio la riservatezza operativa. Il testo di partenza insiste proprio su indipendenza da Internet, efficienza e controllo delle condizioni di archiviazione .

La stessa architettura, però, può diventare problematica se viene usata per conservare dati personali senza base legittima, accumulare leak non verificati o interrogare materiale sensibile senza scopo proporzionato.

La domanda guida resta: questo file serve davvero alla verifica? Se la risposta è no, non entra. Se la risposta è sì, va classificato, protetto, documentato e riesaminato.

Un archivio OSINT maturo non impressiona per la quantità di dati. Funziona perché permette di trovare rapidamente ciò che serve, spiegare da dove viene, chiarire cosa dimostra e riconoscere cosa non può dimostrare.

Il risultato atteso è un ambiente di lavoro più ordinato: meno ricerche ripetute, meno dipendenza da fonti volatili, meno rischio di perdere provenienza e contesto. La parte tecnica conta, ma la differenza la fa la disciplina: perimetro chiaro, cifratura, log delle fonti, indicizzazione selettiva, query documentate, esclusione del materiale non necessario.