In nessun ordine particolare e in cima alla mia testa:
Singolo fornitore:
- relazioni più facili e veloci
- (di solito) migliore integrazione di diversi prodotti, a condizione che non siano kit di rebranding
- più semplice da "passare la mano" se i prodotti A e B non si vedono, sono entrambi della stessa responsabilità del venditore.
Fornitori multipli:
- minor rischio di blocco del fornitore
- maggiore concorrenza, quindi possibilità di prezzi inferiori
- più difficile tenere traccia delle licenze e dei contatti
- rischio di duplicazione del lavoro tra diversi prodotti (l'azienda A ha un prodotto che esegue 1, 2, 3, l'azienda B ha un altro 3, 4, 5. L'attività 3 può in alcuni casi (ad esempio l'antivirus) portare anche a conflitti) .
- maggiori possibilità di un preciso adattamento di ciascun prodotto alle tue esigenze
Come vedi, la soluzione a più fornitori sembra avere più "svantaggi" - ma questi punti non dovrebbero essere semplicemente contati, dovrebbero essere ponderati in ogni situazione specifica. Inoltre, la maggior parte dei punti sono ipotetici, sono rischi o opportunità e se si verificano o meno dipendono dal / dai venditore / i e dalla situazione.
Credo che nessuna delle due opzioni possa essere raccomandata a priori .
Le ore uomo e i costi di manutenzione sono più o meno proporzionali al numero di venditori, a parità di altre condizioni, ma i risparmi (in termini di prezzo, risorse, manutenzione e produttività) sono in percentuale, e quindi proporzionali al numero di installazioni e dimensioni dell'azienda.
In una grande azienda, con forza lavoro e procedure da sfruttare, e un budget più grande, probabilmente l'opzione di più fornitori ha la possibilità di essere migliore. Un'impresa più piccola, forse senza un vero ruolo dedicato alla sicurezza, probabilmente troverà più conveniente negoziare una singola offerta e dimenticarsene fino alla valutazione del prossimo anno.
Da un punto di vista della sicurezza, credo che ciò che conta davvero sia l'ecosistema del prodotto: quali prodotti sono realmente di un determinato fornitore (anziché i prodotti rimarchiati e, forse, mantenuti solo dagli equipaggi scheletrici che sopravvissuto all'acquisizione della società originaria), come sono supportati e l'impegno del fornitore verso questi prodotti: il migliore di tutti sarebbe ovviamente una società che garantisce un strong supporto a tutti i suoi prodotti, non solo "ammiraglia" o "sviluppati-qui".
Nella mia esperienza, i prodotti "acquisiti" sono paragonabili all'originale per la prima versione, peggio per la prossima release (s) (quando la società acquirente cerca di calzare il prodotto nella sua forma, ad esempio cambiando l'interfaccia utente o spostare i file di configurazione in XML e così via), quindi migliorare costantemente (o essere abbandonati) mentre i team di programmazione si mettono in azione.
Ciò che fa davvero la differenza (ma questa è la mia esperienza limitata) è quanto tempo (e budget) puoi dedicare a following dei prodotti - controllare gli aggiornamenti, gli avvisi di sicurezza, navigare nei forum, e magari fai qualche prova da solo. Quanto il fornitore spedisce un prodotto perché ritiene nel prodotto, invece di tenerlo attivo in modo che possa fare una "offerta completa".
Di solito, controllare le pagine dei contatti e controllare il prodotto e la cronologia degli aggiornamenti è sufficiente per valutare il livello di impegno di cui gode il prodotto.
Di solito c'è una discussione sulla "biodiversità" nei prodotti di sicurezza, che più o meno si riduce a:
- diversi prodotti dello stesso fornitore e codice base potrebbero condividere le stesse vulnerabilità.
- diversi prodotti possono avere una "sovrapposizione di sicurezza" in modo che ciò che non è protetto da uno, sarà intercettato dall'altro.
Credo che entrambi i punti siano vicini al punto (tranne se discendono dall'atteggiamento del venditore del venditore, se vuoi):
- molti prodotti che condividono il codice comune avranno quel codice testato più duro, più lungo e migliore e i bug in esso contenuti verranno risolti una volta per tutte. Mentre diverse implementazioni di uno stesso algoritmo, condividendo una vulnerabilità concettuale , probabilmente porteranno a correzioni scaglionate e diverse finestre di vulnerabilità.
- due prodotti che hanno una "sovrapposizione" sono la stessa cosa dei prodotti in conflitto o della duplicazione dello sforzo . Se voglio sovrapporre, di proposito acquisto due prodotti in modo da poter controllare la sovrapposizione - invece di affidarmi a una duplicazione casuale, la cui estensione potrebbe non essere completamente nota (perché due prodotti dello stesso fornitore hanno due focus diversi: la sovrapposizione quindi sarà probabilmente nell'area "visione periferica" di entrambi. Se è qualcosa che viene gratis, un extra , posso godermelo, ma contare su di esso? Ripensaci).
Anche in questo caso, questi fattori devono essere valutati dal punto di vista del fornitore e considerati alla luce della politica, del budget e delle esigenze della tua azienda.