Quali sono gli aspetti unici di un ciclo di vita del software di un attacco / strumento su una vulnerabilità del software?

Nella mia università locale, c'è un piccolo club di informatica per studenti di circa 20 studenti. Il club ha diversi piccoli team con specifiche aree di interesse, come sviluppo mobile, robotica, sviluppo di giochi e hacking / sicurezza.

Sto introducendo alcuni concetti di sviluppo agili di base a un paio di team, come le storie degli utenti, la stima della complessità delle attività e l'integrazione continua per il controllo delle versioni e build / test automatizzati.

Conosco alcuni cicli di vita di sviluppo di base, come cascata, spirale, RUP, agile, ecc., Ma mi chiedo se esiste un ciclo di vita di sviluppo software per l'hacking / violazione della sicurezza. Sicuramente, gli hacker stanno scrivendo un codice per computer, ma qual è il ciclo di vita di quel codice? Non penso che si preoccuperebbero troppo della manutenzione, poiché una volta che la violazione è stata trovata e corretta, il codice che ha sfruttato quella violazione è inutile.

Immagino che il ciclo di vita sarebbe qualcosa del tipo:

1. Trova gap nella sicurezza
2. Sfruttare il divario nella sicurezza
3. Procura il carico utile
4. Utilizza payload

Che tipo di differenze (se presenti) esistono per il ciclo di vita dello sviluppo del software quando lo scopo del prodotto è violare la sicurezza?

Di che tipo di codice stai parlando?

Esistono molti strumenti di sicurezza utilizzati nel processo di pirateria informatica, inclusi scanner come nmap , sqlmap , Nessus e molti altri. Immagino che abbiano lo stesso tipo di cicli di vita del software di qualsiasi altra applicazione.

D'altra parte, ci sono codici exploit. Codici scritti per sfruttare un exploit e una situazione molto specifici. Dubito fortemente che quelli abbiano bisogno di un ciclo di vita. Tuttavia, molti codici exploit sono integrati anche con un framework di sfruttamento più ampio come Metasploit .

Dopo una discussione con @AviD, vorrei aggiungere alcuni punti.

Sarà molto diverso per situazioni specifiche.

Alcuni codici exploit potrebbero essere sbalzati fuori per tenere conto della finestra prima che il giorno zero sia corretto. Il codice potrebbe essere espulso anche per altri motivi. Vedi: CRIMINE - Come battere il successore di BEAST? per un ottimo esempio di questo. Una persona ha scritto un pezzo di codice PoC per dimostrare rapidamente il suo punto. Nessuna metodologia del ciclo di vita del software viene presa in considerazione per codici come questo.

Probabilmente lo fanno i malware armati come stuxnet o FLAME. Software in pacchetto come Metasploit.

Quindi la risposta giusta è ... dipende.

Non vedo perché ci dovrebbe essere un ciclo di vita di sviluppo specificamente diverso a seconda dello scopo del prodotto.

Il software sviluppato per violare la sicurezza può durare quanto qualsiasi altro tipo di software e richiede la stessa quantità di manutenzione e lavoro.

Diversi creatori di tale software adotteranno diversi cicli di vita a seconda delle loro esigenze.

I modelli di sviluppo che specifichi sono proprio questi: modelli di sviluppo. Sono estremamente utili quando si sta sviluppando ingegneria, quando si hanno requisiti, quando è necessario creare o modificare architetture di sistema o progetti di componenti, quando è necessario costruire o modificare un prodotto e i test associati e quando si rilascia a un cliente.

Non sono sicuro che questi modelli possano essere applicati direttamente a progetti più orientati alla ricerca, in cui si sta cercando di rispondere a domande o saperne di più su un sistema (o sui punti deboli della sicurezza del sistema, nel tuo caso particolare).

Sospetterei che i modelli iterativi / incrementali, come i metodi agili e il modello a spirale, sarebbero i più utili per formare una base. In ogni iterazione, puoi lavorare per rispondere alle domande o definire più parametri con cui lavorare, che potrebbero includere o meno la scrittura di alcun codice. Forse vari metodi di ricerca scientifica potrebbero anche fornire una base interessante.

L'hacking ha recentemente visto una forte professionalizzazione, lontano dai singoli hacker che lo fanno "per i lulz" o per guadagnare fama, verso la collaborazione tra specialisti con l'obiettivo di fare soldi. Il risultato sono stati "kit di hacking" commerciali a tutti gli effetti come il kit di exploit Blackhole in cui specifici punti deboli del software possono essere facilmente integrati come plug-in. Suppongo che tali prodotti siano sviluppati praticamente esattamente come qualsiasi altro prodotto software.

Apparentemente esiste anche un mercato in via di sviluppo per exploit zero-day .

Life-Cyle non dipende mai dal codice. Dipende piuttosto da altri fattori come:

1. Tempo
2. bilancio
3. Natura del cliente
4. Natura del prodotto

Nel tuo scenario, la metodologia di Agile Life Cyle sarebbe molto utile. Il motivo è che è necessario coinvolgere il cliente durante lo sviluppo e verificare i parametri di qualità accettabili del prodotto. La metodologia agile ti aiuterebbe immensamente a migliorare il tuo software di hacking raccogliendo il feedback dei tuoi clienti e lavorando gradualmente su base incrementale .