Base per "fidarsi" di codice e servizi di terze parti

Naviga le tue risposte
1

Ricordo di aver letto un articolo che diceva che i servizi e il codice di terzi non dovrebbero essere considerati attendibili, il che significa fiducia cieca.
Quindi, stavo pensando, tutti usano il codice di terze parti nello sviluppo del software ogni giorno, anche aziende di sicurezza IT di alto profilo, e alcuni di noi danno per scontato che il codice che hanno appena usato sia affidabile, cioè sicuro e testato.

Domande :

  • Qual è la base per fidarsi del codice e dei servizi di terze parti nello sviluppo del software?
  • Quali misure vengono prese dalle società di sicurezza IT prima di concedere tale fiducia?
  • Quali misure vengono prese dalle società di sicurezza IT per mantenere tale fiducia?

Sia open-source che closed-source.

Ad esempio, pensa a:

  • La società di web hosting per ospitare le tue e i tuoi dati e i tuoi dati

  • Il software che non hai scritto ma con cui lavorare.

Grazie!

    
posta HassenPy 16.12.2015 - 16:24
fonte

1 risposta

3

Recentemente sono stato assunto per un'organizzazione che utilizzava software di terze parti. Ecco il nostro processo di pensiero.

  • C'è forza nei numeri. Il software di terze parti che è A) open source, B) ha un team di sicurezza dedicato e ben informato, C) ha una politica di divulgazione responsabile, e D) è ampiamente utilizzato da migliaia di clienti è meglio di qualsiasi cosa la nostra organizzazione possa mai mettere fuori
  • C'è forza nel fare il lavoro di gambe. Sono stato assegnato a ogni modulo di questo software di terze parti e ne ho fatto una revisione completa prima di consentirne l'aggiunta alla nostra infrastruttura. E se abbiamo trovato una vulnerabilità, abbiamo utilizzato il programma di divulgazione responsabile per migliorare il software.
  • C'è un punto di forza nell'aggiornamento. Ci siamo iscritti agli avvisi dei fornitori per assicurarci che se qualcun altro avesse trovato qualcosa, siamo stati in grado di rispondere all'incidente e proteggere la nostra infrastruttura.

Naturalmente, ci sono anche punti deboli a questo approccio:

  • C'è debolezza nel software omogeneo. Se è venuto fuori un grosso exploit, c'è un'alta probabilità che qualcuno trovi il nostro sito e abbia tentato un punto e sparato a exploit.
  • C'è debolezza nei numeri. Abbiamo fatto una recensione completa, ma le altre migliaia di persone lo hanno usato? Probabilmente no.
  • C'è debolezza nel lavoro di volontariato. Se qualcosa fosse accaduto, non c'era nessun rappresentante con cui parlare. Abbiamo dovuto A) ripercorrere il problema, e B) risolverlo prima di essere colpiti.
  • C'è debolezza nel controllo di qualità. L'open source è tutto basato sul contributo della comunità. Tuttavia, la prima legge degli umani è che gli umani sono stupidi e nessuna lingua è una prova stupida. Soprattutto PHP, che è quello in cui è stato scritto il software.

Come per tutte le politiche di sicurezza, devi essere consapevole del rischio e ridurre al minimo i rischi, laddove possibile. L'unico modo per ridurre il rischio a zero è scrivere su tavolette di cera a lume di candela.

    
risposta data 16.12.2015 - 16:57
fonte

Leggi altre domande sui tag

Perché le sessioni di app del telefono cellulare non sono mai scadute? Questo metodo di conferma della password rischia di compromettere l'integrità del file crittografato?