Server Infezione: best practice post-pulizia

7

Ho letto Come faccio a gestire un server compromesso? e hanno seguito i passaggi per ripulire / mitigare eventuali danni futuri.

Mi sto solo chiedendo se ci sono dei passaggi post-pulizia che sono considerati "best practice", come ad esempio:

  1. Informare i clienti dell'infezione e ripulire
  2. invio delle shell / file infetti a qualsiasi azienda di sicurezza
  3. riportare i dettagli dell'exploit utilizzato per qualsiasi società di sicurezza
  4. indagine / segnalazione di un indirizzo IP di attacco

Non sono sicuro che nessuna di queste informazioni possa essergli utile o meno, quindi attualmente sto registrando meticolosamente la documentazione.

    
posta Artsen 22.04.2014 - 18:47
fonte

3 risposte

2

Questa domanda potrebbe essere altamente motivata in termini di "migliori pratiche".

Tuttavia, potrebbero esserci alcuni requisiti di settore / contrattuali o legali per la notifica dei clienti o l'indagine forense. Per ottenere la risposta ottimale, dovrai chiedere assistenza per un consulente legale specifico per un determinato incidente. In senso generale, dovresti fare ciò che è giusto e nel migliore interesse dei tuoi clienti / utenti, ma se stai gestendo un'attività, dovresti bilanciarlo con il tuo desiderio di avere un la preoccupazione .

Un buon punto di partenza generale sarebbe con NIST SP 800-61: "Computer Guida alla gestione degli incidenti di sicurezza ". Puoi anche vedere SP 800-86: "Guida all'integrazione delle tecniche forensi nella risposta agli incidenti ".

Ci sono anche alcune risorse CERT / SANS / etc:

Alcuni riferimenti per leggi e requisiti di settore (esempi specifici per gli USA):

Questo rapporto del servizio di ricerca del Congresso fornisce anche una sintesi di alcune leggi federali statunitensi. Questo Berkley Law Paper potrebbe anche essere di interesse per le leggi federali degli Stati Uniti.

    
risposta data 27.04.2014 - 17:24
fonte
0

Cercherò di rispondere alle tue domande nel miglior modo possibile.

Informing the customers of the infection and clean up

Non informerei i clienti a meno che tu non abbia uno SLA per farlo o sia legato alla conformità. Spesso questo provoca il panico solo dagli uomini d'affari. Se ci sono PII persi, potrebbe comunque essere nel tuo interesse.

submitting the shells/infected files to any security firms reporting details of the exploit used to any security firms

Puoi inviare i file a Virus Total (virustotal.com). Questo è spesso distribuito ai fornitori di AV e puoi vedere se questo è già stato presentato da altri. In genere tutto ciò di cui il fornitore ha bisogno sarà nell'eseguibile che invierai a loro.

investigation/reporting of attacking ip address

È possibile inviare i dettagli degli indirizzi IP ai fornitori. Conosco McAfee con la mia esperienza e il loro motore di reputazione è Trusted Source (trustedsource.org) e puoi inviare loro un feedback.

La registrazione meticolosa è nel tuo interesse. Utilizzare la documentazione per aiutare a giustificare e costruire politiche aggiuntive in merito alla sicurezza e alla risposta agli incidenti. Sicuramente questa non sarà l'ultima volta in cui violerai (non qualcosa contro di te, ma è proprio così com'è), ma un processo specifico che puoi costruire aiuterà le persone a tenere le teste dei primi rispondenti chiare e dar loro una direzione da prendere . Cerca un modello per un rapporto di risposta agli incidenti per iniziare.

In tutti i posti in cui ho lavorato (pubblico e privato F100), la parte più preziosa delle azioni post-incidente è il debriefing. La vista posteriore è 20/20 ed è importante che tu e il tuo team comprendiate tutti i dettagli e i sintomi che sono stati scoperti. È necessario utilizzare questi punti per comprendere meglio la postura e i processi di sicurezza per gestire tali incidenti o impatti sul servizio. Questo è anche il momento migliore per rivedere l'architettura in quanto i responsabili delle decisioni aziendali saranno più sciolti con le stringhe di borsa quando si è verificata una violazione. La sicurezza è spesso trascurata o vista solo come spesa aziendale senza benefici per i margini di profitto dell'azienda quando non ci sono incidenti di sicurezza.

    
risposta data 22.04.2014 - 19:18
fonte
0

Fondamentalmente stai chiedendo informazioni sulle best practice relative alla gestione degli incidenti, ma essenzialmente come applicabile dopo "hai già gestito l'incidente". Per quanto ne so e sulla base delle domande specifiche che hai presentato, non esiste un approccio cookie cutter per ciò che la tua organizzazione deve fare dopo la fase "lezioni apprese". È davvero una questione di ciò che sei legalmente responsabile o semplicemente di volere / volere fare. Se fosse coinvolta una proprietà intellettuale di valore, allora potenzialmente si aprirà una lattina di vermi. Allo stesso modo ci sono alcune "cose" che richiedono che ti piaccia o meno, contattare le forze dell'ordine. ecc. Penso che tutti abbiano ragione. Caratterizzazione del tipo di incidente (attacchi IP e furto, DoS, malware, e-mail come molestie o phishing, spionaggio, violazioni delle norme come uso non autorizzato, attività illecite, minacce interne da distruttivo non distruttivo a distruttivo intenzionale, ecc.), Determinazione dell'estensione danni e quindi contattare le parti appropriate sono tutte cose che avrebbero dovuto essere fatte durante la fase di contenimento. Ecco una risorsa per aiutarti con detta classificazione; documento di classificazione caso CSIRT

Ora, sembra che tu abbia già passato l'identificazione, il contenimento, l'estirpazione e il recupero e presumo che tu abbia guardato e / o stia guardando attentamente il ritorno dell'attaccante? Quindi andiamo su quello che è generalmente considerato la migliore pratica nella fase 6 della gestione degli incidenti standard "dal libro". Molte organizzazioni / persone "non hanno il tempo" o si preoccupano di affrontare davvero questa fase, ma lascia che sia affrontata, gli aggressori stanno migliorando continuamente, quindi è necessario anche migliorare. È tempo di andare avanti e fare nuovi errori, ma l'intero punto di questo processo è di evitare di ripetere gli stessi vecchi. Quello che dovresti fare ora è documentare cosa è successo e come le funzionalità operative possono essere migliorate in modo da evitare che incidenti simili si ripetano. Un modo per farlo è creare un rapporto di follow-up. Idealmente, si desidera iniziare subito questo rapporto, immediatamente dopo il recupero. L'istituto SANS mette a disposizione alcuni moduli di incidenti utili che puoi utilizzare in questo processo. In genere è buona norma incoraggiare tutte le parti interessate a rivedere la bozza. Una volta che il rapporto è stato rivisto, pianifica una riunione di "lezioni apprese" se puoi. Idealmente, questo incontro dovrebbe avvenire entro una settimana o due dalla ripresa della produzione, mentre gli eventi sono ancora "freschi" nella memoria di tutti. In generale, lo scopo principale dell'incontro è quello di ottenere il consenso sul sommario esecutivo del rapporto sugli incidenti. IMO la chiave del riepilogo esecutivo sta illustrando l'importanza di avere in atto procedure di gestione degli incidenti efficaci.

Guarda anche i "sette peccati capitali" della gestione degli incidenti. Potresti trovarlo utile

    
risposta data 27.04.2014 - 16:23
fonte

Leggi altre domande sui tag