Quanto sono popolari le revisioni del codice di sicurezza?

Question

Nel mondo reale, quanti qui sono sottoposti a approfondite revisioni del codice di sicurezza? Quelli che fanno, quanto spesso - una volta un quarto, una volta una versione, una volta una luna blu? Quelli che non lo fanno - perché no? (Non mi riferisco ai programmatori di piccole o hobbies - non che li sto banalizzando, è solo che non mi aspetto che loro ;-)).

In qualità di consulente di sicurezza, sono solitamente chiamato a fare le revisioni di sicurezza, tuttavia questo di solito è solo per organizzazioni molto sensibili alla sicurezza (ad esempio grandi banche, fornitori di software, militari, ecc.) O come un risultato dei requisiti normativi (es. PCI-DSS).
Ora, pochi gruppi (eccetto quelli delle più grandi aziende come Microsoft, Intel, RSA, ecc.) Apprezzano davvero la recensione, anche se in realtà dovrebbe essere un'esperienza positiva. Mi sembra che ciò sia dovuto principalmente all'elevato investimento percepito - delle risorse, del tempo e, naturalmente, del denaro per portare i consulenti.

Ok, quindi non è solo percepito, è abbastanza reale: è comunemente accettato che un singolo recensore può coprire tra 50-100 LoC all'ora. Anche se siamo riusciti a moltiplicare questo aspetto - dal momento che siamo alla ricerca di specifici problemi di sicurezza (e i clienti stanno facendo pressioni per costi inferiori) e possiamo ridurre l'ambito in base al rischio - possiamo massimizzare a circa 1000 LoC per ora. Per qualsiasi sistema medio-grande, si tratta ancora di centinaia di ore di consulenza costose, non banali affatto.

L'alternativa suggerita comune è scanner automatico di codice sorgente, ala Fortify, laboratori oncia, ecc, tuttavia, oltre ai costi di licenza, questo è ben lungi dall'essere efficiente - in genere troviamo questi strumenti per produrre risultati nei 100 migliaia, con un molto alto (70-90%) tasso di falsi positivi (e duplicati). Quindi stai ancora spendendo grandi quantità di tempo tra i risultati, E questi strumenti non coprono una serie sostanziale di potenziali vulnerabilità (es. Falle logiche, business logic, ecc.)

Detto questo, (e un grande ESCLUDE dovrebbe vai qui :) Ho lavorato negli ultimi mesi con uno dei fornitori di strumenti per sviluppare un servizio che lo avrebbe fatto in modo molto efficiente - ad es. essere in grado di coprire 500 K LoC in appena una settimana di lavoro, e tuttavia fornire risultati reali, reali, accurati e completi - praticamente zero falsi positivi e quasi nessun mancato falso negativo.

Quelli di voi che dovrebbero fare SCR, ma non lo sono, sarebbe sufficiente a convincervi del contrario? o c'è qualcos'altro che ti trattiene? O semplicemente non è un problema per te?

---

Per chiarire, non sto cercando di promuovere me stesso o il mio servizio, solo cercando di ottenere qualche punto di vista del mondo reale oltre la mia agenda di sicurezza-evangelistico. Mi piacerebbe vedere i problemi come gli altri programmatori li vedono ...

Ulteriori chiarimenti, NON sto chiedendo COME eseguire revisioni del codice, quali opzioni ci sono, ecc. Ho molta esperienza in questo campo, e è questa esperienza che vendo ai miei clienti. La mia domanda è SE le revisioni del codice sono impopolari come sembrano, PERCHÉ questa attività specifica non è così popolare come dovrebbe essere, e COME possiamo andare a cambiarla. (Irrilevante di scelta della metodologia, strumento, ecc)

---

Inoltre, come Corneliu e altri hanno sottolineato, revisioni del codice di sicurezza non dovrebbe essere presa solo come unica protezione e la verifica della sicurezza di un sistema, piuttosto dovrebbe essere un elemento di un completo, olistico framework SDLC (secure development lifecycle). Tuttavia, nemmeno dovrebbe essere dimenticato. Quindi la mia domanda si concentra davvero su quell'unico elemento, sia nel contesto dell'intero SDLC che da solo come un passo avanti da penetrate-and-patch.

Answer 1

Il tuo punto su tempi e costi di una revisione esterna del codice è fondamentale. Un paio di anni fa, la mia azienda ha incaricato Cigital di eseguire una revisione dettagliata del codice basata su strumenti. L'analista della sicurezza ha utilizzato Fortify e trascorso settimane a completare la revisione manuale del codice. Il tempo, i costi e il tempo impiegato per supportare l'analisi, rispondere alle domande e interpretare i risultati, era più di quanto potessimo sostenere su base regolare. Facciamo le nostre revisioni del codice, utilizzando le linee guida di sicurezza di OWASP e le liste di controllo preparate da Cigital.Inoltre, utilizziamo strumenti di analisi statica (Coverity, Findbugs) nel nostro ambiente di integrazione continua, ogni versione viene verificata con IBM Watchfire Appscan (o qualsiasi altra chiamata IBM oggi) e programmiamo regolari test di penna con Foundstone. I test con penna sono un buon uso del denaro e gli strumenti di analisi statica contribuiscono a garantire un'alta qualità del codice.

Se esistesse un'offerta di revisione del codice di sicurezza economica, veloce ed efficace, sì, ci sarebbe un mercato. Costruisco software finanziario: i miei clienti non sono pazzi per l'idea di inviare software all'estero per l'analisi di Veracode o simili.

Answer 2

Per essere onesti, raramente, se mai li hanno.

Tanto quanto l'azienda è consapevole che la sicurezza è importante è sempre una di quelle cose (molto simile a test) che finisce per prendere un colpo a favore di entrare in nuove funzionalità, modifiche ecc

mentre tutti sa che questo è il modo sbagliato di fare cose che dubito cambierà molto fino a quando l'applicazione non verrà morsa da una vulnerabilità di sicurezza. Scusa per essere così cinico.

Answer 3

Vengo dall'Australia e devo dire che le recensioni sulla sicurezza sono (forse) più popolari qui.
Negli ultimi due progetti in cui ho lavorato abbiamo avuto revisioni di sicurezza formali. Ho una recensione in più allineata nel prossimo futuro, ma dal mio punto di vista una "recensione di sicurezza" è sbagliata in base alla progettazione.

Le persone che eseguono le revisioni di sicurezza cercano solo un proiettile d'argento economico per comunicare che il codice non è completamente eliminato e che la possibilità di un attacco dell'applicazione è leggermente inferiore a "accadrà nelle prime 10 ore di produzione" .

Penso che una revisione di sicurezza inizia con:

• un Architectural Review da una prospettiva di sicurezza quando l'architettura sia messo in atto.
• Quindi lavori con Architect + Business su Threat Modeling e comprendi i potenziali problemi da affrontare e le mitigazioni che possono essere implementate.
• Quindi si costruisce un approccio per mettere queste mitigazioni sul posto preferibilmente a livello di architettura e cercare di isolare gli sviluppatori a livello aziendale dalla maggior parte del codice di sicurezza possibile.
• In seguito, eseguirò il ciclo di vita completo di sviluppo della sicurezza con il team e insegnerò loro le corrette linee guida per la codifica sicura. Mostra loro tutti i tipi di attacchi che possono accadere sulla loro applicazione sulla base del modello di minaccia che hai creato in precedenza. Mostra loro come codificare e proteggere.
• Insegna al team la difesa in profondità e come proteggere ogni pezzo del loro puzzle
• Insegnare loro come distribuire in modo sicuro, come progettare pezzi isolati con una sicurezza minima richiesta su di loro e così via.
• Insegnare loro come eseguire revisioni del codice di sicurezza del proprio codice e provocarli a provocarsi reciprocamente nello scrivere codice migliore.

Questo ci vorrebbe due settimane buone direi. Forse tre.

Quindi, si torna regolarmente e si effettuano revisioni parziali, si aggiorna il modello di minaccia e si forniscono ulteriori indicazioni su potenziali problemi che potrebbero introdurre.

Con questo si ha una migliore possibilità alla fine del progetto di fare una revisione finale del codice e avere una buona fiducia che quello che hai è buono e sicuro.

Oh, e puoi venderlo a un business molto meglio di "Ho bisogno di un mese per esaminare la tua base di codice e ti farò sapere quanto è stata sballata la tua app". Puoi andare in vacanza per un mese e tornare e dire che tutti sono buoni amici e non hanno idea di cosa hai fatto.

I miei 2 centesimi,

Corneliu.

Answer 4

Dipende dall'importanza dell'organizzazione e dell'app.

Si consiglia di verificare Veracode e Fortify (stili di contrasto) che automatizzano il processo. Entrambi gli abiti decenti e entrambi con una lista di clienti decente.

Questo verrà utilizzato in combinazione con un test penna di sicurezza dell'applicazione. Se stai presentando un accesso a una risorsa protetta su Internet, probabilmente vorrai eseguire il codice che compone il modulo di autenticazione. È necessario automatizzarlo un po '- le piccole applicazioni possono contenere 100K linee di codice e altro ancora. Vuoi sederti tutto questo manualmente? Sembra piuttosto noioso?

È inoltre necessario considerare il loro valore aggiunto. Se la tua infrastruttura è terribilmente aperta, allora non ha molto senso eseguire una revisione del codice. Perché controllare le finestre di casa quando tutte le porte sono aperte?

In una banca con cui ho lavorato (in un Security Consulting/Architetto/cani generali) come parte del loro ciclo di vita del progetto, ciascun progetto avrebbe dovuto sostenere il costo del proprio strumento di revisione del codice (rafforzare in questa particolare istanza). Tuttavia alcune delle loro applicazioni sono state interrotte e possedute in meno di 5 minuti a causa della scarsa configurazione di IIS.

Codice recensioni: a che punto del ciclo Dev si farebbe? Diventa un po 'più interessante da una prospettiva Agile.

Noelie Dunne

Answer 5

esecuzione Fortify (o un attrezzo simile) contro qualsiasi App Enterprise troverà sempre un carico capannone di vulnerabilità. Quanti di questi sono teorici, quanti di questi sono reali rischi di impatto sul business? Come classifichi cosa è importante e cosa no & tagliando i falsi positivi? Con cosa combatti contro Fortify?

Questo è l'approccio che prendo generalmente da una prospettiva di sicurezza nell'applicazione/architettura di livello enterprise .... Prima di tutto comprendi i casi di "utilizzo" per l'applicazione e le interfacce/componenti/accoppiamenti all'interno e all'esterno della tua applicazione. Scomposizione dell'utente & Interfacce di sistema Utente: stai osservando i casi d'uso per l'app, ovvero browser/thick client, livelli di privilegio Sistema: cose come MQ, interfacce Tibco, qualsiasi gestione/amministrazione, listener Oracle TNS , ODBC, ADO, interfacce proprietarie e così via.

Se sei un'applicazione di trading che si occupa di obbligazioni/opzioni, quali sono i tuoi interessi?

1) La capacità di un utente anonimo per accedere ai dati delle applicazioni private 2) La possibilità per un utente autorizzato di superare i permessi all'interno del loro profilo 3) La possibilità per un utente autorizzato ad accedere ai dati di un diverso utente 4) La possibilità per un utente autorizzato di accedere a diversi utenti che elaborano i risultati 5) La possibilità per un utente autorizzato di ottenere qualsiasi livello di accesso a qualsiasi componente dell'applicazione o architettura interna

Quindi questo sarà guidato dall'accesso modulo e i componenti che il modulo chiama dopo l'autenticazione riuscita. Ti interessa principalmente eseguire la convalida dell'input tramite i controlli del codice &.

Non c'è assolutamente alcun codice di controllo dei componenti di controllo, dll che non sono accessibili direttamente o indirettamente tramite un altro componente.

E questo presuppone che l'infrastruttura della piattaforma sia in the money.

Answer 6

Non sono sicuro se questo è il tipo di risposta che stavi cercando, ma spero che possa esserti utile.

Ho un paio di pensieri. Innanzitutto, apprezzo molto la sicurezza e penso che le recensioni dei codici di sicurezza siano una buona idea, ma posso capire perché potrebbero non essere popolari in tutti i casi, a seconda del settore. Questa è pura speculazione, ma molte aziende fanno beta pubbliche e quindi si affidano al feedback ricevuto da quelle sessioni. Possono vedere la sicurezza come qualcosa che dovrebbe essere iterativamente migliorato e quindi mettono meno enfasi su di esso all'inizio, certi che alcuni smart tester troveranno i bug e che l'etichetta beta li proteggerà da ogni responsabilità. Ovviamente non sono tutte le aziende, ma alcuni potrebbero pensare in modo simile.

Se vuoi davvero espandere il tuo mercato, potresti prendere in considerazione l'idea di pubblicarlo in una luce diversa. Oltre ad evidenziare le revisioni della sicurezza come una potenziale gestione del rischio, esse potrebbero essere viste in termini di risparmi sui costi nel tempo in termini di debito tecnico, salario, reputazione e questioni legali.

Per esempio, preferisco pagare un avvocato in anticipo per scrivere un contratto a prova di proiettile piuttosto che rappresentarmi in un tribunale per una controversia contrattuale. È una forma di gestione del rischio, ma la considero anche un investimento e un enorme risparmio nel tempo. Non solo sono più sicuro legalmente, ma ci sono anche cose intangibili come una relazione definita tra me e un cliente, in cui ci sono dei limiti e delle aspettative da soddisfare da entrambe le parti. Con quei limiti, sei più libero di concentrarti sulle cose su cui devi concentrarti.

Se è possibile presentare la sicurezza in modo simile, in termini di risparmio e tranquillità, è possibile che le persone (leggi la direzione) che prendono decisioni sull'assunzione di consulenti per la sicurezza siano più aperte ai servizi perché si è influenzando la loro linea di fondo in modo positivo. Presentalo in modo che tu li salvi molto più del tuo costo.

Answer 7

Dato che stai facendo una ricerca di mercato, mi piacerebbe contribuire.

Sto facendo così tanto SCR per altre aziende (generalmente come hai detto tu, banche, grandi app di e-commerce, componenti critici e altre cose finanziarie). Falsi-positivi e in termini di denaro non usano i big: Fortify, Ounce Labs.

Se stai progettando di introdurre un nuovo strumento in quel mercato con falsi positivi bassi e un cartellino del prezzo decente (perché Fortify e Ounce sono ridicoli, perché dominano il mercato), io e tante altre persone possiamo ottenerlo . La MS sta scavando lo stesso mercato nell'area VS.NET, quindi alcuni sviluppatori potrebbero andare in quel modo e la MS può schiacciare qualsiasi altro avversario (allo stesso tempo può portare un po 'di attenzione pubblica al mercato). Dovresti stare attento a questo.

Non è una risposta diretta alla tua domanda, ma spero che sia d'aiuto e se lo rilasci tienimi aggiornato.

Answer 8

I professionisti della sicurezza non devono sottoporre a revisione manuale il codice al 100%. Spero che tu abbia una copia di Ounce Labs o equivalente e stia solo esaminando per eliminare i falsi positivi, le regole di ottimizzazione, ecc.

Answer 9

Partecipo a un progetto open source chiamato Galleria. Quando raggiungiamo il candidato 1 di rilascio per una data versione, assumiamo un team esterno per eseguire una revisione della sicurezza. L'obiettivo è quello di ottenere una nuova serie di occhi altamente qualificati che li focalizzino su eventuali problemi di sicurezza latenti introdotti nel prodotto. In qualsiasi versione tipica, abbiamo riscontrato che la revisione della sicurezza (sebbene costosa) genera problemi e classi di vulnerabilità che i nostri sviluppatori tipici non avrebbero scoperto. Anche se siamo un team di sviluppo ragionevolmente attento alla sicurezza, ci sono sempre nuovi vettori di attacco che non siamo consapevoli di ciò che dobbiamo affrontare.

Finora abbiamo avuto 3 recensioni di sicurezza complete per i prodotti Gallery 2.x e 1 recensione di sicurezza per il prodotto Gallery 3.x (in tal caso abbiamo fatto la revisione mentre eravamo in alpha perché volevamo un feedback su vulnerabilità il più presto possibile).

Gli strumenti automatici (leggi: analisi statica) sarebbero utili. Anche gli strumenti automatici di test delle penne sono belli. Ma crediamo che ci sia un grande valore nell'avere un umano nel processo per investigare il codice e cercare le sottili vulnerabilità che ci distruggono.