log amministratori di sistema

[Piergiorgio Venuti]

>> La problematice è che a mio avviso non è applicabile come soluzione
>> > al garante. Il provvedimento dice che il dato deve essere mantenuto
>> > in modo sicuro e immodificabile. Splunk non è in grado di garantire
>> > la immodificabilità del dato. Per questa prerogativa il garante fa
>> > riferimento a sistemi di memorizzazione che garantiscono
>> > l'immodificabilità, ed in questo caso per ignoranza cita supporti
>> > ottici quando si potrebbero utilizzare sistemi di tipo WORM, o firma
>> > debole.
>
> la questione e' abbastanza complessa.
> Premetto che non ho le conoscenze legali e/o di legalese sufficienti,
> e per l'interpretazione corretta del dps mi sono affidato a uno studio
> legale.
> Il garante non parla mai di supporti worm, l'immodificabilita' del
> dato e' in realta' una "garanzia che il dato non sia stato alterato",
> e in questo caso, visto che ogni dato indicizzato e archiviato da
> splunk viene marcato con un hash, direi che soddisfa in pieno i
> requisiti del dps.

Ciao,
vorrei segnalare che esistono prodotti di mercato (evito di fare
pubblicità visto che la mia società ne fornisce uno) in grado di
conservare i log messages in database cifrati proprietari.
Se la "macchina" contenente il db venisse violata resterebbe ancora da
violare il db per alterare i dati. Ovviamente da admin del server che
raccoglie i log si potrebbe cancellare il db ma per questo motivo ci
devono essere policy di disaster recovery che archiviano il db in altri
siti.

Concordo che un hash di un archivio salvato tra l'altro nella stessa
posizione dell'archivio non da nessuna garanzia di inalterabilità.

Solo per mia curiosità... come vi state organizzando (se vi state
organizzando) per fronteggiare la disposizione del garante? Soluzioni
fai da te? Soluzioni commerciali? State ammazzando gli amministratori di
sistema?

--
+------------------------------+
| Ing. Piergiorgio Venuti, CCSP|
| 0x15521C4E |
+------------------------------+

[Stefano Zanero]

Piergiorgio Venuti wrote:

>> Il garante non parla mai di supporti worm, l'immodificabilita' del
>> dato e' in realta' una "garanzia che il dato non sia stato alterato",
>> e in questo caso, visto che ogni dato indicizzato e archiviato da
>> splunk viene marcato con un hash, direi che soddisfa in pieno i
>> requisiti del dps.
>
> Ciao,
> vorrei segnalare che esistono prodotti di mercato (evito di fare
> pubblicità visto che la mia società ne fornisce uno) in grado di
> conservare i log messages in database cifrati proprietari.

La security through obscurity non e' proprio il massimo della vita...

> Se la "macchina" contenente il db venisse violata resterebbe ancora da
> violare il db per alterare i dati.

Se la macchina e' violata, il DB e' violato.

> Ovviamente da admin del server che
> raccoglie i log si potrebbe cancellare il db ma per questo motivo ci
> devono essere policy di disaster recovery che archiviano il db in altri
> siti.

Allora quelle policy, da sole e senza il prodotto in questione, sono
efficaci tanto quanto il prodotto in questione.

> Concordo che un hash di un archivio salvato tra l'altro nella stessa
> posizione dell'archivio non da nessuna garanzia di inalterabilità.

Ne' la cifratura con una chiave che sta nella memoria della macchina
violata.

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[Luca Caldiero]

Piergiorgio Venuti wrote:

> Ciao,
> vorrei segnalare che esistono prodotti di mercato (evito di fare
> pubblicità visto che la mia società ne fornisce uno) in grado di
> conservare i log messages in database cifrati proprietari.
> Se la "macchina" contenente il db venisse violata resterebbe ancora
> da violare il db per alterare i dati.
> Ovviamente da admin del server che
> raccoglie i log si potrebbe cancellare il db ma per questo motivo ci
> devono essere policy di disaster recovery che archiviano il db in
> altri siti.
> Concordo che un hash di un archivio salvato tra l'altro nella stessa
> posizione dell'archivio non da nessuna garanzia di inalterabilità.

Buongiorno,
personalmente ritengo che lo spirito con cui il Garante della Privacy abbia in mente l'ormai noto provvedimento sia quello di iniziare a mettere un freno alla assoluta libertà e conseguente impunità di utilizzo e manipolazione di dati (personali e sensibili) da parte degli amministratori di sistema.
A poco serve fare terrorismo psicologico, cercando di interpretare, talvolta per evidenti e più o meno giustificabili fini commerciali, nella maniera più restrittiva ed "integralista" alcune parole del provvedimento.
Esistono anche soluzioni software completamente gratuite (alcune open source) in grado di fornire supporto all'applicazione del decreto.

L'adeguatezza delle misure che qualsiasi azienda intenderà adottare è responsabilità delle persone e del loro buon senso in primis; la tecnologia viene dopo.

Nessuna soluzione, infine, riuscirà mai ad eliminare dalla mente di chiunque, compresa la mia, la fatidica domanda: "Quis custodiet ipsos custodes?".

Luca Caldiero.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4562 (20091101) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Fabio Invernizzi]

On 10/11/2009 20:51, Stefano Zanero wrote:
>> > Concordo che un hash di un archivio salvato tra l'altro nella stessa
>> > posizione dell'archivio non da nessuna garanzia di inalterabilità.
>
> Ne' la cifratura con una chiave che sta nella memoria della macchina
> violata.

come qualcun altro su questa lista pensavo ad una soluzione "fatta in
casa" con una firma con marca temporale. secondo voi sarebbe una
soluzione valida?

un'altra idea, per evitare la marca temporale, era quella di inviare gli
hash dei log su una casella pec che ne certifichi quindi l'orario di
ricezione...

ovviamente i log sarebbero modificabili dalla ricezione dell'evento fino
al momento in qui verrebbero processati/marcati temporalmente.

--
ciao,
Fabio.

[Stefano Zanero]

Fabio Invernizzi wrote:

> come qualcun altro su questa lista pensavo ad una soluzione "fatta in
> casa" con una firma con marca temporale. secondo voi sarebbe una
> soluzione valida?

Aredaje. La firma DI CHI ? Per attestare COSA ? Apposta QUANDO ?

Se la appone automaticamente il log server... tanto vale fidarsi del log
server :)

Non fate le cose piu' complicate del necessario, evvia!

> un'altra idea, per evitare la marca temporale, era quella di inviare gli
> hash dei log su una casella pec che ne certifichi quindi l'orario di
> ricezione...

Ma NESSUNO lo impone, ci deve essere un RIFERIMENTO temporale, non una
MARCA temporale. Sono due cose diverse. Il RIFERIMENTO e' quello che il
tuo syslog vanilla ci mette davanti :)

Lo dice il provvedimento: misure di sicurezza ADEGUATE ALLO SCOPO per
cui la conservazione e' stata imposta. Lo scopo e' "non consentire ai
sysadmin di fare l'accidenti che gli pare senza controlli". Per cui i
log devono essere "inalterabili" nel senso che non deve essere
consentito ai soggetti monitorati di manipolarli !

Ragazzi, state impantanandovi su una cosa SEM PLI CE !

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[Fabio Invernizzi]

Stefano Zanero ha scritto:
> Fabio Invernizzi wrote:
>
>> come qualcun altro su questa lista pensavo ad una soluzione "fatta in
>> casa" con una firma con marca temporale. secondo voi sarebbe una
>> soluzione valida?
>
> Aredaje. La firma DI CHI ? Per attestare COSA ? Apposta QUANDO ?

la firma mia (del server) per attestare il momento in cui l'ho apposta,
per garantire il fatto che neanche io, amminitratore della macchina, ho
successivamente modificato i log. (Ovviamente è indispensabile la marca
temporale perché una entità esterna certifichi l'orario della firma.)

Il quando è un problema ovviamente... giornalmente? <brrr> questo è
sicuramente il punto più debole.

Ho dato per scontato che questa idea nasce dal fatto che in piccole
realtà l'amministratore di sistema si ritroverebbe a gestire anche
questa macchina.

...
> Lo dice il provvedimento: misure di sicurezza ADEGUATE ALLO SCOPO per
> cui la conservazione e' stata imposta. Lo scopo e' "non consentire ai
> sysadmin di fare l'accidenti che gli pare senza controlli". Per cui i
> log devono essere "inalterabili" nel senso che non deve essere
> consentito ai soggetti monitorati di manipolarli !

Appunto... un syslog centralizzato è sufficiente... a patto che io
amministratore non abbia le password.

Sono obbligato a dare la cosa in outsourcing? Ad acquistare una scatola
nera da mettere sulla mia rete? La risolvo dando la password di root
alla segreteria o all'AD che la mette in cassaforte?

>
> Ragazzi, state impantanandovi su una cosa SEM PLI CE !

Sicuramente. A parte una implementazione che rispetti i requisiti minimi
ero interessato alla possibilità teorica di implementare una
inalterabilità dei log basata su qualcosa di meno "fisico" di una
stampante ad aghi o un dispositivo WORM.

--
Ciao,
Fabio.

[Stefano Zanero]

Fabio Invernizzi wrote:

> la firma mia (del server) per attestare il momento in cui l'ho apposta,

Allora non e' la firma TUA ma del SERVER, quindi apposta con una chiave
che sta sul server. Quindi chi ha accesso al server, puo' fare il cavolo
che gli pare (TM)

> per garantire il fatto che neanche io, amminitratore della macchina, ho
> successivamente modificato i log. (Ovviamente è indispensabile la marca
> temporale perché una entità esterna certifichi l'orario della firma.)

Aaaaaah, quindi siamo tornati alla marcatura temporale. Che costa un tot
a linea di log, oppure:

> Il quando è un problema ovviamente... giornalmente? <brrr> questo è
> sicuramente il punto più debole.

E quindi, che cosa lo facciamo a fare ? Anche perche', ovviamente,
questo significa che nell'ultimo batch di cose prima della marcatura
temporale tu puoi comunque fare il cavolo che ti pare (sempre TM)

> Ho dato per scontato che questa idea nasce dal fatto che in piccole
> realtà l'amministratore di sistema si ritroverebbe a gestire anche
> questa macchina.

E allora non va bene, qualunque idea tu ti faccia venire non ha senso e
non garantisce l'integrita', se il controllato controlla il controllore.

> Appunto... un syslog centralizzato è sufficiente... a patto che io
> amministratore non abbia le password.

Eeeeeeesattamente.

> Sono obbligato a dare la cosa in outsourcing? Ad acquistare una scatola
> nera da mettere sulla mia rete? La risolvo dando la password di root
> alla segreteria o all'AD che la mette in cassaforte?

Sono tutte soluzioni potenziali.

La Soluzione (TM) come sempre "dipende" :-)

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[KJK::Hyperion]

Stefano Zanero wrote:
> Aaaaaah, quindi siamo tornati alla marcatura temporale. Che costa un tot
> a linea di log

domanda così per curiosità, esistono diversi servizi gratuiti di marca
temporale, come http://timestamp.verisign.com/scripts/timestamp.dll o
http://timestamp.globalsign.com/scripts/timstamp.dll (con protocollo
Microsoft Authenticode [1]), usati ampiamente per le firme digitali del
software. Questi hanno una qualche validità legale o no?

[1]
http://msdn.microsoft.com/en-us/library/bb931395(VS.85).aspx#implementation_details_and_wire_format

[Stefano Zanero]

KJK::Hyperion wrote:
> Stefano Zanero wrote:
>> Aaaaaah, quindi siamo tornati alla marcatura temporale. Che costa un tot
>> a linea di log
>
> domanda così per curiosità, esistono diversi servizi gratuiti di marca
> temporale, come http://timestamp.verisign.com/scripts/timestamp.dll o
> http://timestamp.globalsign.com/scripts/timstamp.dll (con protocollo
> Microsoft Authenticode [1]), usati ampiamente per le firme digitali del
> software. Questi hanno una qualche validità legale o no?

Quelli nello specifico no, perche' non corrispondono ai requisiti di legge.

Per inciso, mi pare che siano SOLO per authenticode, quindi immagino uno
si debba comprare un certificato di code-signing.

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[Claudio Telmon]

Stefano Zanero wrote:
> KJK::Hyperion wrote:
>> domanda così per curiosità, esistono diversi servizi gratuiti di marca
>> temporale, come http://timestamp.verisign.com/scripts/timestamp.dll o
>> http://timestamp.globalsign.com/scripts/timstamp.dll (con protocollo
>> Microsoft Authenticode [1]), usati ampiamente per le firme digitali del
>> software. Questi hanno una qualche validità legale o no?
>
> Quelli nello specifico no, perche' non corrispondono ai requisiti di legge.

Mi sono perso, quali requisiti di legge? Non stavamo parlando di log?
Non mi pare che ci siano requisiti di legge sui timestamp.

ciao

- Claudio

--

Claudio Telmon
***@telmon.org
http://www.telmon.org

[Marco Ermini]

2009/11/13 Fabio Invernizzi:
[...]
> La risolvo dando la password di root
> alla segreteria o all'AD che la mette in cassaforte?
[...]

E perché no? alla fine è la soluzione più semplice e sicura, e in
molte realtà aziendali (sia grandi che piccole) permette di rispettare
le policy. Alla fine, il responsabile del business è chi prende le
decisioni nel business. (si spera l'AD, non la segretaria, anche se
niente si può escludere ;-))


Cordiali saluti
--
Marco Ermini
***@human # mount -t life -o ro /dev/dna /genetic/research
http://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"
Sent from Salzburg, Austria
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Domenico Viggiani]

* Marco Ermini wote:
> Fabio Invernizzi wrote:
> [...]
> > La risolvo dando la password di root
> > alla segreteria o all'AD che la mette in cassaforte?
>
> E perché no? alla fine è la soluzione più semplice e sicura, e in
> molte realtà aziendali (sia grandi che piccole) permette di rispettare
> le policy.

Proseguendo sulla linea della semplicità massima, mi date un parere sul
seguente insieme di soluzioni che stiamo adottando, in un'azienda di medie
dimensioni?
- server Linux: autenticazione su Active Directory; accesso diretto da rete
come "root" e con user "generiche" disabilitato (rimane da console...);
syslog centralizzato di eventi di security
- server Windows: password di Domain Administrator non nota ai sysadmin, i
quali adoperano il loro account personale; Administrator locale
disabilitato; logging centralizzato tramite Snare
- log centralizzato: server syslog non accessibile ai sysadmin

Parlando concretamente: è davvero necessario evidenziare gli accessi
amministrativi su TUTTE le macchine? E per i PC cosa va fatto? Che altro
bisogna fare per essere ragionevolmente conformi?

La cosa può diventare drammatica!

--
Domenico Viggiani

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Simone ([e-mail])]

On 17/nov/2009, at 12.33, Domenico Viggiani wrote:

> * Marco Ermini wote:
>> Fabio Invernizzi wrote:
>> [...]
>>> La risolvo dando la password di root
>>> alla segreteria o all'AD che la mette in cassaforte?
>>
>> E perché no? alla fine è la soluzione più semplice e sicura, e in
>> molte realtà aziendali (sia grandi che piccole) permette di rispettare
>> le policy.
>
> Proseguendo sulla linea della semplicità massima, mi date un parere sul
> seguente insieme di soluzioni che stiamo adottando, in un'azienda di medie
> dimensioni?
> - server Linux: autenticazione su Active Directory; accesso diretto da rete
> come "root" e con user "generiche" disabilitato (rimane da console...);
> syslog centralizzato di eventi di security
> - server Windows: password di Domain Administrator non nota ai sysadmin, i
> quali adoperano il loro account personale; Administrator locale
> disabilitato; logging centralizzato tramite Snare
> - log centralizzato: server syslog non accessibile ai sysadmin

L'unica parte che vedo scoperta ma che alla quale magari hai già dato soluzione e non hai indicato nella tua mail è: l'accesso alla "entita" preposta a fare da repositori avrà sicuramente un suo amministratore.
Hai curato che questo utenza non sia disponibile al "controllato" ma solo al "controllore"?

>
> Parlando concretamente: è davvero necessario evidenziare gli accessi
> amministrativi su TUTTE le macchine? E per i PC cosa va fatto? Che altro
> bisogna fare per essere ragionevolmente conformi?
>
Purtroppo tanti stanno facendo terrorismo. Il garante chiede, e questa è una interpretazione che mi sono dato, di tenere traccia di tutti gli operatori che fanno amministrazione sui sistemi informativi che nel DPS sono stati indicati per il mantenimento delle informazioni ritenute sensibili e personali.


> La cosa può diventare drammatica!
>
> --
> Domenico Viggiani
>
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Simone (***@gmail.com) wrote:

>> Parlando concretamente: è davvero necessario evidenziare gli
>> accessi amministrativi su TUTTE le macchine? E per i PC cosa va
>> fatto? Che altro bisogna fare per essere ragionevolmente conformi?
>>
> Purtroppo tanti stanno facendo terrorismo. Il garante chiede, e
> questa è una interpretazione che mi sono dato, di tenere traccia di
> tutti gli operatori che fanno amministrazione sui sistemi informativi
> che nel DPS sono stati indicati per il mantenimento delle
> informazioni ritenute sensibili e personali.

Non e' un'interpretazione, quanto la lettera della norma e nella FAQ :)

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.

[omissis]

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.

[omissis]

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.

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/19 Piero Cavina <***@gmail.com>:

>
> Quindi sostanzialmente i PC avrebbero le stesse problematiche dei
> server.. invio a log centralizzato e disabilitare l'admin locale o
> rendere la (le) pwd nota a una sola persona..

Pensandoci meglio.. disabilitando gli admin locali (che in certe
situazioni può essere una rottura..) gli eventi di login dei domain
admins sono comunque registrati dai domain controller.. quindi sul PC
non devo loggare nulla. Potrebbe passare?


--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Domenico Viggiani]

* Piero Cavina:
> Pensandoci meglio.. disabilitando gli admin locali (che in certe
> situazioni può essere una rottura..) gli eventi di login dei domain
> admins sono comunque registrati dai domain controller.. quindi sul PC
> non devo loggare nulla. Potrebbe passare?
Noi ci stiamo regolando così.

Ciao
--
DV

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/17 Domenico Viggiani <***@tiscali.it>:

> Parlando concretamente: è davvero necessario evidenziare gli accessi
> amministrativi su TUTTE le macchine? E per i PC cosa va fatto? Che altro
> bisogna fare per essere ragionevolmente conformi?

Guardiamo per esempio questa FAQ..:
http://www.compliancenet.it/content/privacy-amministratori-di-sistema-risposte-alle-domande-piu-frequenti-faq

<< 4) Relativamente all'obbligo di registrazione degli accessi logici
degli AdS, sono compresi anche i sistemi client oltre che quelli
server

Sì, anche i client, intesi come "postazioni di lavoro informatizzate",
sono compresi tra i sistemi per cui devono essere registrati gli
accessi degli 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. >>

Al punto 4 si parla esplicitamente di tutti i client; al punto 11 la
definizione "sistemi con cui vengono trattati anche indirettamente.."
mi pare essere un sinonimo di client, anche se mi piacerebbe sapere
esattamente cosa intende l'autore con "indirettamente". Se è proprio
così, mi chiedo se può essere corretto perlomeno restringere il campo
ai client normalmente utilizzati dagli utenti che gestiscono i dati
personali / sensibili?

Quindi sostanzialmente i PC avrebbero le stesse problematiche dei
server.. invio a log centralizzato e disabilitare l'admin locale o
rendere la (le) pwd nota a una sola persona..


--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Domenico Viggiani wrote:

> Parlando concretamente: è davvero necessario evidenziare gli accessi
> amministrativi su TUTTE le macchine? E per i PC cosa va fatto?

Tutte le macchine (client inclusi) che trattano dati personali. Vedi FAQ
del Garante:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/20 Stefano Zanero <***@elet.polimi.it>:
> Domenico Viggiani wrote:
>
>> Parlando concretamente: è davvero necessario evidenziare gli accessi
>> amministrativi su TUTTE le macchine? E per i PC cosa va fatto?
>
> Tutte le macchine (client inclusi) che trattano dati personali. Vedi FAQ
> del Garante:
> http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499


Esiste una definizione concreta del termine "trattare"? Dal punto di
vista informatico la cosa può assumere sfumature molto diverse.

Esempio:

Dati su file server, l'utente li tratta aprendoli direttamente da un
disco del PC collegato a una share. Il PC "tratta" i dati? Beh direi
di sì..

Applicazione client/server, dati e logica in un database su server,
interfaccia utente (con qualche validazione preliminare dei dati) su
client (browser, ma non è detto). Il client è un PC, devo tracciare
anche gli accessi degli amministratori su questo PC?

Oppure: applicazione centralizzata, accesso con emulazione di
terminale su PC. Sul PC in effetti i dati arrivano sotto forma di
"schermate", si può dire che anche questa macchina effettua
"trattamenti"? Variante: remote desktop.

Thin client, che non sono altro che piccoli PC con su Linux o Windows
CE e vari programmi di emulazione / desktop remoto. Queste macchine
trattano i dati? Notare che alcuni thin client in realtà hanno anche
Open Office e possono montare share SMB.. però non esiste un concetto
di amministratore, almeno in quelli che conosco io.

--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Piero Cavina wrote:

> Esiste una definizione concreta del termine "trattare"? Dal punto di
> vista informatico la cosa può assumere sfumature molto diverse.

Come no ? Nella 196:
a) "trattamento", qualunque operazione o complesso di operazioni,
effettuati anche senza l'ausilio di strumenti elettronici, concernenti
la raccolta, la registrazione, l'organizzazione, la conservazione, la
consultazione, l'elaborazione, la modificazione, la selezione,
l'estrazione, il raffronto, l'utilizzo, l'interconnessione, il blocco,
la comunicazione, la diffusione, la cancellazione e la distruzione di
dati, anche se non registrati in una banca di dati;

Ovviamente non risponde direttamente alla tua domanda, ma considerando
che si parla anche di mera "consultazione", temo che anche un thin
client ricada nel perimetro del trattamento.

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/20 Stefano Zanero <***@elet.polimi.it>:

> l'estrazione, il raffronto, l'utilizzo, l'interconnessione, il blocco,
> la comunicazione, la diffusione, la cancellazione e la distruzione di
> dati, anche se non registrati in una banca di dati;

Quindi anche i router, gli switch ecc ecc (interconnessione, comunicazione..) ?

> Ovviamente non risponde direttamente alla tua domanda, ma considerando
> che si parla anche di mera "consultazione", temo che anche un thin
> client ricada nel perimetro del trattamento.

Ma in definitiva, quale sarebbe il senso del tracciare gli accessi
amministrativi ai client, quando sono usati solo come interfaccia
utente (emulazioni di terminale - applicazioni web)? Prevenire azioni
di spionaggio degli amministratori tramite installazione di keylogger?
Il fatto è che se la mettiamo su questo piano, gli amministratori
hanno mille risorse per accedere ai dati (modificarli magari è un po'
più complicato) senza lasciare tracce.


--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piergiorgio Venuti]

Ciao Stefano

>>>>> >>> >> Il garante non parla mai di supporti worm,
l'immodificabilita' del
>>>>> >>> >> dato e' in realta' una "garanzia che il dato non sia stato
alterato",
>>>>> >>> >> e in questo caso, visto che ogni dato indicizzato e
archiviato da
>>>>> >>> >> splunk viene marcato con un hash, direi che soddisfa in
pieno i
>>>>> >>> >> requisiti del dps.
>>> >> >
>>> >> > Ciao,
>>> >> > vorrei segnalare che esistono prodotti di mercato (evito di fare
>>> >> > pubblicità visto che la mia società ne fornisce uno) in grado di
>>> >> > conservare i log messages in database cifrati proprietari.
> >
> > La security through obscurity non e' proprio il massimo della vita...
> >
Non si parla di quello, è un db che utilizza certificati x.509, la
cifratura è asimmetrica ed è largamente utilizzata.

>>> >> > Se la "macchina" contenente il db venisse violata resterebbe
ancora da
>>> >> > violare il db per alterare i dati.
> >
> > Se la macchina e' violata, il DB e' violato.
> >
No fino a quando non viene ottenuto il certificato con la chiave privata
che non è conservato sulla macchina. Poi qui si potrebbe parlare una
vita, posso darti ragione ma direi che è un buon livello di sicurezza.

>>> >> > Ovviamente da admin del server che
>>> >> > raccoglie i log si potrebbe cancellare il db ma per questo
motivo ci
>>> >> > devono essere policy di disaster recovery che archiviano il db
in altri
>>> >> > siti.
> >
> > Allora quelle policy, da sole e senza il prodotto in questione, sono
> > efficaci tanto quanto il prodotto in questione.
> >
Parlavo solo di policy di disaster recovery, le policy di backup
all'interno si riferiscono sempre al db cifrato.

>>> >> > Concordo che un hash di un archivio salvato tra l'altro nella
stessa
>>> >> > posizione dell'archivio non da nessuna garanzia di inalterabilità.
> >
> > Ne' la cifratura con una chiave che sta nella memoria della macchina
> > violata.

Non credo che stia in memoria, poi lascio la palla alla mia ignoranza

Sono comunque bene accetti altri suggerimenti. Per quello che è la mia
conoscenza del prodotto e delle soluzioni che si trovano in giro direi
che è una buona soluzione. Avete visto altro sul Log Management in
relazione alla disposizione del garante?



+------------------------------+
| Ing. Piergiorgio Venuti, CCSP|
| 0x15521C4E |
+------------------------------+

[Stefano Zanero]

Piergiorgio Venuti wrote:

> Non si parla di quello, è un db che utilizza certificati x.509, la
> cifratura è asimmetrica ed è largamente utilizzata.

Quindi proteggi la confidenzialita', non l'integrita', dei dati.

> No fino a quando non viene ottenuto il certificato con la chiave privata
> che non è conservato sulla macchina. Poi qui si potrebbe parlare una
> vita, posso darti ragione ma direi che è un buon livello di sicurezza.

E' un ottimo livello di sicurezza, se dovessi impedire la sottrazione di
quei log. Invece il problema e' garantirne l'integrita', quindi
ovviamente cifrarli con una chiave pubblica non serve a un ciufolo.

> Non credo che stia in memoria, poi lascio la palla alla mia ignoranza

Se non sta in memoria chi e' che la digita a ogni riga di log ? :-)

Lo stesso che inserisce la smart card per firmare digitalmente e marcare
temporalmente, immagino ! :-)

> Sono comunque bene accetti altri suggerimenti.

Un server syslog su cui gli amministratori non abbiano accesso ?

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/

[Paolo Pedaletti]

Ciao Stefano,

>> Sono comunque bene accetti altri suggerimenti.
> Un server syslog su cui gli amministratori non abbiano accesso ?

basta questo?
(almeno) 2 amministratori che si controllano a vicenda?
questo e' fattibile.
ma non esclude accordi sottobanco ;-)

ciao

--
Paolo Pedaletti
www.openlabs.it
http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf
http://linguistico.sourceforge.net/pages/traduzioni/ms_illegal.html

[Paolo Cavarretta]

2009/11/13 Paolo Pedaletti <***@openlabs.it>:

> basta questo?
> (almeno) 2 amministratori che si controllano a vicenda?
> questo e' fattibile.
> ma non esclude accordi sottobanco ;-)

non proprio...la password di root del server syslog si puo' per esempio separare
su 3 utenti diversi, di cui solo uno e' l'amministratore della
macchina, gli altri non sono dei
tecnici. quindi non sono due amministratori che si controllano a vicenda.

ciao
paolo
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Criscione]

In data mercoledì 11 novembre 2009 20:13:26, Piergiorgio Venuti ha scritto:
> > > Se la macchina e' violata, il DB e' violato.
> No fino a quando non viene ottenuto il certificato con la chiave privata
> che non è conservato sulla macchina. Poi qui si potrebbe parlare una
> vita, posso darti ragione ma direi che è un buon livello di sicurezza.

Mi permetto di dissentire, perchè l'ho sentita troppe volte la favoletta della
cifratura anti-violatura.
Il pregresso potrebbe (dico potrebbe perchè dipende da tanti fattori, non
ultimo come posso garantire che l'aggressore non sostituisca il dato?) restare
al sicuro, ma da quel momento in poi mi gioco tutto. Certamente Piergiorgio
sarà un'ovvietà anche per te, ma tanto per essere chiari sulla cosa. Poi
quello che si ritiene "buon livello" dipende: in genere vedo grandi
investimenti in misure di sicurezza piuttosto poco utili e poi mancano le
patch sui controller, per cui sono un pò conservativo sulla materia :-P

Personalmente mi sembrano leziose molte valutazioni: stiamo parlando di
applicare meccanismi di monitoraggio per l'utente amministrativo per sistemi
operativi che semplicemente non sono in grado di offrire la funzionalità in
modo strutturato.

Possiamo certamente inventarci un sacco di voli pindarici, ma dato che non
possiamo semplicemente risolvere il problema in modo che non ci siano falle,
secondo me la cosa migliore in questo caso è focalizzarsi su un livello
ragionevole, senza aggiungere troppe infrastrutture e magari sfruttando
l'occasione per altro.
Per fare un esempio <vendor mode>potrebbe essere una ottima idea sfruttare la
necessità di installare un agent sulle macchine per integrarle in una
soluzione di monitoraggio più esteso delle performance </vendor>, mentre
investire fiori di quattrini in soluzioni hardware di storage worm mi sembra
piuttosto inutile.

Just my 2 cents.

--
Claudio Criscione

Secure Network S.r.l.

[Alfredo Speranza]

> Luca Caldiero wrote:
> Esistono anche soluzioni software completamente gratuite
> (alcune open source) in grado di fornire supporto
> all'applicazione del decreto.

Salve,

Sono molto interessato a quello che scrive, perchè sto studiando come adempiere a alle richieste del provvedimento, ma portarmi in casa altro software proprietario da gestire, non ho proprio voglia.

Sarebbe così gentile da indicarmi alcuni software open source?

Grazie
Alfredo Speranza



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Luca Caldiero]

>> Luca Caldiero wrote:
>> Esistono anche soluzioni software completamente gratuite (alcune open
>> source) in grado di fornire supporto all'applicazione del decreto.

>Salve,

>Sono molto interessato a quello che scrive, perchè sto studiando come adempiere a alle richieste del provvedimento, ma portarmi in casa altro software proprietario da gestire, non ho proprio voglia.

>Sarebbe così gentile da indicarmi alcuni software open source?

>Grazie
>Alfredo Speranza

Gentile Alfredo Speranza,
putroppo gli elementi che mi ha fornito sono piuttosto scarni e mi fanno porre una domanda fondamentale: è sicuro di dover adempiere al provvedimento del Garante della Privacy?

Mi permetto quindi di fare alcune assunzioni, ovviamente personali:

1) La "casa" a cui fa riferimento è un'azienda/istituzione che si deve adeguare al provvedimento.
2) Lei sta valutando, seppure sia facoltativo e mai menzionato come obbligatorio dal Garante, l'ipotesi di dotarsi di uno strumento che permetta una gestione "centralizzata e sicura" dei log prodotti.
3) Il suo ruolo nella "casa" prevede l'assunzione formale di responsabilità per l'applicazione del provvedimento.
4) Lei è conscio del fatto che l'espressione "open source" non significhi "a costo zero" e che l'adozione di qualsiasi software implichi una qualche forma di gestione.

Fatte queste doverose premesse, la migliore soluzione open source in grado di fornire supporto (ed evidenzio la parola "supporto") per adempiere al provvedimento del Garante per la protezione dei dati personali è, a mio modesto avviso, syslog-ng. Il prodotto, nella sua edizione open source, è reperibile al seguente indirizzo:

http://www.balabit.com/network-security/syslog-ng/opensource-logging-system

Tuttavia tale soluzione presenta alcune limitazioni per quanto concerne il recupero dei log da ambienti "Microsoft Windows" che, nel bene o nel male, rappresentano la stragrande maggioranza delle postazioni client aziendali.
Per rispondere a questa esigenza la mia indicazione ricade invece sul prodotto Snare, sempre nella sua versione open source, reperibile al seguente indirizzo:

http://www.intersectalliance.com/projects/EpilogWindows/index.html

In ultima istanza le riporto un estratto di una delle "FAQ" presenti sul sito del Garante della Privacy (fonte: http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499#4), che, dando ottimo esempio di semplificazione nella comunicazione tra lo Stato ed il Cittadino, invita comunque a valutare anche soluzioni di tipo più complesso.

---
"4) Relativamente all'obbligo di registrazione degli accessi logici degli AdS, sono compresi anche i sistemi client oltre che quelli server?"

[...] 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.
---

Ultima considerazione: ritengo che spesso non comunicare alcune informazioni significhi mentire.
Concludo quindi il mio intervento facendo presente che lavoro per un'azienda che offre sul mercato una soluzione in grado di aiutare le aziende sulla tematica in oggetto.
L'azienda per la quale opero non è comunque in nessun modo legata da rapporti contrattuali di natura commerciale con le software house "Balabit" (produttrice di syslog-ng) o "InterSect Alliance" (produttrice di Snare).

La ringrazio per l'attenzione e le auguro un felice fine settimana,

Luca Caldiero.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Maria Elena]

Il giorno 12/nov/09, alle ore 12:21, Alfredo Speranza ha scritto:

>
>> Luca Caldiero wrote:
>> Esistono anche soluzioni software completamente gratuite
>> (alcune open source) in grado di fornire supporto
>> all'applicazione del decreto.
>
> Salve,
>
> Sono molto interessato a quello che scrive, perchè sto studiando
> come adempiere a alle richieste del provvedimento, ma portarmi in
> casa altro software proprietario da gestire, non ho proprio voglia.
>
> Sarebbe così gentile da indicarmi alcuni software open source?
>
> Grazie
> Alfredo Speranza
>
>
>
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List

Ciao a tutti,

anch'io sarei interessata a soluzioni open.

Per ora sto pensando di ricorrere al parsing dei secure log per gli
accessi ssh alla macchina...ma i concetti (e i programmi temporali)
sono ancora un pò fumosi...

Grazie!

Ciao
M.E.________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Criscione]

In data venerdì 13 novembre 2009 22:59:19, Maria Elena ha scritto:
[...]
> anch'io sarei interessata a soluzioni open.

In realtà abbiamo testato anche noi SNARE e Syslog-ng. Una ottima accoppiata,
ma molto difficile da gestire centralmente in ambienti più grandi di qualche
macchina (se parlassimo solo di server l'opinione cambierebbe, penso).

<vendor mode on>
Alla fine abbiamo deciso di partire da zabbix (Zabbix.com), che fa quel che
serve ed ha un agent leggerissimo, e aggiungere pezzi di integrazione di varia
natura - cifratura, firma etc etc, - per realizzarne un prodotto più carino.
Per la norma comunque può bastare la versione "base" vanilla.

Con l'architettura proxy si riescono a realizzare anche soluzioni ASP per cui
non bisogna tenersi log localmente, e con bassissimo effort si raddoppia come
soluzione di monitoraggio puro (che è poi il motivo per il quale lo
conoscevamo come strumento).
</vendor mode off>

Penso si possa poi fare anche con nagios lo stesso giochino: in fin dei conti
una volta che il tool è in grado di recuperare dati dall'event viewer o da file
filtrando secondo delle regexp hai già gran parte di quel che serve.

--
Claudio Criscione

Secure Network S.r.l.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[yersinia]

2009/11/15 Claudio Criscione <***@securenetwork.it>:
> In data venerdì 13 novembre 2009 22:59:19, Maria Elena ha scritto:
> [...]
>> anch'io sarei interessata a soluzioni open.
>
> In realtà abbiamo testato anche noi SNARE e Syslog-ng. Una ottima accoppiata,
> ma molto difficile da gestire centralmente in ambienti più grandi di qualche
> macchina (se parlassimo solo di server l'opinione cambierebbe, penso).
Ho 500 server con syslog-ng+mysql+php-syslog-ng. Ho 120 server con
rsyslog+mysql+phplogcon. La seconda soluzione è più raffinata per come
è stata implementata (code, trasporto tcp, retry ecc.).

Saluti
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Paolo Pedaletti]

Ciao yersinia,

> Ho 500 server con syslog-ng+mysql+php-syslog-ng. Ho 120 server con
> rsyslog+mysql+phplogcon. La seconda soluzione è più raffinata per come
> è stata implementata (code, trasporto tcp, retry ecc.).

puoi accennare alle differenze di implementazioni, prestazioni e/o
funzionalità dei due diversi logger?
la tua esperienza e' sicuramente interessante (almeno per me, visto che
anch'io sto valutando se passare da syslog-ng a rsyslog)
grazie
ciao

--
Paolo Pedaletti
www.openlabs.it
http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf
http://linguistico.sourceforge.net/pages/traduzioni/ms_illegal.html
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Criscione]

In data lunedì 16 novembre 2009 16:15:21, yersinia ha scritto:

> Ho 500 server con syslog-ng+mysql+php-syslog-ng. Ho 120 server con
> rsyslog+mysql+phplogcon. La seconda soluzione è più raffinata per come
> è stata implementata (code, trasporto tcp, retry ecc.).

Interessante, ti chiedo di più :-)

Parliamo solo di ambiente Unix o anche Windows (rsyslog per esempio con
trasporto tcp per windows è un pò PITA)?
Hai modificato qualcosa / scritto qualcosa ex novo?
Come hai gestito il filtering (se lo hai fatto ovviamente!)?
E per quanto riguarda le workstation?

--
Claudio Criscione

Secure Network S.r.l.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Maria Elena]

Claudio Criscione ha scritto:
> In data venerdì 13 novembre 2009 22:59:19, Maria Elena ha scritto:
> [...]
>> anch'io sarei interessata a soluzioni open.
>
> In realtà abbiamo testato anche noi SNARE e Syslog-ng. Una ottima accoppiata,
> ma molto difficile da gestire centralmente in ambienti più grandi di qualche
> macchina (se parlassimo solo di server l'opinione cambierebbe, penso).
>
> <vendor mode on>
> Alla fine abbiamo deciso di partire da zabbix (Zabbix.com), che fa quel che
> serve ed ha un agent leggerissimo, e aggiungere pezzi di integrazione di varia
> natura - cifratura, firma etc etc, - per realizzarne un prodotto più carino.
> Per la norma comunque può bastare la versione "base" vanilla.
>
> Con l'architettura proxy si riescono a realizzare anche soluzioni ASP per cui
> non bisogna tenersi log localmente, e con bassissimo effort si raddoppia come
> soluzione di monitoraggio puro (che è poi il motivo per il quale lo
> conoscevamo come strumento).
> </vendor mode off>
>
> Penso si possa poi fare anche con nagios lo stesso giochino: in fin dei conti
> una volta che il tool è in grado di recuperare dati dall'event viewer o da file
> filtrando secondo delle regexp hai già gran parte di quel che serve.
>

Ciao,

non ho capito come costruiresti il ponte tra Nagios e
Syslog-ng...potresti spiegarti meglio?

Grazie.

Ciao
M.E.

--
PGP Public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x34977A00
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Criscione]

In data lunedì 16 novembre 2009 16:52:20, Maria Elena ha scritto:
: > Claudio Criscione ha scritto:
[...]
> > Penso si possa poi fare anche con nagios lo stesso giochino: in fin dei
> > conti una volta che il tool è in grado di recuperare dati dall'event
> > viewer o da file filtrando secondo delle regexp hai già gran parte di
> > quel che serve.
> non ho capito come costruiresti il ponte tra Nagios e
> Syslog-ng...potresti spiegarti meglio?

In realtà non l'ho fatto, da cui il "penso".
Non sono un profondo conoscitore di Nagios ma immagino che una volta che
l'informazione sia stata portata nel db centrale si possa tranquillamente
estrarla con uno script locale e gesitrla (un pò come - e qui ti dico che si
può fare senza problemi - facciamo noi con Zabbix).


--
Claudio Criscione

Secure Network S.r.l.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Simone ([e-mail])]

On 16/nov/2009, at 20.07, Claudio Criscione wrote:

> In data lunedì 16 novembre 2009 16:52:20, Maria Elena ha scritto:
> : > Claudio Criscione ha scritto:
> [...]
>>> Penso si possa poi fare anche con nagios lo stesso giochino: in fin dei
>>> conti una volta che il tool è in grado di recuperare dati dall'event
>>> viewer o da file filtrando secondo delle regexp hai già gran parte di
>>> quel che serve.
>> non ho capito come costruiresti il ponte tra Nagios e
>> Syslog-ng...potresti spiegarti meglio?
>
> In realtà non l'ho fatto, da cui il "penso".
> Non sono un profondo conoscitore di Nagios ma immagino che una volta che
> l'informazione sia stata portata nel db centrale si possa tranquillamente
> estrarla con uno script locale e gesitrla (un pò come - e qui ti dico che si
> può fare senza problemi - facciamo noi con Zabbix).
>
>
Scusatemi, ma il garante non dice che i dati devono essere tenuti garantendo la immodificabilità, inaccessibilità e la loro inalterazione?
Io ricevo tramite degli agent le informazioni e le metto in un DB centrale. Quindi non li sto tenendo nella sua forma nativa.

Il clusit in una sua presentazione ha fatto una riflessione su questi punti. Da quando i log devono essere immodificabili, inaccessibili ed inalterabili. Dopo di che quando metto i log all'interno di un DB per la loro ottimizzazione questi non sono stati alterati? Non dovrei invece tenere il log cosi come in formato raw in un repositori che mi garantisce la loro inalterabilità, inaccessibilità e immodificabilità?

Una mia riflessione.
Grazie e buon lavoro.



> --
> Claudio Criscione
>
> Secure Network S.r.l.
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Luca Caldiero]

On 16/nov/2009, at 20.07, Claudio Criscione wrote:

> Scusatemi, ma il garante non dice che i dati devono essere tenuti garantendo la immodificabilità, inaccessibilità e la loro inalterazione?
> Io ricevo tramite degli agent le informazioni e le metto in un DB centrale. Quindi non li sto tenendo nella sua forma nativa.

> Il clusit in una sua presentazione ha fatto una riflessione su questi punti. Da quando i log devono essere immodificabili, inaccessibili ed inalterabili. Dopo di che quando metto i log all'interno di un DB per la loro ottimizzazione questi non sono stati alterati? Non dovrei invece tenere il log cosi come in formato raw in un repositori che mi garantisce la loro inalterabilità, inaccessibilità e immodificabilità?

> Una mia riflessione.
> Grazie e buon lavoro.

> --
> Claudio Criscione
>
> Secure Network S.r.l.

Buongiorno,
Il garante parla di "ragionevole sicurezza", già questo dovrebbe bastare a dirimere qualsiasi controversia.

Aggiungo che le parole "immodificabilità", "inalterabilità" e "inaccessibilità" sono pressoché di impossibile applicabilità reale e integrale in ambito informatico.

Invito chiunque a:

- dimostrare scientificamente il contrario;
- leggere, letteralmente, le FAQ disponibili sul sito del Garante Privacy, in particolare la numero 12, che per comodità di chi legge questo thread riporto qua sotto (fonte: http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499#12).

---

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.

---

Spiace ripetermi, ma ritengo che far leva su concetti informatici, alquanto discutibili, di sicurezza, sia assolutamente controproducente.
Le aziende possono, con mirati investimenti (anche soltanto in "tempo"), adeguarsi facilmente alle semplici richieste del Garante.

E' rimandato alla sensibilità delle persone coinvolte sfruttare o meno l'opportunità per estendere il dominio ed i criteri di raccolta e conservazione delle informazioni censite.
E' invece auspicabile che vendor e consulenti aiutino le aziende a comprendere come trarre informazioni e valore dai log, che fino a qualche mese fa erano considerati da molti poco più che spazzatura informatica.


Buona giornata a tutti.

Luca Caldiero
Consoft Sistemi S.p.A.
www.consoft.it
www.splunk.it



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Criscione]

In data venerdì 20 novembre 2009 10:21:21, Luca Caldiero ha scritto:
: > On 16/nov/2009, at 20.07, Claudio Criscione wrote:
> > Scusatemi, ma il garante non dice che i dati devono essere tenuti
> > garantendo la immodificabilità, inaccessibilità e la loro inalterazione?
> > Io ricevo tramite degli agent le informazioni e le metto in un DB
> > centrale. Quindi non li sto tenendo nella sua forma nativa.
> Buongiorno,
> Il garante parla di "ragionevole sicurezza", già questo dovrebbe bastare a
> dirimere qualsiasi controversia.
>
> Aggiungo che le parole "immodificabilità", "inalterabilità" e
> "inaccessibilità" sono pressoché di impossibile applicabilità reale e
> integrale in ambito informatico.
[...]

Si ma occhio al quoting Caldiero, questa è una riflessione (a mio parere
errata) di Simone, non mia. Noi comunque per buona pace i log li salviamo nel
DB anche nel formato originale oltre a fare postprocessing :P



--
Claudio Criscione

Secure Network S.r.l.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Paolo Giardini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simone (***@gmail.com) wrote:

> Scusatemi, ma il garante non dice che i dati devono essere tenuti garantendo la immodificabilità, inaccessibilità e la loro inalterazione?
> Io ricevo tramite degli agent le informazioni e le metto in un DB centrale. Quindi non li sto tenendo nella sua forma nativa.
>
> Il clusit in una sua presentazione ha fatto una riflessione su questi punti. Da quando i log devono essere immodificabili, inaccessibili ed inalterabili. Dopo di che quando metto i log all'interno di un DB per la loro ottimizzazione questi non sono stati alterati? Non dovrei invece tenere il log cosi come in formato raw in un repositori che mi garantisce la loro inalterabilità, inaccessibilità e immodificabilità?

Rileggendo le FAQ si possono trovare delle risposte coerenti.
In questo caso, il punto 10 pone il caso di log con informazioni
ridondanti, come è il caso del comando sudo, ad esempio, che può loggare
anche il comando dato. In questo caso si suggerisce la possibilità di
filtrare tali log per avere solo il dato richiesto (login - logout -
errori), Risulta quindi evidente la non-necessità di mantenere il
formato originale. Il log deve essere inalterabile dopo la
memorizzazione sul supporto di destinazione.
Inoltre il punto 12 riporta altre interessanti considerazioni.

Come sempre, IMHO.


- --
Paolo Giardini | EUCIP Certified Professional | CCOS Regione Umbria
Privacy Officer AIP/ICTS | Direttore Osservatorio Privacy Sicurezza IT
A.I.P./ITCS|CLUSIT|GNU/LUG Perugia|AIPSI|ISSA|ILS|BackTrack.it
http://blog.solution.it|Cel.337.652876|Fax [phone]|skype pgiardini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLBlX3MTCPYEjE66sRAsakAJ9vDlb5MwT2sJQhXN3iSpUMK7V+KwCguum6
HzNLMfLH4gGJoaIIMxdJvFo=
=483i
-----END PGP SIGNATURE-----
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Simone (***@gmail.com) wrote:

> Scusatemi, ma il garante non dice che i dati devono essere tenuti
> garantendo la immodificabilità, inaccessibilità e la loro
> inalterazione?

Si', da parte dei controllati.

> Io ricevo tramite degli agent le informazioni e le metto in un DB
> centrale. Quindi non li sto tenendo nella sua forma nativa.

Nessuno te lo chiede (anzi, si parla esplicitamente di "estrazione" o
"filtraggio" nelle FAQ).

> Il clusit in una sua presentazione ha fatto una riflessione su questi
> punti. Da quando i log devono essere immodificabili, inaccessibili ed
> inalterabili. Dopo di che quando metto i log all'interno di un DB per
> la loro ottimizzazione questi non sono stati alterati? Non dovrei
> invece tenere il log cosi come in formato raw in un repositori che mi
> garantisce la loro inalterabilità, inaccessibilità e
> immodificabilità?

Dunque, non ho capito se questa riflessione e' tua o del CLUSIT (che non
saprei se parla "in quanto tale" o in quanto "un socio del CLUSIT ha
detto), e in ogni caso dubito fortemente che il CLUSIT abbia titolo per
estendere o interpretare le norme e i provvedimenti del Garante... :-)

Per rispondere nel merito: quale sarebbe la forma "nativa" o "raw" di un
log ? Se faccio loggare verso Syslog anziche' verso il formato
proprietario, ad esempio, e' "nativa" o no? C'e' un termine tecnico per
definire queste domande, ed e' "attrezzo-tipico-del-falegname-4-lettere
mentale".

Ripeto e ribadisco, non facciamo le cose piu' complicate del necessario.
La ratio della norma e' semplice e chiara:
"L'operato degli amministratori di sistema deve essere oggetto, con
cadenza almeno annuale, di un'attività di verifica da parte dei titolari
o dei responsabili del trattamento, in modo da controllare la sua
rispondenza alle misure organizzative, tecniche e di sicurezza rispetto
ai trattamenti dei dati personali previste dalle norme vigenti."

E il metodo di registrazione dei log utilizzato deve: "avere
caratteristiche di completezza, inalterabilità e possibilità di verifica
della loro integrità adeguate al raggiungimento dello scopo di verifica
per cui sono richieste."

Il fatto che il formato sia raw, medium, medium-well o well-done
influisce su questa possibilita' di raggiungere lo scopo di verifica
(aka vedere se gli amministratori si loggano alle 3 di notte o la
domenica su macchine che non sono di loro competenza)? Se la risposta e'
no, come quasi sicuramente e', perche' quel che ti interessa e' il dato
e non il suo formato, allora siamo sempre nel campo degli attrezzi da
falegname onirici.

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Alfredo Speranza]

--- Sab 14/11/09, Luca Caldiero <***@consoft.it> ha scritto:

> 1) La "casa" a cui fa riferimento è un'azienda/istituzione
> che si deve adeguare al provvedimento.

La casa è un azienda di circa 400 persone, che si deve adeguare al provvedimento. Tra l'altro, ne approfitto per intervenire a questo proposito, ho letto alcuni interventi che asseriscono il fatto che non tutte le aziende debbano adeguarsi al provvedimento del Garante. Mi permetto di dissentire perchè praticamente ogni azienda ha sui propri sistemi informatici almeno indirizzo e/o numero di telefono dei propri dipendenti; già questi sono dati personali e quindi soggetti al decreto del garante.

> 2) Lei sta valutando, seppure sia facoltativo e mai
> menzionato come obbligatorio dal Garante, l'ipotesi di
> dotarsi di uno strumento che permetta una gestione
> "centralizzata e sicura" dei log prodotti.

Sto valutando dei software per garantire all'azienda dove lavoro, di essere in regola con il decreto del garante. Onestamente sto vedendo tanti software raffazzonati che non fanno quello che garantiscono, addirittura ho assistito a una presentazione penosa di un commerciale che vendeva un software e non sapeva nemmeno come funzionava. Questo per dire che molte aziende intuendo il business si sono buttate nell'affare, ma la soluzione proposte non garantiscono la copertura completa. I software da me testati, se sono sviluppati su piattaforma windows non contemplano che esistano altri sistemi se non windows, e purtroppo devo dire che è vero anche il viceversa, ma più per la difficoltà di integrazione che per una reale volontà.

> 3) Il suo ruolo nella "casa" prevede l'assunzione formale
> di responsabilità per l'applicazione del provvedimento.

No, io sono il network e telco manager, anche se amministro quasi tutta la sicurezza informatica dell'azienda (antivirus, AAA, firewall, IDS, ecc.), ma la responsabilità formale è del mio capo. Infatti in questo momento sto operando su suo mandato.

> 4) Lei è conscio del fatto che l'espressione "open source"
> non significhi "a costo zero" e che l'adozione di qualsiasi
> software implichi una qualche forma di gestione.

Certamente si a tutte e due le domande.

> Tuttavia tale soluzione presenta alcune limitazioni per
> quanto concerne il recupero dei log da ambienti "Microsoft
> Windows" [...] Per rispondere a questa esigenza la mia indicazione ricade
> invece sul prodotto Snare, sempre nella sua versione open
> source, reperibile al seguente indirizzo:

E se la mia esigenza fosse quella di gestire una ambiente eterogeneo: macchine win e linux, Db Oracle e Sqlserver, integrazione con log di accesso sui firewall o su altri device, cosa mi consiglierebbe?

una domanda x S. Zanero: ho visto che consiglia l'adozione di un syslog server per adempiere al decreto. Questo syslog non deve essere accedibile dagli amministratori di sistema, ma solo al "controllore", cioè al "titolare del trattamento" dei dati personali (legge 675 del 96). Supponiamo, come spesso lo è, questo titolare non sia un tecnico e quindi non sia in grado di gestire e garantire la continuità di questo servizio, ciò non può essere pericolo per l'azienda, perchè chi dovrebbe controllare non è stato dotato di uno strumento ideoneo per fare ciò?

Grazie a tutti per l'interessante dibatitto.
Alfredo



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Alfredo Speranza wrote:

> Mi permetto di dissentire perchè praticamente ogni azienda ha sui
> propri sistemi informatici almeno indirizzo e/o numero di telefono
> dei propri dipendenti; già questi sono dati personali

Quello a cui si faceva riferimento e' l'esenzione che si ritrova qui:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1571218

> una domanda x S. Zanero: ho visto che consiglia l'adozione di un
> syslog server per adempiere al decreto. Questo syslog non deve essere
> accedibile dagli amministratori di sistema, ma solo al "controllore",
> cioè al "titolare del trattamento" dei dati personali (legge 675 del
> 96).

La legge 675/96 e' abrogata.

> Supponiamo, come spesso lo è, questo titolare non sia un tecnico
> e quindi non sia in grado di gestire e garantire la continuità di
> questo servizio,

Come e' gia' stato spiegato, e' sufficiente suddividere il segreto (e
peraltro non riesco a immaginare in che modo l'indisponibilita' di un
servizio di logging possa creare un problema di continuita'...).

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Luca Caldiero]

--- Sab 14/11/09, Luca Caldiero <***@consoft.it> ha scritto:

>> Tuttavia tale soluzione presenta alcune limitazioni per quanto
>> concerne il recupero dei log da ambienti "Microsoft Windows" [...] Per
>> rispondere a questa esigenza la mia indicazione ricade invece sul
>> prodotto Snare, sempre nella sua versione open source, reperibile al
>> seguente indirizzo:

--- Sab 16/11/09, Alfredo Speranza <***@yahoo.it> ha scritto:

> E se la mia esigenza fosse quella di gestire una ambiente eterogeneo: macchine win e linux, Db
> Oracle e Sqlserver, integrazione con log di accesso sui firewall o su altri device, cosa mi
> consiglierebbe?

Buonasera,
consiglierei a lei di valutare anche la soluzione proposta dall'azienda per cui lavoro, che si basa sul prodotto splunk ( http://www.splunk.com , http://www.splunk.it ), prodotto dall'omonima società statunitense e distribuito in Italia da Consoft Sistemi S.p.A..

Esistono inoltre, reperibili su internet, diversi esempi e wiki relativi all'integrazione tra splunk e prodotti quali nagios e ossec.

Distinti saluti.

Luca Caldiero
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Telmon]

Alfredo Speranza wrote:
> I software da me testati, se sono sviluppati su piattaforma
> windows non contemplano che esistano altri sistemi se non windows, e
> purtroppo devo dire che è vero anche il viceversa, ma più per la
> difficoltà di integrazione che per una reale volontà.

Syslog-ng, almeno nella versione a pagamento (premium), ha un agente che
può leggere gli eventi di Windows. Mi pare che anche altri strumenti
basati su syslog abbiano questa possibilità (conversione
windows/syslog). In generale, mi sembra comunque più semplice
interfacciare con windows uno strumento fatto per altri ambienti che
viceversa, perché nel primo caso ci si deve occupare di una sola
"eccezione", che per quanto rilevante in termini di numero di sistemi
dal punto di vista delle tipologie di agenti e di problemi rimane una.

ciao

- Claudio

--

Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[rino lo turco]

Alfredo Speranza ha scritto: in data 15/11/2009 23.01:
> La casa è un azienda di circa 400 persone, che si deve adeguare al provvedimento. Tra l'altro, ne approfitto per intervenire a questo proposito, ho letto alcuni interventi che asseriscono il fatto che non tutte le aziende debbano adeguarsi al provvedimento del Garante. Mi permetto di dissentire perchè praticamente ogni azienda ha sui propri sistemi informatici almeno indirizzo e/o numero di telefono dei propri dipendenti; già questi sono dati personali e quindi soggetti al decreto del garante.
>
basterebbe leggere meglio il decreto, nella sua interezza, e quanto di
altro è stato scritto di seguito anche dal garante stesso per comprender
la reale portata del provvedimento.
la tenuta dei una rubrica dei dipendenti è un fatto di ordinaria
amministrazione , esiste il bisogno di reperibilità per continuità di
servizio, reperibilità per sicurezza delle persone ( avviso dei parenti
in caso di incidente ), l'esempio non è quindi calzante.
Invece devo dire che i trattamenti derivanti dai sistemi vds, se non
strettamente necessari alle operazioni di produzione (vedasi laboratori
automatizzati) , mettono fuori semplificazione l'azienda.

Molte aziende effettuano trattamenti che in fin dei conti nulla hanno a
che fare con il reale bisogno e questa semplificazione è una ulteriore
occasione per rivedere i propri bisogni informativi bilanciandoli con
reali interessi, costi e "mancate semplificazioni " o "nuovi obblighi" .
Sono convinto , e l'aver conosciuto intimamente molte aziende grandi e
piccole mi conforta, che le aziende che necessitano concretamente del
ADS siano poche , ciò non toglie che sia comunque necessario iniziare a
controllare queste figure che speso hanno abusato della loro posizione,
spesso anche inconsciamente diciamo per abitudine, ritardando lo
sviluppo aziendale , diretta conseguenza di un errata applicazione di
regole e metodologie IT .


>> 2) Lei sta valutando, seppure sia facoltativo e mai
>> menzionato come obbligatorio dal Garante, l'ipotesi di
>> dotarsi di uno strumento che permetta una gestione
>> "centralizzata e sicura" dei log prodotti.
>>
>
> Sto valutando dei software per garantire all'azienda dove lavoro, di essere in regola con il decreto del garante. Onestamente sto vedendo tanti software raffazzonati che non fanno quello che garantiscono, addirittura ho assistito a una presentazione penosa di un commerciale che vendeva un software e non sapeva nemmeno come funzionava.
Ecco un altro valido motivo per avere ordine in una professione
estremamente importante nella realtà industriale e non solo.
>> 3) Il suo ruolo nella "casa" prevede l'assunzione formale
>> di responsabilità per l'applicazione del provvedimento.
>>
>
> No, io sono il network e telco manager, anche se amministro quasi tutta la sicurezza informatica dell'azienda (antivirus, AAA, firewall, IDS, ecc.), ma la responsabilità formale è del mio capo. Infatti in questo momento sto operando su suo mandato.
>
>
E quindi con "responsabilità", è divertente avere continue conferme
della italica antipatia e repulsione alla responsabilità.
> una domanda x S. Zanero: ho visto che consiglia l'adozione di un syslog server per adempiere al decreto. Questo syslog non deve essere accedibile dagli amministratori di sistema, ma solo al "controllore", cioè al "titolare del trattamento" dei dati personali (legge 675 del 96). Supponiamo, come spesso lo è, questo titolare non sia un tecnico e quindi non sia in grado di gestire e garantire la continuità di questo servizio, ciò non può essere pericolo per l'azienda, perchè chi dovrebbe controllare non è stato dotato di uno strumento ideoneo per fare ciò?
>
>
e chi lo dice? , cosa significa controllo ?
l'amministratore di un'azienda non è detto che sappia stare in linea di
montaggio , non è detto che sappia ad esempio costruire ciò che la sua
azienda vende eppure ne ha il controllo e la suprema responsabilità.
Tanto per fare un riferimento il recente processo di torino (incendio)
ha portato alla sbarra, come responsabile di tutto , non il responsabile
della sicurezza ma direttamente l'amministratore delegato a
dimostrazione che le responsabilità non sempre si legano a concetti di
"pratica conoscenza".
Nella 196 il reale responsabile è chiaramente identificato il titolare
del trattamento , la lageg ben sa che questi può non avere tutte le
conoscenze preventivabili e difatti lo affianca da altri soggetti pero
mantiene su di lui il concetto di responsabile, di "capo". Il comandante
di una nave spesso neanche sa come è fatto il motore che permette alla
sua nave di andare avanti però lui ne è sempre e totalmente
responsabile, si affianca da collaboratori .
Il provvedimento sugli ADS introduce un serio problema e ne da una
prima valida soluzione , introduce il concetto che ne sistema
informativo esistono soggetti "fuori controllo" , soggetti che con varie
scuse e a vario titolo hanno di fatto sottratto il "potere del capo" al
capo ovvero a colui che oggi è identificato come il titolare del
trattamento, ebbene questi deve ritornare a essere il "capo" e deve
imparare a circondarsi da soggetti che possono affiancarlo nel suo
lavoro di titolare del trattamento. Gli obblighi di scelta e selezione ,
tramite criteri del tutto soggettivi seppur proiettati verso un punto
ben definito, oltre che "controllo operativo", sono di fatto la
soluzione al problema.
Compito del tecnico è mettere il titolare in condizioni di assolvere al
dettato secondo i suoi criteri ( suoi del titolare) e non secondo
proprie personali idiosincrasie spesso figlie di atavici timori
risultanti di una incultura generale sul reale ruolo che si ricopre.

La prima cosa che mi viene in mente di dire al fine di scegliere una
soluzione al problema specifico e di sceglierla tenendo sempre ben
presente, e in primo piano, chi è il reale utilizzatore e cosa deve
farne ovvero a cosa gli deve servire.

e come diceva un verso di una nota canzone . tutto il resto è .......

rino

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Alfredo Speranza]

Stefano Zanero wrote:

> La legge 675/96 e' abrogata.

Bisognerebbe anche informare il Garante, visto che sul sito alla pagina "normativa --> italiana" risulta presente:
http://www.garanteprivacy.it/garante/navig/jsp/index.jsp?folderpath=Normativa%2FItaliana%2FLa+legge+n.+675

E in ogni caso la figura del "titolare del trattamento" non è e non può essere abbrogata.

>(e peraltro non riesco a immaginare in che modo l'indisponibilita' di un
> servizio di logging possa creare un problema di continuita'...)

Evidentemente non si sono spiegato bene, mi scuso. Non parlavo di continuità del business (business continuity), ma bensì della contunità del servizio di "collezionamento" dei log di accesso degli amministratori.
Supponiamo che il syslog vada a "ciampanelle" e il titolare del trattamento dei dati sensibili non se ve accorga, supponiamo anche dopo un periodo di tempo medio lungo arrivi un audit del garante. Il titolare non sarà più in grado di produrre alcun log di accesso degli amministrator, quindi l'azienda sarà multata o nel peggiore dei l'amministratore delegato (o il rappresentante legale) sarà processato penalmente.
Per questo credo che sia opportuno fornire un servizio facile da gestire da chi non è un tecnico.

Alfredo



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Alfredo Speranza wrote:

>> La legge 675/96 e' abrogata.
>
> Bisognerebbe anche informare il Garante, visto che sul sito alla pagina "normativa --> italiana" risulta presente:
> http://www.garanteprivacy.it/garante/navig/jsp/index.jsp?folderpath=Normativa%2FItaliana%2FLa+legge+n.+675

Bisognerebbe leggere le leggi:
Art. 183. Norme abrogate

1. Dalla data di entrata in vigore del presente codice sono abrogati:

a) la legge 31 dicembre 1996, n. 675;

(ex 196/2003)

> E in ogni caso la figura del "titolare del trattamento" non è e non può essere abbrogata.

E chi l'ha mai abrogata ? :-)

> Per questo credo che sia opportuno fornire un servizio facile da gestire da chi non è un tecnico.

Che il titolare abbia bisogno di opportuni cruscotti e meccanismi di
controllo di quel che accade e' pacifico, anche perche' non c'e' mica
solo la 196 in circolazione, ma pure la 231...

--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Simone ([e-mail])]

On 17/nov/2009, at 12.19, Alfredo Speranza wrote:

> Stefano Zanero wrote:
>
>> La legge 675/96 e' abrogata.
>
> Bisognerebbe anche informare il Garante, visto che sul sito alla pagina "normativa --> italiana" risulta presente:
> http://www.garanteprivacy.it/garante/navig/jsp/index.jsp?folderpath=Normativa%2FItaliana%2FLa+legge+n.+675
>
> E in ogni caso la figura del "titolare del trattamento" non è e non può essere abbrogata.
>
>> (e peraltro non riesco a immaginare in che modo l'indisponibilita' di un
>> servizio di logging possa creare un problema di continuita'...)
>
> Evidentemente non si sono spiegato bene, mi scuso. Non parlavo di continuità del business (business continuity), ma bensì della contunità del servizio di "collezionamento" dei log di accesso degli amministratori.
> Supponiamo che il syslog vada a "ciampanelle" e il titolare del trattamento dei dati sensibili non se ve accorga, supponiamo anche dopo un periodo di tempo medio lungo arrivi un audit del garante. Il titolare non sarà più in grado di produrre alcun log di accesso degli amministrator, quindi l'azienda sarà multata o nel peggiore dei l'amministratore delegato (o il rappresentante legale) sarà processato penalmente.
> Per questo credo che sia opportuno fornire un servizio facile da gestire da chi non è un tecnico.
>
> Alfredo
>
>
Penso che Alfredo abbia messo alla luce qualcosa che molti stanno trascurando e che nella fretta di prendere la cosa migliore al costo più basso stanno sottovalutando.
Penso che sia chiaro che il Garante ha un disegno in testa che sia di più lunghe mire.
Il garante nella sua intestazione della norma, per quello che riguarda la mia interpretazione, dice che vuole evincere che le attività fatte dagli operatori per puro scopo di amministrazione dei sistemi dove vengono mantenute informazioni ritenute sensibili e personali si possa fare con un report annuale.

1a Domanda: Ma da un login ed un logout si evince che un'operatore che fa amministrazione stia facendo pura amministrazione? Forse c'è un diritto del lavoro troppo forte che adesso non permette di poter fare loggin anche di quello che fa?

2a Domanda: Ci viene detto di tenere i log per un periodo minimo di 6 mesi e che basta un report annuale? 6 mesi log = report annuale?

Questa è solo una mia riflessione.

Dopo di che concordo con Alfredo che il garante non ha detto che dobbiamo dare l'alta affidabilità dei sistemi per la raccolta dei log. Ma comunque dobbiamo essere in grado di fronte ad una verifica di provare che i log sono stati mantenuti in modo corretto. Dice che cosa andiamo in contro nel caso in cui questo non viene fatto. Ma non dice che nel caso in cui nel controllo viene chiedo di verificare un periodo dove non siamo stati in grado per vari motivazioni di non raccogliere i log cosa succede.
Per una mia riflessione personale, secondo me la Guarda di Finanza preposta a fare questo controllo di sicuro non ci farà un plauso.

Buona giornata.


>
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Paolo Giardini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simone (***@gmail.com) wrote:

>>
> Penso che Alfredo abbia messo alla luce qualcosa che molti stanno trascurando e che nella fretta di prendere la cosa migliore al costo più basso stanno sottovalutando.
> Penso che sia chiaro che il Garante ha un disegno in testa che sia di più lunghe mire.
> Il garante nella sua intestazione della norma, per quello che riguarda la mia interpretazione, dice che vuole evincere che le attività fatte dagli operatori per puro scopo di amministrazione dei sistemi dove vengono mantenute informazioni ritenute sensibili e personali si possa fare con un report annuale.
>
> 1a Domanda: Ma da un login ed un logout si evince che un'operatore che fa amministrazione stia facendo pura amministrazione? Forse c'è un diritto del lavoro troppo forte che adesso non permette di poter fare loggin anche di quello che fa?
>
> 2a Domanda: Ci viene detto di tenere i log per un periodo minimo di 6 mesi e che basta un report annuale? 6 mesi log = report annuale?

"report annuale" non sta scritto da nessuna parte. Si richiede una
"attività di verifica ...*almeno* annuale dell'operato" ecc. ecc.Punto f
del provvedimento. Quindi un semplice log non basta. D'altra parte
"attività di verifica da parte dei titolari in modo da controllare la
sua rispondenza alle misure organizzative, tecniche e di sicurezza..."
potrebbe essere una definizione alquanto ampia.
Anche leggere le FAQ aiuta. cfr punto 12, 14, 16

>
> Questa è solo una mia riflessione.
>
> Dopo di che concordo con Alfredo che il garante non ha detto che dobbiamo dare l'alta affidabilità dei sistemi per la raccolta dei log. Ma comunque dobbiamo essere in grado di fronte ad una verifica di provare che i log sono stati mantenuti in modo corretto. Dice che cosa andiamo in contro nel caso in cui questo non viene fatto. Ma non dice che nel caso in cui nel controllo viene chiedo di verificare un periodo dove non siamo stati in grado per vari motivazioni di non raccogliere i log cosa succede.
> Per una mia riflessione personale, secondo me la Guarda di Finanza preposta a fare questo controllo di sicuro non ci farà un plauso.
>

Direi inosservanza ai provvedimento del Garante, art. 170 d.lgs 196/2003

- --
Paolo Giardini | EUCIP Certified Professional | CCOS Regione Umbria
Privacy Officer AIP/ICTS | Direttore Osservatorio Privacy Sicurezza IT
A.I.P./ITCS|CLUSIT|GNU/LUG Perugia|AIPSI|ISSA|ILS|BackTrack.it
http://blog.solution.it|Cel.337.652876|Fax [phone]|skype pgiardini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLBk6lMTCPYEjE66sRAi7MAJ9I5a1zwA5nsFMkUrh7AJfrVhZ/iQCgzkNe
+JjElQfMIkq0GBB+WaTw3hI=
=DDhO
-----END PGP SIGNATURE-----
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Fenati]

Nella mia organizzazione sono presenti circa 25 server linux (con architetture diverse) 10 windows 2003 e un as400 .
Ho pensato di concentrare in un unico file i log di accesso di tutti i server.
Questo dovrà risiedere su una macchina di cui gli amministratori di sistema hanno un accesso di sola lettura, me l'amministratore di questa macchina sarà l'amministratore delegato dell'organizzazione.
Sulle macchine linux ho avuto pochissime difficltà, utilizzando le funzionalità del syslogd.
Per le macchine windows, ho installato un agent free che invia gli eventi al syslog server. Problema: windows genera una montagna di informazion (inutili) che non sono ancora riuscito a filtrare, creando un problema di dimensione dei file di log (che vanno conservati per almeno sei mesi). In un giorno mi hanno generato 32Mbytes di log.
In ultimo l'AS400. Da giorni mi sto perdendo su vari forum per capire come posso "passare" al syslog server le info di login, senza nessun risultato concreto. Ho pensato anche ad un programmino che trasmette il log da eseguire alla login/logaut dell'amministratore.
DOMANDE:
1. Qualcuno ha in mente qualcosa per ridurre la dimensione dei log di windows, filtrando solo quelli effettivamente necessari?.
2. Qualche idea su come intervenire per "catturare" i log dell'as400?
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Paolo Giardini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefano Fenati wrote:

> 1. Qualcuno ha in mente qualcosa per ridurre la dimensione dei log di windows, filtrando solo quelli effettivamente necessari?.

Per windows sto provando snare; puoi filtrare e mandare ad un rsylog (ad
esempio) quello che vuoi.


- --
Paolo Giardini | EUCIP Certified Professional | CCOS Regione Umbria
Privacy Officer AIP/ICTS | Direttore Osservatorio Privacy Sicurezza IT
A.I.P./ITCS|CLUSIT|GNU/LUG Perugia|AIPSI|ISSA|ILS|BackTrack.it
http://blog.solution.it|Cel.337.652876|Fax [phone]|skype pgiardini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLBICYMTCPYEjE66sRAiLcAKCfLmqeriL9troLlZirdBr/b1TVEACg55c/
LesZesw7AVpdRfDe/N2XYa8=
=2TTq
-----END PGP SIGNATURE-----
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/18 Stefano Fenati <***@terremerse.it>:

> 2. Qualche idea su come intervenire per "catturare" i log dell'as400?

Da quello che ho letto in giro, lo strumento da usare è l'audit
journal. In forma nativa, mi pare di capire che potrebbe anche
soddisfare il requisito di non alterabilità, dato che non c'è nulla
nel sistema operativo che permetta di modificare questi oggetti,
neppure spostandoli su un altro sistema. Però mi sa che ti scordi
l'integrazione con sistemi di log centralizzato..
Non credo purtroppo che sia tra le caratteristiche del sistema più
semplici da affrontare..

--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Claudio Telmon]

Stefano Fenati wrote:
> Problema: windows
> genera una montagna di informazion (inutili) che non sono ancora
> riuscito a filtrare, creando un problema di dimensione dei file di
> log (che vanno conservati per almeno sei mesi). In un giorno mi hanno
> generato 32Mbytes di log.

Non mi sembra tanto in senso stretto, se è la produzione complessiva. In
fondo si tratta di circa 10 Giga all'anno, se non sbaglio i conti.
Naturalmente se la maggior parte è informazione inutile uno ne farebbe a
meno ;)

> DOMANDE: 1. Qualcuno ha in mente
> qualcosa per ridurre la dimensione dei log di windows, filtrando solo
> quelli effettivamente necessari?. 2. Qualche idea su come intervenire
> per "catturare" i log dell'as400?

Premetto che è una funzionalità che finora ho esaminato sulla carta
perché stiamo valutando se considerarla presso un cliente, comunque
syslog-ng premium ha un agente per iSeries, non so se fa al caso tuo.
Inoltre, ha dei meccanismi di marcatura e filtraggio dei messaggi, e se
vogliamo anche riscrittura, (questi in buona parte li ho provati) che ti
permettono di fare parecchio, già lato agent anche su windows. C'è anche
un meccanismo di throttling (limitazione lato agent dl numero di eventi
per secondo inviati al server) e la possibilità di leggere "in tail" da
un file, ad esempio un log generato da un applicativo. Non so se faccia
tutto quello che ti serve, ma si può scaricare in prova e l'assistenza
finora mi è sembrata molto disponibile anche avendo la versione in prova.

ciao

- Claudio

--

Claudio Telmon
***@telmon.org
http://www.telmon.org

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Domenico Viggiani]

* Stefano Fenati:
>
> Per le macchine windows, ho installato un agent free che invia gli
> eventi al syslog server. Problema: windows genera una montagna di
> informazion (inutili) che non sono ancora riuscito a filtrare, creando
> un problema di dimensione dei file di log (che vanno conservati per
> almeno sei mesi). In un giorno mi hanno generato 32Mbytes di log.
> In ultimo l'AS400. Da giorni mi sto perdendo su vari forum per capire
> come posso "passare" al syslog server le info di login, senza nessun
> risultato concreto. Ho pensato anche ad un programmino che trasmette
> il log da eseguire alla login/logaut dell'amministratore.
> DOMANDE:
> 1. Qualcuno ha in mente qualcosa per ridurre la dimensione dei log di
> windows, filtrando solo quelli effettivamente necessari?.

Vedo che hai scelto la strada più semplice, come ho fatto io.
Il concetto di autenticazione del dominio Windows, in effetti, è un po'
"allargato" :-) e ci sono moltissime entry per qualsiasi cosa venga
effettuata ma, se ci pensi, è giusto così: un "accesso" non deve per forza
essere interattivo (terminal server o console) ma ci sono anche quelli a
condivisioni file, stampanti, semplici accessi in rete delle macchine del
dominio, etc.
Mi sa che dobbiamo conservarci tutto e trovare pure un modo di
interpretarlo all'occorrenza ;-)

--
Domenico Viggiani

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Piero Cavina]

2009/11/19 Domenico Viggiani <***@tiscali.it>:

> Vedo che hai scelto la strada più semplice, come ho fatto io.
> Il concetto di autenticazione del dominio Windows, in effetti, è un po'
> "allargato" :-) e ci sono moltissime entry per qualsiasi cosa venga
> effettuata ma, se ci pensi, è giusto così: un "accesso" non deve per forza
> essere interattivo (terminal server o console) ma ci sono anche quelli a
> condivisioni file, stampanti, semplici accessi in rete delle macchine del
> dominio, etc.


per esepio ecco un articolo per iniziare ad approfondire (Audit
Account Logon Events ):
http://technet.microsoft.com/en-us/library/bb742435.aspx

bisogna avere un'idea delle basi del funzionamento di kerberos
(premetto che ne ho giusto un'idea.. perdonate le imprecisioni):

l'evento più significativo per i nostri scopi è quello con id = 672
(authentication ticket granted), che in caso di autenticazione
riuscita fornisce tra le altre cose l'utente e l'indirizzo IP del
client
questo evento da solo non rappresenta l'accesso a un servizio (p.es.
ad una share di rete o a un desktop remoto), questi sono tracciati
dagli eventi 673 (service ticket granted)

come facevate notare, gli eventi generati sono tantissimi in un
dominio con molti utenti, però se vengono filtrati restringendo a
"eventi relativi ai sysadmin che accedono a sistemi con dati
personali" restano solo quelli rilevanti.

Mi pare però che l'aspetto del filtraggio potrebbe essere un po' delicato..

per esempio.. un sysadmin si logga sulla workstation X e poi monta una
share del server A (che non contiene dati personali) e successivamente
si collega con rdp al computer B (che contiene dati personali).. ora..
l'evento 672 al momento dell'autenticazione su X non dice ancora quale
attività il sysadmin va a svolgere, poi immagino che ci siano due
eventi 673 dei quali uno solo è rilevante dal nostro punto di vista.

in definitiva che fare?
- cercare di filtrare solo gli eventi relativi agli accessi a risorse
"sensibili", per i soli sysadmin
- loggare tutti gli eventi 672 e 673 indipendemente dal servizio per i
soli sysadmin
- loggare tutti gli eventi 672 e 673 per tutti gli utenti (un sacco di eventi)
- loggare tutti gli eventi del registro Protezione (un grosso sacco)

Le ultime due possibilità sono un po' della serie "lo faccio solo per
rispondere ai requisiti, poi saranno cavoli di chi li deve
interpretare". Mi chiedo se questo approccio non porti a problemi di
altro tipo in caso di "incidenti".. nel log ci possono andare anche
degli eventi extra?

Inoltre se si vuole generare una sola riga per ogni accesso a una
risorsa "sensibile" con utente, client, servizio, orario bisogna
effettuare una pre-elaborazione degli eventi generati dai domain
controller che metta in relazione gli eveni 672 e 673 attraverso
l'utente in un certo range temporale.. giusto?
ah già poi ci sarebbero gli eventi di logoff :-)

Così ad occhio una cosa fatta bene non mi pare del tutto scontata.
Registrare tutto invece è banale ma davvero bruttino e non ci
scommetteri sul fatto che passi. Qualcuno conosce una "giusta via di
mezzo".. già sperimenata?

--
Ciao,
P.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List