Discussion:
log amministratori di sistema
(too old to reply)
Massimo Giaimo
2009-10-29 10:34:05 UTC
Permalink
Buongiorno a tutti,

come sapete entro il 15 dicembre ogni azienda dovrà adeguarsi al
provvedimento del Garante della privacy relativo al controllo delle
attività degli amministratori di sistema. Volevo sapere se qualcuno in
lista ha già avuto modo di testare qualche prodotto ed eventualmente se
potesse dare un giudizio sui pro e sui contro delle soluzioni provate.
Squilloni Valentino
2009-10-29 18:12:05 UTC
Permalink
-----Original Message-----
From: ml-***@sikurezza.org [mailto:ml-***@sikurezza.org] On Behalf Of Massimo Giaimo
Sent: giovedì 29 ottobre 2009 11.34
Subject: [ml] log amministratori di sistema
Post by Massimo Giaimo
Buongiorno a tutti,
come sapete entro il 15 dicembre ogni azienda dovrà adeguarsi al provvedimento del
Garante della privacy relativo al controllo delle attività degli amministratori di
sistema. Volevo sapere se qualcuno in lista ha già avuto modo di testare qualche
prodotto ed eventualmente se potesse dare un giudizio sui pro e sui contro delle
soluzioni provate.
Buongiorno,

per l'azienda per la quale lavoro sto approcciando, dall'inizio dell'anno, il mercato italiano (prevalentemente large account) su questa tematica, seguendo e realizzando diversi progetti, sia di taglio organizzativo che tecnologico, e avendo modo di confrontarmi con moltissimi Security Manager.

Prodotti sul mercato ce ne sono moltissimi. Si va dai più blasonati prodotti di mercato RSA enVision e Arcsight, a ELM di CA, a Sentinel Log Manager di Novell, alla suite Oracle per i DB, per arrivare a soluzioni opensource (syslog-ng, snare, ..) che moltissimi stanno valutando e implementando per la raccolta dei log. Una via alternativa all'implementazione di una soluzione in casa è l'outsourcing del servizio verso un SOC, che permette di essere conformi con la normativa con un investimento iniziale minimo e pagando il servizio a canone.

Per la mia esperienza la scelta di una soluzione rispetto ad un'altra dipende prevalentemente (oltre che ovviamente dai rapporti commerciali già in essere) dalla visione del cliente, che può essere:
- tattica: ovvero l'implementazione minima che mi permette di essere conforme alla normativa, senza pensare alle possibile evoluzioni
- strategica: una volta che una funzione aziendale inizia ad accentrare i log poi "l'appetito vien mangiando" e diverse aree sono interessate (pensate all'IT per performance e monitoring, alla sicurezza per correlazione e rilevazione di incidenti di sicurezza, al top management per cruscotti direzionali, ...)

Un altro driver fondamentale per la scelta della soluzione è la disponibilità di personale interno per mantenere la soluzione. Una soluzione basata su appliance è tipicamente più semplice da implementare e mantenere rispetto ad una soluzione custom basata su software opensource, in cui ad esempio è necessario sviluppare autonomamente i report (che nelle soluzioni commerciali sono tipicamente già presenti, o più semplicemente sviluppabili).

Quello che generalmente si consiglia, indipendentemente dalla soluzione tecnica scelta, è di non approcciare il Provvedimento da un mero punto di vista tecnologico, ma di coinvolgere le aree organizzative (HR, Privacy, Compliance, ...) per disegnare e formalizzare insieme all'IT i processi ottimali per l'azienda. Questo concetto generale vale non solo per il requisito meramente tecnologico del Provvedimento (quello relativo alla conservazione dei log), ma anche per i requisiti di stampo più tipicamente organizzativo (definizione del processo di verifiche, designazione, mantenimento dell'elenco degli amministratori, ...).

Spero che le considerazioni fatte, per quanto generali, siano lo stesso utili. Consideri che è molto difficile consigliare un prodotto come migliore degli altri per un Provvedimento come questo che per le aziende medio grosse può avere impatti molto consistenti. Per fare capire i due estremi, alcune aziende interpretano il Provvedimento con la necessità di implementare una suite di Identity and Access Management integrata col sistema di Log Management ($$$), altre si limitano a masterizzare i log su cdrom una volta al mese (seguendo il parere del legale interno all'azienda)...

Valentino Squilloni
Security Reply S.r.l.
www.reply.eu

--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Criscione
2009-10-30 22:28:30 UTC
Permalink
In data giovedì 29 ottobre 2009 19:12:05, Squilloni Valentino ha scritto:
[...]
Post by Squilloni Valentino
soluzione basata su appliance è tipicamente più semplice da implementare e
mantenere rispetto ad una soluzione custom basata su software opensource,
in cui ad esempio è necessario sviluppare autonomamente i report (che
nelle soluzioni commerciali sono tipicamente già presenti, o più
semplicemente sviluppabili).
Qui diamo per scontato che si possa fare reportistica a volontà, ma - prima di
trasferirci su Lex - inviterei a riflettere attentamente sulle implicazioni di
questo in termini di controllo dei lavoratori.
--
Claudio Criscione
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Manfredi
2009-10-29 16:01:26 UTC
Permalink
Post by Massimo Giaimo
come sapete entro il 15 dicembre ogni azienda dovrà adeguarsi al
provvedimento del Garante della privacy relativo al controllo delle
attività degli amministratori di sistema. Volevo sapere se qualcuno in
lista ha già avuto modo di testare qualche prodotto ed eventualmente se
potesse dare un giudizio sui pro e sui contro delle soluzioni provate.
Soluzioni ce ne sono molte. Free e Commerciali. Personalmente mi trovo molto
bene con la soluzione di RSA. La piattaforma enVision è facile da installare e
la manualistica per la configurazione delle fonti per l'invio dei log è molto
completa. Propone molte opzioni di personalizzazione sia dei report che degli
alert. Se lo provi fammi sapere che ne pensi...
Ciao
Manfredi
rino lo turco
2009-10-29 17:29:03 UTC
Permalink
Post by Massimo Giaimo
Buongiorno a tutti,
come sapete entro il 15 dicembre ogni azienda dovrà adeguarsi al
provvedimento del Garante della privacy relativo al controllo delle
attività degli amministratori di sistema.
Non *ogni* azienda ma solo le aziende che non rientrano nella
"semplificazione" ovvero quelle che non possono fare
l'autocertificazione ovvero quelle che sono obbigate al DPS.
Pregherei di non dare falsi messaggi, ma sollo messaggi che rispondo
alla normativa vigente .
Grazie

rino
Marco Bizzantino
2009-10-29 16:06:24 UTC
Permalink
sapere se qualcuno in lista ha già avuto modo di testare qualche pr
odotto ed eventualmente se potesse dare un giudizio sui pro e sui co
ntro delle soluzioni provate.
Io sto testando un prodotto chiamato splunk presso un cliente con
circa 200 server.
Ho visto anche altre soluzioni ma questa Ú quella che mi ha
soddisfatto maggiormente.

Disponibile a dare ulteriori informazioni se interessa.

Ciao
Bizza
Simone (carverrace@gmail.com)
2009-10-31 15:22:30 UTC
Permalink
Post by Marco Bizzantino
Post by Massimo Giaimo
sapere se qualcuno in lista ha già avuto modo di testare qualche
prodotto ed eventualmente se potesse dare un giudizio sui pro e sui
contro delle soluzioni provate.
Io sto testando un prodotto chiamato splunk presso un cliente con
circa 200 server.
Ho visto anche altre soluzioni ma questa è quella che mi ha
soddisfatto maggiormente.
Disponibile a dare ulteriori informazioni se interessa.
Ciao
Bizza________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Ho visto il prodotto da te menzionato e sembra carino per il fatto di
tirar fuori dei buoni report.

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.

Ciao.________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Bizzantino
2009-11-01 17:19:47 UTC
Permalink
Post by Simone (***@gmail.com)
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
Marco________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Simone (carverrace@gmail.com)
2009-11-02 12:55:48 UTC
Permalink
Post by Marco Bizzantino
Post by Simone (***@gmail.com)
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
Marco________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Vero. La mia era una pura divagazione al Worm.

Sta di fatto che ciò che dici è corretto. Una firma debole a garanzia
dell'immodificabilità del dato dovrebbe essere uno dei requisiti
minimi della soluzione che deve essere presa in considerazione.________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Zanero
2009-11-03 21:14:44 UTC
Permalink
Post by Simone (***@gmail.com)
Post by Marco Bizzantino
Il garante non parla mai di supporti worm, l'immodificabilita' del
dato e' in realta' una "garanzia che il dato non sia stato alterato",
Cosa che si puo' ottenere mediante, ad esempio, un server di logging
qualsiasi che non possa essere acceduto dagli stessi amministratori che
dobbiamo loggare.
Post by Simone (***@gmail.com)
Sta di fatto che ciò che dici è corretto. Una firma debole a garanzia
1) "firma debole" e' un termine inesistente, definire firma debole prego.

2) firma di chi ? Apposta come ? Se e' apposta in automatico da una
macchina con la chiave che sta sulla macchina, e' valida "tanto quanto"
un hash. Ovvero, manifestamente inutile.
--
Cordiali saluti,

Ing. Stefano Zanero, PhD
CTO & Co-Founder

Secure Network S.r.l.
Via Venezia, 23 - 20099 Sesto San Giovanni (MI)
Phone: +39 02.24126788
Fax: +39 02.24126789
email: ***@securenetwork.it
web: www.securenetwork.it
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Alessio L.R. Pennasilico - mayhem
2009-11-04 00:33:55 UTC
Permalink
Post by Stefano Zanero
Post by Simone (***@gmail.com)
Post by Marco Bizzantino
Il garante non parla mai di supporti worm, l'immodificabilita' del
dato e' in realta' una "garanzia che il dato non sia stato
alterato",
Cosa che si puo' ottenere mediante, ad esempio, un server di logging
qualsiasi che non possa essere acceduto dagli stessi amministratori che
dobbiamo loggare.
Post by Simone (***@gmail.com)
Sta di fatto che ciò che dici è corretto. Una firma debole a garanzia
1) "firma debole" e' un termine inesistente, definire firma debole prego.
2) firma di chi ? Apposta come ? Se e' apposta in automatico da una
macchina con la chiave che sta sulla macchina, e' valida "tanto quanto"
un hash. Ovvero, manifestamente inutile.
3) Io che mi preoccupo oltre che di firmare, di marcare temporalmente
quello che firmo, sono troppo paranoico?

un mayhem ed il troppo cardinal mendoza
--
If we keep asking questions and thinking outside the box, there will
always be something good to look forward to. E. Goldstein
http://mayhem.hk - Key on pgp.mit.edu ID B88FE057

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Maria Elena
2009-11-04 14:37:17 UTC
Permalink
Post by Alessio L.R. Pennasilico - mayhem
Post by Stefano Zanero
Post by Simone (***@gmail.com)
Post by Marco Bizzantino
Il garante non parla mai di supporti worm, l'immodificabilita' del
dato e' in realta' una "garanzia che il dato non sia stato alterato",
Cosa che si puo' ottenere mediante, ad esempio, un server di logging
qualsiasi che non possa essere acceduto dagli stessi amministratori che
dobbiamo loggare.
Post by Simone (***@gmail.com)
Sta di fatto che ciò che dici è corretto. Una firma debole a garanzia
1) "firma debole" e' un termine inesistente, definire firma debole prego.
2) firma di chi ? Apposta come ? Se e' apposta in automatico da una
macchina con la chiave che sta sulla macchina, e' valida "tanto quanto"
un hash. Ovvero, manifestamente inutile.
3) Io che mi preoccupo oltre che di firmare, di marcare temporalmente
quello che firmo, sono troppo paranoico?
un mayhem ed il troppo cardinal mendoza
Direi di no...la ritengo anch'io la soluzione giusta, ma per ora sono
ferma al grepping sui log del secure per gli accessi...

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
Stefano Zanero
2009-11-04 15:10:39 UTC
Permalink
Post by Alessio L.R. Pennasilico - mayhem
Post by Stefano Zanero
2) firma di chi ? Apposta come ? Se e' apposta in automatico da una
macchina con la chiave che sta sulla macchina, e' valida "tanto quanto"
un hash. Ovvero, manifestamente inutile.
3) Io che mi preoccupo oltre che di firmare, di marcare temporalmente
quello che firmo, sono troppo paranoico?
Rimangono i problemi che evidenziavo (chi firma i log? tu a mano?) e ne
aggiungi uno di costo (una marca temporale costa quei 20 centesimi
spannometrici...).
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. +39 02 2399-4017
Fax. +39 02 2399-3411
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Criscione
2009-11-04 17:40:19 UTC
Permalink
In data mercoledì 4 novembre 2009 01:33:55, Alessio L.R. Pennasilico - mayhem
[...]
Post by Alessio L.R. Pennasilico - mayhem
3) Io che mi preoccupo oltre che di firmare, di marcare temporalmente
quello che firmo, sono troppo paranoico?
Secondo me non c'è una risposta diretta e univoca.
Si parla di "misure commisurate" ed il garante ha anche ribadito, in sostanza,
che "dipende". Tutto sommato, per quanto si possa interpretare la cosa in un
sacco di modi, credo che sia indice di ragionevolezza... che poi faccia
impazzire noi tecnici è tutt'altro discorso :-)
--
Claudio Criscione

Secure Network S.r.l.
Via Venezia, 23 - 20099 Sesto San Giovanni (MI) - Italia
Tel: +39 02.24126788 Mob: +39 392 3389178
email: ***@securenetwork.it
web: www.securenetwork.it
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
nicola mondinelli
2009-11-02 16:36:11 UTC
Permalink
Post by Marco Bizzantino
Post by Simone (***@gmail.com)
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.
ma l'hash generato è firmato??
generare un hash dopotutto non è cosi' complicato: modifico o cancello
le righe del log e poi rigenero l'hash e il gioco è fatto.

se non è firmato a mio avviso non soddisfa affatto il requisito, a mio
avviso ovvio.
NM
Post by Marco Bizzantino
ciao
Marco________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco Bizzantino
2009-11-04 13:16:34 UTC
Permalink
Post by nicola mondinelli
ma l'hash generato è firmato??
generare un hash dopotutto non è cosi' complicato: modifico o
cancello le righe del log e poi rigenero l'hash e il gioco è fatto.
se non è firmato a mio avviso non soddisfa affatto il requisito, a
mio avviso ovvio.
NM
Provo a rispondere brevemente, cosi' confronto la mia esperienza con
chi sicuramente conosce meglio di me tutte le sfumature di questo dps.
Sia chiaro che il mio obiettivo e' quello di chiarire questi aspetti,
e se possibile aver suggerito un prodotto che soddisfa la richiesta
iniziale, e non fare pubblicita' al prodotto stesso.

Splunk di fatto lavora come un generico server di logging
centralizzato, indicizza i dati in base a regole opportunamente
configurate, archivia i dati su filesystem, e fornisce strumenti user-
friendly per effettuare ricerche e creare reportistiche/alert in base
a quello che ha nel suo db.
Questi database (su file) sono crittografati e ogni record marcato con
un hash, e dall'interfaccia utente/amministratore, io non ho la
possibilita' di andarli a modificare, ma posso solo eseguire ricerche
(query).
Ovviamente se ho accesso a quella porzione di filesystem io sono in
grado di modificarli e cancellarli, ma a parte il fatto che un db
crittografato non e' cosi' semplice da aprire, correrei il rischio di
rendere questi dati illeggibili.
Se il mio obiettivo e' quello di compromettere i dati indicizzati ho
ottenuto il mio scopo, ma qui la questione si sposta sulla sicurezza
del mio storage piuttosto che alla compliance del prodotto con il
famoso dps.

Cosa ne pensate?

ciao
bizza________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Domenico Viggiani
2009-10-30 15:53:47 UTC
Permalink
Post by Massimo Giaimo
come sapete entro il 15 dicembre ogni azienda
dovrà adeguarsi al provvedimento del Garante
della privacy relativo al controllo delle
attività degli amministratori di sistema.
Ho notato che si parla esclusivamente di collezionamento ed archiviazione
dei log. In realtà, il provvedimento del Garante è più ampio e riguarda il
"controllo" degli accessi degli amministratori di sistema.
Se dieci amministratori adoperano tutti "root" per l'accesso ai sistemi, non
è che collezionando i log si ottempera al provvedimento :-)
Io, per prima cosa, sto configurando su tutte le macchine Linux
l'autenticazione centralizzata sul dominio Active Directory (tramite
Kerberos+LDAP), disabilitando, nel contempo, l'accesso da remoto attraverso
utenze generiche (es. utenze applicative ed ovviamente "root"). Tutti
possono quindi accedere attraverso l'account personale di dominio Windows ed
eventualmente impersonare l'utenza applicativa o amministrativa desiderata
con "su".
Mi rimane scoperto l'accesso da console (c'è la sicurezza fisica del Data
Center ma, spesso, le console sono accessibili da remoto e quindi siamo
punto e daccapo).

Segue logging centralizzato da qualche parte, ma lo considero un aspetto
secondario (non come importanza ma come ordine temporale).

--
Domenico Viggiani

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Claudio Criscione
2009-10-30 22:25:54 UTC
Permalink
[...]
Post by Domenico Viggiani
utenze generiche (es. utenze applicative ed ovviamente "root"). Tutti
possono quindi accedere attraverso l'account personale di dominio Windows
ed eventualmente impersonare l'utenza applicativa o amministrativa
desiderata con "su".
Mi rimane scoperto l'accesso da console (c'è la sicurezza fisica del Data
Center ma, spesso, le console sono accessibili da remoto e quindi siamo
punto e daccapo).
Perdonami, ma come mai non hai considerato l'opzione naturale di usare sudo e
bloccare root del tutto?
--
Claudio Criscione
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Luca Berra
2009-10-31 09:09:11 UTC
Permalink
Post by Domenico Viggiani
possono quindi accedere attraverso l'account personale di dominio Windows ed
eventualmente impersonare l'utenza applicativa o amministrativa desiderata
con "su".
io in un caso ho dovuto mettere su un meccanismo con sudo e sudosh, per
poter loggare i comandi inseriti dagli utenti dopo un su a un utenza
privilegiata (root, dba, etc...)
Post by Domenico Viggiani
Mi rimane scoperto l'accesso da console (c'è la sicurezza fisica del Data
Center ma, spesso, le console sono accessibili da remoto e quindi siamo
punto e daccapo).
molti sistemi di console remota prevedono la possibilita' di autenticare
gli utenti su un AD o un ldap, in caso contrario puoi utilizzare un
firewall che implementi una user-based authentication per dare accesso
alle console :(

L.
--
Luca Berra -- ***@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
S***@ar-ent.net
2009-11-04 10:19:52 UTC
Permalink
[start quoting]
------------------------------------------------------------
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
Marco
[end quoting]

Concordo sul fatto che una soluzione come Splunk possa ritenersi idonea,
così come tutte le soluzioni che permettono di marcare e archiviare i dati
con un *semplice* hash. Esaminando attentamente il provvedimento si trova,
infatti, quanto segue:

"{...} Le registrazioni (access log) devono avere caratteristiche di
completezza, inalterabilità e possibilità di verifica della loro integrità
adeguate al raggiungimento dello scopo di verifica per cui sono
richieste.{...} "

e, ancora, nelle relative FAQ (12 e 13) si specifica che il requisito di
inalterabilità dei log 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".

Questo equivale a dire che, i dati in questione non devono avere - ai
sensi del provvedimento - alcun requisito di non ripudiabilità, né risulta
necessaria la memorizzazione su supporti WORM. Si chiede unicamente che il
dato sia acquisito e conservato *in condizioni di ragionevole sicurezza e
con strumenti adatti, in base al contesto in cui avviene il trattamento*.
Un log, in sostanza, potrà dirsi “inalterato” qualora vengano usati i
normali strumenti di integrità dei dati già disponibili nei sistemi
operativi o eventualmente ottenibili mediante appositi software, dei quali
tuttavia non si indica alcun grado di sofisticazione. Per i casi più
semplici, il Garante afferma che può essere sufficiente esportare
periodicamente tali log file su supporti non riscrivibili, ma non vi sono
indicazioni stringenti; e quando indica i *supporti di memorizzazione non
riscrivibili* fa riferimento anche, ad esempio, a oggetti come CD-R/DVD-R
et similia, non necessariamente - e soltanto - a strumenti WORM.
E onestamente, in questo caso, non mi pare che l'indicazione sia frutto di
ignoranza, ma solo di espressa volontà ...

JM2C ...
Ciao,
Sonia

-----------------------------------------------------------
Sonia Valerio - CISSP, IQNet-ISM, OPSA
***@gmail.com
Marco Gaiarin
2009-11-13 13:25:48 UTC
Permalink
Mandi! Massimo Giaimo
In chel dì si favelave...

MG> come sapete entro il 15 dicembre ogni azienda dovrà adeguarsi al
MG> provvedimento del Garante della privacy relativo al controllo delle
MG> attività degli amministratori di sistema. Volevo sapere se qualcuno in
MG> lista ha già avuto modo di testare qualche prodotto ed eventualmente se
MG> potesse dare un giudizio sui pro e sui contro delle soluzioni provate.

Arrivo come sempre tardi su questo thread, ma spero di non dire
(troppe) cavolate, anzi spero di dire cose utili e che magari qualcuno
mi completi un po' qualche tassello mancante.

Allora, innanzitutto concordo che il provvedimento del garante Ú
assolutamente condivisibile nello spirito, e che il 'livello di
paranoia' (e quindi le modalità di gestione 'sicure') non Ú fisso ma
deve essere scientamente definito a priori dall'azienda.

Concordo anche sul fatto che visto che si deve implementare questo
accorcchio, Ú bene prevedere che sia abusato ben oltre le misure minime
del garante, ma magari usato per collezionare eventi di altro tipo (nel
rispetto della privacy dei dipendenti).

Io mi sono orientato verso una appliance, ed esattamente perchÚ non
avevo nessuna intenzione di perder tempo a mettere in piedi e fare il
fine tuning della parte di reporting.
Il prodotto non Ú di quelli blasonati (che ho scartato per le
dimensioni e la struttura della mia azienda...) ma di una ditta
italiana che però ha fatto un prodottino per me molto interessante (non
l'ho ancora comprato, quindi se questa email vale come buono-sconto...
;-):

http://www.securelog.it/

Sostanzialmente usa syslog oppure un client 'propietario' per
reccogliere gli eventi nella appliance, dove Ú montato sawmill per il
reporting.


In generale mi sono anche messo a guardare le soluzioni libere, o a
pensare di costruirne una, ma (a parte la reportistica, come dicevo,
che non Ú un problema occorre solo avere tempo e volgia di farla...) ci
sono tre problemi (a mio avviso):

1) lo storage sicuro: non Ú un problema insormontabile, forse Ú la
parte più facile, ma certo occorre prendere un server e 'inscatolarlo'
per bene, in contesti critici potrebbe essere una bella sfida.

2) il trasferimento sicuro (safety) dei log: syslog su udp non Ú
sicuramente il candidato, usare syslog su tcp potrebbe andare ma
occorre tenere in considerazione che il provvedimento si applica anche
ai client, e quindi anche ai client nomadici o con connettività non
always on.
Occorre un sistema che implementi un trasferimento dei log in maniera
'offline', e potrebbe essere RELP:
http://www.rsyslog.com/doc-relp.html
http://www.librelp.com/

implementato che io sappia in rsyslog e basta.

3) il trasferimento sicuro (security) dei log: non per tutti potrebbe
essere un requisito (nel senso che i log Ú sufficiente che vengano
timestampati e hashati sul server...), ma qualcuno potrebbe volere
anche questa sicurezza.
Ho scoperto che esiste una apposita draft:
https://datatracker.ietf.org/idtracker/draft-ietf-syslog-sign/
con una implementazione:
http://syslog-sec.sourceforge.net/

ma non conoscendo bene come girano le cose in IETF non capisco se Ú una
cosa 'seria' o se ne parla da anni e non si conclude nulla. ;-)))


A naso in questo momento per implementare una soluzione totalmente
libera sarebbe necessario implementare (o pacciare) un server syslog di
modo che supportasse 2) e 3) (se riescono a convivere...), e farlo
ovviamente per tutti i sistemi operativi, quindi anche per windows.


Spero questo post possa essere utile, e magari se qualcuno ha qualche
altro pezzettino per il puzzle...
--
Errare Ú umano, ma per fare veramente casino
ci vuole la password di root (Zio Budda)
Continue reading on narkive:
Loading...