Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
DRIFT Linux è una distribuzione Linux italiana open source progettata per Incident Response e Digital Forensics. Offre uno strumento portatile e veloce per analizzare e preservare le evidenze digitali.
Il 15 aprile 2026 è stata rilasciata DRIFT Linux, progetto tutto italiano e open source scaricabile dal sito ufficiale all’indirizzo: https://www.driftlinux.org/. Si tratta di una distribuzione Linux orientata alle attività di Incident Response e Digital Forensics, fondata su pochi pilastri ma ben definiti:
DRIFT Linux è un progetto open source italiano ideato, sviluppato e pubblicato da Massimiliano Dal Cero, autore del presente articolo e professionista che opera quotidianamente negli ambiti della Cyber Security, della Digital Forensics e della risposta agli incidenti, e che nel tempo ha contribuito anche ad altri progetti gravitanti nelle medesime orbite tecnologiche.
Nel presente articolo si intende offrire una panoramica delle caratteristiche di DRIFT Linux, partendo innanzi tutto dal contesto operativo nel quale si colloca, cioè quello della Digital Forensics e dell’Incident Response, per poi passare alla sua presentazione, alla sua genesi, alla filosofia che ne ha guidato e continua a orientarne lo sviluppo e alle principali scelte tecniche che ne definiscono l’identità.
Un detto popolare recita che «la fortuna è cieca, ma la sfortuna ci vede benissimo» e, sebbene lo scrivente non sia scaramantico e non creda nella fortuna, nella sfortuna o in altri elementi di fantasia, ritiene altresì che certi proverbi popolari offrano buone metafore della realtà e che, in fondo, nascondano inconsapevolmente un po’ di verità.
Negli ambienti complessi, caratterizzati da molte dinamiche interconnesse che coinvolgono sistemi ed esseri umani, la possibilità che si verifichi un evento negativo aumenta con l’aumentare delle parti coinvolte e della superficie esposta. Un click sbagliato, un errore compiuto involontariamente, una configurazione errata, una password finita in un data leak o un servizio esposto di troppo possono infatti diventare fattori sufficienti a innescare un esito avverso o ad offrire nuove opportunità di attacco per attori malevoli pronti a sfruttare in modo opportunistico ogni debolezza disponibile.
Questo esempio, che nella sua semplicità riflette bene un classico spaccato della vita digitale di molte Organizzazioni, evidenzia come sia essenziale prepararsi al peggio, non solo perché nei detti popolari vi possa essere una parte di verità, ma anche perché, in termini pratici, l’aumento della complessità, delle interdipendenze e della superficie esposta rende più facile l’insorgere di condizioni avverse e, quando queste si concretizzano, il costo per gestirle risulta molto più elevato se non ci si è preparati in anticipo.
La gestione degli incidenti risulta quindi una scelta obbligata, oggi più che mai, in quanto rappresenta una colonna portante nella tutela del patrimonio digitale di qualsiasi Organizzazione.
Seppure la gestione dell’imprevisto sia sempre stata un’attività importantissima, ma troppo spesso ignorata, oggi la consapevolezza in merito è indubbiamente aumentata, sia per effetto di una maggiore comprensione delle dinamiche di fragilità ed effemerità del digitale, sia per l’intervento di provvedimenti normativi che hanno reso tale aspetto, di fatto, imprescindibile anche sotto il profilo della compliance.
Ma cosa vuol dire “gestire un incidente”? Seppure sia trattato con un termine singolare, dietro “un” incidente non vi è una singola attività da svolgere, bensì un insieme di attività trasversali che coinvolgono l’intera organizzazione nei suoi molteplici livelli e che, in quel momento di tensione, devono operare in concerto tra loro.
L’orchestrazione delle parti coinvolte è fondamentale, poiché nei momenti di concitazione l’adrenalina prende il sopravvento, si insinua il timore del giudizio interno, emerge il rischio di incrinare la reputazione aziendale e, in tutto questo saliscendi emotivo, si aggiunge il macigno della necessità di ripartire nel minor tempo possibile. In uno scenario caotico e adrenalinico, come quando si verifica un incidente informatico, lo stress aumenta rapidamente e perdere “pezzi” è un attimo. I dati sono effimeri e azioni errate possono causare la perdita di frammenti informativi preziosi per determinare le cause dell’accaduto.
Proprio in questi contesti intensi e tesi, è fondamentale delineare in anticipo processi trasversali che coinvolgano tutta l’organizzazione, dalla comunicazione interna ed esterna, alla gestione delle terze parti, fino alle dinamiche tecniche sia della fase di ripristino sia di quella di indagine, che senza una coerenza operativa rischiano di “pestarsi i piedi” reciprocamente. La parte tecnica dedicata al recovery, spinta dalla tensione di dover far tornare operativa l’Organizzazione, rischia di cancellare evidenze digitali con le proprie attività; viceversa, la parte investigativa rischia di essere percepita come un rallentamento indesiderato.
Per le organizzazioni è quindi fondamentale avere chiaro in anticipo come e dove intervenire, disponendo di procedure e strumenti certi, entrambi fondamentali per operare al meglio.
Allo scatenarsi di un incidente informatico e ritrovandosi in un contesto simile a quello appena descritto, l’Organizzazione può decidere di affidare la fase delle investigazioni digitali a un team interno specializzato in DFIR (*), potendo eventualmente affiancargli il supporto di consulenti esterni. In alternativa può decidere strategicamente di affidare completamente le attività a professionisti esterni, così da sopperire a eventuali lacune tecniche o rispondere alla necessità di distanziare le analisi dalle dinamiche interne, potendo così disporre di uno sguardo esterno capace di valutare in modo indipendente.
(*) Quando si utilizza il termine DFIR (Digital Forensics and Incident Response), si fa riferimento a quell’insieme di pratiche che consentono di intervenire e affrontare un incidente informatico con metodo scientifico e finalità investigative, con l’obiettivo di preservare le evidenze digitali utili a ricostruire le dinamiche che hanno portato all’incidente, nonché di leggere e interpretare correttamente le tracce lasciate dalla compromissione.
Oltre alla gestione dell’incidente, esistono anche altri contesti nei quali uno strumento operativo come DRIFT Linux può trovare applicazione, in particolare quelli legati alla digital forensics, nei quali consulenti o forze dell’ordine attive sul campo abbiano la necessità di operare su casi di investigazione digitale in ambiti legali, dove la preservazione degli elementi informativi e la solidità, nonché la replicabilità, dell’ambiente operativo risultano essenziali per non compromettere il proprio lavoro e conferire maggiore solidità a quanto prodotto.
In questi scenari il tempo è un fattore cruciale oltre che critico, poiché le tracce digitali sono spesso fragili ed effimere: memoria volatile, processi in esecuzione, connessioni attive, log locali e file temporanei possono sparire da un momento all’altro o essere distrutti in modo irrimediabile da attività di recovery svolte senza le dovute cautele.
Per questo la preparazione dell’arsenale operativo è fondamentale. Strumenti di acquisizione, ambienti live, tool di analisi, supporti adeguati, checklist e procedure già collaudate permettono di arrivare sulla scena digitale con un laboratorio pronto, riducendo l’improvvisazione e aumentando la qualità delle evidenze raccolte.
–
Premesso ciò, e senza alcuna pretesa di completezza, ma con il solo obiettivo di introdurre lo scenario, risulta chiaro come in quei momenti sia cruciale arrivare sul luogo del misfatto con una propria cassetta degli attrezzi pronta e consolidata, senza il timore che manchi qualcosa di essenziale o vi siano alterazioni. Poiché l’ambiente risulterà già teso e frammentato di suo, l’operatore DFIR che arriva sulla scena dovrà poter contare con certezza sia sulla metodologia che sugli strumenti tecnici che utilizzerà, così da poter lavorare al meglio anche in contesti di crisi.
Introdotto lo scenario, risulta ora più lineare presentare DRIFT Linux e le motivazioni pragmatiche sottese al suo rilascio e al contesto operativo nel quale si colloca.
Come già richiamato in apertura, il 15 aprile 2026 è stata rilasciata DRIFT Linux progetto tutto italiano e open source scaricabile dal sito ufficiale.
Si tratta di una distribuzione Linux orientata alle attività di Incident Response e Digital Forensics, costruita attorno a pochi principi chiari: preservazione dell’ambiente operativo, rapidità di fruizione, disponibilità di strumenti concreti e attenzione agli aspetti di avvio sicuro.
Essendo una prima release, la sua pubblicazione rappresenta un momento particolare. Da un lato vi è la soddisfazione di vedere assumere una forma concreta a qualcosa che per lungo tempo è rimasto confinato tra idee, test, correzioni e ricerca del dettaglio; dall’altro vi è la consapevolezza che, nel momento in cui un progetto esce dal proprio perimetro originario, comincia inevitabilmente a misurarsi con aspettative, confronti e letture esterne, contribuendo così alla sua ulteriore evoluzione.
DRIFT Linux non fa eccezione, ma per comprenderne davvero la natura è opportuno chiarire fin da subito che, seppur sia, sulla carta, un progetto nuovo, non nasce dal nulla.
Alle sue spalle vi è infatti un percorso che nasce da lontano, costruito nel tempo attraverso attività sul campo di digital forensics, incident response e sviluppo di tool e distribuzioni dedicate. In questo percorso non si può non menzionare DEFT, che ha rappresentato un passaggio importante e che oggi appartiene a un passato concluso con la chiusura del progetto ormai anni fa. Si è trattato di un progetto che ha avuto un ruolo significativo nel panorama forense sia nazionale che internazionale, rispetto al quale DRIFT si pone in naturale continuità, anche perché nel progetto confluisce il patrimonio tecnico e progettuale di chi, in DEFT, ha espresso un contributo primario determinante sia a livello implementativo sia progettuale, non sempre percepibile all’esterno in ragione delle tipiche dinamiche di visibilità. Ciò comunque non modifica la sostanza del dato tecnico e storico, né il valore fondativo che quell’esperienza ha avuto nel maturare metodo, visione e approccio di tutto quello che è venuto dopo.
Tra i percorsi che da DEFT hanno preso vita vi è Tsurugi Linux, progetto tuttora attivo e vitale, con il quale DRIFT condivide una forte prossimità tecnica e culturale anche in ragione del coinvolgimento comune in entrambi i progetti. In questa catena di “discendenza” si inserisce DRIFT Linux, che trova nella storia di DEFT una naturale eredità oggi condivisa parallelamente con Tsurugi. In questo contesto DRIFT Linux è quindi da intendersi come nuovo spazio nel quale sviluppare come libera espressione esigenze tecniche e idee, senza per questo investire altri nell’affrontare scelte che riflettono una visione specifica e che rispondono a esigenze pratiche. DRIFT e Tsurugi restano così progetti distinti ma vicini e collaborativi, con la possibilità concreta di alimentarsi reciprocamente, potendo contaminarsi in modo positivo e crescere mantenendo ciascuno la propria identità. Non si tratta quindi di una ridondanza, ma di un’estensione naturale capace, nel tempo, di produrre risultati ancora più solidi.
Anche il nome DRIFT (traducibile in italiano con sgommare o derapare) nasce da una scelta ben ponderata. Al suo interno convivono più livelli di significato, tutti coerenti con l’identità del progetto. Il primo richiama l’urgenza tipica dell’incidente, il momento in cui bisogna reagire rapidamente, mettere in moto gli strumenti e muoversi senza esitazioni, ma mantenendo aderenza, controllo e capacità di governo della situazione, fornendo una risposta pronta, professionale e lucida. Vi è poi un secondo livello interpretativo, più tecnico e al tempo stesso più ludico, nel quale “DRIFT” può essere letto anche come anagramma di “DFIRT”, cioè “DFIR Toolkits” (Digital Forensics & Incident Response Toolkits). Infine il nome conserva anche un’eco più storica e affettiva, che richiama in qualche misura il “fu DEFT”. Non si tratta di un esercizio nostalgico, ma del riconoscimento del fatto che anche i nomi, talvolta, sedimentano la memoria tecnica delle idee da cui nascono.
L’idea di fondo era quella di costruire un laboratorio DFIR portatile, orientato alla preservazione e pensato per affiancare operativamente sul campo il professionista nel coprire in modo concreto attività che, nella pratica, tornano con grande frequenza: acquisizione dei drive dei dispositivi, acquisizione di contenuti Web e Cloud, attività di first response. Dietro questa sintesi vi è in realtà una filosofia precisa. Non si tratta soltanto di raccogliere strumenti utili, ma di disporre di un ambiente operativo che non debba essere reinventato ogni volta da zero, che nasca per preservare prima ancora che per mostrare e che provi a ridurre quanto più possibile attrito, rumore e comportamenti indesiderati, offrendo quindi un ambiente stabile e riutilizzabile, sempre “uguale a se stesso”.
Il tutto con una filosofia per certi versi “antica”, ma allo stesso tempo sorprendentemente contemporanea, che richiama in parte anche il concetto di container: un ambiente prevedibile, riutilizzabile ed effimero per natura, salvo gli elementi esplicitamente destinati alla persistenza, più che una distribuzione classica intesa in senso tradizionale.
Per questa ragione DRIFT Linux è stato concepito prima di tutto come live ISO. Non è una scelta fatta con approccio nostalgico, ma una decisione tecnica ben precisa. In molti scenari forensi e di incident response serve uno strumento portabile, rapido da avviare, prevedibile nel comportamento e capace di impattare il meno possibile sul contesto che si sta osservando o acquisendo. Una live costruita con criterio continua quindi ad avere pieno senso operativo.
Si può sottolineare come non solo DRIFT Linux permetta l’esecuzione “live”; così fanno anche Kali, Parrot e le altre varie distribuzioni. Ciò è assolutamente vero, ma in quel contesto la live è pensata più come “test” o come “viatico” per l’installazione che non come il vero e proprio ambiente di utilizzo. Sono quindi poco ottimizzate per essere scattanti in modalità live, sono ingombranti nell’occupazione di RAM e prevedono prima di tutto di essere installate.
Tale aspetto è ben evidente anche nella prima fase di boot, che, dopo aver verificato con attenzione che il sistema tratti i dischi in modalità rigorosamente ReadOnly fin dall’avvio, permette all’utente di selezionare subito lingua e layout della tastiera, così da rendere l’ambiente agevole da utilizzare fin dai primi istanti. Questo perché non ci si trova nell’anticamera di un’installazione, ma già nel cuore pulsante dell’operatività.
DRIFT Linux, nella sua variante “Fast” (l’altra variante sarà la “Paddock”, ma per ora è fuori contesto e non la tratteremo), nasce invece per essere solo una distribuzione live, minimizzata nelle componenti al fine di essere veloce e snella, minimizzata nei pacchetti presenti per non occupare RAM inutilmente, e caratterizzata dal minor numero possibile di processi attivi al boot per non pesare sulle performance, ma allo stesso tempo ricca di funzionalità utili allo scopo delle indagini DFIR.
Il sistema operativo alla base di DRIFT è stato costruito partendo dalla versione più minimale possibile di Ubuntu 24.04 per poi procedere additivamente, inserendo solo lo stretto necessario, evitando selettivamente quelle funzionalità inutili o indesiderate. Un esempio su tutti è la voluta assenza di “snap”, che in un contesto come quello di DRIFT risultava più un problema che un vantaggio, in quanto introduceva rallentamenti e livelli di isolamento che, per un operatore di digital forensics, possono risultare più d’impaccio che di reale valore aggiunto.
Al tutto si sono poi affiancate regole di sistema necessarie alla preservazione dei dispositivi e alla limitazione del rumore nel contesto in cui si inserisce. L’obiettivo è dare forma a un “arsenale” pronto all’uso, replicabile a sé stesso e verificabile in ogni occasione, così da poter anche fornire prova della sua genuinità, caratteristica fondamentale in determinati contesti.
La filosofia live-first non implica però dipendenza dalla sola interfaccia grafica. DRIFT è stato pensato anche per scenari meno comodi, nei quali una GUI non sia disponibile, non sia eseguibile o semplicemente non sia opportuna. Per questo il progetto può essere utilizzato anche in ambiente testuale puro, con il supporto di TUI sviluppate ad hoc. Non si tratta di folklore da terminale, ma di una scelta pragmatica, poiché in determinati contesti semplicità, leggibilità e capacità di avvio nel maggior numero di condizioni contano molto più di qualsiasi interfaccia apparentemente rassicurante.
Uno dei principi che ha guidato DRIFT fin dall’inizio è stato evitare l’approccio più semplice, ma spesso anche più fragile, cioè prendere una base generica, aggiungere una quantità di tool utili e fermarsi lì. DRIFT non nasce come contenitore di programmi, ma come sistema costruito con una logica coerente. Ciò significa lavorare non soltanto sulla selezione degli strumenti inclusi, ma anche sulla struttura generale, sulla gestione dei pacchetti, sul comportamento all’avvio, sulla controllabilità delle connettività, sulla sicurezza dei dispositivi collegati e sulla possibilità di aggiornare e far crescere il progetto nel tempo.
In quest’ottica, la scelta della base è ricaduta su Ubuntu 24.04 LTS, nella sua forma più minimale possibile. Anche questa è una decisione molto più pragmatica che ideologica. In un progetto DFIR la priorità non è inseguire la novità più recente, ma poggiare su una piattaforma stabile, solida e prevedibile, sulla quale costruire in modo governabile. Una base matura consente di concentrare gli sforzi dove servono davvero, evitando di consumare energie nel rincorrere cambiamenti che richiederebbero ulteriori cicli di adattamento, contenimento e stabilizzazione.
A questa impostazione si affianca un ulteriore aspetto tecnico che è stato perseguito con particolare attenzione, ossia la piena compatibilità con il Secure Boot. L’obiettivo è stato quello di ridurre il più possibile ogni frizione in fase di avvio, evitando che moduli di GRUB, componenti della initramfs o altri elementi del processo di boot potessero risultare sgraditi ai meccanismi di controllo del firmware. In altri termini, si è cercato di rendere DRIFT Linux avviabile senza richiedere modifiche alle impostazioni del BIOS/UEFI, evitando quindi di dover disabilitare il Secure Boot. Si tratta di un aspetto tutt’altro che secondario, perché in molti contesti il minor impatto possibile sul sistema e sull’ambiente operativo costituisce già di per sé un requisito importante.
Parallelamente, è stato mantenuto un boot ibrido, così da consentire l’utilizzo del sistema anche su macchine più datate che ancora richiedano compatibilità con modalità di avvio legacy. Naturalmente, per sistemi realmente molto vecchi, resta più sensato rimandare a progetti del passato nati in contesti differenti, come la vecchia DEFT Zero, ancora scaricabile dal sito di DRIFT Linux. In coerenza con questa impostazione, DRIFT Linux include l’ultima versione disponibile del kernel 7.0 e, seguendo la logica dei rilasci Canonical che firmano il kernel per l’esecuzione in Secure Boot, il progetto verrà progressivamente riallineato agli aggiornamenti via via disponibili. Questo potrà avvenire sia mediante aggiornamento dal repository, sia riscaricando le build che si succederanno nel tempo, il cui changelog documenterà puntualmente l’evoluzione del sistema.
Nella stessa direzione si colloca la presenza di un repository ufficiale. Anche qui non si tratta di un dettaglio accessorio, ma di un elemento strutturale. Il repository serve a organizzare meglio la fase di building, a gestire i componenti in modo più ordinato, a distribuire aggiornamenti e correzioni anche dopo il rilascio della ISO e, soprattutto, a evitare che ogni miglioramento richieda di rigenerare l’intera immagine come se il progetto fosse un oggetto immobile. DRIFT, peraltro, non adotta una logica di full repository completamente chiuso, ma una sovrapposizione ragionata rispetto all’ecosistema Ubuntu. È una scelta meno scenografica di altre, ma molto più sensata dal punto di vista progettuale, perché consente di continuare a poggiare su una base ampia e ben mantenuta, concentrando l’intervento sugli aspetti realmente distintivi della distribuzione.
Il cuore tecnico di DRIFT Linux sta però soprattutto nella sua impostazione preservativa. L’obiettivo non è soltanto avviare un sistema con strumenti utili a bordo, ma fare in modo che il comportamento del sistema stesso sia il più possibile prudente, rispettoso e difensivo verso il contesto che si trova davanti. Per questo il progetto interviene fin dalle primissime fasi di boot del kernel, con l’intento di aumentare il più possibile le garanzie di inalterabilità delle evidenze collegate.
Questa attenzione ha richiesto lavoro non solo sulla gestione dei bus dei dispositivi, come SATA, USB e altri canali di collegamento dei supporti, ma anche su aspetti hardware che troppo spesso vengono liquidati come dettagli secondari. Tra questi rientra l’orologio di sistema, che in un contesto forense può assumere un rilievo tutt’altro che marginale rispetto alla coerenza temporale, alla ricostruzione delle timeline e, più in generale, all’affidabilità del quadro probatorio. In questo senso, DRIFT prova a fare ciò che uno strumento DFIR dovrebbe fare per sua natura, ossia preservare il contesto prima ancora di interagirci.
Un altro elemento tecnico qualificante riguarda l’isolamento delle connettività, sia radio sia cablate. In molti scenari investigativi o incidentali, lasciare che un sistema si comporti “normalmente” dopo il boot può essere già troppo. Una porta Ethernet attiva, una scheda Wi-Fi che tenta di associarsi, il Bluetooth che si annuncia o una connessione avviata senza volontà esplicita dell’operatore possono generare rumore, contaminare il contesto o esporre la presenza dell’analista. Per questo in DRIFT Ethernet, Wi-Fi e Bluetooth vengono annullati fin dall’avvio, lasciando poi all’operatore la possibilità di riabilitarli in modo deliberato e controllato. Non è una forma di hardening fine a sé stessa, ma una scelta che rimette il controllo in mano a chi opera.
Questa filosofia si riflette anche nello sviluppo di tool interni pensati non soltanto per aggiungere funzionalità, ma per costruire una coerenza operativa capace di guidare l’operatore lungo percorsi quanto più possibile lineari e controllati. Nel contesto DFIR, infatti, non basta disporre di strumenti potenti: serve anche ridurre il margine di errore in attività che, per loro natura, si svolgono spesso in condizioni di pressione, urgenza e stress elevato. In questo senso, DRIFT Linux non si limita a offrire un contenitore di tool, ma prova a presentarsi come una base solida sulla quale costruire un ecosistema operativo coerente, destinato ad arricchirsi ulteriormente nel tempo.
Un esempio concreto di questa filosofia riguarda il file manager Thunar, che è stato modificato per non montare automaticamente i dischi e per prevedere due modalità esplicite di mounting: Read Only, cioè in sola lettura, e Read and Write, cioè in lettura e scrittura. La prima modalità consente di accedere al contenuto assicurando di non apportare modifiche al supporto, mentre la seconda permette un’interazione completa, ove necessaria. Anche l’interazione con il dispositivo è stata ripensata: il semplice click non conduce direttamente al contenuto del disco se non dopo un’esplicita selezione dell’azione di apertura. Si tratta di una scelta progettuale voluta, poiché il dispositivo potrebbe contenere materiali sensibili, riservati o particolarmente delicati che l’operatore non deve poter incapparci e visualizzarli involontariamente durante le sue attività. Nella stessa logica si colloca anche l’assenza di thumbnails generate automaticamente, così da evitare che l’occhio possa cadere accidentalmente su contenuti che non si possa, o non si voglia, visionare.
Nella stessa idea concettuale appartengono anche i tool per l’acquisizione Web, che orchestrano in modo guidato una serie di azioni necessarie, il mount manager progettato per guidare l’operatore nella visione strutturata dei drive e dei relativi stati di protezione a basso livello e gli strumenti dedicati alla gestione delle connettività, pensati per limitare il più possibile il rumore sulla rete cablata o wireless. In questo senso, la distribuzione non è soltanto un insieme di programmi utili, ma anche una base strutturata che ha permesso e che permetterà di facilitare la presenza di strumenti sviluppati in seno al progetto all’interno di una logica comune, per aiutare in modo coerente le attività operative DFIR.
Un altro elemento che ritengo importante chiarire è che DRIFT Linux non pretende di presentarsi come un progetto monolitico. Sarebbe poco utile. Il progetto è pensato per proporre varianti, evolvere, essere raffinato, corretto, ampliato e, auspicabilmente, accompagnato nel tempo anche da una community di persone interessate a seguirne la crescita.
Questa crescita è già parte della visione progettuale. Oltre alla live ISO attuale, sono previste ulteriori varianti, tra cui una versione micro, particolarmente leggera ed essenziale, pensata per ambienti limitati o hardware più contenuto. Sono inoltre previste declinazioni rivolte al mondo cloud, in contesti come Azure, AWS, Google Cloud e scenari affini, perché il lavoro DFIR da tempo non si esaurisce più nel solo rapporto con macchine fisiche e supporti locali. Allo stesso modo è prevista, più avanti, anche una sorta di box installabile, con caratteristiche differenti rispetto alla live, ma coerente con la medesima impostazione di fondo.
In definitiva, DRIFT Linux non nasce per aggiungere un’ulteriore sigla al panorama delle distribuzioni specialistiche, ma per provare a costruire un ambiente DFIR coerente, aggiornabile, controllabile e realmente utile. Un sistema che prova a partire da esigenze concrete, a ridurre il rumore dove possibile, a preservare il contesto prima di modificarlo e a fornire agli analisti uno strumento che non debba essere reinventato ogni volta da capo. Se poi, nel tempo, questo percorso riuscirà anche ad alimentare e a farsi alimentare da progetti vicini come Tsurugi, tanto meglio: significherà che la distinzione non avrà generato frammentazione sterile, ma ulteriore fertilità tecnica.
L’auspicio per il progetto è che venga scaricato, provato sul campo e messo realmente alla prova da molti professionisti, così da poter risultare utile nel lavoro quotidiano e, al tempo stesso, raccogliere feedback preziosi per le sue prossime evoluzioni.
QUATTRO LEZIONI PER COMPRENDERE IL DARKWEB ED ENTRARE DA PROTAGONISTI NELLA CYBER THREAT INTELLIGENCE.
Per info e iscrizioni: 📱 Whatsapp 379 163 8765 ✉️ [email protected]
Dopo il successo delle scorse edizioni, Red Hot Cyber è lieta di annunciare una nuova live-class del corso "Dark Web & Cyber Threat Intelligence". A differenza dei corsi e-learning pre-registrati, queste lezioni online in tempo reale, condotte dal professor Pietro Melillo, offrono un’esperienza formativa interattiva e coinvolgente, ideale per approfondire i contenuti e affrontare casi pratici.
Le Live Class sono progettate per garantire un apprendimento mirato e personalizzato, con un massimo di 14 partecipanti per sessione. Questo consente di adattare il percorso formativo alle esigenze specifiche, ma anche di mantenere alta la qualità: i posti sono limitati e nelle scorse edizioni sono andati in sold-out due settimane prima dell’inizio. Prenota subito per assicurarti il tuo posto!
Risorse online:
Al termine del corso, potrai accedere all’esclusivo Laboratorio di Intelligence DarkLab, un ambiente operativo dove mettere in pratica le competenze acquisite. Sarà l’occasione per sperimentare attività di investigazione nel Dark Web, analisi delle minacce e redazione di report di intelligence e ricerche approfondite.
Per info e iscrizioni: 📱 Whatsapp 379 163 8765 ✉️ [email protected]