Educause Security Discussion mailing list archives

Re: Are users right in rejecting security advice?


From: Michael Sinatra <michael () RANCID BERKELEY EDU>
Date: Wed, 17 Mar 2010 14:47:32 -0700

On 3/17/10 2:11 PM, Eric Case wrote:
-----Original Message-----
From: Michael Sinatra [mailto:michael () rancid berkeley edu]
Sent: Wednesday, March 17, 2010 1:57 PM
To: The EDUCAUSE Security Constituent Group Listserv
Cc: Eric Case
Subject: Re: [SECURITY] Are users right in rejecting security advice?

On 3/17/10 11:51 AM, Eric Case wrote:
Is it then ok if the user accepts more risk than the institution is
willing
to accept?

Your question doesn't actually relate to my quote above, which referred
to the risks that the institution recognizes to itself.  Your question
IS relevant to my second paragraph (not quoted by you) where I discuss
"monetizing" user-generated externalities and trying to capture them in
the market.  Here is the answer:

If the externality is captured, yes.  That's the whole point.  Extra
risk can be managed if the institution understands the economic
incentives and can properly modify them.

Here's an example: The central IT organization provides database
services for campus users.

Unless the users take on the extra risk of running their own db, with or
maybe without patches, a blank SA password, etc.  This is what I'm talking
about.  The users accepting more risk than the institution is willing to
accept?  You know.  "It's my grant and my grad student will take care of the
server."

Exactly the type of work-around that I am talking about, and one that
can be captured in a similar manner as my example.  There are many
examples as to how incentives can be modified without a whole body of
"thou shalt not"-style policy (which could be subject to even more
work-arounds as Steven Alexander points out).  To be honest, I am not
sure what point you're trying to get at, as you seem to be supporting
the general theme of the article.  I'd be happy to discuss this further
off-list if necessary.

michael

Current thread: