Quali considerazioni sulla sicurezza dovrei fare quando pianifichi di fare una risposta agli incidenti nel mio ambiente cloud pubblico ibrido?

0

Sto tentando di compilare un elenco di aree di cui tenere conto quando si esegue la risposta agli incidenti in ambienti cloud pubblici, ad es. un cloud pubblico ibrido, in cui alcuni servizi vengono forniti nel data center locale, mentre è nel cloud.

Alcuni pensieri:

  • Tirare la RAM per fare memoria forense sarà difficile, se non impossibile, da fare su un servizio SAAS, PAAS o simile.
  • L'accesso fisico ai dispositivi sarà nella maggior parte dei casi impossibile. Se devi procurarti il disco fisico che ha archiviato materiale illegale, probabilmente sei sfortunato.
  • Il servizio che stai utilizzando potrebbe essere limitato, modificato o in altri modi diverso da quello che stai normalmente utilizzando. Per esempio. SQL di Azure come servizio, non hai un database completo a cui sei abituato. Pianificare per questo.

Alcune preoccupazioni che non sono direttamente influenzate da Incident Handling, ma la mia causa è che succeda:

  • Isolamento vs. multi-tenancy. In qualche modo, condividerai le risorse. Il tuo servizio cloud potrebbe avere altri client che lo rovinano per i tuoi sistemi.
  • Quanto sopra può valere anche per la sicurezza. Compromissione di un client SAAS, potrebbe portare a compromessi di altri se il venditore non è configurato correttamente.
  • VM Escape è una possibilità temuta. Un compromesso nell'hypervisor sottostante potrebbe compromettere tutti gli host.
  • Se non hai familiarità con le ACL del servizio cloud, potresti esporre in modo non sospetto i servizi su Internet aperto, che altrimenti ritenevi essere solo interno.
  • Il fornitore di servizi cloud potrebbe non essere tanto disinvolto quanto te quando si tratta di limitare l'accesso fisico. #BadUSB
  • I tuoi dati potrebbero essere suscettibili di e-discovery, anche se non hai avuto nulla a che fare con l'incidente.

Qualcuno ha altri pensieri o dubbi su come un cloud pubblico può avere un impatto sulla gestione degli incidenti? Preferibilmente, potremmo tenere a mente anche le 6 fasi:

  • Preparazione
  • Identificazione / Analisi
  • Il contenimento
  • Eradicazione
  • Recupero
  • Lezione appresa
posta Chris Dale 07.04.2015 - 21:10
fonte

1 risposta

1

Molto di questo si riduce alla partnership, all'identificazione delle responsabilità e alla comunicazione tra te e il cloud Service Provider (CSP)

Preparazione

Identificare chi è responsabile del monitoraggio delle attività sospette. Acquisisci registri, monitora e rivedi registri e avvisi? Il CSP?

Identificazione / Analisi

Se sospetti di un incidente, sai con chi parlare al CSP? Se il CSP sospetta un incidente, ti contatteranno? In tal caso, è questo standard o un percorso di escalation? cioè sei informato tempestivamente o troppo tardi?

Il contenimento

Hai gli strumenti per farlo? Sai quali risorse stai condividendo con gli altri? Come offerta cloud ibrida, hai altre strutture, ambienti su cui puoi fare affidamento? Come si identifica l'infezione e la sua propagazione? Chi informa? Devi dire al CSP prima di contenere il problema? Devono agire per tuo conto?

L'eradicazione

Hai risorse da sradicare quando anche contengono? Puoi confermare l'eradicazione? Il CSP può confermare o garantire lo stesso?

Recupero

Hai dei backup, immagini pulite? Hai bisogno di risincronizzarti con altri ambienti? Avete meccanismi per raggiungere questo obiettivo e verificare l'integrità dei vostri sistemi, applicazioni, dati una volta completati?

Lezioni apprese

Se succede di nuovo, puoi ridurre tutto il carico di lavoro sopra? In base a come è stata gestita la situazione, dovresti dare più o meno responsabilità al CSP? Puoi migliorare la comunicazione e la trasparenza delle attività? È possibile modificare i problemi identificati che richiedono modifiche o identificare le alternative?

    
risposta data 07.04.2015 - 21:25
fonte

Leggi altre domande sui tag