È un buon modo per gestire la risposta agli incidenti

Supponendo che questo sia il tuo processo completo, non un sottoinsieme in cui sono già state prese altre decisioni, suggerirei che il tuo primo punto decisionale non è se c'è o meno un'intrusione ma se c'è o meno un impatto sul business service.

Alert - > Controlla log - > Impatto del servizio aziendale?

Dopo aver determinato l'impatto del servizio aziendale, puoi utilizzarlo per guidare il resto della risposta all'incidente. Se il tuo servizio è influenzato, devi coinvolgere le persone giuste nel business (che dovrebbero già essere documentate) per notificare loro l'impatto, fornendo una prima panoramica del problema.

Impatto del servizio aziendale? - > Sì - > Notifica al responsabile degli incidenti aziendali

Una volta che l'attività è stata notificata, puoi passare alla determinazione della natura esatta del problema e al resto del flusso di processo.

Se non vi è alcun impatto sul servizio aziendale, continui comunque con la determinazione dei problemi.

Impatto del servizio aziendale - > No - > Intrusion?

Il mio prossimo punto sarebbe che, anche se l'evento non è un'intrusione, potrebbe ancora essere un evento di sicurezza che desideri (o hai bisogno) di eseguire azioni come risultato di.

Ad esempio, rilevi una forma di scansione automatica o manuale delle tue applicazioni web. Potresti decidere di voler bloccare l'indirizzo IP dell'utente malintenzionato. Questo è solo un semplice esempio.

Tale decisione potrebbe richiedere un'autorizzazione da parte di rappresentanti aziendali o tecnologici appropriati, quindi, di nuovo, gli accessi necessari all'azienda devono riflettersi nel flusso del processo.

In sintesi, i miei punti di feedback sono:

1. Non dimenticare che stai difendendo un'applicazione aziendale, assicurati che il tuo processo di risposta agli incidenti rispecchi le esigenze dell'azienda, non solo descrivendo dettagliatamente i passaggi tecnici richiesti.

2. Un'intrusione è ovviamente il caso peggiore ma non lo sconto delle azioni richieste per altri eventi relativi alla sicurezza. Potrebbe non essere solo una configurazione errata.

HTH !!

OSSIM ha OSSEC. OSSEC può essere utilizzato su interfacce di registrazione UDF mod-security, Wordpress e MySQL, oltre al monitoraggio dell'integrità dei file e alla gestione di syslog.

Non capisco la necessità o il desiderio di Splunk quando Novell Sentinel Log Manager 25 e Q1Labs QRadar Log Manager hanno opzioni liberamente scaricabili che sono migliori, oltre ad un sacco di altri progetti open-source che sono anche migliori (soprattutto per il prezzo). Sono d'accordo sul fatto che Splunk sia troppo costoso.

I principi sono semplici e lungo le linee che hai delineato.

1. Registrazione remota. Registrazione non ritardata, ma in tempo reale. rsyslog funziona alla grande. Come perfezionista, cerco di acquisire e inviare i log direttamente dal sorgente, non di accedere prima ai file e poi li ho prelevati da rsyslog - solo per evitare la possibilità di intercettazioni intermedie.
2. Includi il monitoraggio dell'integrità dei file. OSSEC è buono in questo settore, ma io uso il mio.
3. Analisi live. Uso MozDef (The Mozilla Defense Platform). OSSIM era troppo proprietario e troppo restrittivo (dopo un po 'sembrava che l'unico scopo di OSSIM fosse promuovere il prodotto a pagamento). Se sei il primo timer, prova l'immagine della finestra mobile. Per l'utilizzo in produzione, è necessario comprendere come i componenti si uniscono e creare una configurazione personalizzata per se stessi. Sarò felice di aiutarti se lo desideri.
4. Gestione della configurazione. Sì.
5. Ridistribuzione automatica. Attendi! Come funzione DevOps, questo è ottimo, ma tu vuoi essere super conservatore quando si tratta di IR. Qualsiasi automazione deve coprire molti scenari. Lo facciamo con semplici webserver, non ma altro. Questo perché scopriamo che nella vita reale quasi ogni scenario è diverso da ciò che avevamo immaginato e preparato (so che potrebbe anche significare che non stiamo immaginando / preparando abbastanza).
6. Remote forensics con acquisizione automatica. Molto bello da avere, anche se automatizzato o meno è discutibile. Ci sono troppi rischi lì, a meno che tu non abbia un ambiente strettamente controllato (non ne ho mai visti troppi). Preferiamo usare GRR / equivalente. La necessità di condurre indagini forensi è infrequente (la nostra esperienza). Per provare e configurare ogni endpoint (anche solo i server) sotto la tua cura, potrebbe essere un po 'esagerato, a meno che tu non stia gestendo asset di alto valore (banche / militari / ...). Quindi lo facciamo in modo selettivo.