Threat Intelligence, MISP & eg0n con @roccosicilia

Guarda su YouTube → 1:03:37 16 luglio 2025

Descrizione

Oggi parliamo di Threat Intelligence, e per farlo ho deciso di invitare Rocco Sicilia, consulente di offensive security e red teamer. In questi ultimi mesi Rocco e la sua community stanno portando avanti un progetto open (eg0n), il cui obiettivo è agire come layer di integrazione tra MISP e tipici dispositivi che si trovano in un contesto di difesa (SIEM, firewall, etc). Scopri il lavoro di Rocco: - https://roccosicilia.com/about/ - https://www.patreon.com/roccosicilia - https://roccosicilia.com/2025/02/22/eg0n-versione-di-test-online/ Se vuoi supportare il mio lavoro: - https://patreon.com/hexdump - https://buymeacoffee.com/hexdump - https://www.paypal.com/donate/?hosted_button_id=T49GUPRXALYTQ I miei progetti: - https://esadecimale.it - https://hexdump.sh ------------------------- TIMESTAMP 00:00 Introduzione 01:55 Che cos'è la Threat Intelligence? 05:30 Sulla condivisione degli Indicator of Compromise (IoC) 15:25 Sull'utilizzo degli IoC per effettuare detection 19:35 MISP Open Source Intelligence Platform 25:10 Problemi nell'utilizzo di MISP 30:30 La nascita di eg0n 35:00 Il lato divulgativo del progetto 41:00 Demo tecnica di MISP & eg0n 54:00 Threat Hunting 59:00 Conclusione

Commenti 6

I commenti vengono da YouTube e sono aggiornati periodicamente.

@kilberggalva 17 luglio 2025 1

Grazie della condivisione. Bel video. Buon lavoro ad entrambi.
@antonellocasu6578 16 luglio 2025 1

Oh ma che bella collaborazione! Ottimo! Ho seguito il progetto dell'honeypot .
@aldobrrrr 19 luglio 2025 1

Molto interessante, unica questione che mi viene da commentare è la scelta del linguaggio e dell'ambiente per lo sviluppo di eg0n. Mi pare di aver compreso che quest'ultimo, tra le altre cose, dovrebbe andare a colmare gli aspetti negativi di MISP, che dal video, correggimi se sbaglio, sembrano essere sostanzialmente relativi alle prestazioni e alla manutenibilità. Allora perchè scegliere Python e quindi Django, che non spiccano nè per prestazioni nè tantomeno per manutenibiltà del codice? La mia non vuole essere una polemica, ma piú una riflessione: so bene che ci sono molti modi per ovviare a questi problemi al di la del linguaggio o del framework utilizzato, ma troppo spesso mi capita di vedere che vengano usati i tool con i quali si ha maggior confidenza anche a discapito dei requisiti di progetto. Perciò il progetto (e quindi l'architettura software e di sistema) diventa "al servizio" dei tool e non il viceversa.
3 risposte
1. @esadecimale Autore 19 luglio 2025 1
  
  In generale sarei d’accordo col tuo punto di vista, però devi anche tenere in considerazione che per loro non è un lavoro full time, ma a tutti gli effetti un side project (da quello che ho capito), quindi anche la quantità di risorse allocata è limitata. E quindi per loro ha piu senso andare con scelte “lazy” della serie “mi baso su tecnologie che conosco”, piuttosto che studiarsi nuove tecnologie. Perché se sí dovessero studiare nuove tecnologie probabilmente farebbero altro. Personalmente non partecipo al progetto, ma lo vedo utile per chi vuole esplorare la threat intelligente e l’interazione stessa con MISP. Poi, mi dirai, si, ci saranno sicuramente modalità più efficienti di eg0n per gestire il tutto, ma esplorare anche solo un diverso design di API può comunque essere utile per un futuro potenziale team con piu risorse. my two cents
2. @roccosicilia 20 luglio 2025
  
  Dal punto di vista tecnico hai perfettamente ragione. Provo a dare qualche dettaglio sulla scelta. Premessa necessaria: il nostro è un progetto didattico, è un modo per crearci qualcosa di utile che porta i partecipanti ad approfondire i temi che vengono trattati. Python è emerso come linguaggio noto alla maggior parte dei partecipanti di cui pochissimi sono programmatori full time. I problemi di prestazione a cui mi riferisco sono per lo più legati a scelte di architettura di MISP. Lato nostro ci siamo basati su come le applicazioni terze parti accedono a questi dati e di conseguenza abbiamo valutato come avremmo potute servire le informazioni. É emerso che l’output finale doveva essere costituito per lo più da file formattati. Una delle prime idee (mi pare di averlo scritto anche sul forum di esadecimale) era di appoggiare gli output su GitHub in modo da non diventare un collo di bottiglia. L’idea resta valida. Al momento, considerando i tipi di accesso al dato che stiamo considerando, django sembra soddisfare abbondantemente il tipo di richieste. Va considerato che non è previsto un’accesso massivo da centinaia o migliaia di sistemi. Come accennavo il problema era più legato all’architettura. Ad ogni modo sono/siamo molto interessati a suggerimenti! Ogni spunto è utile proprio per la natura del progetto.
3. @aldobrrrr 20 luglio 2025 1
  
  @roccosicilia Certo, capisco le vostre ragioni, ma spesso le migliori soluzioni nascono proprio da progetti didattici/hobbistici. Non vorrei che nel momento in cui diventasse una soluzione adottata da molti le scelte iniziali iniziassero a pesare. Chiaramente dipende molto più "dalle mani" che dal linguaggio, si possono scrivere progetti grandi in Python, ci mancherebbe, ma penso sia più difficile rimanere disciplinati e senza il supporto di un compilatore al crescere della base di codice può diventare frustrante. Ad ogni modo il progetto mi sembra promettente, specialmente la parte relativa agli IoC qualificati che non è cosa scontata. Ti faccio un grande in bocca al lupo!