Re: [ml] Leggete e meditate...

Riprendo dai vari commenti, e mescolo :p

> infatti nei sistemi mission critical ormai si usano soluzioni di 
> autenticazioni forti e senza ripudio.

E' una speranza, vero ? :)

No, perche' io ho in mente un po' di controesempi...

> una password ben creata accompagnata da un comportamento responsabile
>  è sufficientemente robusta secondo la mia modesta esperienza; 
> cambiarla ciclicamente mi pare esponga in maniera evidente a una 
> serie di rischi...

Mi pare esattamente il trade-off di cui parla Spafford e che nella
discussione in lista si e' saltato a pie' pari...

> Si, lo so, l'educazione degli utenti e' fondamentale, ma devo ancora
> vedere la prima educazione alla sicurezza "di massa" di tutta una
> organizzazione che non venga percepita come una cosa tra il superfluo
> e l'eccessivamente paranoico.

Rispondo citando Ranum:

"Educating Users

"Penetrate and Patch" can be applied to human beings, as well as
software, in the form of user education. On the surface of things, the
idea of "Educating Users" seems less than dumb: education is always
good. On the other hand, like "Penetrate and Patch" if it was going to
work, it would have worked by now. There have been numerous interesting
studies that indicate that a significant percentage of users will trade
their password for a candy bar, and the Anna Kournikova worm showed us
that nearly 1/2 of humanity will click on anything purporting to contain
nude pictures of semi-famous females. If "Educating Users" is the
strategy you plan to embark upon, you should expect to have to "patch"
your users every week. That's dumb.

The real question to ask is not "can we educate our users to be better
at security?" it is "why do we need to educate our users at all?" In a
sense, this is another special case of "Default Permit" - why are users
getting executable attachments at all? Why are users expecting to get
E-mails from banks where they don't have accounts? Most of the problems
that are addressable through user education are self-correcting over
time. As a younger generation of workers moves into the workforce, they
will come pre-installed with a healthy skepticism about phishing and
social engineering.

Dealing with things like attachments and phishing is another case of
"Default Permit" - our favorite dumb idea. After all, if you're letting
all of your users get attachments in their E-mail you're "Default
Permit"ing anything that gets sent to them. A better idea might be to
simply quarantine all attachments as they come into the enterprise,
delete all the executables outright, and store the few file types you
decide are acceptable on a staging server where users can log in with an
SSL-enabled browser (requiring a password will quash a lot of worm
propagation mechanisms right away) and pull them down. There are
freeware tools like MIMEDefang that can be easily harnessed to strip
attachments from incoming E-mails, write them to a per-user directory,
and replace the attachment in the E-mail message with a URL to the
stripped attachment. Why educate your users how to cope with a problem
if you can just drive a stake through the problem's heart?

When I was CEO of a small computer security start-up we didn't have a
Windows system administrator. All of the employees who wanted to run
Windows had to know how to install it and manage it themselves, or they
didn't get hired in the first place. My prediction is that in 10 years
users that need education will be out of the high-tech workforce
entirely, or will be self-training at home in order to stay competitive
in the job market. My guess is that this will extend to knowing not to
open weird attachments from strangers.

> cambia un granche`...ma se pensi la questione in termini di "ok un qualche
> attacker ha ottenuto la password, limitiamo il tempo e la quantita' di
> informazioni alle quali puo' accedere con la password 

Mi stai dicendo che supponi che ci si metta piu' di n mesi ad
individuare un intruso ? :) Il problema allora e' un po' piu' serio che
cambiare le password (cito da te stesso piu' in basso :-)

> Inference/Guessing - non si genera e consegna (e quindi non e` decisa
> dall'utente, come ipotizza in "Inference") una password "forte" 

Le password eterogenerate hanno pro e contro, eh...

-- 
Cordiali saluti,
Ing. Stefano Zanero
---------------------------
CTO & Co-founder
Secure Network S.r.l.
www.securenetwork.it