Usable
Security – Really?
| |
"Security adds hassle and blocks
progress."
"Tight security usually leads first to
paralysis and then to weak security,
which no one complains about until there
is a crisis."
- Butler Lampson |
It has
become something of a cliché to say that there is a
trade-off between security and usability of any user
software. We have all experienced identity fatigue
where each site we visit has incompatible
restrictions on the user name and password that can
be used to access the site. Psychologists have known
that it is fairly easy for most of use to keep one
or two username and password combinations straight,
but as soon as users need more; forget it. There is
almost no chance that users can keep all of their
identity needs straight, let alone stick to
stringent security policies while still completing
the task that sent us to the internet in the first
place. Many solutions have been proposed: smart
cards, biometrics and single sign-on programs. None
has provided more than isolated improvements. But we
have found a method that helps make the best of a
bad situation, so read on.
Both of
the papers referenced below point out that “security
is about economics”. It is a balance between the
expected benefit of loss prevention versus the real
cost, not only of deploying and maintaining hardware
and software that blocks attacks that seek to create
those losses, but also the time spent by users
remembering or recovering passwords, or finding a
workaround that allows them to do their jobs. Most
security is too difficult for users who have little
incentive to cooperate with a hassle that blocks
their ability to get their work done. This is
completely rational behavior by users who perceive
the cost of security to be too high given the time
that it takes away from productive work. By the same
token, trying to “educate” users on good security
practices in face of the clear and present cost to
them of complying with security directives is not
time well spent.
JW
Secure creates security solutions where the
question, “Is this Usable Security?” can be answered
– “Yes, really!” That answer is supported by metrics
generated both during normal operations and by user
feedback. These are metrics that not only prove the
efficacy of deployed product, but also help
continuous improvement.
Metrics
that can be generated automatically for comparison
between new and experienced users to determine how
clear each task and decision point is include:
|
1. |
Time to complete specific tasks, |
|
2. |
Time at each decision page, |
|
3. |
Fall off at each decision page and for
the entire task. |
|
4. |
For longer term operations, whether the
user needs to stop a task and return
later. |
These
data should be a part of the normal data collection
along with server statistics.
The
following notes apply to metrics that can be
generated by user input either during the operation
of the task or later using feedback from a variety
of channels:
|
1. |
The best feedback comes from the user at
the time that they frustrated. |
|
2. |
Always allow the user send feedback on a
task as it completes. |
|
3. |
Radio button feedback takes the least
user effort and so will have the best
volume. |
|
4. |
Text boxes where users can tell you
their problem will be the most helpful. |
|
5. |
The most expensive feedback is from
focus groups or user interviews. |
The
real point is to marry the determination of whether
the security is usable with “design for test”
principals. That way, the design of the schema and
data collection will include the information needed
to get real usability metrics from the operation of
the delivered code. This should happen both during
beta testing and in the field. The results drive
improvements to subsequent versions of the product.
Interesting reports on usable security:
|
Welcome
to the tenth edition of the JW Secure Informer, our
bi-monthly newsletter. This is an opportunity to
share what’s on our radar, specifically with respect
to enterprise network security, but also regarding
IT and business more generally.
