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

La gestione degli incidenti informatici presso l’Area Sistemi Informativi

dell’Università di Pavia

“La sicurezza informatica tra diritto e tecnologia”

24 maggio 2007 Marisa Alicanti

AGENDA

Architettura della rete dell’Ateneo pavese.

Procedura di gestione degli incidenti applicata dal GARR-CERT.

Procedura di gestione degli incidenti adottata dall’Università 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

ATHENET: LA RETE WIRED D’ATENEO


Pal. Centrale

Pal. Maino Orto Botanico

Area di Via Luino

Casa Zazzera

Polo di Via Ferrata

Pal. San Felice

Pal. Botta

Pal. San Tommaso

Area di Via Bassi – Taramelli - Forlanini

Sede di Cremona

Sede di Voghera

Sede di Mantova

Fondazione Mondino

Policlinico San Matteo

Fondazione Maugeri

C. R. A.

I.U.S.S.

Anello urbano1 Gb/s

Clinica Santa Margherita

Rete GARR

INTERNET

Rete wireless

UNIPV - WIFI

ATHENET: la rete wired d’Ateneo


Collegamenti poli urbani 1Gb/s.

Dorsali di area 1Gb/s.

Connessioni utente 100Mb/s.

Connessione a Internet 100Mb/s.

Apparati installati > 300

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

ATHENET: la rete wired d’Ateneo

L’Università 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 > 12.000

IP usati (computer connessi in rete) > 5.500

Indirizzi IP privati sono adottati in ambienti delimitati e non vengono diffusi né all’interno, né verso l’esterno.

UNIPV-WIFI: la rete wireless d’Ateneo

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 dell’ambiente.

L’accesso è consentito a dipendenti, studenti e ospiti, previa autenticazione e secondo specifiche policy.

L’ambiente WI-FI adotta indirizzi IP privati che vengono traslati per l’accesso ad AtheNet e a Internet. In ottemperanza alla normativa vigente vengono mantenuti log di accesso.


ATHENET / UNIPV-WIFI: gli utenti

I potenziali utenti dell’infrastruttura 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..

INCIDENTI INFORMATICI

In questa sede ci limitiamo a considerare gli eventi che hanno arrecato disagio a macchine/reti/servizi esterni all’Università 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 d’Ateneo, ma semplicemente che a suo carico non pervengono notifiche.


INCIDENTI INFORMATICI SEGNALATI

Si deve premettere che la segnalazione di malware non è in generale regolata da procedure comunemente condivise.

Nell’ambito della rete dell’Università e della ricerca (GARR), a cui l’Università di Pavia aderisce, viene gestito un CERT che ha l’obiettivo 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.


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 all’APM dell’Ente.

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 l’incidente informando la fonte.


LA PROCEDURA LOCALE

L’Area S.I., ricevuta una segnalazione:verifica la sussistenza del problema;

contatta telefonicamente il responsabile;

inoltra al responsabile la segnalazione vai e-mail.

L’Area S.I. richiede di:scollegare la macchina dalla rete d’Ateneo;

procedere al ripristino delle condizioni di sicurezza;

comunicare l’avvenuta risoluzione.

L’Area S.I. offre supporto per:analizzare il problema;

determinare e applicare metodi d’indagine;

individuare e utilizzare tool adatti alla soluzione del problema.


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

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

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%)

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?


I MOTIVI PIÙ COMUNI

L’utente 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 l’utente di un computer collegato in rete non si accorge della presenza di malware, soprattutto quando l’attività svolta dal malware è trasparente per il normale funzionamento della macchina.

La segnalazione di un evento non sempre ottiene soddisfazione.


CONCLUSIONI

L’attività di segnalazione non è regolamentata, né obbligatoria. Manca una metodologia certa così come un obbligo che responsabilizzi.

La scelta di segnalare il malware viene valutata all’interno di una organizzazione in base a: sensibilità al problema, disagio percepito, perdita economica/danni materiali, tempo uomo impegnato, costo globale dell’attività, ecc..

La lotta di coloro che adottano la segnalazione come mezzo per limitare il malware sembra persa in partenza, l’attività ha scarso seguito, è mal organizzata, non da risultati certi, in breve è una lotta impari.


UN ESEMPIO DI LOTTA IMPARI

Il server di posta elettronica d’Ateneo 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.

L’Area S.I. ha adottato un applicativo in grado di riconoscerli e trattenerli, collabora inoltre con l’azienda che produce l’applicativo inviandole campioni di spam non riconosciuto. La segnalazione, se effettuata, avrebbe riguardato circa 180.000 mail al giorno.


INCIDENTI SEGNALATI?


La punta di un iceberg

Documents

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