Linee guida per la pianificazione della risposta agli incidenti

Cercate il piano di risposta agli incidenti del Campus? Vai invece su Information Security Documents. La seguente linea guida per la pianificazione della risposta agli incidenti si riferisce ai sistemi e alle applicazioni che devono aderire alla politica del Campus MSSEI.

La politica di sicurezza dellaUC Berkeley impone la conformità allo standard minimo di sicurezza per le informazioni elettroniche per i dispositivi che gestiscono i dati coperti.

Requisiti

Ogni custode di sistema deve sviluppare e rivedere almeno annualmente un piano di risposta agli incidenti a livello di sistema che contenga:

Nomi e informazioni di contatto per il team locale di risposta agli incidenti, inclusi:
- Contatto per la sicurezza e contatto/i alternativo/i che abbia/no credenziali di amministratore di sistema, conoscenza tecnica del sistema e conoscenza della posizione del piano di risposta agli incidenti.
- Un’autorità locale/decisore per il sistema che comprende l’impatto aziendale del sistema e la sua indisponibilità.
Dettagli del sistema, o riferimento all’ubicazione di tali informazioni, compresi:
- Diagrammi del flusso dei dati
- Diagrammi di rete
- Inventario hardware del sistema (come richiesto dal controllo di registrazione annuale)
- Informazioni di registrazione (come richiesto dal controllo di registrazione dell’audit)
Procedure per segnalare e gestire un sospetto incidente, definite per ruolo: Sys Admin, utente con accesso massivo, utente finale, ad esempio,
- Chi contattare
- Come NON manomettere le potenziali prove (es, non tentare le indagini forensi se non autorizzati)

Descrizione del rischio

Se gli utenti e gli amministratori di sistema non sono a conoscenza delle procedure di risposta agli incidenti, la risposta sarà ritardata e le prove possono essere danneggiate o perse, aumentando notevolmente il potenziale impatto di un incidente.

Raccomandazioni

Per garantire che gli eventi di sicurezza delle informazioni e i punti deboli associati ai sistemi centrali coperti siano comunicati in modo da consentire l’adozione di azioni correttive tempestive, le procedure di segnalazione e di escalation degli eventi dovrebbero essere documentate in un piano formale di risposta agli incidenti. Le procedure di risposta agli incidenti rientrano tipicamente nelle seguenti fasi:

Rilevamento – Valutazione iniziale e triage degli incidenti di sicurezza sui sistemi centrali coperti, compresa l’escalation all’Information Security Office (ISO) e l’assegnazione del livello di priorità dell’incidente.
Analisi – Eseguire un’analisi dettagliata dell’impatto per dare la giusta priorità alle attività di risposta aggiuntive richieste per violazioni ad alto impatto. Iniziare le attività di conservazione e contenimento delle prove, così come il recupero iniziale.
Recupero – In linea con la gravità dell’incidente, mitigare l’impatto dell’incidente terminando le attività di contenimento e sradicamento e, infine, il recupero. Durante questa fase, l’attività spesso ritorna al rilevamento e all’analisi, ad esempio per vedere se altri host vengono infettati dal malware mentre si elimina un incidente di malware.
Post-Incidente – Dopo che l’incidente è stato adeguatamente gestito, rilascia un rapporto che dettaglia la causa principale e il costo totale dell’incidente, insieme ai passi che l’organizzazione dovrebbe fare per prevenire incidenti futuri.

Tutto il personale del campus, gli appaltatori e gli utenti terzi dovrebbero essere messi al corrente delle procedure di segnalazione dei diversi tipi di eventi che potrebbero avere un impatto sulla sicurezza dei dispositivi coperti. Dovrebbero essere tenuti a segnalare qualsiasi incidente di sicurezza delle informazioni il più rapidamente possibile al punto di contatto designato.

Che cos’è un incidente di sicurezza?

Un incidente di sicurezza nel contesto di questo requisito MSSEI è un evento che compromette o ha il potenziale per compromettere:

il funzionamento dei sistemi centrali coperti o
la riservatezza o l’integrità delle risorse di dati coperte

Un incidente di sicurezza può coinvolgere uno o tutti i seguenti elementi:

una violazione delle politiche e degli standard di sicurezza informatica del campus
accesso non autorizzato al computer o ai dati
presenza di un’applicazione dannosa, come un virus
presenza di programmi inaspettati/insoliti
una condizione di denial of service contro dati, rete o computer
abuso di servizio, sistemi o informazioni
danni fisici o logici ai sistemi
furto di computer

Componenti di un piano di risposta agli incidenti per sistemi e servizi individuali

I proprietari e i custodi delle risorse dovrebbero assicurarsi che il loro piano di risposta agli incidenti contenga i seguenti componenti. Forniamo questo TEMPLATE per i piani di risposta agli incidenti per sistemi e servizi individuali.

Nomi, informazioni di contatto e responsabilità del team locale di risposta agli incidenti, compresi:
- Gestore degli incidenti: Contatto per la sicurezza e contatto/i alternativo/i che hanno credenziali di amministratore del sistema, conoscenza tecnica del sistema e conoscenza della posizione del piano di risposta all’incidente.
- Gestore delle risorse: Un’autorità locale/decisore per il sistema che comprende l’impatto aziendale del sistema e la sua indisponibilità. Il proprietario della risorsa dovrebbe assumersi le responsabilità del manager della risorsa o designare un membro del personale del campus per questo ruolo.
Dettagli del sistema, o riferimento all’ubicazione di tali informazioni, inclusi:
- Diagrammi del flusso di dati
- Diagrammi di rete
- Inventario hardware del sistema (come richiesto dal controllo di registrazione annuale)
- Informazioni di registrazione (come richiesto dal controllo di registrazione di audit)
Procedure per segnalare e gestire un sospetto incidente, tra cui:
- Compilare un rapporto sull’incidente, che dovrebbe includere le seguenti informazioni:
  - Nome e numero di telefono della persona da contattare
  - Indirizzo IP, nome dell’host e posizione fisica del sistema violato
  - Nome del sistema coperto (come appare in NetReg)
  - Quali tipi di dati coperti erano disponibili su/da un host violato?
    - Nome completo
    - Numero di previdenza sociale
    - Numero della patente di guida o numero della carta d’identità della California
    - Numero della carta di credito o del conto finanziario (compreso il PIN o la data di scadenza)
    - Numero di conto corrente bancario (compreso il PIN o altre informazioni di accesso)
    - Informazioni mediche o di assicurazione sanitaria
    - Altro
  - Per ogni file contenente informazioni personali specificare:
    - Nome del file
    - Dimensione del file
    - Posizione del (percorso completo del) file
  - I dati sono stati criptati, e se sì, come?
  - Descrivere l’impatto dell’incidente (ad esempio il numero di record di dati compromessi o il numero di utenti che sono interessati dal sistema non disponibile)
  - Descrivere l’incidente di sicurezza, compresa la cronologia delle attività, come l’incidente è stato rilevato, l’impatto (business e tecnico) dell’incidente, i dettagli dei controlli di mitigazione in atto come il meccanismo di crittografia dei dati è stato utilizzato.
  - Documentare le azioni intraprese sul sistema violato (qual è lo stato del sistema ora, ecc)
Relazione dell’incidente di sicurezza all’ISO (email [email protected]*) e includere il rapporto di assunzione. Assegneremo un analista di sicurezza per coordinare qualsiasi attività di risposta all’incidente.
- Dopo che un incidente di sicurezza è stato segnalato a ISO, non disconnettersi o accedere al sistema violato fino alle istruzioni dell’analista di sicurezza ISO.
- L’interruzione del servizio che non è il risultato di attività dannose dovrebbe essere segnalata al personale di supporto IT appropriato. Ulteriori informazioni sulla segnalazione di diversi tipi di incidenti possono essere trovate sul sito web della sicurezza. Ad esempio, per la maggior parte delle applicazioni aziendali a livello di campus, l’interruzione del servizio dovrebbe essere segnalata al Campus Shared Services IT.
Rispondere all’incidente di sicurezza in modo tempestivo in base alla linea guida di priorità degli incidenti.

*Nota che l’indirizzo email [email protected] deve essere usato solo per segnalare incidenti di sicurezza coperti dal MSSEI. Gli incidenti di sicurezza non coperti dal MSSEI devono essere segnalati a [email protected].

Priorità degli incidenti di sicurezza

Per aiutare a dare priorità ai tempi e alle risorse necessarie per implementare le azioni correttive, i proprietari e i custodi delle risorse devono valutare l’impatto di un incidente di sicurezza in base ai seguenti fattori:

Come l’incidente avrà un impatto sulla funzionalità esistente dei sistemi interessati
Se l’incidente viola la riservatezza o l’integrità dei dati coperti UC P4 (ex UCB PL2) o dei dati non coperti
Quanto della popolazione di utenti è interessata dall’incidente di sicurezza
Qual è l’impatto reputazionale/finanziario per il campus

Usando i fattori sopra elencati come punto di partenza, gli incidenti di sicurezza dovrebbero essere valutati e assegnati a un livello di priorità alta o bassa dal responsabile degli incidenti designato e dal responsabile delle risorse. I fattori da considerare includono non solo l’impatto attuale dell’incidente, ma anche il probabile impatto futuro dell’incidente se non viene immediatamente corretto. Qualsiasi incidente ad alta priorità dovrebbe essere immediatamente segnalato all’ISO seguendo le procedure di gestione degli incidenti. Una volta che un incidente di sicurezza è segnalato all’analista ISO, la valutazione della priorità sarà confermata o rivista dopo un’ulteriore analisi dell’evento.

Esempi di incidenti di sicurezza ad alta priorità includono un evento che porta alla perdita di funzioni critiche per una popolazione di utenti a livello di campus o di dipartimento. Allo stesso modo, la violazione della riservatezza dei dati coperti che colpisce più di 500 utenti deve anche essere assegnata una valutazione di alta priorità. Il livello di priorità dell’incidente può essere rivisto nelle fasi successive del processo di risposta all’incidente, dopo che l’analisi delle prove aggiuntive fornisce una comprensione più accurata dell’impatto dell’incidente. Qualsiasi aggiornamento del livello di priorità dovrebbe essere rivisto dai membri del team locale di risposta agli incidenti e da un analista ISO.

La seguente tabella fornisce ulteriori indicazioni sull’impegno di tempo dei membri del team di risposta agli incidenti in caso di incidente di sicurezza (Analista ISO, Incident Handler, Resource Manager):

Fasi di risposta agli incidenti	Incidente ad alta priorità	Incidente a bassa priorità
Rilevamento	Immediato	8 ore
Analisi	Responsabile delle risorse e gestore degli incidenti assegnato a lavorare con ISO Analyst* su base dedicata, base continua.	Gestore degli incidenti assegnato e dedicato a lavorare con l’analista ISO sul caso durante il normale orario di lavoro.
Recupero	Gestore delle risorse e gestore degli incidenti assegnato a lavorare con l’analista ISO* su base dedicata e continua.	Gestore degli incidenti assegnato a lavorare con l’analista ISO sul caso in base al tempo/risorse disponibili.
Post-Incidente	Il responsabile dell’incidente è assegnato a lavorare con l’analista ISO sul caso in base al tempo/alle risorse disponibili.	Il responsabile dell’incidente è assegnato a lavorare con l’analista ISO sul caso in base al tempo/alle risorse disponibili.

* I casi ad alta priorità possono coinvolgere altre parti interessate nel campus, tra cui la politica IT, il consiglio del campus e altri rappresentanti della leadership del campus.

Definizioni della fase di risposta all’incidente:

Rilevamento – Questo specifica la quantità massima di tempo che dovrebbe trascorrere da quando l’evento sospetto viene rilevato al momento in cui le seguenti azioni dovrebbero essere completate:
- Valutazione iniziale e triage
- Determinare il livello di priorità iniziale basato sul rapporto di assunzione
- Riportare l’incidente a ISO
- L’analista ISO è assegnato a lavorare con il gestore dell’incidente e il responsabile delle risorse
- Inserire l’incidente nel sistema di ticketing ISO
Analisi – Il periodo di tempo nel ciclo di vita del caso in cui è richiesta una risposta attiva all’incidente per assicurare la risoluzione positiva del caso. Tipicamente questo include interruzioni di sistema o di servizio, e/o la conservazione urgente delle prove. Si verifica anche la legittimità dell’incidente, si conferma la priorità e si effettua l’escalation appropriata in base all’impatto dell’incidente. Le attività tipiche includono:
- Valutazione, triage, contenimento, conservazione delle prove, recupero iniziale
Recupero – Il periodo di tempo nel ciclo di vita del caso in cui la risposta attiva all’incidente non è necessaria per risolvere con successo il caso. Le attività tipiche includono:
- Raccolta delle prove, analisi e indagine, forense, rimedio, recupero completo, post-mortem.

Post-Incidente – Dopo che l’incidente è stato adeguatamente gestito, il team di risposta all’incidente emette un rapporto che dettaglia la causa e il costo dell’incidente e i passi che l’organizzazione dovrebbe fare per prevenire incidenti futuri.

Le definizioni derivano da http://www.first.org/_assets/resources/guides/csirt_case_classification….

Risorse aggiuntive

NIST Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf
Software Engineering Institute Handbook for Computer Security Incident Response Teams (CSIRTs),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm
Incident Response Plan TEMPLATE per sistemi e servizi individuali
Campus Incident Response Plan

Heading