Cosa considerare in uno SLA per garantire software sicuro quando si esternalizza lo sviluppo di software?

Come ha detto @Lucas, un avvocato dovrebbe essere il tuo primo punto di riferimento, tuttavia da un alto livello posso dare alcune indicazioni sulle aree da osservare - questi sono un piccolo sottoinsieme:

• In che modo l'organizzazione mette alla prova la propria sicurezza?
• Usano tester approvati, team interni o entrambi?
• Avrai il diritto di controllare utilizzando il tuo personale o consulenti?
• Come gestiscono incidenti, vulnerabilità ed eccezioni?
• Avrai visibilità degli incidenti, delle vulnerabilità e delle eccezioni durante il ciclo di vita dello sviluppo?
• Usano un framework come OpenSAMM ?
• Quali responsabilità mantengono dopo la consegna?
• Con quale rapidità possono rispondere agli avvisi, da parte tua, di un CERT o di un venditore?
• Hanno un accordo di garanzia in caso di collasso finanziario?
• Chi sarà il proprietario del codice? Potrebbe finire per essere pubblicato senza la tua approvazione?
• In che modo schermano o controllano i loro dipendenti prima del loro impiego?
• Entro quale giurisdizione operano?

E così via ...

Ottieni un avvocato che conosca questa roba!

Ottima domanda. Affrontare tempestivamente problemi di sicurezza - quando si trova un appaltatore, si scrive un contratto, durante la definizione dei requisiti e quando si definisce l'architettura - alla fine ridurrà i costi di produzione di software sicuro per gli sviluppatori e ridurrà i rischi ei costi associati per i clienti. Win-win.

Esiste un ottimo scenario di come le cose possano andare male a Appoggio di casi ipotetici di software sicuro - OWASP .

Suggerisco di consultare l' allegato del contratto software sicuro OWASP come punto di partenza per il tipo di lingua che desideri inserire il contratto. Quella pagina inizia con una rapida FAQ che parla di domande spinose come "Ma chi dovrebbe pagare tutte queste attività?" e come gestire il codice di terze parti. Se il tuo ambiente di minaccia non è grave e le tue esigenze non sono così rigide, puoi rilassarne alcune. Oppure, se hai a che fare con beni davvero preziosi e le minacce sono grandi, puoi estenderle.

Copre queste aree:

1. Introduction
2. Philosophy
3. Lifecycle Activities
4. Security Requirement Areas
5. Personnel And Organization
6. Development Environment
7. Libraries, Frameworks, And Products
8. Security Reviews
9. Security Issue Management
10. Assurance
11. Security Acceptance And Maintenance

Altrimenti tu e il tuo appaltatore potreste finire a spendere molti soldi per gli avvocati che discutono l'applicazione legale di res ipsa loquitur .

IANAL, ma sulla base della mia esperienza in Y2K, dove con il software che ho curato ci sono un numero enorme di problemi, c'è poco spazio nella pratica per la restituzione dei problemi - il miglior risultato per il cliente è risolvendo i problemi con il piena collaborazione del fornitore. Gli unici che staranno meglio in queste dispute sono gli avvocati.

Ciò significa in questo contesto che i problemi di sicurezza sono meglio affrontati nella selezione di un fornitore, che dovrebbe essere ribadito nel contratto. Tuttavia, l'esistenza di requisiti nel contratto non riduce in alcun modo l'obbligo di garantire la conformità al contratto prima e durante lo sviluppo del servizio - in attesa fino a dopo la distribuzione del servizio prima di scoprire che il provider non aveva il codice i controlli di auditing in atto rendono la colpa a mio parere, anche se il fornitore sarebbe in violazione del contratto.

Tuttavia, con la migliore volontà del mondo, le vulnerabilità possono ancora essere introdotte nel codice, per sbaglio o in base alla progettazione, quindi vale sicuramente la pena pianificare in termini di inversione di tendenza, definizione dell'ambito di responsabilità e garanzia che il fornitore essere in grado di effettuare la restituzione in caso di colpevolezza. Poiché i potenziali costi derivanti dalla vulnerabilità del software possono superare in modo massivo il costo del software stesso, non è possibile (ad es.) Utilizzare l'impegno.

In effetti, se si esamina l'articolo, i punti relativi alla sicurezza (ad eccezione dei riferimenti a una legislazione specifica) si applicano a tutte le funzionalità del servizio.

A rischio di avventurarsi fuori tema, IMHO la soluzione migliore è gestire il controllo e il testing del codice (per tutti gli aspetti della qualità) indipendentemente dal provider, anche se semplicemente replichi quello che dicono che stanno già facendo.

Andando oltre, la sicurezza del servizio significa anche la continua disponibilità. Sia questo sia il punto sollevato nel paragrafo precedente mostrano chiaramente l'obbligo di accedere al codice sorgente dell'applicazione. Mentre l'impegno finanziario ha molti vantaggi, IMHO, l'impegno del codice sorgente, in pratica, non è nell'interesse del cliente. NB che la proprietà della proprietà intellettuale non dipende dall'accesso al codice sorgente e, specificatamente, fornendo al client l'accesso al codice sorgente in alcun modo erode le responsabilità del cliente né i diritti IP del fornitore.

Tuttavia ci sono significativi vantaggi per il cliente nel possedere il copyright rispetto al codice sviluppato, e laddove vi è una certa garanzia della qualità fornisce un'utile posizione contrattuale per compensare la responsabilità futura dello sviluppatore.