È ragionevole fare un pentest (o altro controllo di sicurezza non teorico) su un'infrastruttura critica?

In qualsiasi test che si occupa di sistemi critici, in genere si limiterà il test a operazioni a basso rischio e si eviteranno strumenti automatici (ad esempio Nessus) che potrebbero potenzialmente danneggiare il sistema.

Specifico per l'infrastruttura critica, direi quanto segue:

• Pianifica il test a un basso punto di domanda, dove applicabile.
• Rendi consapevoli del test i tecnici e gli altri addetti all'assistenza e assicurati che siano pronti a risolvere rapidamente eventuali problemi.
• Assicurati che durante il test sia pianificata una maggiore capacità / ridondanza.
• Assicurarsi che ai tester venga fornito un piano d'azione appropriato che specifichi come gestire guasti gravi o sistemi non responsivi. Questo dovrebbe includere i contatti di emergenza.

Nonostante ciò, ci sarà sempre un rischio. È qualcosa che devi affrontare, e in un certo senso è una buona cosa. Se i tester mettono fuori linea qualcosa eseguendo solo azioni a basso rischio, allora sai che un attaccante potrebbe fare molto peggio. Un crash accidentale del sistema durante un test pianificato potrebbe far schifo, ma non tanto quanto un arresto anomalo a causa della malizia quando nessuno se lo aspetta. Se si scende nello scenario di test, è possibile pianificare di conseguenza e apportare le correzioni appropriate.

Bene, no, non è "ragionevole" fare test potenzialmente distruttivi su un'infrastruttura critica. Questo è per definizione: l'infrastruttura critica è critica .

Facciamo matematica (la matematica è bella). Un test di penetrazione ha alcune probabilità (auspicabilmente piccole) p ₁ di interrompere il servizio su cui è applicato. Ha anche probabilità p ₂ per consentire il rilevamento e la correzione di un problema che avrebbe avuto probabilità p ₃ da sfruttare, portando a un'interruzione del servizio. Quindi la probabilità di interruzione quando si applica il test di penetrazione è p ₁ + (1 - p ₂ ) · p ₃ (o il pentest rompe le cose subito o "manca" il buco e l'attaccante ha comunque successo). Se quel valore è maggiore di p ₃ , allora il pentest sul live, sistema critico fa più male che bene e non deve essere eseguito.

In generale, questa è tutta la analisi dei rischi : devi bilanciare i rischi legati al fare il pentito, con i rischi coinvolti con non a fare il pentest. Contrariamente a quanto le mie poche annotazioni matematiche di cui sopra sembrano implicare, le probabilità rilevanti non possono essere conosciute con una precisione decente, quindi alla fine è tutto congetture. Ciò che davvero deve essere ricordato è che esiste una serie relativamente ampia di possibili strategie:

• Puoi fare il pentest sul sistema critico dal vivo.
• Puoi pagare per la configurazione di un clone del sistema live, che sarà identico al sistema live che può essere raggiunto fisicamente, e fare il pentest su quel sistema.
• Puoi fare la maggior parte del pentest su una cruda emulazione del sistema live, e lavorare con il pentestore per classificare le azioni più potenti: per alcuni, il sistema live può comportarsi come l'emulazione, per altri no. Questo potrebbe già rivelare cose interessanti.
• Puoi anche non fare nulla. Il rischio potrebbe tuttavia essere trasferibile con un meccanismo assicurativo (a seconda del contesto, gli affari sono facilmente trasferibili, le vite umane sono più difficili).

Un altro punto da considerare è che gli attacchi sono solo un tipo di rischio. Hai altri tipi, ad es. inondazioni, terremoti e incendi, che possono comunque distruggere la maggior parte delle "infrastrutture critiche", e devi anche tenerne conto. Un modo tipico per gestire le inondazioni consiste nell'avere un'infrastruttura di backup da qualche parte (un "sito freddo", "sito caldo" o "sito caldo", a seconda di quanto è stata completata in anticipo l'installazione di quel sito). In alcuni casi, questo sito di backup può essere utilizzato per pentests privi di rischio.

Converti gli host in guest VM e poi portali fuori sede per metterli alla prova altrove. Raccogli i campioni del firmware ed eseguili con Qemu. Richiedi alcuni dispositivi DCS, PLC, RTU o smart meter che possono essere forzati al prepensionamento per scopi di laboratorio.