OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Features versus Security versus User Education
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Features versus Security versus User Education

  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: Re: Features versus Security versus User Education
  • From: David LeBlanc <dleblancMINDSPRING.COM>
  • Date: Mon, 29 Mar 1999 20:09:07 -0800
  • Approved-By: Russ.CooperRC.ON.CA
  • Comments: To: Russ <Russ.CooperRC.ON.CA>
  • In-Reply-To: <61143C10CC8AD211A2F10000F878E683066CE7ns.rc.on.ca>
  • Reply-To: David LeBlanc <dleblancMINDSPRING.COM>
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
At 10:08 PM 3/29/99 -0500, Russ wrote:

>Some would like to think that the solution is in user education. My
>Security-related web-portal idea was, in part, based on the premise that
>users need a place to get answers. Answers at varying levels of
>sophistication to allow them to learn more.
>
>Fact is, the computer is a tool, and if I need to become an expert with
>every aspect of a tool in order to do my job, the tool is broken. A
>carpenter's job is to build a house with hammer and saw. Most aren't
>likely going to be able to tell you the torsional tolerance of their
>hammer or the expected number of sawcuts their saw still has in it. When
>it breaks they'll throw it away and get another, the tool was flawed,
>not how they used it.

As usual, I agree with some of this but not with all of it.  Users may not
need to understand the arcane details, but some education is certainly in
order.  For example, if you tell someone to not go down on Main Street
after dark or they will get mugged, then odds are that they will not go
there, or will take some precautions.  People display a fair bit of sense
about their personal security, and will often go to the extent of mastering
relatively complicated alarm systems, etc.

However, these same people will sometimes hit "Ok" on a dialog which reads
"This document contains a macro that could send all your information to
your competitor, format your hard drive, and possibly end all sentient life
on the planet".

This difference in behavior is what tells me that education is in order.
No matter what else we do to solve the problem, if we do not make user
education a component of it, we will fail.  People DO take measures to
protect themselves when they understand the threat and the consequences.

That said, another component is making the computer easier for the user and
the administrator.  Using macros as an example, it would be nice if I could
get the warning to tell me something about what the macro does before I
decide to run it or not.  To use your example of a hammer, we shouldn't
expect the hammer to contain a lengthy warning about not smashing your
thumb, nor should we expect the hammer to contain a $1000 thumb-detection
system to prevent you from smashing it.  We reasonably expect people to
understand that if they hit themselves with a hammer that they will get
hurt.  Similarly, we cannot make the software foolproof - as my friend Mike
Warfield likes to say - "If you try to make something foolproof, the
universe will invent a bigger fool".

We're seeing this in many different facets of applications - for example,
in the early days of the ISS Scanner, we assumed that the user was a fairly
astute administrator and we gave fairly terse fix info.  At the time, it
was true.  As more people started to use the app, that assumption no longer
held, and we needed to make the fix information much more user-friendly.

Applications are simply going to have to become more sophisticated about
telling the user what is going on in terms that they can understand.  With
macros, we really have 3 options - disable them entirely (which is not at
all practical at many sites), enable them all the time (not very secure),
or expect the user to judge which are good and which are bad.  At the
moment, people are told to ignore the warning often enough that they do it
when they shouldn't.

No single facet of this problem can be the only solution.  We cannot simply
eliminate features - won't happen.  We cannot just assume that end-users
are completely without a clue and will stay that way - the number of ways
that a person can screw things up is virtually infinite, so we must educate
them.  What we can do is try to think about security when we add features,
and we have to find ways to educate people about what their risks are and
how to protect themselves.


David LeBlanc
dleblancmindspring.com