Sistemi paralleli, nel caso in cui uno dei due abbia exploit noti

Mentre la maggior parte degli oggetti è già stata raccolta e discussa da dr jimbob in sua risposta , vorrei attirare la vostra attenzione su quanto segue:

1. Questo tipo di problema è chiamato "errore in modalità comune".

2. Nancy G. Leveson ha studiato i guasti in modalità comune e la presunta soluzione di software ridondante (stack software, come lei descrive) e ha notato che la comunanza potrebbe andare molto più in profondità del previsto. Ad esempio, entrambi i sistemi potrebbero condividere un'implementazione di alcuni protocolli, il che significa che tu verrai disinformato se ci sarà un vuln seduto da qualche parte all'interno. Lo stesso sviluppatore potrebbe essere stato assunto dalle due società, oppure i programmatori erano troppo pigri e privi di fantasia per inventare il proprio algoritmo e semplicemente scelto lo stesso algoritmo da una fonte pubblicamente disponibile. Non c'è davvero alcun limite a tali elementi comuni e non è possibile escluderne nessuno senza un approfondito esame del codice.

3. Avere entrambi gli stack online significa che un avversario dotato e pieno di risorse sarà in grado di entrare in entrambi e possibilmente sovvertire il meccanismo di commutazione.

4. Avere uno stack caldo e uno freddo significa che lo stack freddo deve essere aggiornato con tutte le patch di sicurezza (quindi, non è completamente freddo , anche se gli aggiornamenti sono fatti dietro il traferro, e non fornisce una disponibilità totale).

5. Il più grande svantaggio del tuo schema è l'esistenza di una comunanza fondamentale: entrambi i sistemi sono implementati nel software . Se vuoi davvero difendere in profondità contro una minaccia avanzata, crea un sistema separato e semplificato che non si basa su reti sofisticate . Semplice vecchia telefonia (anche telefonia audio-assistita ) e gli operatori umani sono molto utili proprio per questo scopo.

Questo sembra un po 'controproducente. È molto più lavoro mantenere un sistema ridondante, costruito su uno stack software completamente diverso e mantenere i dati sincronizzati tra i due sistemi molto diversi. Più che raddoppia il lavoro necessario (mantenere due sistemi raddoppia il lavoro e quindi mantenerli sincronizzati e coerenti). L'esperienza richiesta sarà diversa su stack molto diversi, quindi probabilmente dovrai avere un intero nuovo staff e gestire tutti i overhead delle intercomunicazioni di gruppo .

Raddoppia anche l'esposizione potenziale. Invece di essere vulnerabili agli attacchi dello zero-day nello stack che hai scelto, i tuoi dati sono vulnerabili a essere rubati se uno degli stack ha buchi da zero in loro ogni volta che lo stack è operativo. (Questo non sarebbe il caso se uno stack è sempre offline dal mondo esterno fino a quando necessario).

Certo, nei casi in cui il downtime è completamente inaccettabile una soluzione del genere può avere un senso, dove si dispone di uno stack standard con tutte le caratteristiche fantasiose e uno stack di emergenza in qualche caso semplificato in cui si passa se c'è un problema con i tuoi sistemi principali o stanno subendo un aggiornamento importante.

Non ho mai sentito nessuno che stia facendo esattamente il tuo approccio. Quando si considerano le vulnerabilità zero day, questo non aiuta molto, poiché non si ha idea di quali giorni zero esistano in ogni stack. Potrebbe potenzialmente raddoppiare la tua esposizione, poiché un attaccante con un giorno zero nello stack B potrebbe aspettare finché non passi da A a B e poi ti attacca.

Tuttavia, un principio in qualche modo simile è ampiamente seguito. Un design di rete comune è "internet - firewall - dmz - firewall - rete interna". In tali progetti, alcuni esperti di sicurezza sostengono l'uso di firewall di due diversi fornitori. La teoria è che se esiste una vulnerabilità in un firewall di un fornitore, non esiste nell'altro, quindi non sarà possibile per un utente malintenzionato accedere da Internet alla rete interna.

In realtà, questo era un consiglio standard, ma ora è stato screditato. Il problema è che la rete interna è maggiormente a rischio da attacchi basati su browser sulle workstation e l'utilizzo di due firewall diversi non fa assolutamente nulla per risolverlo. Inoltre, è emerso che i firewall sembrano essere una scommessa abbastanza sicura: sono state scoperte poche vulnerabilità gravi.

Al giorno d'oggi è più comune disporre di un singolo firewall con più connessioni per DMZ, reti interne, ecc. In realtà, tale accordo è preferibile perché rende più economico e facile impostare segmenti di rete isolati, e questo ha maggiori vantaggi per la sicurezza rispetto all'utilizzo di più fornitori di firewall.