La gestione degli incidenti informatici presso l

1
La sicurezza informatica tra diritto e
tecnologia
La gestione degli incidenti informatici presso
lArea Sistemi Informativi dellUniversità di
Pavia
24 maggio 2007

Marisa Alicanti
2
AGENDA

• Architettura della rete dellAteneo pavese.
• Procedura di gestione degli incidenti applicata
  dal GARR-CERT.
• Procedura di gestione degli incidenti adottata
  dallUniversità degli Studi di Pavia.
• Dati relativi agli incidenti segnalati nel corso
  del 2006.
• Breve analisi dei dati e commenti per una
  riflessione.

24 maggio 2007
2
Marisa Alicanti
3
ATHENET LA RETE WIRED DATENEO
24 maggio 2007
3
Marisa Alicanti
4
ATHENET la rete wired dAteneo

• LUniversità di Pavia è costituita da diverse e
  articolate sedi collegate fra loro e cablate in
  modo capillare. La tabella seguente raccoglie
  alcuni valori caratteristici dellinfrastruttura
  di rete con particolare riferimento alla banda
  trasmissiva disponibile.

Collegamenti poli urbani 1Gb/s.
Dorsali di area 1Gb/s.
Connessioni utente 100Mb/s.
Connessione a Internet 100Mb/s.
Apparati installati gt 300
24 maggio 2007
4
Marisa Alicanti
5
ATHENET la rete wired dAteneo

• LUniversità di Pavia utilizza generalmente
  indirizzi IP pubblici.
• Gli indirizzi vengono assegnati su richiesta e
  previa assunzione di responsabilità, secondo le
  seguenti disponibilità

Reti classe C 48
IP pubblici disponibili gt 12.000
IP usati (computer connessi in rete) gt 5.500

• Indirizzi IP privati sono adottati in ambienti
  delimitati e non vengono diffusi né allinterno,
  né verso lesterno.

24 maggio 2007
5
Marisa Alicanti
6
UNIPV-WIFI la rete wireless dAteneo

• La rete wireless, disponibile presso i principali
  poli universitari, è costituita da 92
  access-point operanti a 54 Mb/s. e da alcuni
  apparati e server per la gestione centralizzata
  dellambiente.
• Laccesso è consentito a dipendenti, studenti e
  ospiti, previa autenticazione e secondo
  specifiche policy.
• Lambiente WI-FI adotta indirizzi IP privati che
  vengono traslati per laccesso ad AtheNet e a
  Internet. In ottemperanza alla normativa vigente
  vengono mantenuti log di accesso.

24 maggio 2007
6
Marisa Alicanti
7
ATHENET / UNIPV-WIFI gli utenti

• I potenziali utenti dellinfrastruttura di rete
  wired e/o wireless sono i seguenti

Personale docente 1.153
Personale tecnico-amministrativo 959
Studenti 23.960
TOTALE 26.072

• A questi si aggiungono un numero variabile di
  ospiti, consulenti, ecc..

24 maggio 2007
7
Marisa Alicanti
8
INCIDENTI INFORMATICI

• In questa sede ci limitiamo a considerare gli
  eventi che hanno arrecato disagio a
  macchine/reti/servizi esterni allUniversità di
  Pavia e per i quali è giunta segnalazione.
• Non vengono prese in considerazione le
  problematiche rilevate e risolte internamente che
  non sono state oggetto di segnalazione.
• Malware interno non significa necessariamente che
  lo stesso non varca i limiti della rete dAteneo,
  ma semplicemente che a suo carico non pervengono
  notifiche.

24 maggio 2007
8
Marisa Alicanti
9
INCIDENTI INFORMATICI SEGNALATI

• Si deve premettere che la segnalazione di malware
  non è in generale regolata da procedure
  comunemente condivise.
• Nellambito della rete dellUniversità e della
  ricerca (GARR), a cui lUniversità di Pavia
  aderisce, viene gestito un CERT che ha
  lobiettivo di veicolare verso gli Enti associati
  le segnalazioni interne ed esterne.
• La gestione degli incidenti effettuata da
  GARR-CERT si basa su una procedura approvata da
  GARR-OTS il 20/12/1999.

24 maggio 2007
9
Marisa Alicanti
10
LA PROCEDURA GARR-CERT

• In sintesi, ricevuta una segnalazione, il CERT
• verifica quale Ente è coinvolto
• assegna un numero univoco di incidente
• segnala via e-mail il problema allAPM dellEnte.
• I tempi di intervento richiesti sono
• open mail relay o similari 3 giorni
• azioni ostili (port scan, attacchi, ecc.) 1
  giorno
• attacchi tipo DoS 1 ora.
• Il CERT, ricevuta la notifica di risoluzione del
  problema, provvede a chiudere lincidente
  informando la fonte.

24 maggio 2007
10
Marisa Alicanti
11
LA PROCEDURA LOCALE

• LArea S.I., ricevuta una segnalazione
• verifica la sussistenza del problema
• contatta telefonicamente il responsabile
• inoltra al responsabile la segnalazione vai
  e-mail.
• LArea S.I. richiede di
• scollegare la macchina dalla rete dAteneo
• procedere al ripristino delle condizioni di
  sicurezza
• comunicare lavvenuta risoluzione.
• LArea S.I. offre supporto per
• analizzare il problema
• determinare e applicare metodi dindagine
• individuare e utilizzare tool adatti alla
  soluzione del problema.

24 maggio 2007
11
Marisa Alicanti
12
SEGNALAZIONI RICEVUTE NEL 2006
Tipologia incidente Segnalazioni 2006 Fonti
Spam 27 10
Infected node 24 1
Piracy 21 5
Attack 7 5
Probe 6 4
Phishing page 4 2
Bot 1 1
Totale 90 28
24 maggio 2007
12
Marisa Alicanti
13
SPUNTI PER UNA RIFLESSIONE

• Tre fonti hanno effettuato il 53,34 delle
  segnalazioni e ciascuna ha segnalato una sola
  tipologia di incidente.

Fonte (Tipo incidente) Segnalazioni (Totale inc.) per tipologia sul totale
Società Telecomunicazioni (Infected Node) 24 (24) 100,00 26,67
Servizio gratuito (Spam) 15 (27) 55,55 16,67
Azienda specializzata (Piracy) 9 (21) 42,86 10,00
Totale 48 (90) 53,34
24 maggio 2007
13
Marisa Alicanti
14
SPUNTI PER UNA RIFLESSIONE

• Le rimanenti 25 fonti hanno segnalato il 46,66
  degli incidenti, in media meno di due incidenti
  ciascuna.
• Le segnalazioni di piracy hanno riguardato
• Solo 3 segnalazioni provengono da fonte italiana
  e in generale per ogni evento è pervenuta una
  sola segnalazione.

Film Cinema/TV 16 (76,19)
Software 3 (14,29)
Giochi PC/Playstation 2 (9,52)
24 maggio 2007
14
Marisa Alicanti
15
RIASSUMENDO

• Quasi tutte le segnalazioni (72 su 90) provengono
  da un numero estremamente limitato di fonti (3 su
  28).
• La maggior parte delle tipologie di incidenti
  colpiscono un numero consistente di utenti e
  dovrebbero quindi essere segnalati tante volte
  quanti sono i computer/servizi colpiti, invece
  solo 2 su 90 sono stati segnalati due volte.
• In apparenza le aziende/gli utenti preferiscono
  difendersi anziché attaccare segnalando.
• Quali sono le motivazioni?

24 maggio 2007
15
Marisa Alicanti
16
I MOTIVI PIÙ COMUNI

• Lutente finale, a fronte di problemi ampiamente
  trattati dagli addetti ai lavori, non riceve una
  formazione adeguata e quindi non sviluppa una
  spiccata sensibilità nei confronti del problema.
• In molti casi lutente di un computer collegato
  in rete non si accorge della presenza di malware,
  soprattutto quando lattività svolta dal malware
  è trasparente per il normale funzionamento della
  macchina.
• La segnalazione di un evento non sempre ottiene
  soddisfazione.

24 maggio 2007
16
Marisa Alicanti
17
CONCLUSIONI

• Lattività di segnalazione non è regolamentata,
  né obbligatoria. Manca una metodologia certa così
  come un obbligo che responsabilizzi.
• La scelta di segnalare il malware viene valutata
  allinterno di una organizzazione in base a
  sensibilità al problema, disagio percepito,
  perdita economica/danni materiali, tempo uomo
  impegnato, costo globale dellattività, ecc..
• La lotta di coloro che adottano la segnalazione
  come mezzo per limitare il malware sembra persa
  in partenza, lattività ha scarso seguito, è mal
  organizzata, non da risultati certi, in breve è
  una lotta impari.

24 maggio 2007
17
Marisa Alicanti
18
UN ESEMPIO DI LOTTA IMPARI

• Il server di posta elettronica dAteneo ha
  gestito nel 2006 circa 4.750 caselle di posta
  elettronica assegnate a dipendenti e strutture.
• Ogni giorno il server di posta elettronica ha
  ricevuto mediamente oltre 200.000 messaggi.
• Il 90 circa dei messaggi erano spam.
• LArea S.I. ha adottato un applicativo in grado
  di riconoscerli e trattenerli, collabora inoltre
  con lazienda che produce lapplicativo
  inviandole campioni di spam non riconosciuto. La
  segnalazione, se effettuata, avrebbe riguardato
  circa 180.000 mail al giorno.

24 maggio 2007
18
Marisa Alicanti
19
INCIDENTI SEGNALATI?
La punta di un iceberg
24 maggio 2007
19
Marisa Alicanti