Re: The home user problem returns

[Mason Schmitt <mason () schmitt ca>]

> On the one hand, I agree with Tina -- people change their OWN
> behavior based on their OWN pain. On the other hand, this insight
> leads people to some terrible attempts at training, because people
> (dogs, cats, octopus, anything with a brain of reasonable size)
> do not respond effectively to imposed pain. Positive training
> methods always work better on long-term measures.

I'm in full agreement there.  IMHO, the most common attempts at
"education", by the security community, involve scaring people, telling
them what not to do, telling people they are bad for what they have done
or beating them about the head with a clue-by-four and calling them
stupid.  These are all negative approaches to the problem that, as you
say, are not likely to gain long term traction.  In my experience,
people will attempt to shut out messages that make them feel guilty or
stupid.  People want to feel good and unencumbered.

> Why is this relevant in security? Because the principal problem
> is NOT that people don't feel pain when they screw it up -- it's
> that there's absolutely no reward for doing it right (in fact,
> it often causes pain itself).

Very good point.  In fact, the security community makes this very clear
when they say that security is inversely proportional to ease of use...
 I still think that statement is symptom of the current state of
computing rather than an immutable security truism.  There are ways of
improving security for the end user without an equivalent decrease in
ease of use.  One reasonable example is Apple's use of sudo.  The user
does not run as a full root user, but when they need to elevate
privileges for installing software, they are prompted for their
password.  This is obviously not a great solution, but it is quick and
easy for the vendor and does mean that the user is not running as root.

There are pieces of low hanging fruit that can be had by vendors.
However, to really make progress, vendors are going to have to start
taking security much more seriously.  Which brings me back to your
point.  If users are experiencing pain and they complain to their
vendors, then the vendors will experience pain, if the vendors
experience pain that has the potential to decrease their bottom line,
then they now have Tina's carrot in front of them.  The vendor now has
an incentive for providing easy to use security which in turn improves
the situation for the user.  There are obvious pitfalls to this
scenario, but it is an ecosystem in which the bar can be raised.  So, as
crappy as all of the "hacking is cool" and "enumerating badness" may be,
it may also serve to get vendors moving in the right direction.

The above examples and arguments are narrow in scope in somewhat flawed.
 I recognize that just picking on vendors will not solve the problem and
really picking on vendors is just more of same negative approach that
we're trying to avoid, but the above scenario does at least place one
carrot in the mix.  We should be striving to create environments that
are more amenable to change by introducing more carrots into the mix.

> If more secure solutions were
> faster, nicer, more fun OR cheaper in practical terms, we
> wouldn't have the problems we do.

Yup.

> Asking people to choose
> long-term lack of pain over immediate reward is like asking
> water to flow uphill. It can be done, but it's an awful
> lot of work...

This is also a symptom of a selfish, instant gratification, consumer
society, but that's another issue altogether that we're not going to
solve by looking at the limited scope of computer security.  For those
working on that problem, the benefits of incremental successes will
transfer to all aspects of human society.

> As long as you're working on increasing the pain for bad
> security and making it happen faster, you're still
> working on doing things the hard, ineffective way. If
> you can get a reward for good security, then you're
> working with the flow.

If we do both, then the gains should progress faster than the sum of
their parts.  We do need to look at changing our perspectives though.  I
don't have a road map for that change, but it really comes down to
choices in the moment - do I wield the clue-by-four or do I take a more
patient approach, do I force people to see the security measures I am
implementing  because I think they should be more aware or do I try to
find ways of making security happen transparently so that the users I
service can continue with their work without having to get bogged down
in technical details.  Each time we are faced with a decision regarding
security, we need to look at working carrots in.

This is a potentially difficult change in mindset, because security
folks tend to be very "default deny" in their thinking - centralize
control, mistrust, restrict access, block this block that, etc. (I'm
really guilty of this).  The same thing can be expressed by saying -
increase manageability, auditability, and accountability; trust those
you have reason to trust; permit known good; allow access to what is
needed; etc.  I'm not saying that the industry doesn't have its moments
where it thinks this way, but as Marcus points out the industry spends
most of it's time enumerating badness and selling based upon the fear
that enumerating badness brings.

I'd like to sum up by pointing out that while some of what I say appears
to be contradictory, I do think all the forces at work, negative and
positive, are creating an environment for change.  Pain due to negative
behaviours pushes people to change, and positive messages and carrots
encourage people to change.  We clearly need more of the latter.
Finally, when people have endured enough pain, they need to have
something to move to.  We need to have solutions ready for people that
are still easy to use, but are more secure and reasonably trustworthy.
These solutions should include training in positive behaviours and
technical solutions that are as transparent and easy to use as possible.

--
Mason
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards