Newsgroup: it.comp.os.linux.sys
Titolo: Hash dei log per la conformità al Garante

Utilizzo Splunk per la racolta dei log centralizzata è funziona benino
ora ho il problema di calcolare l'hash e firmare digitalmente questi
log per la conformità al garante.
Ringrazio chiunque mi dia indicazioni in merito anche in relazione
alle soluzioni adottate per la conformita al garante per l'D.d.S.

 log per la conformità al garante.
Premetto di non conoscere affatto bene la normativa, ma
perche' dovrebbero essere firmati e da chi?
perche' se ne dovrebbe calcolare un hash?
Qualora si dovessero svolgere queste attivita` (cosa che non credo),
non vedo quali siano i problemi tecnici a farlo.
A quanto ne ho capito io basta che i log non siano modificabili e
questo obiettivo viene raggiunto 
p.es
. semplicemente masterizzandoli
su CD-ROM

 viene raggiunto 
p.es
. semplicemente masterizzandoli su CD-ROM
Si`, ma non devono mai essere modificabili, nemmeno un nanosecondo dopo 
che li hai scritti, quindi devi tenere una sessione aperta sul CD-ROM e 
scrivere riga per riga li`. Non puoi farlo la sera o ogni ora, deve 
essere in tempo reale.
Quella della firma non la sapevo nemmeno io, ma so che ci sono servizi su 
Internet che offrono il servizio di logging remoto e di certificazione 
della non modificabilita`.
Poi, come sappiamo, e` lo stesso root a configurare la propria macchina, 
e puo` loggare come non loggare quello che vuole, ma tant'e`...
Bye.

 essere in tempo reale.
Dove sta scritto? Rileggiti le FAQ del garante, la mette giù in modo molto 
differente rispetto alla prima lettura.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 log per la conformit� al garante.
Non � necessario, ma se vuoi farlo puoi fare una cosa cos�:
##########################################
#!/bin/bash
FILENAME=$1
TMP=$(mktemp)
MD5S=$(md5sum "$FILENAME")
HASH=$(echo "$MD5S" | cut -c1-32)
FILE=$(echo "$MD5S" | cut -c35-)
TIME=$(date '+%Y%m%d%H%M%S')
echo "File: $FILE" > $TMP
echo "Hash: $HASH" >> $TMP
echo "Time: $TIME" >> $TMP
ntpq -pn >> $TMP
if gpg --batch --sign --output "$FILENAME.sign" $TMP
then
     logger -p 
local0.info
 -t sign "Successfully signed File: $FILE"
else
     logger -p local0.error -t sign "Failed signing File: $FILE Error: $?"
fi
rm $TMP
##########################################
Ovviamente prima devi aver generato una chiave gpg con cui firmare.
Per vedere la firma
gpg --decrypt $FILENAME.sign
e confronti l'hash


 differente rispetto alla prima lettura.
Quindi anche la demenza tecnica del garante non e` infinita.
Ma io mi chiedevo e con un logserver non acccedibile se non in lettura
e solo dall'auditor, i requisiti del caso non sarebbero
automaticamente rispettati? Ma e se poi il disco del logserver ci
lascia? Mi sa che comunque su CD ogni tanto e` meglio salvare i log.

 MD5S=$(md5sum "$FILENAME")
So che e` ancora in uso, ma md5 non e` deprecato perche' crackabile?

 lascia? Mi sa che comunque su CD ogni tanto e` meglio salvare i log.
Teoricamente dovrebbe comunque rientrare nella 196/03 dato che nei log ci 
sono dati personali (gli username), quindi saresti obbligato ad avere un 
backup dei dati settimanale. C'� per� da dire che se i log li mantieni per 
almeno 7 giorni anche sulle macchine che centralizzi potresti considerare la 
gestione centralizzata dei log alla stregua di un backup e quindi scamparla 
in quel modo.
Io comunque faccio un salvataggio mensile su DVD.


 Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)
Ubuntu in Tutzi significa "Preferisco usare Debian riuscita bene"

 essere in tempo reale.
Ma anche no.
Ripetete come un mantra "il provvedimento del Garante è una cagata
pazzesca" e leggete la FAQ.


Tutto va rapportato all'uso che se ne deve fare. Per questo scopo basterebbe 
anche crc32 perch� non vi � nulla di particolare da proteggere, � solo un 
contentino per chi dovesse venire a rompere le palle e non si accontentasse 
di un caff�.
Quanto alla cracckabilit� di MD5, anche se la via � segnata, siamo ancora 
distanti. Sono state trovate delle debolezze nell'algoritmo che fan s� che 
in particolari condizioni si possa trovare una collisione in 2^39 o anche in 
2^32 cicli invece che in 2^64, e questo pu� effettivamente essere un 
problema perch� quell'ordine di grandezza � oggi gestibile da un 
supercomputer (o un cluster di calcolo). Ma se questo significa che un 
certificato x509 non � da ritenersi sicuro se firmato usando MD5, non 
significa che tale funzione non sia usabile per molti altri scopi come questo.


 normativa tecnicamente valida
Bah, io avrei dei dubbi anche su questo, consentimelo. :)

 questa saggia decisione.
Cos� ti becchi pure una denuncia per trattamento illecito di dati personali 
dato che li hai comunicati a terzi senza averne l'autorizzazione. Siamo in 
Italia :-)
-- 
Flavio Visentin


 alle soluzioni adottate per la conformita al garante per l'D.d.S.
Io usavo certificati SSL, verificati localmente con openssl e abbiamo 
passato la verifica del garante senza problemi ...
In linea di massima, veniva prodotto un certificato, con password, per 
ogni server sul quale venivano raccolti i log.
La password veniva letta da un file di testo accessibile solo all'utente 
che effettuava lo scambio dei file... un po' idiota questa parte qui.
se vuoi dettagli dammi un attimo per ricordare perch� ho cambiato lavoro 
a Novembre ....
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 su CD-ROM
non � questo il concetto. Nel mio caso (uguale per tutti gli operatori 
Telco) si tratta di una mole immensa di dati di audit, che deve essere 
scaricata giornalmente da ogni singolo server.



Il caso citato mi pare che richieda l'attivazione dell'audit. Tu 
registrerai l'accesso dell'utente 'pippo', nonch� tutti i comandi che 
pippo lancia fino al logout. Ripulirai la configurazione dell'audit per 
evitare di ricevere syscall delle quali non te ne frega nulla, ma in 
linea di massima, in una server-farm di quelle toste non � gestibile in 
real-time.
Non credo che ce la fai ad usare un syslog server.
Ti dico solo una cosa (TIENITI FORTE E NON TI SPAVENTARE): la sola 
server-farm dei server per la raccolta dell'audit nell'azienda XXX (la 
conoscete tutti), consiste di 150 (centocinquanta) server RedHat!
150 server solo per raccogliere gli audit di tutti gli altri server... 
non so se mi spiego....
Si tratta di un DB relazionale e gerarchico di tipo distribuito, dove i 
dati sono distribuiti in questo anello composto da tutti questi nodi.
La server-farm analoga che ho "deployato" io in una azienda un po' pi� 
piccola, consisteva di circa 40 RedHat.


 Italia :-)
No, io pensavo di trasmettergli crittati e poi di fargli avere un bel
plico in cui descrivo tutta la loro storia e fornisco i recapiti per
chiedere la chiave per decrittarli. :-)


chiaramente il gpg che suggerisce zipman va altrettanto bene.


 pippo lancia fino al logout.
Si`, questo avrebbe senso, ma non pretenderai che la normativa abbia
senso. Che io sappia e` solo richiesta la registrazione degli accessi
e delle disconnessioni. In pratica l'auth.log (UNIX) e quello della
sicurezza Windows, dai quali potresti poi anche escludere gli accessi
che non riguardano gli ADS. Non e` poi tutta questa mole di dati. Non
e` molto utile (per usare un eufemismo) praticamente in qualsiasi
circostanza e infine e` facilmente aggirabile da un amministratore di
sistema che manometta i log prima che vengano registrati, quindi in
conclusione piu` che inutile  direi che e` dannosa, dato il tempo che
fa perdere per ottenere dei risultati senza costrutto.

 e delle disconnessioni.
non prentendo di saperti rispondere, in quanto non lavoro in un ufficio 
legale.
Posso solo dirti, quello che mi richiedevano di dover fare e nel nostro 
caso registravamo *tutto*, ma proprio tutto:
wget 
http://porntube/porno.mpg
, vlc porno.mpg e cos� via .... (*) :-)
Non so se questa differenza � normata anch'essa, forse in base al 
settore in cui opera l'azienda.
Non ti so proprio dire. Nel mio caso era Telco.
Aggiungo che c'� un ulteriore, terzo caso: dati per la magistratura.
La registrazione di questi dati avviene in "gabbie" (aree con accesso VPN).
(*) era un lavoro da matti!! Bastava uno script in giro scritto ad 
cacchium e ti mandava tutto a puttane sul tuo DB.
Una volta ho scovato uno script su uno dei tanti server che lanciava 
degli awk, su degli array che lui si costruiva.
Di fatto era un casino (e ora non vado nel dettaglio) e sul DB mi 
trovavo un milione di 'awk' al giorno provenienti da una singola 
macchina .... ma io non ero responsabile delle macchine dalle quali 
prendevo i dati. Chiedevo all'owner e mi diceva sempre "non so, non so".
Mi toccata andare su tutte quelle merde di macchine a risolvere i 
problemi uno per uno.
Fortuna che ho cambiato lavoro :-)


 (*) era un lavoro da matti!!
un'altra volta ancora ho trovato una syscall in giro che mi generava 
svariati milioni di entry al giorno. Si trattava della syscall 'semop'.
Per farla disattivare, cosa che sembra banalissima, abbiamo dovuto fare 
una conference-call con i manager e uff... uff .... uff che non ti 
dico..... una palla incredibile!



qui entra in ballo la parte pi� controversa di tutta la norma.
La pretesa - secondo l'ufficio legale della azienda - era che io dovevo 
essere in grado di poter amministrare tutto l'ambar-adam, senza per� 
poter accedere al dato stesso.
E vai l�, mesi a spiegare l'impossibilit� di ci�.
Io parlavo il "tecnichese", il mio interlocutore parlava il "legalese" e 
siamo andati avanti per mesi a non capirci l'uno con l'altro, fin quando 
un bel giorno mi hanno recapitato una bella liberatoria da firmare che 
ha risolto tutti i problemi nell'unico modo possibile.
Io mi impegnavo a non guardare un dato (del quale non mi interessava 
assolutamente nulla) e loro si impegnavano a scomparire per sempre dalla 
mia vita.
in tecnichese la cosa era di una stupidit� unica: io ero admin di un DB 
relazionale, sul quale dovevo poter fare delle insert e delle drop, ma 
la granularit� del DB "� quella che �", e sia una insert, sia un drop, 
richiedono il privilegio minimo della select.


 wrote:

La norma fra le altre cose dice testualmente :
4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi
logici (autenticazione informatica) ai sistemi di elaborazione e agli
archivi elettronici da parte degli amministratori di sistema. 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.Le registrazioni devono comprendere i riferimenti
temporali e la descrizione dell'evento che le ha generate e devono
essere conservate per un congruo periodo, non inferiore a sei mesi.
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.
La FAQ 4 dice :
Nei casi più semplici tale requisito può essere soddisfatto tramite
funzionalità già disponibili nei più diffusi sistemi operativi, senza
richiedere necessariamente l'uso di strumenti software o hardware
aggiuntivi. Per esempio, la registrazione locale dei dati di accesso
su una postazione, in determinati contesti, può essere ritenuta idonea
al corretto adempimento qualora goda di sufficienti garanzie di
integrità.
Sarà comunque con valutazione del titolare che dovrà essere
considerata l'idoneità degli strumenti disponibili oppure l'adozione
di strumenti più sofisticati, quali la raccolta dei log centralizzata
e l'utilizzo di dispositivi non riscrivibili o di tecniche
crittografiche per la verifica dell'integrità delle registrazioni.
La FAQ 12 dice
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.
Ora la norma è stata fatta apposta prevede varie interpretazioni per
essere sicuro però in caso di controllo i log devono essere
immodificabili (crittografati) e raccolti su un log server
centralizzato. (nelle verifiche effettuate hanno sempre richiesto
queste caratteristiche).
Sono daccordo che come è stata fatta è una misura demenziale ma visto
che possono dare una multe da 30  a 180,000 €
è sempre meglio attuare la soluzione che nel tuo contesto di fornisce
piu garanzie anche perchè se sei stato nominato A.d.S. devi
giustificare le tue scelte tecniche al titolare.
Mi piacerebbe conoscere le vostre soluzione o indicazioni per la
raccolta dei log degli A.d.S. nelle vostre strutture operative e se
avete ricevuto la nomina ad A.d.S.
Ciao a tutti

 e leggete la FAQ.
Questo lo faro` al piu` presto.
Bye.

 raccolta dei log degli A.d.S. nelle vostre strutture operative 
Syslog centralizzato che raccoglie i soli accessi amministrativi e firma 
elettronica non qualificata ogni ora con backup giornaliero e salvataggio 
mensile su DVD.


 che possono dare una multe da 30  a 180,000 ï¿½
ecco: questo ï¿½ uno dei motivi per cui eviterei, se possibile, di 
mettermi a fare anche l'avvocato oltre che l'informatico.


 log per la conformit� al garante.
Faccio notare solamente che TU, che sei l'admin saresti in conflitto 
d'interessi con te stesso quando vesti il ruolo di colui che raccoglie i 
dati.
Poi ognuno pu� farsi i film che vuole su tale normativa, ma tanto alla 
fine sono le solite cose all'italiana....

 salvataggio mensile su DVD.
Chi gestisce il syslog server?
:)


Io. La legge non dice nulla a tal riguardo e visto che l'utilitï¿½ di quei log 
per la sicurezza ï¿½ esattamente pari a zero non vedo perchï¿½ complicarsi 
inutilmente la vita.
Utilizzando syslog se volessi fare il coglione basterebbe che staccassi il 
cavo di rete al login ed al logout e non si vedrebbe nulla.


 chiunque avesse idee alternative le faccia presenti....
Salvi su uno storage normalissimo e firmi digitalmente. Oppure se vuoi 
qualcosa di worm recuperi una vecchia stampante ad aghi e un pacco di nastro 
continuo e stampi l'hash di ogni file firmato. Oppuri salvi su DVD come 
detto dal garante. Oppure manti in append su un nastro LTO4 Worm (hai 800GB 
non compressi a nastro da poter riempire).


 DVD come detto dal garante.
Anche questo va bene in contesti di ridotte dimensioni.
Nel contesto in cui ho operato, erano stati predisposti 40 server Linux 
con lo scopo di raccogliere dati di audit.
Successivamente ho cambiato azienda, e anche tipo di lavoro, e a un paio 
di scrivanie di distanza ascoltavo dei colleghi che parlavano dello 
stesso prodotto che io avevo usato poco prima.
Un giorno gli ho chiesto delucidazioni e mi hanno detto che 
l'installazione del prodotto (che si chiama Sensage) consiste di 150 
server Linux.
Ciï¿½ ti fa rendere conto, di quanto possa essere *immenso* il database 
che memorizza i dati di audit e di che mole di dati stiamo parlando?


 dati.
Chiaro. Altrimenti, tu te la canti e tu te la suoni :)
Il fatto di essere admin dei vari sistemi in giro, e admin pure del 
server che raccoglie i log � una cosa che non va.
Almeno formalmente, deve figurare che chi raccoglie quei dati, non sia 
pure admin dei sistemi dai quali li raccoglie.
Infatti, io avevo un accesso sudo pro tempore sui sistemi target. Ed ero 
admin solo del sistema di raccolta dell'audit.


 mi ricordo) dell'azienda, richiedevano di fare.
Cio` di cui credo si stia parlando e` la normativa introdotta dal
garante ed entrata in vigore a meta` di dicembre 2009 sugli ADS
(amministratori di sistema), la quale, che io sappia, non fa richieste
ulteriori rispetto a quelle esposte da Zippomanno.


Pu� darsi che per le aziende del settore telecomunicazioni ci siano 
norme aggiuntive. Perch�, ripeto, per soddisfare le norma del garante, 
sia azienda XXX, sia azienda YYY hanno fatto le stesse identiche cose.
Per�, se parliamo di "non modificabilit� del dato" penso che la cosa non 
cambi. E allora cerchiamo di inquadrare le cose nel loro scenario 
corretto e cerchiamo di capire che io non posso stampare hash per 1000 
server tutti i santi giorni, e che non posso masterizzare 50 DVD al giorno.
Allo stesso modo non fa una grinza quel che fa notare Michela nell'altro 
post: controllore e controllato non possono essere la stessa persona. 
Sarebbe al di fuori di ogni logica.
A rigor di logica non puoi amministrare al tempo stesso sia la server 
farm, sia la raccolta dei tuoi audit.
IMHO ci sono tanti punti oscuri... e anche come � stato fatto da noi, 
secondo me presentava tante lacune. Ma credimi la discussione sarebbe 
talmente lunga che nemmeno ci inizio :)


 talmente lunga che nemmeno ci inizio :)
Bisognerebbe cominciare dalla fine  e cioe` da qual e` l'obiettivo che
voleva raggiungere il legislatore.

 voleva raggiungere il legislatore.
L'obbiettivo del legislatore era chiaro: visto che per poter lavorare 
l'amministratore deve avere dei privilegi che gli consentono di accedere a 
dati personali e/o sensibili cui non dovrebbe n� potrebbe avere accesso, � 
opportuno istituire un minimo di controllo sugli accessi in modo da sapere 
quando l'admin ha avuto tale possibilit�.
Peccato che come al solito si sia perso in un bicchier d'acqua, imponendo 
cose inutili e non considerando cose invece essenziali (come la 
conservazione dei backup).


 la conservazione dei backup).
Non � possibile fare backup di una quantit� di dati cos� imponenente.
Ma non tanto perch� ti serviranno troppe cassette, ma perch� i dati 
successivi ti arriverano ancora prima che tu abbia finito il backup in 
corso.
Non farai in tempo a backuppare i dati: sono troppi e arrivano in 
continuazione.
I dati sono ridondati con un cluster applicativo: ciascuno dei nostri 
nodi contiene i suoi dati, e i dati del nodo successivo.
Se ti scoppiano i due nodi adiacenti, denunci l'evento, e fai una nota 
scritta per il garante.
Inoltre, non serve conservare quei dati, perch� pian piano, saranno 
svecchiati dalla politica di max retention.


 voleva raggiungere il legislatore.
gli obiettivi potrebbero anche essere pochi, ma, in piccole realt�, dove 
la segregazione dei ruoli � inapplicabile, questi obiettivi sono quasi 
irragiungibili. Quindi o farai finta di raggiungerli, o ti metti a fare 
l'impossibile.
Abbiamo detto che il dato deve essere NON modificabile.
Abbiamo detto che chi amministra i sistemi non devo poter modificare 
quel dato (viceversa chi amministra quel dato non deve amministrare gli 
altri sistemi).
Abbiamo detto che in certi casi (come chiede l'OP) deve essere garantita 
la fonte di provenienza.
Che deve essere garantita una "min retention" e probabilmente una "max 
retention".
blablabla
Di fatto, gli unici semplice da applicare sono la provenienza (tramite 
certificato SSL o chiave GPG) e la retention.
perch� pensate che si pu� essere sempre freschi, e che tutto si pu� fare 
sempre per scherzo?
Se la norma dice che il dato non deve essere modificabile, allora non 
deve essere modificabile. E questo non � uno scherzo.
Nella piccola realt� li butterai su blue ray, o su DVD. Ma nella grossa 
realt� devi trovare un altro sistema.
Poi, se ci dobbiamo mettere a parlare su Usenet di come poter risolvere 
tutti questi problemi, se permetti, faccio un libro e lo pubblico, che 
almeno ci faccio i soldi.


 nodi contiene i suoi dati, e i dati del nodo successivo.
per inciso: puoi trovare un thread iniziato da me, dove chiedevo 
consiglio su come fare il backup di una directory contenente svariati 
milioni di file.
Bene - leggi bene - in attesa che venisse il garante, dovevo fare il 
deploy per l'estensione dei nodi e dovevo fare il backup di uno di 
questi nodi, il quale nodo conteneva SOLO 5 giorni di auditing (poich� i 
dati pi� vecchi di 5 giorni venivano spostati su Centera).
Per fare, la copia raw dei file, con un tar, o con un rsync, ho 
impiegato 24 ore.
LEGGI ANCORA MEGLIO: stiamo parlando solo di 5 giorni, e stiamo parlando 
solo di un trentesimo del dato complessivo, poich� il dato completo era 
distribuito su 30 nodi.... e nell'altra azienda di cui ti parlavavo il 
dato completo era distribuito su 150 nodi.
Siamo ancora alla teoria dell'hash stampato sui pizzini, o ci stiamo 
evolvendo verso qualcosa di pi� avanzato?


 Io. La legge non dice nulla a tal riguardo 
Non ï¿½ cosi, perchï¿½ non PUO' esistere un controllore che sia anche 
controllato, a parte i sindaci revisori delle quotate in borsa 
italiane... :)
Sull'utilitï¿½ possiamo disquisire tranquillamente, sono d'accordo sul 
fatto che sia inutile.

 italiane... :)
Qualche riferimento legislativo, per favore.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 italiane... :)
Ma perchï¿½ ci si deve divertire a sparar minchiate? Tu trova dove sta scritto 
che io, amministratore di sistema, non posso amministrare il log server 
centralizzato coi log degli accessi degli AdS, e ti offro una bella cena.
Se non la trovi me la offri tu?


 bella cena.
Ehi, gliel'ho chiesto prima io.
Se non risponde, la cena ce la offriamo a vicenda. ;-)



premetto che  interpetare la legge non ï¿½ un nostro compito (al massimo 
possiamo interpretare ciï¿½ che fa EMC2, da un punto di vista tecnico(.
Ciï¿½ detto: la legge dice che il dato deve essere non mobificabile.
Il dato che tu registri su un syslog server, dal quale tu puoi staccare 
il cavo di rete, e sul quale tu puoi fare login come root per brasare 
tutto, ti pare che sia un dato non modificabile?
A registrarlo su blu-ray/dvd sarai sempre tu, ma non ci scrivi in tempo 
reale. E prima di passarlo su tali supporto i dati sono sempre alla tua 
mercï¿½.
Secondo me ï¿½ chiaro che non stai ottemperando a quanto prescritto dalla 
legge.


 Ciï¿½ detto: la legge dice che il dato deve essere non mobificabile.
non modificabile = non alterabile, non cancellabile.


 Se non la trovi me la offri tu?
Si`, a ben pensarci questa non e` piu` assurda di altre cose, dato che
lo stesso amministratore di sistema amministra le macchine da cui
vengono i log per cui volendo potrebbe direttamente falsificarli ab
origine, senza nemmeno dover staccare il cavo di rete del log server.
A fare le cose bene ci dovrebbe essere un amministratore di sistema
diverso dal primo responsabile dell'auditing, ma cio` non e` previsto
e credo nemmeno auspicabile, almeno in organizzazioni normali con
normali esigenze di sicurezza.

 diverso dal primo responsabile dell'auditing, ma cio` non e` previsto
E chi controllerebbe gli accessi dell'amministratore di sistema
addetto al controllo dell'auditing?
E come si potrebbe eseguire l'auditing del controllore dell'auditing?
Insomma, io continuo a pensarla in questo modo:
A legiferare sul buon senso si ottengono degli aborti legislativi.
Se sono sysadmin, i log riporteranno solo quello che io voglio che
riportino, se ho deciso di fare qualche giochetto.
E se ci si inventa un super-super-user, che controlla il super-user,
e i cui poteri non ha il super-user, non si fa altro che spostare
verso l'alto il problema, oltre a richiedere la riscrittura della
maggior parte dei sistemi operativi, perch� allora anche il
super-super-user dovrebbe essere controllato da un 
super-super-super-user, e cos� via, ad libitum.
No, questa norma � una bella teoria inapplicabile.
O applicabile solo per forma, ne resta nulla la sostanza e il
beneficio, IMHO.


 normali esigenze di sicurezza.
intendiamoci: la legge non prevedere che ci debbano essere 
amministratori distinti e non deve prevederlo.
La legge ti dice quale deve essere l'obiettivo (immodificabilit� del 
dato). E tu a questo devi attenerti.
Come fai ad ottenere ci�, se non tramite la segregazione dei ruoli? Se 
trovi un sistema differente, userai quello.
Difatto il problema � l'obiettivo: il dato non deve essere modificabile.


 No, questa norma � una bella teoria inapplicabile.
E' di difficilissima, o forse impossibile applicazione. Di questo do atto.



Facebook: Massimo Bacilieri

 legge.
Ma visto che tu non conti un cazzo, che le FAQ hanno dato un'interpretazione 
di riferimento del concetto e che a diversi avvocati va bene cosï¿½, io 
continuo a dormire tranquillo.


 guardi. :-(
Siamo in Italia. Non c'è da aggiungere altro.



quoto.
p.s.: il problema di fondo è che ad essere fuorilegge (secondo questa 
norma) sono i sistemi operativi stessi, che non sono granulari in tal 
senso, al punto di consentire ciò che il legislatore vorrebbe ottenere.
Con lo storage speciale ti avvicini maggiormento al risultato, ma è 
difficile riuscire ad escludere tutte le back-doors.


 Siamo in Italia. Non c'è da aggiungere altro.
Temo che questa norma sia simile/uguale in tutta europa.


 senso, al punto di consentire ciò che il legislatore vorrebbe ottenere.
Dicci la verità.... ti stai allenando per il campionato del mondo di 
velocità o per quello di consistenza?
Sappi che sei già preparatissimo per entrambi; cazzate ne spari a raffica di 
immense, non ti serve altro allenamento per arrivare primo. Risparmia pure 
la banda.



Zip, dillo chiaramente: su questa cosa non ci ho capito una cippa, ma 
ostento ugualmente sicurezza e conoscenza che effettivamente NON ho 
acquisito.
gli avvocati spiegano a te come si interpretano le leggi, ma tu devi 
spiegare agli avvocati i dettagli tecnici dei quali loro necessitano, e 
i problemi tecnici cui vai incontro, nel tentare di applicare la norma.
Sei riuscito ad ottenere un dato *non* modificabile? Come pensi di 
ottenere il raggiungimento di questo scopo? Perché i certificato ISO9001 
e gli uffici legali delle varie aziende non sono d'accordo con quel che 
tu dici?
Io non ho difficoltà a dire che la legge è difficilmente applicabile, ma 
tu non puoi dire che la legge è applicata, non avendola applicata per 
niente.


 niente.
Se tu non capisci quel che leggi è un TUO problema; o magari non leggi e 
quindi non capisci. Comunque è inutile proseguire; tu butta pure tutti i 
milioni che vuoi in inutili storage immodificabili, ma smettila di sparare 
minchiate e vedi di informarti meglio (magari anche attingendo a qualche 
fonte affidabile invece che dai commerciali di storage immodificabili).


 continuazione.
D� la verit�, ti pagano per far la figura del pirla. Non credo che qualcuno 
possa arrivare a tanto senza un sostanziale interesse economico.



se vuoi, incazzati pure, perch� � l'unica cosa che sai fare.
So di cosa sta parlando perch� si tratta di qualcosa che conosco, 
evidentemente meglio di te, e l'ironia non fa assolutamente centro.
Ripeto: se una copia disk to disk mi ha preso 24 ore, una copia su 
nastro, su un backup server remoto, avrebbe impiegato il triplo, il 
quadruplo, 10 volte pi� tempo.
Nella realt� alle quali mi riferisco, non � possibile fare un backup di 
quei dati.
E per finire, c'� pure qualcun altro che tenta di spiegarti che la *tua* 
non � una soluzione al problema.
poi succede che anche i legali non hanno ben chiari i problemi e questa 
� colpa della norma che � di difficile applicazione.
Ma tu non puoi dire di aver soddisfatto i requisiti della norma... 
almeno fintanto che non proporrai all'OP e a me, un metodo per non 
consentire la cancellazione del dato.



il fatto che tu dopo 5 giorni li riversi su blu-ray, non � una 
soluzione, perch� in quei 5 giorni pu� succedere di tutto.
Concentrati su questo, rispondi su questo e lascia fottere tutto il resto.
Inizia a parlarmi di "chattr" e di segregazione dei ruoli e forse 
iniziano ad esserci un po'. Io - francamente - oltre allo speciale 
storage (del quale tu non disporrai di chiavi) e quello che ho appena 
detto (chattr+segregazione) non vedo altre soluzioni.


 detto (chattr+segregazione) non vedo altre soluzioni.
Se non hai chiaro il problema (ti � stato detto circa 50 volte di leggere la 
norma e le FAQ che ne sono l'interpretazione di riferimento ma ancora non 
l'hai fatto e continui a battere incessantemente le tue stupide fantasie ), 
� ovvio che tu non possa vedere nulla al di l� delle idee che ti sei creato 
nella tua mente.



non sono le mie fantasie, caro: io ho semplicemente riportato le 
fantasie di azienda XX e azienda YY....
Parlando di questo aspetto del problema, posto da me e dall'OP, tu hai 
proposto la firma digitale.
Ti si fa subito notare che la firma digitale (memorizzata o stampata su 
carta) protegge solo contro la alterazione del dato.
Adesso, visto che quella *non* � una soluzione, cambi discorso e dici 
che non � necessario.
Bene, ti propongo IO un'altra soluzione alternativa valida per le 
piccole e medie aziende, e pongo fine della discussione:
La firma digitale andr� in realtime su uno storage di dimensioni 
modestissime, sul quale la cancellazione � stata inibita.
Ad ogni file di firma, deve corrisondere un file dei log.
Se per una firma mancher� un file di log, vuol dire che qualcuno lo ha 
cancellato.
Altres�, ascolta bene, testaccia dura: se tu fermi l'audit sul target, 
il riavvio successivo sar� stato registra nel file di audit stesso.
ECCO PERCHE' SI RENDE NECESSARIO REGISTRARE TUTTO, E NON SOLO LE LOGIN 
(non perch� il garante richiede ci�, ma perch� questa pratica consente 
di chiudere il cerchio di tutte le verifiche)
Ma ti si sta iniziando ad aprire un pochettino la mente?


 di chiudere il cerchio di tutte le verifiche)
questa parte qui credo che dovrebbe render chiaro il processo, pi� di 
tutto il resto.


 origine, senza nemmeno dover staccare il cavo di rete del log server.
Appunto.
Se sono amministratore del mio sistema come puoi fidarti dei log che
lo stesso ti manda _sulle mie attivit�_?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 > di chiudere il cerchio di tutte le verifiche)
So di non sapere, ma:
1. come da oggetto si sta parlando del logging degli ADS secondo
quanto previsto da legge entrata in vigore il 15/12/2009, non di altro
2. tale audit richiede solo la registrazione degli accessi (login e
logout) degli ADS e la memorizzazione non alterabile di questi dati e
la loro conservazione per almeno 6 mesi
3. se stacchi il cavo dal log server non e` che l'audit si fermi anche
se certamente finche' non lo riattacchi non arrivano piu` i dati
4. la cosa piu` semplice, senza dover mettere le mani sul log server
per un ADS maligno sarebbe manomettere i logger delle macchine che
inviano le registrazioni al log server.
Data questa situazione non risolvi nemmeno con accrocchi hardware come
quelli che hai descritto, devi avere una o piu` figure di
amministratori addetti a questo compito che soli abbiano i privilegi
per configurare e gestire i logger di tutti i sistemi e del logserver
e di quanto loggato e non solo del logserver. Questo non e` previsto e
dunque la normativa, QED, e` un piccolo monumento alla inutilita`
dannosa in quanto tale.

 se certamente finche' non lo riattacchi non arrivano piu` i dati
Ops, sorry, io a questo non c'ero arrivato.
Immaginavo di staccare il cavo *del mio server*, invio sulla pass,
riattacco il cavo.
Syslogd non lavora in udp?


 Syslogd non lavora in udp?
Mi sembra proprio di si`


syslog lavora anche tcp (syslog-ng)


 inviano le registrazioni al log server.
appunto: modificare i log � una cavolata. Per questo io parlo di audit.
Qui la discussione si complica e viene fuori man mano tutto il resto... 
che spero chiarisca tutti, me compreso.... e se vogliamo parlare 
*seriamente* di non modificabilit� del dato.


 Ma ti si sta iniziando ad aprire un pochettino la mente?
S�, la mente mi si sta aprendo. E' sempre pi� limpida l'associazione tra te 
ed Euclide, solo che lui, a volte, capisce di pi�.


 filtrerai adeguatamente).
Chiaramente, il server che raccoglie l'audit, far� pure self-auditing.
Andiamo avanti.... perch� credo che stiamo ingranando un pochettino.


 c) e se qualcuno cancella i log cosa fai?
AUDIT non LOG.
se qualcuno cancella gli audit ha fatto qualcosa di penalmente 
rilevamente. E pertanto � da inculare.
Al prossimo post ti faccio il disegnino.


 Mi sembra proprio di si`
syslog-ng lavora in tcp. Ma io non parlo pi� di syslog.


 visto un file di audit?
se tu lanci "vi /file/di/audit" va a finire in audit anche questo
se lanci "rm /file/di/audit" questo va a finire nell'audit creato 
successivamente.
Non hai scampo con l'audit.
Questo � il motivo per cui si rende necessario fare auditing, e non solo 
collezzionamento di log.


 dannosa in quanto tale.
È sempre stata la considerazione che mi è venuta... nel momento in cui
un administrator è appunto administrator, ovvero ha potere di gestione
sulla macchina, ha facoltà di alterare il logger a piacere.
A quel punto il log nasce corrotto "ab origine", e tutto il discorso
sulla registrazione, firma, non manomissibilità, duplicazione, storage
su supporti non modificabili e quant'altro, è pura fuffa.


 su supporti non modificabili e quant'altro, è pura fuffa.
siamo prossimi alla fuffa e questo non lo metto in dubbio ^_^
Vi prego, però, di descrivermi passo passo tutte le operazioni che 
eseguireste per alterare un file di audit, o cancellarlo senza farvene 
accorgere.
Spiegatemi, passo passo, la procedura che usereste. Attenzione: non 
parlo di loggin, ma di auditing (che viene utilizzato in luogo del 
loggin per questa precisa ragione).
ti dico in partenza che:
- non puoi fermarlo perché il riavvio viene registrato a nome 
dell'utente che lo riavvia.
- non puoi cancellarlo (a occhio l'rm finisce nel file successivo).
- un vuoto nell'auditing è palesemente riscontrabile
- l'auditing stesso avrà un pid differente al riavvio successivo.


 Al prossimo post ti faccio il disegnino.
Non servono dimostrazioni. Sono gi� certissimo che tu sia meglio come 
disegnatore che come sysadmin.


 fraudolentemente senza che i tuoi log, pardon, AUDIT, riportino nulla.
Ottimo!
Quando ci sarai riuscito segna un bug direttamente qui:
http://people.redhat.com/sgrubb/audit/
e qui:
https://bugs.launchpad.net/ubuntu/+filebug
mi credi se ti dico che l'audit � di per se inalterabile? Altrimenti, ma 
che cazzo l'hanno fatto a fare?
Gi� che ci sei, descrivimi passo passo come faresti ad alterare un file 
di audit senza lasciare traccia.
Te lo do io un suggerimento: l'unica cosa che puoi fare � prendere a 
martellate il device dove audisp scrive i suoi dati! Farai le operazioni 
losche che devi fare, e poi richiederai la sostituzione del disco.


 losche che devi fare, e poi richiederai la sostituzione del disco.
ecco trovata una back-door. Ma questo � un altro paio di maniche, e sono 
io il primo a dire che tale norma � di difficile applicazione.



workaround: al contrario di come si � fatto nella nostra azienda, 
l'audit deve scrivere sulla partizione di root.
Per evitare problemi con lo spazio disco, non appena viene superata una 
certa dimensione, si dice al file di configurazione dell'audit, di 
spezzare il file e di scrivere su uno nuovo (funziona cos� anche se 
molti non hanno idea di cosa sia l'auditing su Unix).
Il file pi� vecchio sar� quindi inviato sullo storage.


 losche che devi fare, e poi richiederai la sostituzione del disco.
Bravo... tu continua pure nelle tue convinzioni... io resto in attesa della 
scommessa.


 paga e come minimo ci sono le spese di viaggio, vitto e alloggio.
potremmo fare la scommessa in remoto.
Potrei installare un vserver. E' da capire come funziona il meccanismo 
dell'auditing su eventuali jail.
Se funziona come sulle zone solaris (se non ricordo male) ti inculerei 
in partenza senza troppo piacere, perch� audisp girerebbe al di fuori 
della jail e non potresti nemmeno toccarlo o nemmeno vederlo.
In caso si potesse installare all'inerno della jail, potrei installarlo 
sulla mia macchina e ti darei una pass.
Quindi funziona cos�, se si riesce ad organizzare la cosa:
io lancio "screen -x blabla" tu ti agganci al mio screen con lo stesso 
comando, e in questo modo vedo cosa stai facendo. O vuoi farlo a mia 
insaputa? Ma io devo vedere che � vero che tu lanci qualcosa che audisp 
non riesce ad intercettare.
Quindi non ci sono spese.
Se ci riesci, a me il compito di segnalare questa vulnerabilit� del 
sottosistema di audit
se non ci riesci .... uhm uhm .... dovresti cambiare la tua signature 
per due mesi e dovrai scriverci dentro:
Max_Adamo effettivamente ha sbattuto la testa per un anno sulla 
questione dell'auditing e qualcosa ha veramente imparato in questo 
periodo. Perch�, ho dovuto fare questa figuraccia con lui?


 potremmo fare la scommessa in remoto.
Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?


 Quale parte di "accesso fisico e amministrativo alla macchina" non hai capito?
E comunque con piffero che ti mostro quel che faccio; per imparare bisogna 
*pagare*. L'unica cosa che farei � darti una prova minimale che ho 
effettivamente acceduto alla macchina senza che il tuo audit abbia rilevato 
nulla di anormale.



Ti do root sul vserver. Chi se ne frega.... o adesso mi dici che sei in 
grado di scalare anche fuori dalla jail? sei proprio una hacker de paura.
con l'accesso fisico cosa ci vuoi fare? Mi vuoi prendere il disco a 
martellate? non c'� bisogno, ti ho detto io che quell'espediente funziona.
Vuoi giocare con il cavo di rete?
Descrivi qui passo pass quello che faresti e ti spiego perch� non 
funzionerebbe.
Inizio a essere sicuro che non hai chiaro il funzionamento dell'audit.



il mio kernel non supporta vserver.
Spiega ai presente le operazioni che faresti passo passo.


 accorgere.
Secondo me stai commettendo un errore in partenza nel pensare che un
sysadmin voglia in qualche modo "hackerare" un sistema funzionante,
quando molto più semplicemente - essendo sysadmin - può benissimo
configurare in partenza tutto il sistema di logging o auditing per
lasciarsi una "porta" aperta dove farsi i suoi porci comodi.
Al limite, se uno vuol farla proprio sporca ed ha buone capacità, può
prendersi i sorgenti di audit e farsi una versione "ad hoc", e allora
ciao.
A quel punto chiunque può ragionevolmente ritenere che la macchina sia
configurata nel rispetto della normativa, quando nei fatti il sysadmin
continua a fare il cazzo che vuole impunemente.
Insomma, stiamo parlando dell'*amministratore di quella macchina*,
diamine, mica di un utente qualsiasi.
In sostanza, la normativa è uno degli ennesimi esempi di UCAS (*) per
creare problemi inutili senza ottenere nei fatti ciò che si voleva,
perché alla fine quand'anche hai fatto tutto "a norma", ti ritrovi
sempre con un sistema che funziona sulla buona fede dell'amministratore,
e nient'altro.
Al che, se devi basarti sulla buona fede dell'amministratore, allora
vanno bene anche i normali log, senza complicazioni.
(*) Ufficio Complicazioni Affari Semplici


 Inizio a essere sicuro che non hai chiaro il funzionamento dell'audit.
Continua a zompettare e quando ti sei stufato e avvisa. Per il momento per� 
torna nell'ignore list; ogni tanto mi sforzo di pensare che tu possa aver 
imparato qualcosa e che non stia sempre a sparar cazzate e sparlare di quel 
che non conosci, ma tutte le volte � sempre la solita delusione...
In questo sei una certezza.


 vanno bene anche i normali log, senza complicazioni.
Appunto, e proprio per questo non vi è nemmeno alcun motivo per vietare 
all'amministratore l'accesso a quei log.



A-S-S-O-L-U-T-A-M-E-N-T-E  P-E-N-O-S-O.
Avevo chiesto una sola stupidissima cosa e non hai risposto:
riporta qui LE TRE OPERAZIONI IN CROCE che hai intenzione di fare quando 
ti trovi di fronte alla macchina con accesso amministrativo.
Io, o chiunque altro, avremmo detto: funziona / non funziona.


 Io, o chiunque altro, avremmo detto: funziona / non funziona.
Continua a rosicare... finch� non paghi da me non avrai nulla.
Altrimenti prova con Crononauta; magari lui � pi� buono di me, o si lascia 
commuovere dalla pena di vederti sbavare dietro alla soluzione, e te la cede 
per meno.
Sci�, Sci�.... f/u


 In sostanza, la normativa è uno degli ennesimi esempi di UCAS (*)
non dirmelo oltre, perché sono d'accordo.
E' possibile attenersi alla norma in aziende molto grandi, dove un cavo 
di rete che viene scollegato, allarma un intero front-end preposto a 
guardare le lucette del monitoring 24 ore al giorno.
E' quasi impossibile da attuare per le piccole aziende, dove il 
sistemista è - per forza di cose - un fac-totum che fa anche 
l'elettricista nella sala macchine. E non scherzo. Quando lavoravo per 
una azienda media a milano, mi occupavo dai quadretti per abilitare le 
linee telefoniche, al riordino dei cavi sui patch-panel, ai database e 
alle applicazioni :-)


 alle applicazioni :-)
Immagino sia fallita... o che si sia salvata dopo la tua dipartita.
Pussa via... f/u


 per meno.
La soluzione non la devi cedere a me, ma al popolo di Usenet, il
quale
ti legge e non sa più se aver paura o dover ridere di questo hacker
de
paura. .... e nun te 'ncazza!!
Crononauta non ha detto che riesce ad aggirare l'audit di una
macchina. Ciò che lui dice ha anche un senso, ma è una cosa un po'
parossistica (riscriversi il codice....)
Massimiliano


Ma si, ma certo. Ma chi è che non si riscrive un sottosistema di audit
tutti i giorni?
A tal proposito, sarei curioso di sapere quanto codice tu hai generato
in vita tua.
sbaglio o tu dovevi fare login su un sistema da me configurato, dove
io,  a questo punto mi memorizzo anche l'md5 dell'audit?
In base a quanto ho espresso fino ad ora:
a me basta sapere che c'è stato fermo volontario, una manomissione
sull'audit. Questo ti pone già nella situazione di "colpevole".
Tu puoi nascondermi quel che succede in mezzo. E questo l'ho detto
chiaramente (se rileggi bene): io ti traccio al successivo riavvio e
ti traccio anche perché crei un vuoto nella raccolta degli audit: gli
audit dei quali parlo io registrano il server che respira (ho rimosso
solo la syscall 'semop').
p.s.: mi pare che tu stia diventando un po' thorin di questi tempi,
che immagino sarà finito in qualche manicomio :-)


dove modificabile = non cancellabile, oltre che non alterabile ? Cosa
fai: stampi gli hash su carta non strappabile, ignifuga e resistente
persino ai cestini dell'immondizia?
che sei un po' una macchietta, te lo hanno mai detto?
Ho deciso di accettare la tua scommessa.
Le mie regole sono solo due:
1. memorizzo l'md5 di auditd e dei suoi file di configurazione.
2. è sufficiente che io tracci un riavvio forzato di auditd e avrai
perso.
spero che il punto 2 sia chiaro, ovvero, spero che tu abbia letto bene
il thread.
Per quanto riguarda le modalità di svolgimento della scommessa, ahimé,
qualche problema ce l'ho: ho una gamba rotta e tengo il gesso fino al
19.
Fammi sapere come si può fare.

 parossistica (riscriversi il codice....)
Veramente ti sto dicendo una cosa ancora diversa: riscrivere l'audit è
una possibilità, ma il punto base è che se tu sei l'amministratore della
macchina, sei quello che la installa e la configura. E di conseguenza
configura anche l'audit. Ci siamo? ;-)


 bella cena.
Ti offro quello che vuoi.
Se sei avvocato....
http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499
4.4 Verifica delle attivitï¿½3
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.
4.5 Registrazione degli accessi
Devono essere adottati sistemi idonei alla registrazione degli accessi 
logici (autenticazione informatica) ai sistemi di elaborazione e agli 
archivi elettronici da parte degli amministratori di sistema. 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.
Le registrazioni devono comprendere i riferimenti temporali e la 
descrizione dell'evento che le ha generate e devono essere conservate 
per un congruo periodo, non inferiore a sei mesi.
TU non le puoi gestire.
Poi fai quello che minchia ti pare....
Noto solo che tanti avvocati ,cosï¿½ bravi, sono davvero sprecati per il 
settore IT!!

 Bye.
Sarà pure quello che dici e potrei anche essere daccordo ma se ti
fanno un controllo e non sei in regola ti fanno il c....... e se sei
anche ADS te lo fanno due volte.

 settore IT!!
Fai una cosa "mister ho capito tutto"; posta quanto sopra su 
it.diritto.internet e poni la domanda fatidica a chi ha piï¿½ competenza di 
noi. La domanda, o meglio le domande, sono molto semplici:
ï¿½Puï¿½ un amministratore di sistema, ai sensi della normativa sugli accessi 
dell'AdS, amministrare il sistema che raccoglie centralmente i log? E puï¿½ 
essere egli stesso incaricato della masterizzazione delle informazioni su 
supporto non riscrivibile qualora si sia scelta questa strada? Puï¿½ un AdS 
essere anche titolare o responsabile del trattamento e quindi avere il 
compito di verificare il proprio operato?ï¿½
Prima magari puoi anche dare un'occhiata agli archivi (l'argomento ï¿½ stato 
trattato abbastanza approfonditamente), e magari dai un occhio anche a 
quelli di 
law.sikurezza.it
.


 19.
Si chiarisce il motivo per cui sei tornato a scrivere minchiate con tale 
frequenza. Auguri di prontissima guarigione.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 con l'accesso fisico cosa ci vuoi fare?
Uhm... senza saper nulla di cosa vuole fare Zip io inizierei staccando
il cavo di alimentazione.
Se poi la macchina la devo installare e configurare io non c'� alcuna
speranza che ti arrivino dati sensati.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png

 riportino, se ho deciso di fare qualche giochetto.
La soluzione ci sarebbe, con gli impatti del caso: MAC/RBAC.

 Zip, dillo chiaramente: su questa cosa non ci ho capito una cippa
ROTFL.
A me pare che sia *tu* a voler spacciare per verità rivelata la tua
*personalissima* interpretazione della norma.

 fantasie di azienda XX e azienda YY....
Le quali dicono ciò che dicono per *vendere*, t'e capì?

 1. l'assunto è che stiamo parlando di auditing
Il decreto sugli AdS _non prevede auditing globale_ ma le sole registazioni
di login e logout, period.

 sulla macchina, ha facoltà di alterare il logger a piacere.
Role Based Access Control.
Tanti auguri a chi ci si volesse cimentare in un ambiente di produzione. :-)

 TU non le puoi gestire.
Siccome mi sono confrontato con una ventina di uffici legali sulla
faccenda, potresti essere così gentile da dirmi con precisone qual
è esattamente, nella norma, il punto in cui si afferma quanto tu sostieni?

whiplash ha scritto:

Ok, e chi li installa sulla macchina dell'ADS X?
Insisto nel dire che puoi complicarmi la vita, ma finchè mi lasci il
sistema operativo in mano, se ne ho le capacità, mi riscrivo con una
back door qualunque sistema di controllo.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 back door qualunque sistema di controllo.
Corretto. L'unico modo per evitarlo è quello di non avere mai per policy 
(ovviamente con policy enforcement) l'accesso fisico alle macchine da parte 
di un singolo amministratore (e sperare che due non si accordino per 
fotterti). Una macchina è potenzialmente sicura solo se accedibile in modo 
controllato dalla rete. Se posso accedervi fisicamente non c'è nulla da fare 
per impedire l'accesso fraudolento e/o per verificare se è stato acceduto o 
manomesso qualcosa; al massimo ci si può accorgere della violazione della 
policy (che è ovviamente già sufficiente per intraprendere azioni correttive 
come il rifacimento della macchina dichiarata compromessa).
In ogni caso come è già stato detto sicurezza e usabilità sono inversamente 
proporzionali, quindi l'aumento della sicurezza comporta necessariamente una 
complicazione della gestione che non è giustificabile nel 99.999% dei casi.
Giusto per raffronto l'accesso fisico alla macchina che ospita il 
root-certificate di Verisign è protetto da numerosi livelli di accesso 
fisico e comunque è impossibile se non ci sono contemporaneamente (mi par di 
ricordare) 3 amministratori autorizzati a sbloccare il sistema. Se fosse 
tanto semplice imporre il rispetto delle politiche senza limitare l'accesso 
fisico al nodo centrale non avrebbero adottato tante precauzioni.



mmh ... no... nel senso che non riporto mie interprestazioni della 
norma, ma riporto i dettagli di DUE esperienze sul campo.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo


il concetto è che la legge non parla di strumenti, ma stabilisce solo 
obiettivi.
In base agli obiettivi, e in base al sistema in oggetto, tu ti scegli i 
tuoi strumenti.



per carità, non lo metto in dubbio.
mi si dica però come proteggere un dato da cancellazione, se non 
attraverso storage speciali, il cui controllo NON è affidato a te.


 norma, ma riporto i dettagli di DUE esperienze sul campo.
WOW!!!! ben DUE esperienze...
AHAHAHAHAHAAHAHAHAAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHHAHA
f/u


 parte di un singolo amministratore (e sperare che due non si accordino 
Oh, conosco centinaia di ditte, qui in zona, in cui UN ADS è già
considerato di troppo.
E continua a sfuggirti un particolare: i miei server, me li deve
venire a installare il garante in persona? O dobbiamo fare tutti
parte del plotone di sysadmin "di leva" che a turno dovranno, in
squadre randomizzate (per evitare collusioni) girare l'italia ad
installare gli altrui server?


 installare gli altrui server?
Mi viene in mente il pezzo del film Hancock in cui lui dice "infilo la tua 
testa nel suo culo e la sua testa nel culo dell'altro" :-D


 f/u
e finiscila...


 e finiscila...
e rispetta i f/u. Sono messi per un valido motivo.



E perché? Oltre a essere l'amministratore dei tuoi log, sei pure 
l'amministratore di Usenet?



e allora questa legge nelle piccole aziende è di quasi impossibile 
aplpicazione.
Tranne che, non si inventano uno storage per il collezionamento, che 
funziona un po' come il contatore della luce, con tanto di laccetto e di 
sigillo di piombo.


 Tranne che, non si inventano uno storage per il collezionamento,
Ho una fantastica idea per il posizionamento dello storage...



Facebook: Massimo Bacilieri

 il naso a voler normare questioni squisitamente tecniche. :-/
Stessa lunghezza d'onda (ergo: quoto)



ma verso la latitudine di Trento però.
p.s.: noto che la sera diventi più cattivo :-)



Ma neanche se ne parla:
come si fa nell'Informatica - quella con la I maiuscola - integrator, 
deployer e tester, nel caso raro in cui si dovessero conoscere tra loro, 
si darebbero comunque del lei :-)
L'esimio signor Adamo condurrebbe quindi le operazioni di deploy, test e 
hardening.
Il signor Visentin condurrebbe invece le operazioni di acceptance test.
l'ho detto: checksum md5 dei binari di auditing e dei rispettivi file di 
configurazione e non devo notare riavvii forzati che sarebbero indice di 
colpevolezza.



secondo me, come dice il mio amico palermitano, si attacca bellamente al 
cazzo :-)


 indice di colpevolezza.
"� mancata la corrente"
"il tizio delle pulizie ha tirato il cavo"
"le inondazioni, le cavallette"
O, pi� semplicemente, prima o poi andr� riavviata 'sta macchina?
Se poi ho fretta posso sempre mettere qualcosa tra questa
macchina e la tua.
Stai sempre ragionando come se l'unico sistema informatico esistente
fosse quello che regola gli accessi di fort knox.
