recensioni di sicurezza del codice di terze parti

2

Non ho familiarità con tutti i passaggi coinvolti in un vero e proprio a tutti gli effetti revisione della sicurezza delle informazioni di un'applicazione sviluppata internamente, quindi mi chiedo se il seguente scenario sia o meno normale.

Viene creata un'applicazione Web e viene eseguita sopra il framework .NET di Microsoft.

Secondo i termini della recensione sulla sicurezza, tutto il codice di terze parti, definito qui (comunque a torto oa ragione) come codice non scritto in-house, ha bisogno di essere rivisto

Quindi, anche lo stack .NET stesso - non solo il codice interno scritto in alto dello stack .NET: deve essere controllato. Quindi oltre alla verifica iniziale del codice, eventuali aggiornamenti Microsoft dovrebbero essere controllati. Per esempio, supponiamo che l'app utilizzi MVC 5.2 e Microsoft rilascia MVC 5.3 e aggiornamenti dell'app a MVC 5.3; in questo caso, l'app non ha potuto superare la recensione fino a quando (tra gli altri test) viene eseguito lo stesso codebase di MVC 5.3 auditing / revisione.

Questa parte delle normali recensioni sulla sicurezza delle informazioni?

È prassi normale condurre una revisione della sicurezza della propria base di codice di Microsoft quando si crea un'applicazione nello stack Microsoft?

Come si può assumere un processo di revisione e revisione interna (utilizzando qualunque strumento di terze parti) sarebbe più sofisticato rispetto ai test che Microsoft avrebbe eseguito?

E dove finisce questo ciclo? Chi può dire che gli strumenti di terze parti e / oi test interni siano all'altezza? Suppongo che dovrebbe esserci anche una verifica di tali processi. E poi un audit di quegli audit ... ecc., Ecc., Ecc. Ad un certo punto, questo deve fermarsi e ci deve essere un livello di fiducia, giusto?

    
posta mg1075 30.07.2014 - 17:22
fonte

2 risposte

5

Is it standard practice to conduct a security review of Microsoft's own code base when you build an app on the Microsoft stack?

No. Uno dei motivi è che non si avrà accesso al codice proprietario (Windows, IIS, .Net, patch) a meno che non lo si decodifichi e lo sforzo di esso supererebbe i benefici.

L'approccio comune è definire terze parti fidate e accettare il rischio. Se si desidera coprire il 100% dei componenti di terze parti, è necessario rivedere non solo .Net, Windows, driver di periferica, firmware, BIOS, ma anche l'hardware.

    
risposta data 31.07.2014 - 00:54
fonte
1

No, in genere non lo faresti anche se puoi controllare molte delle librerie di supporto .net in un debugger se vuoi controllare esattamente cosa sta facendo una specifica parte di codice. Potresti essere in grado di eseguire la scansione di alcune librerie utilizzando l'analisi del codice statico che può operare su file binari, ma con grandi fornitori affidabili che avranno già effettuato questo test o simili - i fornitori più piccoli potrebbero non avere.

In definitiva è necessario esaminare le certificazioni, i white paper, il contratto, la reputazione e le pratiche di sviluppo sicuro del fornitore al fine di determinare il rischio associato all'uso del codice. Ad esempio è possibile scegliere un determinato sistema operativo rispetto ad un altro in base al rischio posto da ciascuno, ma non si dovrebbe rivedere tutto il codice sorgente di entrambi!

    
risposta data 31.07.2014 - 15:11
fonte

Leggi altre domande sui tag