Risponditori degli incidenti: puoi fornire alcuni esempi di incidenti / tipi di incidenti che sono adatti per una risposta completamente o parzialmente automatizzata? [chiuso]

3

Configura il monitoraggio della sicurezza: un SIEM / SOC commerciale completo o qualcosa di casalingo (ad es., rsyslog - > OSSIM / MozDef / Splunk / ...). È inoltre possibile impostare alcune regole in modo che venga eseguita una valutazione di alcuni eventi e vengono visualizzati solo gli avvisi per potenziali incidenti.

Mi piacerebbe sapere quale automazione viene svolta oltre questo punto. Non solo più avvisi / invio di e-mail o rapporti, ma qualcosa che tenta di risolvere l'incidente stesso.

Alcuni casi d'uso e alcuni esempi di soluzioni di automazione (standard o fai-da-te) sarebbero utili.

    
posta Sas3 16.06.2017 - 18:35
fonte

2 risposte

3

In cima alla mia testa non direi nulla. Il punto di un SoC / SIEM è quello di portare le cose all'attenzione di un analista umano al fine di valutare l'incidente e decidere su quali azioni fare dopo. Qualsiasi cosa tu non voglia che un essere umano abbia gli "occhi aperti" dovrebbe essere regolata dal set di regole SIEM.

Potrebbero esserci alcune cose a basso rischio che si desidera automatizzare, ad esempio ogni volta che viene rilevato un AV con il malware messo in quarantena o eliminato viene emesso un ticket in modo che la casella venga riesaminata mentre l'analista esegue l'indagine iniziale, ma in genere questo non sarebbe fatto dal SIEM. (Anche se alcuni SIEM avranno questa capacità e alcuni SoC useranno un SIEM per farlo.)

Un SoC maturo di solito ha un playbook per gli avvisi comuni che non sono stati eliminati. Ad esempio, se x accade, allora a , b , c , quindi passa a un analista di livello due per ulteriori indagine. Si tratta di una procedura operativa standard piuttosto che dell'automazione.

    
risposta data 19.06.2017 - 09:14
fonte
3

Le risposte attive come l'eliminazione e l'ignoranza delle richieste sono l'unico tipo di risposta automatica in cui mi sono impegnato.

Qualsiasi IPS commerciale o Web Application Firewall fa questo. Anche HIDS / HIPS possono essere considerati, per implementazioni estremamente ridotte.

Le semplici regole WAF potrebbero bloccare l'attaccante per un tempo limitato se:

  • Se l'User-Agent è wget o curl o simile automazione
  • Se qualcuno tenta un exploit noto, specifico e ben definito
  • Se qualcuno prova una categoria di exploit ben definita: directory traversal, SQL injection,

Il WAF può essere sintonizzato per includere blocchi per cose come:

  • richieste di pagine che indicano una tecnologia che non hai (ad es. aspx)
  • richieste di pagine amministrative comuni /admin.php

Gli IPS possono anche farlo ma sono meno precisi nelle loro firme poiché tendono a non fornire informazioni sul protocollo http, ma invece su pacchetti non elaborati. Ciò fornisce loro alcune abilità extra come il rilevamento di attacchi sul WAF o sul proxy stesso o attacchi non HTTP / HTTP.

Questo tipo di risposte sono normalmente limitate a firme ad alta sicurezza. I venditori commerciali tendono a includere i fattori di fiducia nelle loro informazioni sulla firma e consentono di limitare i blocchi di conseguenza.

Snort, McAfee Intrushield, IBM SiteProtector sono IPS a cui mi sono abituato. ASM di F5 che ho usato per le risposte WAF. fail2ban, OSSSEC, sul lato HIDS.

link

link

I blocchi automatizzati vengono esaminati quotidianamente e monitorati in tempo reale. Il rischio di una firma che incide sulla produzione è molto reale. Le firme vengono distribuite su un ciclo Dev / Stage / Prod in modo che le nuove firme non raggiungano la produzione senza un ciclo completo di test.

    
risposta data 19.06.2017 - 11:22
fonte

Leggi altre domande sui tag