2012/9/24 Marco Gaiarin:
[...]
>> È necessario? Questo ovviamente dipende dal tuo threat model (scommetto
>> di no).
>
> Dati sanitari, io preferirei di si. ;-)

Uhm, io direi ancora di no. Perché mai affidarsi alla criptazione del
layer 2 - che se esiste, è comunque affidata a una password o una
chiave installata nei router in gestione del tuo ISP - piuttosto che
non usare la criptazione del protocollo (e.g. HTTPS/SSL?).

Ti ricordo che due criptazioni non rendono più sicuro il trasporto,
anzi, qualcuno con skill cripto/matematici migliori dei miei potrebbe
magari persino dimostrarti il contrario, in certi casi...


> Ad ogni modo grazie a tutti delle informazioni che mi avete fornito,
> assolutamente sovrabbondanti alla richiesta iniziale, che in buona sostanza
> era quella di farsi un ''thread model''. ;-)

Se c'è una cosa che ho imparato nella sicurezza in questi ultimi anni,
è di avere un approccio "olistico" e non pensare che le singole misure
di per sé - criptare il trasporto, fare l'hardening del server, ecc. -
risolvano tutti i problemi. In alcuni contesti, conviene concentrarsi
su certi aspetti, in altri su altri. Non mi romperei la testa in
questo caso sul come criptare una rete MPLS, mi concentrerei piuttosto
sul SLA che l'ISP è disposto a concederti, e cripterei a livello
applicativo.


> Tra l'altro, i vendor, pungolati sulla questione, confermano che sta al
> cliente valutare l'eventuale livello di sicurezza ulteriore, solitamente
> agendo a livello applicativo (SSL/TLS sul protocollo) oppure di tunnel
> (ovvero facendoci una VPN sopra).

In questo caso sono d'accordo.


> Nel secondo caso, inoltre, ti ricordano gentilmente che poi non c'è da
> sperare che il (loro) QoS funzioni. ;)

Questa non l'ho capita, invece.


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

Rispondere a