Segue dalla Parte I
1. Quale sarà la vostra risposta iniziale?
Avete due possibilità: potete continuare a lasciare funzionare il sistema oppure potete staccare la spina. Nessuna delle possibilità deve essere trascurata. Lasciare il sistema in funzione può permettere di avere informazioni supplementari sull’esecutore dell’attacco, senza che questi sappia che le sue attività sono state scoperte. Tuttavia, se state subendo grossi danni, potreste non avere scelta e mettere il sistema off line per limitare gli effetti dell’attacco stesso.
2. Chi ha commesso questo crimine?
Nell’occuparvi delle attività “maligne”, dovrete sicuramente porvi un problema fondamentale: possono dipendere da qualcuno all’interno dell’organizzazione? Se la risposta fosse affermativa, dovrete scoprire immediatamente di chi si tratta è bloccarlo al più presto. Se chi ha effettuato l’attacco non è un impiegato e non è nemmeno all’interno della giurisdizione legale, vi troverete di fronte a diversi problemi di natura differente. Tenete presente che le leggi sui crimini informatici variano dal paese al paese.
3. Tenterete di perseguire chi ha effettuato l’attacco?
Forse potete pensare che questa sia una domanda facile a cui rispondere. Ma date un’occhiata alle statistiche: un’indagine condotta da CSI/FBI Computer Crime nel 2005 ha evidenziato che soltanto il 34% degli intervistati ha denunciato le intrusioni. Questo numero rimane basso per una serie di motivi, ma soprattutto perché nelle lista ci sono molte organizzazioni che non desiderano una pubblicità negativa, che inevitabilmente seguirebbe a un’eventuale denuncia.
4. La legge vi impone di inviare una segnalazione della violazione della sicurezza?
Per legge, esiste una miriade di aziende a cui è richiesto di segnalare le violazioni. Alcuni stati come hanno precise e rigorose normative e hanno stabilito che il consumatore debba conoscerle.
5. Come è potuto accadere?
Questo è un aspetto che assolutamente dovete conoscere. Può essere dipeso da una password inefficace o la vulnerabilità poteva essere in una parte di software cui mancava una patch: comunque sia, avete l’obbligo di scoprire che cosa c’era di sbagliato. Forse esisteva una policy per impedire un tale evento e non è stata seguita oppure qualcosa è stato semplicemente trascurato?
6. Cosa avete imparato da questo evento?
Mettete in atto i cambiamenti necessari per evitare che simili eventi accadano ancora. Di questa attività dovrebbe fare parte anche il training del personale in relazione alle modalità operative che sono state modificate.
Ora che
avete un’idea migliore delle attività da intraprendere nel caso veniste
attaccati, dovreste avere delle valide motivazioni per sviluppare una buona
policy di incident response e CERT.org è un ottimo punto da cui cominciare. Una
buon la difesa richiede progettazione e preparazione. Essere proattivi può
aiutarvi a evitare un potenziale disastro.
