Rivelare per primi le vulnerabilità di sicurezza ai clienti paganti

8

Caso particolare

Un venditore (senza nome) di un prodotto open source vende anche licenze commerciali e supporto. Uno dei vantaggi dell'affare commerciale è che ti viene notificata immediatamente la vulnerabilità della sicurezza (anche prima che sia stata rilasciata una versione ufficiale) e l'accesso a una build di sicurezza pre-release che includa le correzioni. Include anche l'accesso a versioni di versioni precedenti con correzioni di sicurezza applicate.
In altre parole, gli utenti privi di tale supporto commerciale vengono avvisati solo dopo che è stata rilasciata una versione, quando i clienti paganti conoscono già la vulnerabilità da un po 'di tempo. Sebbene abbiano accesso alle versioni originali (vulnerabili), non hanno accesso alle stesse build di sicurezza (pre-release o backport) (ma sono open source, quindi possono accedere al codice sorgente e crearle da soli).

Ho alcuni seri dubbi su questo approccio. Per me sembra esporre gran parte della base di utenti a rischi inutili.

Domanda generale

Questo tipo di divulgazione è spesso applicato; ci sono altre società (open source) che forniscono in anticipo dettagli sulla vulnerabilità a un ampio gruppo di clienti commerciali? O sta fornendo queste informazioni a tutte le parti interessate contemporaneamente a deve e questo sarebbe generalmente considerato un comportamento irresponsabile?

    
posta Wouter Coekaerts 14.09.2011 - 20:18
fonte

3 risposte

6

È facile dire che questo comportamento è sbagliato. Ma penso che valga la pena dare un'occhiata più dettagliata.

Le problematiche di sicurezza sono una situazione abbastanza difficile per molte aziende che hanno deciso di open source (alcuni dei) programmi, pur mantenendo una versione commerciale. Questo peggiora se una correzione non può essere creata immediatamente.

Motivazione per informare prima i clienti paganti

L'azienda ovviamente dipende dai suoi clienti paganti per sopravvivere come qualsiasi altra azienda. Quindi devono fornire un valore aggiunto a quei clienti.

È probabile che le grandi aziende pagheranno i clienti mentre le piccole imprese e le persone indipendenti tenderanno a utilizzare la versione gratuita. Quelle grandi aziende hanno più probabilità di essere l'obiettivo di un attacco. E in caso di attacco riuscito, è più probabile che saranno sottoposti a una cattiva copertura della stampa.

Inoltre c'è un rischio più elevato che l'avviso di pubblica sicurezza senza una correzione attiri l'attenzione di persone con intenti malevoli. Solo perché il numero di persone è più grande di un paio di ordini di grandezza.

Questo è particolarmente vero se quasi tutti gli utenti seri pagano i clienti. In altre parole: la versione open source è fondamentalmente una demo per quella commerciale.

Motivazione per l'emissione di un avviso di sicurezza combinato

Dopo che la società ha emesso un avviso pubblico, può affermare che non è più responsabile per eventuali danni causati in seguito. Se gli utenti non hanno preso misure contrarie come installare la correzione, sarà colpa loro.

Fornire informazioni in anticipo ai clienti paganti può consentire a qualcuno di loro di usare quella conoscenza per il male. A seconda della legislazione, potrebbe costituire una minaccia legale per l'azienda che non ha avvisato tutti gli utenti, anche se ovviamente era a conoscenza del problema.

Dal punto di vista dell'utente

Dopo aver parlato della motivazione dell'azienda, diamo un'occhiata al lato utente. Penso che sia abbastanza ovvio che i clienti paganti apprezzeranno questo come servizio.

Gli utenti della versione open source sono soggetti a un rischio aggiuntivo e pertanto devono prestare molta attenzione nell'utilizzo di tale software in un ambiente di produzione o con dati sensibili.

In che modo il progetto open source Arianne non commerciale tratta problemi di sicurezza?

Mi piacerebbe concludere con qualche esperienza personale. Arianne è un progetto open source che consiste in una struttura di gioco online e in un gioco di ruolo online 2D chiamato Stendhal. Non è commerciale e non guadagna nulla.

Ci sono molte persone là fuori che gestiscono i server Stendhal poiché è completamente open source (client, server, grafica, tutto). Eseguiamo una istanza di Stendhal da soli.

Quando scopriamo un problema di sicurezza in Stendhal abbiamo finito con questo processo:

  • Condividiamo le informazioni tra gli sviluppatori principali fidati, ne discutiamo e lavoriamo insieme per trovare la causa principale.
  • Risolviamo il problema e commettiamo la modifica al CVS pubblico. Altri sviluppatori principali esaminano la correzione e la testano da soli.
  • Prendiamo la correzione dal vivo sul nostro server.
  • Prepariamo una versione di bugfix basata sull'ultima versione stabile. Nel frattempo altri sviluppatori di core eseguono altri test. I giocatori normali continuano a giocare e quindi testano implicitamente gli effetti collaterali.
  • Facciamo una versione secondaria dell'ultima versione stabile insieme a una patch del codice sorgente e pubblichiamo un annuncio che descrive il problema.

L'intero processo dura da 1 a 2 ore.

Non rilasciamo correzioni di bug per versioni precedenti perché prestiamo molta attenzione a rendere gli aggiornamenti tra le versioni molto facili da installare. L'unica ragione per cui qualcuno non può saltare all'ultima versione è che ha apportato modifiche al codice stesso. Per quelle persone forniamo la patch del codice sorgente.

Posso vedere che qualcuno potrebbe obiettare che aggiornare il nostro server prima sia malvagio, così come sta commettendo la correzione al CVS pubblico prima dell'annuncio. Ma questo è il modo più efficace per ottenere una correzione di alta qualità nel più breve tempo possibile. Abbiamo bisogno del breve test su un server live perché la gente si aspetta davvero che possa installare gli aggiornamenti di sicurezza alla cieca senza dover temere gli effetti collaterali.

    
risposta data 14.09.2011 - 21:43
fonte
3

Normalmente aspetterò fino a quando non avrò il tempo di scrivere una risposta ben formata o qualcuno mi picchierà, ma visto i downvotes:

Non è un modello di business raro nei mondi open source o closed source fornire supporto avanzato o correzioni di sicurezza precedenti a clienti paganti o premium. In alcuni casi, questi sono i clienti più vulnerabili. L'obiettivo è da qualche parte su una scala mobile tra l'assegnazione di più target di alto valore possibile prima di rendere noto un exploit (o fornire una patch che di solito rende facile l'individuazione) e fare qualche dollaro in più lungo la strada.

L'etica di questo non è stata davvero decisa come un'industria, ma come puoi immaginare ci sono molte persone che sono scontenti di questa idea.

    
risposta data 14.09.2011 - 21:38
fonte
3

Sembra essere malvagio, ma vorrei andare con l'altro punto di vista:

Quando un software diventa open source, chiunque può revisionarlo, modificarlo, creare patch / diff, rendere queste patch disponibili nel suo sito, ecc.

Qualcuno decide di fornirgli un supporto: "Controllerò se questo software è abbastanza sicuro, se trovo qualcosa, ti mando subito le correzioni, poi, dopo avertelo avvertito, darò la correzione a chiunque. Devi solo pagarmi in cambio ".

Che si tratti di uno sviluppatore o meno, è la proposta che viene fatta tra due società.

Lo sviluppatore sta creando bug nel soft in modo che possa vendere la soluzione? Se è così, allora sì, sono cattivi e dovrebbero essere citati in giudizio. No, stanno giocando bene? Stanno dando a tutti il soft, il supporto contro i bug (dopo qualche ritardo) e le persone si lamentano di non essere trattati allo stesso modo di quelli paganti? Non so, penso che ci sia troppa responsabilità su di loro. Non ti impediscono di riparare il software da solo.

    
risposta data 14.09.2011 - 22:34
fonte

Leggi altre domande sui tag