Aziende di tutto il mondo sotto attacco hacker

Notizia di oggi che sta riempiendo i giornali e i siti.

Riporto quello tratto da pmi.it:

L’attacco hacker più massiccio, sofisticato ed esteso di tutti i tempi – così verrà ricordato quello scoperto dall’ingegnere Alex Cox, impiegato nell’azienda della Virginia Netwitness, che si occupa di sicurezza per Governo Usa ed FBI – sta terrorizzando le aziende di tutto il mondo. L’iniziativa criminale è partita a fine 2008.

Prese di mira informazioni critiche e dati sensibili di imprese ed enti governativi: 75.000 pc e server, oltre 2.500 aziende in 196 diversi paesi.

Cox ha individuato, il 26 gennaio scorso il sistema, il bot Kneper, utilizzato dagli hacker per carpire i dati. Il funzionamento è piuttosto semplice ma purtroppo efficace, perchè basato sull’ingenuità degli utenti.

Gli hacker hanno indotto i dipendenti a scaricare software maligno che, una volta installato, permette di accedere liberamente ai Pc e ai server aziendali, utilizzando anche un pericoloso spyware già noto come ZeuS.

La base della rete hacker sarebbe stata localizzata in Est-Europa, con un centro di controllo in Germania, ma per ora l’Europa non sembra essere la zona geografica più colpita, bensì Usa, Messico, Egitto, Arabia Saudita e Turchia.

È però necessario sottolineare che l’attacco è ancora in atto, tanto che ancora non è stato possibile quantificare i danni provocati. È pertanto importante continuare a prestare attenzione quando si istallano software scaricati dalla Rete e provenienti da fonti sconosciute.

L’invito arriva mediante email con allegati o link infetti, oppure tramite avvisi che invitano a cliccare su siti infettati, o ancora inviando warnings legati alla necessità di cancellare file dannosi per il computer, inducendo quindi a scaricare programmini creati dagli hacker stessi.

Le mie considerazioni sono:

  1. Troppe aziende sottovalutano la sicurezza;
  2. Pochissime hanno un piano integrato per la sicurezza informatica;
  3. Gli utenti sono troppo poco consapevoli dei rischi per svariati motivi (disinformazione, poca consapevolezza, tanto il sistema magari non è mio)
  4. Tanti non leggono quello che cliccano (magari non sanno le lingue)
  5. Spendere in sicurezza? e perchè? tanto non capiterà mai a me

E poi si chiude la stalla quando i buoi sono fuggiti. Questo dal punto di vista degli utenti.

I provider nazionali invece potrebbero fare qualcosa di più, visto che questo diventerà il terreno di scontro delle prossime guerre. Policy di sicurezza più strette, filtri intelligenti per la gestione del traffico e molto altro ancora.

Ovviamente secondo il nostro punto di vista

Articoli Correlati

Password: gli utenti usano ancora password troppo semplici

I tempi passano ma alcune brutte abitudini rimangono.  Le password che l’utente medio utilizza sui sistemi informatici sono ancora troppo semplici.

Da recenti studi, sembra che le password più usate siano queste:

  1. 12345
  2. 123456
  3. qwerty
  4. 65432
  5. password
  6. il nome della persona
  7. il login
  8. 12345678
  9. 111111
  10. etc…

Beh che dire… sono troppo semplici ed espongono l’utente ad una molteplicità di problemi: furto di credenziali, accessi non desiderati, e molto altro.

Eppure metodi semplici ci sono: utilizzare maiuscole minuscole all’interno di una frase che conoscete, utilizzare i numeri, aggiungere qualche simbolo speciale.

Facciamo un esempio.

Utilizziamo una semplice password: password. Troppo semplice vero? Proviamo a complicarla:

  1. PaSSwoRd
  2. !PAssw0RD! (non è una o, è uno zero)
  3. !P455m0rD! (qui abbiamo giocato che la a rovesciata è simila al 4 e la s è simile al 5)

Semplice no? e non sono neanche molto semplici da trovare, neanche con un attacco brute force.

Ma vediamo le linee quida canoniche per creare password complesse e difficili da individuare:

  • lunghe almeno 8 caratteri
  • non deve essere un termine con un senso compiuto che puo’ essere messo in relazione con la persona o con il sistema sul quale viene utilizzato
  • non deve essere rintracciabile su un comune vocabolario (in qualsiasi lingua)
  • non deve essere costituita esclusivamente da una successione di cifre
  • deve contenere lettere maiuscole, minuscole, cifre, simboli e ogni altro carattere normalmente disponibile sulla tastiera
  • non devono essere troppo difficili da ricordare
  • non vanno scritte su foglietti o altri supporti
  • vanno cambiate spesso (almeno ogni tre mesi)
  • si devono utilizzare password diverse per sistemi diversi
  • non utilizzare a rotazione un ristretto numero di password.

Tutto qui. Non è semplicissimo ma neanche impossibile. A voi ora il divertimento di trovare password difficili!!

Articoli Correlati

Amministratori di sistema: un sistema di log open source

Domani entra in vigore il famigerato decreto sugli amministratori di sistema.

Questa è una soluzione che abbiamo sviluppato e che proponiamo ai nostri clienti per quanto riguarda la parte tecnica, gestione dei log degli accessi degli amministratori di sistema.

Nel pieno rispetto dell’open source presentiamo una soluzione a basso costo utilizzando sistemi liberamente scaricabili da internet.

Sistemi per la gestione dei log ne esistono di tutti i tipi e per tutte le tasche ma, leggendo le caratteristiche di molti a pagamento… abbiamo subdorato che molto spesso sono dei pc embedded con programmi open source venduti a svariati migliaia (se non decine di migliaia) di euro. Vediamo come fare utilizzando la rete.

Prendimao un pc con una buona dotazione di spazio disco (e poi vedremo perchè) e installiamoci una distribuzione open source linux (noi lavoriamo con ubuntu… ma il discorso si puo’ fare con qualsiasi altra distribuzione avendo l’accortezza di utilizzare i comandi adeguati).

A questo punto montiamoci un server MySql e quindi utilizziamo come log server centralizzato il sistema Syslog-ng per salvare tutti i dati sul database menzionato.

Seguendo le direttive trovate sul seguente link:  http://www.openskill.info/infobox.php?ID=1466

Innanzitutto e’ necessario  connettendosi a mysql con il comando mysql -u username -p passwhord -h 127.0.0.1 e creare il database che conterra’ i log con il comando create database db_log;.
Si presuppone che mysql sia in esecuzione sullo stesso sistema del syslog server ed in ascolto sull’indirizzo di loopback.
Una voltra create il database si suggerisce di creare un utente apposito che abbia i privilegi sullo stesso, in modo di evitare di utilizzare l’utenza di root. Anche in questo caso e’ necessario loggarsi al dbms con un mysql -u username -p password -h 127.0.0.1 ed eseguir eil seguente comando:
GRANT ALL PRIVILEGES ON db_syslog.* TO syslog_user@127.0.0.1 IDENTIFIED BY 'syslog_password'.
L’ultima operazione da eseguire sul database e’ la creazione della tabella che conterra’ i messaggi syslog salvati da syslog-ng. Tale operazione puo’ essere portata a termine con il comando mysql -u syslog_user -p syslog_password -h 127.0.0.1 < syslog_table.sql .
syslog_table.sql sara’ un file di testo contenente le istruzione per creare la tabella, e dovra’ contenere le seguenti linee:

#
# Table structure for table `logs`
#

CREATE TABLE logs (

host varchar(32) default NULL,
facility varchar(10) default NULL,
priority varchar(10) default NULL,
level varchar(10) default NULL,
tag varchar(10) default NULL,
date date default NULL,
time time default NULL,
program varchar(15) default NULL,
msg text,
seq int(10) unsigned NOT NULL auto_increment,

PRIMARY KEY (seq),

KEY host (host),
KEY seq (seq),
KEY program (program),
KEY time (time),
KEY date (date),
KEY priority (priority),
KEY facility (facility)

) TYPE=MyISAM;

Ovviamente nel caso il file syslog_table non sia nella stessa directory dalla quale viene lanciato il client mysql sara’ necessario specificare il percorso del file in questione.
Una volta predisposta la parte relativa al database, e’ stata aggiunta la seguente destinazione al file di configurazione di syslog-ng /etc/syslog-ng/syslog-ng.conf:

#file di destinazione con query sql che saranno processate dal feeder
destination file_sql {
file(“/var/log/sqllog/log_sql_$HOUR.$MIN”
template(“INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MONTH-$DAY’, ‘$HOUR:$MIN:$SEC’,’$PROGRAM’, ‘$MSG’ );n”)
template_escape(yes));
};

Questa direttiva fa in modo che all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO vengano inserite una serie di istruzioni INSERT SQL che una volta eseguite dal client mysql andranno ad inserire i dati nella tabella logs del database db_syslog.
A meno che nel file di configurazione di syslog-ng non sia posta a yes l’opzione create_dirs sara’ necessario creare la directory /var/log/sqllog ed impostare dei permessi coerenti con le opzioni owner, group, perm, dir_owner, dir_group e dir_perm se definite nel file di configurazione di syslog-ng.
Inoltre, come si puo’ notare dall’opzione file della direttiva destination, non verra’ creato un singolo file ma diversi a seconda dell’ora e del minuto in cui verranno generati. Tale scelta si e’ resa necessaria per semplificare la creazione e l’esecuzione dello shellscript che eseguira effettivamente gli inserimenti nek database e che verra’ successivamente illustrato.

Infine, la nuova destinazione creata dovra’ essere utilizzata all’interno di una direttiva log del file /etc/syslog-ng/syslog-ng.conf perche’ qualcosa possa essere scritto all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO:

#log query per il feeder
log { source(s_all); destination(file_sql); };

Con questa configurazione, pero’, nessun dato viene ancora scritto all’interno del database ma vengono solo scritte delle istruzioni INSERT nei file /var/log/sqllog/log_sql_ORA.MINUTO.
E’ quindi necessario creare uno script che prenda questi file e inserisca effettivamente i log all’interno del database, ad esempio /opt/syslg-db/feeder.sh:

#!/bin/bash
# Script adattato da process_logs di  Casey Allen Shobe

dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
datadir=”/var/log/sqllog”

while true; do
logfiles=`find $datadir -name “log_sql_[0-2][0-9].[0-5][0-9]”`
sleep 70 # This is to ensure we don’t screw up a log currently being written.
for logfile in $logfiles; do
cat $logfile | mysql –user=$dbuser –password=$dbpass $dbname
if [ $? -ne 0 ]; then
echo “[ERRORE] Problema nel processare il file $logfile!!!” >> $datadir”/feeder_log.log”
#exit 1 #Comment out this line if you want the script to
else
echo “[OK] $logfile inserito nel db in data `date –rfc-3339=seconds`” >> $datadir”/feeder_log.log”
rm -f $logfile
fi
done
done

Nella parte iniziale dello script vengono definite alcune variabili d’ambiente che indicano i parametri da utilizzare per la connessione al database e la directory dove si trovano i files scritti da syslog-ng contenenti le istruzioni inserti da eseguire.
Un aspetto importante dello script e’ l’istruzione sleep 70 eseguita all’interno del ciclo while dopo avere settato la variabile contenente i nomi dei file da processare durante l’iterazione corrente. Quando eseguita essa sospende l’esecuzione dello script per 70 secondi, in modo da impedire che possa essere processato un file in corso di scrittura da parte di syslog-ng.
Poiche’ la destination definita nel file di configurazione di syslog-ng, prevede la creazione di un nuovo file di log ogni minuto (grazie all’utilizzo della macro $MIN), con una sleep di 70 secondi si avra’ la sicurezza che i files definiti nella variabile logfiles non siano piu’ oggetto di scrittura, essendo trascorsi almeno 60 secondi dalla loro creazione.
Per ognuno di questi file, infine, vengono eseguite le istruzioni INSERT in essi contenute passandole in input al client mysql tramite la linea cat $logfile | mysql --user=$dbuser --password=$dbpass $dbname.
Una volta processato, il file viene rimosso tramite il comando rm -f. Lo script verifica inoltre l’exit code del comando mysql ed in base ad esso scrive l’esito del processing del file in /var/log/sqllog. Questa operazione puo’ anche essere considerata superflua ed evitata semplicemente commentando le due istruzioni echo all’interno del ciclo for.
Infine, per automatizzare l’utilizzo dello script feeder.sh e’ possibile modificare lo script /etc/syslog-ng/syslog-ng in modo da avviare e terminare automaticamente feeder.sh insieme al syslog server:

#!/bin/sh
#
[…]

start() {
echo -n $”Starting $prog: ”
daemon $exec $SYSLOGNG_OPTIONS
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
echo “Starting Feeder”
/opt/syslg-db/feeder.sh &
return $retval
}

stop() {
echo “Stopping Feeder”
killall feeder.sh
echo -n $”Stopping $prog: ”
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}

[…]

Bene a questo punto il server è a posto, ricordandosi di abilitare la ricezione dei log remoti modificando una riga su /etc/syslog-ng/syslog-ng.conf . La riga in questione comincia con #udp(). Cancellate il carattere #, salvate riavviate il server syslog- Bene il sistema è quasi pronto.

Passiamo ai clients.

Se i client sono linux, nessun problema, installate su tutti il demone syslog-ng e modificatene il contenuto aggiungendo le seguenti righe:

destination d_loghost  { udp(“ip_server_log”);  };

log { source (s_all); destination (d_loghost);};

Riavviate sui client il demone syslog-ng e il server comincerà a ricevere i log.

Passiamo ai clienti Windows (per client, intendo server windows che manderanno i log sul server di log centralizzato)

Per windows ho testato  Snare Agent per windows, un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. L’installazione si limita al solito doppio click sull’eseguibile, all’impostazione della password ed alla scelta se permettere o meno l’accesso remoto alla pagina di configurazione del servizio. Per effettuare la configurazione è sufficiente puntare il browser su localhost:6161. Utente e password di default sono snare/snare, da cambiare immediatamente.

La configurazione da impostare per avere il log remoto è sulla pagina network. Basta impostare  Destination Snare Server address con l’indirizzo ip del server di log e come  destination  port  514. Attivare Enable Syslog  Header e selezionare come syslog facility auth, con livello notice.

Stanchi? un attimo di pazienza tra un po’ è finito.

A questo punto abbiamo tutti i nostri log su un server mysql. La normativa ci impone di salvarli su supporti non modificabili (cd o dvd in pratica).

Lo risolviamo in questo modo:

Scriviamo un piccolo script che ad una certa ora (impostata con cron) viene eseguito per estrarre i dati dal database e scriverli in un file che poi recupereremo per trasferirlo in un cd  e/o DVD.

lo script è il seguente:

#!/bin/bash
dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
filebackup=backup-log-$(date +%d-%m-%Y –date=”yesterday”)
/usr/bin/mysql –user=$dbuser –password=$dbpass $dbname < /opt/syslg-db/query.sql > /home/log/$filebackup.txt
gzip /home/log/$filebackup.txt

il contenuto del file sql query.sql è questo:

select * from logs where date=(select curdate() – interval 1 day);

Per recuperare il tutto abbiamo utilizzato il servizio ftp (il server  non ha monitor e/o tastiera). Installiamo il demone proftpd, lo configuriamo e creiamo un utente log. A questo punto, a tempi prefissati, ci recuperiamo i files da scrivere sui CD e/o DVD

Alcune note di prestazione: da un nostro cliente con una decina di server e con circa 100 client con tale sistema in meno di cinque giorni abbiamo un db con oltre 2 milioni di righe!!!!  Diventa importante quindi eseguire ogni tanto un task per cancellare dal db i record vecchi di n giorni ( a questo punto è banale l’implementazione).

Altra nota: il garante ci dice che dobbiamo loggare anche tutti gli accessi degli amministratori sui pc che trattano dati pernonali e/o sensibili.. i log diventeranno ancora di più.

Abbiamo finito, questa è una soluzione che abbiamo ritenuto soddisfacente i requisiti minimi del garante (a seguito anche di incontri con esponenti del Garante stesso). Non saraà perfetta, sarà migliorabile, ma funziona.

Attendiamo commenti

Articoli Correlati

Amministratori di sistema: precisazione del Garante

Notizia tratta da www.garanteprivacy.it

 

Amministratori di sistema: precisazioni del Garante

In vista della scadenza del 15 dicembre, termine entro il quale imprese e altri soggetti interessati devono adeguarsi alle prescrizioni impartite a suo tempo in materia di amministratori di sistema, l’Autorità per la protezione dei dati personali ritiene opportuno precisare alcuni aspetti, anche allo scopo di evitare ingiustificati oneri per le aziende.

L’Autorità, nel rilevare il generale impegno da parte delle imprese ad adempiere alle prescrizioni impartite con il provvedimento del 27 novembre 2008, ha infatti constatato che informazioni imprecise o anche talune azioni promozionali da parte di consulenti rischiano di disorientare alcune aziende, soprattutto quelle di piccole dimensioni, esponendole a immotivati aggravi economici.

L’Autorità intende dunque ribadire quanto segue:

  • le prescrizioni riguardano solo quei soggetti che, nel trattare i dati personali con strumenti informatici, devono ricorrere o abbiano fatto ricorso alla figura professionale dell’amministratore di sistema o a una figura equivalente.
  • le prescrizioni non si applicano, invece, a quei soggetti anche di natura associativa che, generalmente dotati di sistemi informatici di modesta e limitata entità e comunque non particolarmente complessi, possano fare a meno di una figura professionale specificamente dedicata alla amministrazione dei sistemi o comunque abbiano ritenuto di non farvi ricorso.

Per quanto concerne, infine, gli aspetti tecnici del provvedimento (in particolare, la conservazione dei log degli accessi effettuati dagli amministratori di sistema), il Garante ricorda come l’adeguamento possa avvenire anche con soluzioni a basso costo, validamente proposte e disponibili in rete (per esempio basate su software gratuito, anche con licenze di tipo open source), che possono costituire valide alternative all’impiego di prodotti commerciali o di apparati più sofisticati.

Roma, 10 dicembre 2009

Articoli Correlati

Amministratori di sistema: scadenza vicina. Una piccola guida.

Il 15 dicembre si sta avvicinando e con esso la scadenza per applicare in azienda il provvedimento del Garante della Privacy del 27 novembre 2008 come modificato dal provvedimento del 25 giugno 2009.

A seguito di un convegno a cui abbiamo assistito oggi, riporto quali sono gli adempimenti da fare in azienda. Tengo a precisare che tali discussioni sono ovviamente frutto di interpretazioni e che quindi vanno applicate coscientemente presso la propria azienda magari sentendo il proprio consulente o le proprie associazioni di categoria. Non ci rendiamo responsabili per applicazioni reali in azienda.

Il provvedimentro del Garante della Privacy del 25 giugno 2009 ha portato con se sostanzialmente due notizie degne di nota: Semplificazioni e proroga dell’individuazione del o degli amministratori di sistema e le attività connesse da mettere in essere.

Questi due provvedimenti hanno individuato, oltre ai ruoli di titolare, responsabile ed incaricato, anche il ruolo di Amministratore di sistema.

Cosa si intende per amministratore di sistema? Non solo il classico personaggio “smanettone” che gestisce i server ma in senso più lato anche:

  • Amministratore di server
  • Amministratore di Database
  • Amministratore di rete
  • Amministratore di sistema
  • Amministratore di software complessi
  • …..

L’individuazione del o degli amministratori di sistema deve essere fisica, cioè una persona, non una persona giuridica. Ne devono essere valutate le caratteristiche e le capacità e tali valutazioni devono essere documentate.

La designazione deve essere scritta e su base individuale.

Entro il 15 dicembre 2009 deve essere redatto un registro degli Amministratori di sistema (AS nel seguito) in cui sono contenuti gli estremi identificativi, le funzioni attribuite a ciascun AS. Nel caso di Outsourcing, tale elenco deve essere tenuto dall’Outsourcer (ma lo vedremo meglio più avanti). Questo registro deve esserci. Il posto migliore dove inserirlo è ovviamente il DPS ma l’azienda puo’ fare quello che vuole.

Nel caso in cui alcuni AS trattino dati dei lavoratori (o possano venirne a conoscenza), i lavoratori stessi devono essere informati (in vario modo, lettera scritta, pubblicazione su intranet, su lavagna, etc) dei nominativi. Quali sono i dati dei lavoratori? sicuramente quelli amministrativi ma anche dati di navigazione in internet, log delle mail, degli accessi. Praticamente questo sottoinsieme degli AS è praticamente identico all’insieme degli AS nella sua interezza.

Una volta all’anno l’azienda deve verificare l’attività degli AS e mantenere traccia di questa valutazione (documenti). Gli AS valutati devono essere sia quelli interni che quelli esterni.

Veniamo ad un altro obbligo che ha gettato molto scompiglio: la registrazione degli accessi (solo log in e log out) degli amministratori di sistema ai vari sistemi. E’ obbligatorio. Tali log vanno tenuti almeno sei mesi su un supporto non riscrivibile (CD o DVD non riscrivibile ad esempio). Non è proibito tenere i log di tutte le attività. E’ a discrezione dell’azienda .

Vediamo quindi in pratica cosa bisogna fare in due situazioni:

  1. AS interni;
  2. AS esterni.

Caso n.1, AS interni.

Nomina dell’AS, con raccolta della documentazione comprovante la competenza, ad es. curriculum e/o corsi di formazione; la nomina deve avere anche il profilo di autorizzazione e quali sono i trattamenti consentiti. Deve essere anche definita la Job descriprion, come meglio descritto nelle faq del garante, numero 7 e 8 che riportiamo in dettaglio:

  • Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS? [Rif. comma 2, lettera  d]. Il provvedimento prevede che all’atto della designazione di un amministratore di sistema, venga fatta “elencazione analitica” degli ambiti di operatività consentiti in base al profilo di autorizzazione assegnato, ovvero la descrizione puntuale degli stessi, evitando l’attribuzione di ambiti insufficientemente definiti, analogamente a quanto previsto al comma 4 dell’art. 29 del Codice riguardante i responsabili del trattamento.
  • Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
    No, è sufficiente specificare l’ambito di operatività in termini più generali, per settori o per aree applicative, senza obbligo di specificarlo rispetto a singoli sistemi, a meno che non sia ritenuto necessario in casi specifici.

La  nomina deve essere individuale, fisica, deve essere conservata la ricevuta di nomina.

Deve essere comunicato ai dipendenti quale AS tratta i loro dati.

Bisogna registrare gli accessi degli AS (Log in e log out) ai vari sistemi (questi sono gli standard minimi). Attenzione ai riferimenti orari (c’e’ quindi la necessità di avere dei time server affidabili). Tali dati poi vanno periodicamente scritti su un supporto non riscrivibile e mantenuti per almeno 6 mesi.

Qui ci vengono in aiuto le faq 9, 10, 11, 12, 13, 14:

  • Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…) [Rif. comma 2, lettera f] Per access log si intende la registrazione degli eventi generati dal sistema di autenticazione informatica all’atto dell’accesso o tentativo di accesso da parte di un amministratore di sistema o all’atto della sua disconnessione nell’ambito di collegamenti interattivi a sistemi di elaborazione o a sistemi software. Gli event records generati dai sistemi di autenticazione contengono usualmente i riferimenti allo “username” utilizzato, alla data e all’ora dell’evento (timestamp), una descrizione dell’evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, o di una condizione di errore, quale linea di comunicazione o dispositivo terminale sia stato utilizzato…).
  • Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log? [Rif. comma 2, lettera f]
    Qualora il sistema di log adottato generi una raccolta dati più ampia, comunque non in contrasto con le disposizioni del Codice  e con i principi della protezione dei dati personali, il requisito del provvedimento è certamente soddisfatto. Comunque è sempre possibile effettuare un’estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.
  • Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo scopo della verifica deve prevedere un’analisi dei rischi?
    La caratteristica di completezza è riferita all’insieme degli eventi censiti nel sistema di log, che deve comprendere tutti gli eventi di accesso interattivo che interessino gli amministratori di sistema su tutti i sistemi di elaborazione con cui vengono trattati, anche indirettamente, dati personali. L’analisi dei rischi aiuta a valutare l’adeguatezza delle misure di sicurezza in genere, e anche delle misure tecniche per garantire attendibilità ai log qui richiesti.
  • Come va interpretata la caratteristica di inalterabilità dei log? Caratteristiche di mantenimento dell’integrità dei dati raccolti dai sistemi di log sono in genere disponibili nei più diffusi sistemi operativi, o possono esservi agevolmente integrate con apposito software. Il requisito può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili. In casi più complessi i titolari potranno ritenere di adottare sistemi più sofisticati, quali i log server centralizzati e “certificati”. E’ ben noto che il problema dell’attendibilità dei dati di audit, in genere, riguarda in primo luogo la effettiva generazione degli auditable events e, successivamente, la loro corretta registrazione e manutenzione. Tuttavia il provvedimento del Garante non affronta questi aspetti, prevedendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione del log degli “accessi” (login) e la loro archiviazione per almeno sei mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in base al contesto in cui avviene il trattamento, senza alcuna pretesa di instaurare in modo generalizzato, e solo con le prescrizioni del provvedimento, un regime rigoroso di registrazione degli usage data dei sistemi informativi.
  • Si individuano livelli di robustezza specifici per la garanzia della integrità?
    No. La valutazione è lasciata al titolare, in base al contesto operativo (cfr. faq n. 14).
  • Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
    Quelli descritti al paragrafo 4.4 del provvedimento e ribaditi al punto 2, lettera e), del dispositivo. L’adeguatezza è da valutare in rapporto alle condizioni organizzative e operative dell’organizzazione.

Ogni organizzazione è poi libera di decidere il suo livello di sicurezza, quindi si possono anche conservare i log di tutti, ma bisogna essere in grado di filtrare quelli degli AS.

Si devono quindi mettere in pratica delle verifiche periodiche sull’attività dell’AS e conservarne gli atti (vanno bene anche delle check list di controllo). Le verifiche devono essere almeno annuali.

Caso 2. AS Esterni.

In questo caso i compiti delegabili sono:

  • Nomina e conservazione del registro  degli AS
  • Verifica periodica delle attività degli AS

Non è delegabile invece la divulgazione degli AS che trattano dati del personale. La lista verrà data dagli Outsourcers.

Le modalità di delega:

  • Compiti delegati assegnati tramite lettera di incarico
  • Le lettere d’incarico devono essere sottoscritte per accettazione.

Ovviamente la funzione delegata deve gia’ essere stata incaricata al trattamento.

Ed ovviamente i casi possono essere diversi e vanno studiati volta per volta (Outsourcing completo, parziale, occasionale).

Quindi: prima del 15 dicembre è d’obbligo scrivere alle società che fanno trattamenti in Outsourcing o gestiscono in Outsourcing i sistemi.

E fino a qui gia’ i mal di testa sono notevoli. Ma si puo’ andare oltre, soprattutto in due casi ulteriori:

  1. Contratto di Outsourcing di società estera a cliente italiano;
  2. Contratto di Outsourcing di società italiana a cliente estero.

Nel primo caso: intra o extra UE? Che clausole di privacy utilizzare? Una cosa è certa: la società italiana è la titolare dei dati e quindi obbligo di nomina.

Nel secondo caso, la società italiana non è titolare ma deve comunque nominare il responsabile dei dati e comunque non si applica il provvedimento.

Penso sia tutto. Per il momento

Articoli Correlati

Privacy: nuova proroga per il provvedimento relativo agli amministratori di sistema

Direttamente dal sito del Garante, ulteriore proroga al 15 di dicembre 2009.

Amministratori di sistema

Il Garante per la protezione dei dati personali ha integrato e parzialmente modificato il provvedimento relativo agli “amministratori di sistema”, recependo alcune indicazioni pervenute, anche da associazioni di categoria, nel corso della consultazione pubblica conclusasi il 31 maggio. Con le nuove disposizioni il Garante intende facilitare il corretto adempimento alle prescrizioni impartite, mantenendo comunque elevato il livello di protezione dei dati personali e le garanzie per i cittadini.

L’Autorità, in particolare, ha consentito che gli adempimenti connessi all’individuazione degli amministratori di sistema e alla tenuta dei relativi elenchi possano essere effettuati, oltre che dai titolari, anche dai responsabili del trattamento. Ciò allo scopo di rendere tali obblighi più agevoli per quelle realtà aziendali nelle quali determinati servizi informatici vengano svolti da società esterne.

Di conseguenza – limitatamente alle misure tecniche e organizzative necessarie per quanto richiesto – il termine per l’adozione delle prescrizioni è stato prorogato al 15 dicembre prossimo.

Roma, 26 giugno 2009

Articoli Correlati

Amministratore di sistema – le faq del garante

Direttamente dal sito del Garante della Privacy, la cui versione integrale è qui.

Risposte alle domande più frequenti (FAQ)  

1 Cosa deve intendersi per “amministratore di sistema”?
2 Cosa vuol dire la locuzione “Qualora l’attività degli ADS riguardi anche indirettamente servizi o sistemi che…”
3 Il caso di uso esclusivo di un personal computer da parte di un solo amministratore di sistema rientra nell’ambito applicativo del 
provvedimento?
4 Relativamente all’obbligo di registrazione degli accessi logici degli AdS, sono compresi anche i sistemi client oltre che quelli server?
5 Cosa si intende per operato dell’amministratore di sistema soggetto a controllo almeno annuale?
6 Chiarire i casi di esclusione dall’obbligo di adempiere al
 provvedimento.
7 Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS?
8 Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
9 Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…)
10 Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log?
11 Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo
scopo della verifica deve prevedere un’analisi dei rischi?
12 Come va interpretata la caratteristica di inalterabilità dei log?
13 Si individuano livelli di robustezza specifici per la garanzia della integrità dei log?
14 Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
15 Cosa dobbiamo intendere per evento che deve essere registrato nel log? Solo l’accesso o anche le attività eseguite?
16 Quali sono le finalità di audit che ci dobbiamo porre con la registrazione e raccolta di questi log?
17 Cosa si intende per “consultazione in chiaro”?
18 Il regime di conoscibilità degli amministratori di sistema è da intendersi per i soli trattamenti inerenti i dati del personale e dei lavoratori?
19 La registrazione degli accessi è relativa al sistema operativo o anche ai DBMS?
20 Nella designazione degli amministratori di sistema occorre valutare i requisiti morali?
21 Cosa si intende per “estremi identificativi” degli amministratori di sistema?
22 E’ corretto affermare che l’accesso a livello applicativo non rientri nel perimetro degli adeguamenti, in quanto l’accesso a una applicazione informatica è regolato tramite profili autorizzativi che disciplinano per tutti gli utenti i trattamenti consentiti sui dati?
23 Si chiede se sia necessario conformarsi al
 provvedimento nel caso della fornitura di servizi di gestione sistemistica a clienti esteri (housing, hosting, gestione applicativa, archiviazione remota…) da parte di una società italiana non titolare dei dati gestiti.
24 Si possono ritenere esclusi i trattamenti relativi all’ordinaria attività di supporto delle manutenzione degli immobili sociali ecc…). Ci si riferisce ai trattamenti con strumenti elettronici finalizzati, ad esempio, alla gestione dell’autoparco, alle procedure di acquisto dei materiali di consumo, alla aziende, che non riguardino dati sensibili, giudiziari o di traffico telefonico/telematico?

 

 

 

1) Cosa deve intendersi per “amministratore di sistema”?
In assenza di definizioni normative e tecniche condivise, nell’ambito del 
provvedimento del Garante l’amministratore di sistema è assunto quale figura professionale dedicata alla gestione e alla manutenzione di impianti di elaborazione con cui vengano effettuati trattamenti di dati personali, compresi i sistemi di gestione delle basi di dati, i sistemi software complessi quali i sistemi ERP (Enterprise resource planning) utilizzati in grandi aziende e organizzazioni, le reti locali e gli apparati di sicurezza, nella misura in cui consentano di intervenire sui dati personali.

Il Garante non ha inteso equiparare gli “operatori di sistema” di cui agli articoli del Codice penale relativi ai delitti informatici, con gli “amministratori di sistema”: questi ultimi sono dei particolari operatori di sistema, dotati di specifici privilegi.

Anche il riferimento al d.P.R. 318/1999 nella premessa del provvedimento è puramente descrittivo poiché la figura definita in quell’atto normativo (ormai abrogato) è di minore portata rispetto a quella cui si fa riferimento nel provvedimento.

Non rientrano invece nella definizione quei soggetti che solo occasionalmente intervengono (p.es., per scopi di manutenzione a seguito di guasti o malfunzioni) sui sistemi di elaborazione e sui sistemi software.

 

 

 

2) Cosa vuol dire la locuzione “Qualora l’attività degli ADS riguardi anche indirettamente servizi o sistemi che…”
I titolari sono tenuti a instaurare un regime di conoscibilità dell’identità degli amministratori di sistema, quale forma di trasparenza interna all’organizzazione a tutela dei lavoratori, nel caso in cui un amministratore di sistema, oltre a intervenire sotto il profilo tecnico in generici trattamenti di dati personali in un’organizzazione, tratti anche dati personali riferiti ai lavoratori operanti nell’ambito dell’organizzazione medesima o sia nelle condizioni di acquisire conoscenza di dati a essi riferiti (in questo senso il riferimento nel testo del 
provvedimento all'”anche indirettamente…”).

 

 

 

3) Il caso di uso esclusivo di un personal computer da parte di un solo amministratore di sistema rientra nell’ambito applicativo del provvedimento?
Non è possibile rispondere in generale. In diversi casi, anche con un personal computer possono essere effettuati delicati trattamenti rispetto ai quali il titolare ha il dovere di prevedere e mettere in atto anche le misure e gli accorgimenti previsti nel provvedimento. Nel caso-limite di un titolare che svolga funzioni di unico amministratore di sistema, come può accadere in piccolissime realtà d’impresa, non si applicheranno le previsioni relative alla verifica delle attività dell’amministratore né la tenuta del log degli accessi informatici.

 

 

 

4) Relativamente all’obbligo di registrazione degli accessi logici degli AdS, sono compresi anche i sistemi client oltre che quelli  server?
Si, anche i client, intesi come “postazioni di lavoro informatizzate”, sono compresi tra i sistemi per cui devono essere registrati gli accessi degli AdS.

Nei casi più semplici tale requisito può essere soddisfatto tramite funzionalità già disponibili nei più diffusi sistemi operativi, senza richiedere necessariamente l’uso di strumenti software o hardware aggiuntivi. Per esempio, la registrazione locale dei dati di accesso su una postazione, in determinati contesti, può essere ritenuta idonea al corretto adempimento qualora goda di sufficienti garanzie di integrità.

Sarà comunque con valutazione del titolare che dovrà essere considerata l’idoneità degli strumenti disponibili oppure l’adozione di strumenti più sofisticati, quali la raccolta dei log centralizzata e l’utilizzo di dispositivi non riscrivibili o di tecniche crittografiche per la verifica dell’integrità delle registrazioni.

 

 

 

5) Cosa si intende per operato dell’amministratore di sistema soggetto a controllo almeno annuale?
È da sottoporre a verifica l’attività svolta dall’amministratore di sistema nell’esercizio delle sue funzioni. Va verificato che le attività svolte dall’amministratore di sistema siano conformi alle mansioni attribuite, ivi compreso il profilo relativo alla sicurezza.

 

 

 

6) Chiarire i casi di esclusione dall’obbligo di adempiere al provvedimento.
Sono esclusi i trattamenti effettuati in ambito pubblico e privato a fini amministrativo-contabili che, ponendo minori rischi per gli interessati, sono stati oggetto delle misure di semplificazione introdotte nel corso del 2008 per legge (art. 29 d.l. 25 giugno 2008, n. 112, conv., con mod., con l. 6 agosto 2008, n. 133; art. 34 del Codice; Provv. Garante 27 novembre 2008.

 

 

 

7) Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS? [Rif. comma 2, lettera d]
Il 
provvedimento prevede che all’atto della designazione di un amministratore di sistema, venga fatta “elencazione analitica” degli ambiti di operatività consentiti in base al profilo di autorizzazione assegnato, ovvero la descrizione puntuale degli stessi, evitando l’attribuzione di ambiti insufficientemente definiti, analogamente a quanto previsto al comma 4 dell’art. 29 del Codice riguardante i responsabili del trattamento.

 

 

 

8 ) Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
No, è sufficiente specificare l’ambito di operatività in termini più generali, per settori o per aree applicative, senza obbligo di specificarlo rispetto a singoli sistemi, a meno che non sia ritenuto necessario in casi specifici.

 

 

 

9) Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…) [Rif. comma 2, lettera f]
Per access log si intende la registrazione degli eventi generati dal sistema di autenticazione informatica all’atto dell’accesso o tentativo di accesso da parte di un amministratore di sistema o all’atto della sua disconnessione nell’ambito di collegamenti interattivi a sistemi di elaborazione o a sistemi software.

Gli event records generati dai sistemi di autenticazione contengono usualmente i riferimenti allo “username” utilizzato, alla data e all’ora dell’evento (timestamp), una descrizione dell’evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, o di una condizione di errore, quale linea di comunicazione o dispositivo terminale sia stato utilizzato…).

 

 

 

10) Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log? [Rif. comma 2, lettera f]
Qualora il sistema di log adottato generi una raccolta dati più ampia, comunque non in contrasto con le disposizioni del Codice e con i principi della protezione dei dati personali, il requisito del provvedimento è certamente soddisfatto. Comunque è sempre possibile effettuare un’estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.

 

 

 

11) Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo scopo della verifica deve prevedere un’analisi dei rischi?
La caratteristica di completezza è riferita all’insieme degli eventi censiti nel sistema di log, che deve comprendere tutti gli eventi di accesso interattivo che interessino gli amministratori di sistema su tutti i sistemi di elaborazione con cui vengono trattati, anche indirettamente, dati personali. L’analisi dei rischi aiuta a valutare l’adeguatezza delle misure di sicurezza in genere, e anche delle misure tecniche per garantire attendibilità ai log qui richiesti.

 

 

 

12) Come va interpretata la caratteristica di inalterabilità dei log?
Caratteristiche di mantenimento dell’integrità dei dati raccolti dai sistemi di log sono in genere disponibili nei più diffusi sistemi operativi, o possono esservi agevolmente integrate con apposito software. Il requisito può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili. In casi più complessi i titolari potranno ritenere di adottare sistemi più sofisticati, quali i log server centralizzati e “certificati”.

È ben noto che il problema dell’attendibilità dei dati di audit, in genere, riguarda in primo luogo la effettiva generazione degli auditable events e, successivamente, la loro corretta registrazione e manutenzione. Tuttavia il provvedimento del Garante non affronta questi aspetti, prevedendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione del log degli “accessi” (login) e la loro archiviazione per almeno sei mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in base al contesto in cui avviene il trattamento, senza alcuna pretesa di instaurare in modo generalizzato, e solo con le prescrizioni del provvedimento, un regime rigoroso di registrazione degli usage data dei sistemi informativi.

 

 

 

13) Si individuano livelli di robustezza specifici per la garanzia della integrità?
No. La valutazione è lasciata al titolare, in base al contesto operativo (cfr. faq n. 14).

 

 

 

14) Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
Quelli descritti al paragrafo 4.4 del provvedimento e ribaditi al punto 2, lettera e), del dispositivo. L’adeguatezza è da valutare in rapporto alle condizioni organizzative e operative dell’organizzazione.

 

 

 

15) Cosa dobbiamo intendere per evento che deve essere registrato nel log? Solo l’accesso o anche le attività eseguite?
Il provvedimento non chiede in alcun modo che vengano registrati dati sull’attività interattiva (comandi impartiti, transazioni effettuate) degli amministratori di sistema. Si veda la risposta alla faq n. 11.

 

 

 

16) Quali sono le finalità di audit che ci dobbiamo porre con la registrazione e raccolta di questi log?
La raccolta dei log serve per verificare anomalie nella frequenza degli accessi e nelle loro modalità (orari, durata, sistemi cui si è fatto accesso…). L’analisi dei log può essere compresa tra i criteri di valutazione dell’operato degli amministratori di sistema.

 

 

 

17) Cosa si intende per “consultazione in chiaro”?
Il riferimento in premessa (par. 1 “Considerazioni preliminari”) è alla criticità di mansioni che comportino la potenzialità di violazione del dato personale anche in condizioni in cui ne sia esclusa la conoscibilità, come può avvenire, per esempio, nel caso della cifratura dei dati.

 

 

 

18) Il regime di conoscibilità degli amministratori di sistema è da intendersi per i soli trattamenti inerenti i dati del personale e dei lavoratori?
Si.

 

 

 

19) La registrazione degli accessi è relativa al sistema operativo o anche ai DBMS?
Tra gli accessi logici a sistemi e archivi elettronici sono comprese le autenticazioni nei confronti dei data base management systems (DBMS), che vanno registrate.

 

 

 

20) Nella designazione degli amministratori di sistema occorre valutare i requisiti morali? [Rif. comma 2, lettera a]
No. Il riferimento alle caratteristiche da prendere in considerazione, al comma 2, lettera a), del dispositivo, è all’esperienza, alla capacità e all’affidabilità del soggetto designato. Si tratta quindi di qualità tecniche, professionali e di condotta, non di requisiti morali.

 

 

 

21) Cosa si intende per “estremi identificativi” degli amministratori di sistema?
Si tratta del minimo insieme di dati identificativi utili a individuare il soggetto nell’ambito dell’organizzazione di appartenenza. In molti casi possono coincidere con nome, cognome, funzione o area organizzativa di appartenenza.

 

 

 

22) È corretto affermare che l’accesso a livello applicativo non rientri nel perimetro degli adeguamenti, in quanto l’accesso a una applicazione informatica è regolato tramite profili autorizzativi che disciplinano per tutti gli utenti i trattamenti consentiti sui dati?
Si. L’accesso applicativo non è compreso tra le caratteristiche tipiche dell’amministratore di sistema e quindi non è necessario, in forza del provvedimento del Garante, sottoporlo a registrazione.

 

 

 

23) Si chiede se sia necessario conformarsi al provvedimento nel caso della fornitura di servizi di gestione sistemistica a clienti esteri (housing, hosting, gestione applicativa, archiviazione remota…) da parte di una società italiana non titolare dei dati gestiti.
Il provvedimento si rivolge solo ai titolari di trattamento. I casi esemplificati prefigurano al più una responsabilità di trattamento (secondo il Codice italiano), e sono quindi esclusi dall’ambito applicativo del provvedimento.

 

 

 

24) Si possono ritenere esclusi i trattamenti relativi all’ordinaria attività di supporto delle aziende, che non riguardino dati sensibili, giudiziari o di traffico telefonico/telematico? Ci si riferisce ai trattamenti con strumenti elettronici finalizzati, ad esempio, alla gestione dell’autoparco, alle procedure di acquisto dei materiali di consumo, alla manutenzione degli immobili sociali ecc…).
Tali trattamenti possono considerarsi compresi tra quelli svolti per ordinarie finalità amministrativo-contabili e, come tali, esclusi dall’ambito applicativo del provvedimento.

Articoli Correlati

Amministratore di sistema, questo sconosciuto

Come molti sanno, le aziende in questi giorni si stanno districando sull’interpretazione degli obblighi (scadenza 30 giugno 2009) introdotti con il provvedimento del Garante della Privacy del 27 novembre 2008 relativo a “misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema, pubblicato sulla G.U. n.300 del 24 dicembre 2008 che vi invito ad andare a leggere su http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499.

Rimane aperta una questione: chi è l’amministratore di sistema, e soprattutto come sceglierlo in base alle capacità, esperienza come richiesto.

Ci può venire in aiuto  il modello EUCIP, riconosciuto a livello internazionale, che cosi’ recita:

L’Amministratore di Sistemi informatici è la figura professionale che svolge il ruolo di supervisione dell’infrastruttura ICT in una piccola-media azienda o negli uffici decentrati di una grande organizzazione.
Nel suo ruolo, l’Amministratore di Sistemi informatici è in grado di:
•   amministrare sistemi informativi di contenute dimensioni, tipicamente configurati in modalità client-server;
•   identificare e risolvere i problemi più semplici e ricorrenti;
•   diagnosticare problemi di più elevata complessità e richiedere l’intervento dello specialista in grado di risolverli;
•   identificare le esigenze (aggiornamenti, modifiche, ampliamenti, ecc.) del sistema informativo e fungere da interfaccia con gli specialisti/fornitori;
•   essere il punto di riferimento per gli utenti del sistema informativo di cui è supervisore.
Un Amministratore di sistemi informatici secondo lo standard EUCIP deve essere in grado di amministrare un insieme di sistemi, tipicamente inseriti in una LAN, comprendenti sia server che PC utilizzati da utenti.
Ad un Amministratore di sistemi informatici viene richiesta la capacità di dare suggerimenti agli utenti aiutandoli e risolvendo i problemi più semplici, così come la capacità di essere autonomo in una prima fase di analisi dei problemi, individuando le necessità di intervento da parte di specialisti e collaborando efficacemente con loro alla risoluzione dei medesimi.
Viene inoltre richiesta la capacità di rilevare le esigenze di aggiornamento del sistema e di fungere da punto di riferimento tanto per gli utenti interni quanto per i fornitori e gli specialisti esterni.
Le competenze dell’Amministratore di Sistemi informatici sono articolate in cinque settori:
1. Hardware del PC
2. Sistemi operativi
3. LAN e servizi di rete
4. Uso esperto della rete
5. Sicurezza informatica

Un profilo quindi non banale, spesso non presente nelle aziende, a volte presente come autodidatta e magari a tempo non pieno.

La difficoltà che si presenta alle aziende in questo momento, a mio avviso, è come districarsi nel moltiplicarsi di offerte di società di informatica improvvisate, senza le necessarie competenze tecniche e gestionali, sfruttando, purtroppo, la scarsa capacità degli imprenditori di valutare questo preciso settore, purtroppo con una stora alle spalle ancora poco matura (almeno qui in Italia).

Articoli Correlati