Fidati del tuo strumento di risposta agli incidenti

Come rispondente di un incidente, vuoi sempre essere molto attento a quali supposizioni fai quando sei su un sistema. In questo senso, le tue domande sono abbastanza pertinenti.

Tuttavia, eserciti anche il tuo giudizio (in alcuni casi, forse erroneamente) su quanta cura sia richiesta in una particolare istanza. Ci sono dei limiti su cosa puoi fare con i sistemi ospitati da cloud pubblico. Cerchi di lavorare con quei limiti (come non essere in grado di fare il boot da un CD); e trovare soluzioni alternative dove possibile. ad es., se non hai bisogno di live forensics, puoi creare la tua "immagine di avvio attendibile con strumenti attendibili", avviare da quell'immagine, collegare i dischi in questione e investigare. Questo è praticamente lo stesso principio di portare i propri dischi di avvio (CD o unità USB). Lo faccio per impostazione predefinita solo quando lavoro su server altamente sensibili, in cui è probabile che gli avversari siano altamente qualificati.

In tutti gli altri casi prendo il percorso più efficiente / pragmatico - come suggerisce @ john-deters.

Le Live Forensics sono un po 'più sfuggenti. Nessun semplice how-to-go. È possibile montare un disco con i propri strumenti (in realtà, in molti casi lo si fa) ma che comporta i propri rischi.

Infine, se hai intenzione di installare strumenti IR remoti (come per esempio il GRR), puoi solo prendere delle precauzioni mentre installi gli strumenti. Come ulteriore precauzione, dovresti creare un avviso di integrità del file (hai bisogno di logging remoto per questo) per assicurarti che il pacchetto GRR non sia alterato in alcun modo. Se ciò non viene attivato, probabilmente sei (sì probabilmente, non certamente!) Su un terreno solido quando accedi per l'IR da remoto.

Nel mondo reale, non è pratico. Amazon non ti lascerà entrare nella porta del loro centro dati per inserire un CD in uno dei loro computer cloud. Ciò ha impedito l'esistenza di Amazon Web Services? Ciò ha impedito alle persone di creare molte aziende di successo nel cloud di Amazon? L'esistenza (e la redditività) di AWS suggerisce che sono abbastanza affidabili.

Invece, proviamo a installare gli agenti di sicurezza del software su macchine appena costruite, e facciamo affidamento sul fatto che nel frattempo non sono stati modificati malevoli. È un approccio pratico che copre la maggior parte della superficie di attacco.

Considera l'inverso: come faresti a sapere se il CD che userai per installare l'agente è un'immagine originale e non un falso intelligente che contiene un kit di root? Come sai che il server non ha un chip dannoso creato da una fonderia inaffidabile e installato da un fornitore di schede madri senza scrupoli? Come sai che qualche oscuro aggressore non ha installato una scheda COTTONMOUTH-III nella torre USB della macchina mentre era seduto in attesa di cancellare la dogana? Ad un certo punto, devi lasciarti andare e esercitare una certa fiducia. Il trucco è non lasciare mai che l'incapacità di raggiungere la perfezione assoluta ti impedisca di raggiungere uno stato che è "abbastanza buono". Sì, c'è sempre un vuoto, un buco nel processo, qualcosa che potrebbe essere sfruttato dalla persona giusta al momento giusto. Riduci al minimo le lacune, certo, ma sappi che stanno per esistere indipendentemente da ciò che fai.

Un approccio più razionale consiste nell'eseguire una valutazione del rischio e un'analisi del rischio. Hai un budget limitato per la sicurezza - lo fanno tutti. Vuoi spendere tutto per portare i CD sui tuoi server con la minima possibilità che sia già infestato da un rootkit di cui non sei completamente all'oscuro? O sarebbe più sensato spenderlo su una minaccia più immediata o su un problema urgente, come implementare un sistema di rilevamento e risposta alle intrusioni di rete, o addestrare gli utenti a riconoscere gli attacchi di phishing o controllare la configurazione TLS?

Innanzitutto innanzi tutto ai problemi realistici.