Ciao a tutti, ho finalmente il tempo di (ri)dedicarmi ad un progetto personale e collaborativo che ha come scopo l’implementazione di un processo di qualifica di IoC ed artefatti. Di base si tratta di un calderone di informazioni su cui gli analisti fanno arricchimento con note tecniche, relazioni, valutazioni.
Inizialmente avevo pensato di strutturare il tutto all’interno di una git repo adottando un formato standard per questo tipo di dato (TAXII), ragionandoci mi sono reso conto che sarebbe stato relativamente scomodo collaborare su due contenuti JSON, per quanto strutturati.
Ho quindi deviato verso l’utilizzo di un framework che mi sembrava affine allo scopo, django. Il vantaggio che ci ho visto è che lavorare su una interfaccia è decisamente più comodo e django ci consente di sviluppare automazioni e workflow senza fatica. Il rovescio della medaglia è che non tutti i potenziali interessati al progetto hanno confidenza con python e django e questo pone una sorta di “gradino” di ingresso.
Faccio appello a chi ha più confidenza con il mondo della programmazione. Considerando che anche all’interno di un progetto GitHub/GitLab potrei implementare delle automazioni o dei flow potrebbe valere la pena “tentate” la via della git repo rispetto al framework?
Io ho il sospetto di no, ma un parere da chi è più sul pezzo mi farebbe piacere.
Spero di aver dato sufficienti elementi.
Bye!
Parere molto personale, per quanto concerne l’analisi di dati opterei per un approccio il “più minimale possibile”, con eventuali scelte opzionali per facilitare determinati flow piuttosto che altri. Nel senso, le due opzioni che hai descritto non sono necessariamente in conflitto. Si può pensare di fare una base dati che, potenzialmente, può essere utilizzata anche senza l’utilizzo di django, e django on top per facilitare determinati flussi.
Il mio approccio “minimale”, permette di scalare rispetto a come si vuole utilizzare una cosa. Questo l’ho sviluppato con gli anni notando che più “il dato è distante dall’utente”, e più è difficile lavorare con lo strumento, qualsiasi esso sia.
Ora, non me ne intendo particolarmente di threat intelligence, quindi in questo dominio non ho le competenze adatte. Detto questo, volendo astrarre, ti direi:
Capisci il formato dei dati “raw” e dove intendi memorizzarli, e i flussi di accesso in lettura e scrittura. Eventualmente si potrebbero offrire API minimali per accedere a questi dati dietro un semplice backend, una cosa minimale tipo flusk. O anche solo tramite github, facendo il clone per leggere, e facendo PR per aggiungere dati.
Una volta che si è stabilito l’accesso minimale, si può pensare di fare cose più sofisticate per gli utenti che vogliono quel tipo di workflows.
Il problema di partire con framework troppo sofisticati è che questi ultimi effettuono tante scelte su come dovrebbero essere gestiti i flussi. Questo va bene quando il developer si prende il carico dello sviluppo, e alla fine è solo lui che vede tutti questi dettagli. Con progetti collaborativi, dal mio punto di vista, diventa più problematico.
Detto questo, penso anche di far parte della nicchia che decide di non over-specializzarsi in nulla per mantenersi flessibili.
Grazie @leo, hai proprio centrato il punto del mio cruccio… ero partito con l’idea di usare git a botte di PR per l’aggiunta dati proprio perché mi sembrava qualcosa di molto accessibile.
Nei prossimi giorni abbiamo una discussione a livello community e ne parleremo in modo strutturato.
Si è tenuta questa sera la prima sessione di confronto aperto sul progetto e sono emerse diverse opinioni sul livello di accesso alle informazioni e sulla modalità di accesso.
Sul piano tecnico pochi dubbi: potremmo esporre una semplice API o usare la base dati per allineare una git repo con i dati che si vorranno condividere. Personalmente mi piace di più questa seconda opzione.
In merito all’inserimento delle informazioni ed alla loro qualifica sono emersi alcuni temi da discutere prima di prendere una decisione: per ora la valutazione propendere per una gestione ridotta agli analisti direttamente tramite l’applicazione web.
Il bello di lavorare ad un progetto in tanti è che emergono nuovi punti di vista ed elementi che alimentano il dialogo.
Update: il piccolo team che si è creato si è messo all’opera e al momento stiamo lavorando al back-end con django.
Come accennavo l’idea rimane di tenere il codice open e accogliere eventuali interessati allo sviluppo o all’arricchimento. Siamo ancora allo stato embrionale ma qui c’è la repo su cui stiamo lavorando e su cui concentreremo la discussione: GitHub - b1th0rn/eg0n.