Re: Are users right in rejecting security advice?

["Mclaughlin, Kevin (mclaugkl)" <mclaugkl () UCMAIL UC EDU>]

Amen.


----- Original Message -----
From: The EDUCAUSE Security Constituent Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU>
To: SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>
Sent: Wed Mar 17 10:56:11 2010
Subject: Re: [SECURITY] Are users right in rejecting security advice?

Regarding passwords, Russell Fulton <r.fulton () AUCKLAND AC NZ> mentioned:

#The general consensus seems to be that there is value in getting users 
#to change their passwords at, say, yearly intervals but as you increase 
#the frequency the cost to the user escalates and eventually they will 
#start writing the passwords down and sticking them to the screen and 
#even before that happens the cost in terms of frustration is significant 
#and may well outweigh any real security benefits.

In my experience, the problem isn't the *frequency* of the changes that's 
the problem, rather it is the:

-- complexity requirements (normally phrased as, "I can't come up with
   a password that isn't rejected as in some dang obscure dictionary
   you're using -- heck, you even know about FOREIGN words!!!")

-- password non-reuse/history requirements (normally phrased as, "I don't
   mind chaning my password every six months, but I really hate the fact
   that I can't reuse a favorite password that I haven't used for a year
   or more!")

-- saved password-related issues (e.g., "In order to change my password
   to something new, I need to know my old password, but because I told
   my email client to save my password the *last* time I set it, I don't
   remember what it is -- the computer just automatically puts it in
   for me. Can you reset it for me so I can change it? Oh yeah, and how
   do I resave that new password in my email client again?")

As far as I can tell, THOSE are the real issues that people have with
mandatory password changes.

BTW, if folks are interested, I've got a "Passwords" talk that I did for
the Northwest Academic Computing Consortium Security meeting in late 2009;
it's available at http://www.uoregon.edu/~joe/passwords/passwords.pdf 
(or .ppt)

#Part of my daily mantra is that "Security must work for the end user".

My favorite aphorism is "Security is a life style choice."

As far as I can tell, there's virtually no way to improve security in
a material way without introducing at least *some* incremental level of 
inconvenience. You can get users to accept that unavoidable 
incremental inconvenience in a variety of different ways:

-- you can inform and persuade them (awareness, training and educational 
   campaigns)

-- you can compell them (policy enforcement by technical or managerial
   means)

-- you can pass along consequences for failure ("because your department
   elected to continue to use SSNs, and suffered a PII breach, the cost
   of notification and credit protection for those affected by that breach
   will come from your budget")

-- you can reward them for their cooperation (carrot rather than stick)

and there are other strategies, but you get the idea.

Regarding two factor authentication...

#So why don't we all do this?  Because 2fa is an identifiable and
#quantifiable cost that some part of the organisation has to pay whereas
#getting users to change their passwords does not come out of anyones
#budget.

In some cases the cost is only ~$5 (see the password talk I mentioned
previously), yet people still don't do hardware crypto fobs. Why? I 
would suggest mundane reasons are part of the problem, including:

-- some applications or operating systems may not support them

-- it's perceived as "too hard" (yes, I know that's a baseless concern)

-- you can't hard code and forget one time passwords in things like email
   applications, so if you're used to POP'ing your email every five 
   minutes, that's probably going to change :-;

-- if you're a bigshot with support staff, it is hard for them to "login
   as you" to screen your email (or whatever) if you have only a single 
   hardware token that can be used to access your account

-- if you forget your fob at home, it can be a big PITA (you either
   need to go home and get it, or arrange for a temporary fob, or live
   without being able to authenticate that day)

#I now cringe when I hear the phrase "Best Practice" when applied to
#security -- I have come to believe that this means that the speaker
#can't be bothered (or lacks the expertise) to do any analysis and is
#simply trotting out some thing 'safe'.  

I think there's value to seeing how other sites (or the community as a
whole) are doing things, if only because you get to learn from others
mistakes (if they'll admit to them and accurately describe them!) rather 
than continually having to reinvent the wheel from scratch.

That said, should you slavishly adopt what site A is doing simply because
they're doing it and have taken the time to document what they did? No,
and I don't often see that sort of unthinking copycat mentality in higher
education.

In fact, part of the issue may be that we really don't have well codified
security norms, or "community expectations for security" if you will. 

As a result, on April 27th at the Internet2 Member Meeting, I'm going to 
be doing a session on "Community Expecations for Campus Computer and 
Network Security." The abstract for that session is,

   "Some years ago, the Internet2 community developed and 
   articulated shared community expectations for baseline networking 
   capabilities -- that is, if you were a member of Internet2, your 
   users, and the Internet2 community at large, should be able to 
   assume that your network met certain basic network standards, 
   which were then articulated. Given those expectations, sites 
   could then review their current status to see if they were 
   meeting those expectations, or if there was work that needed to 
   be undertaken to "come up to spec." Discussions in the Internet2 
   Salsa security group, with input from the AMSAC Council, have 
   raised the question of whether we should have similar minimum 
   Internet2 community expectations for campus computer and network 
   security, and if so, what those simple-to-articulate and 
   generally agreed-upon expectations should be. Please join us for 
   a presentation and discussion of this important and timely topic."

If you're going to be in Crystal City at the Internet2 Member 
Meeting, I'd love to have folks stop by and share their thoughts on
that topic as part of that session.

#I would feel much more comfortable if they described it as "acceptable" 
#or "standard" practice.

Educause uses the term "Effective Practices" if that works better for you:
"Information Security Guide: Effective Practices and Solutions for Higher 
Education," https://wiki.internet2.edu/confluence/display/itsg2/Home
(or http://tinyurl.com/security-ep )

#That then suggests that it may be worth looking further.  But if you
#are implementing "best practice" then this implicitly precludes doing
#anything else. 

I always view "best practices" as a foundation rather than as a complete
set of cast-in-stone unalterable blueprints... especially in security, 
there's seldom a one-size-fits-all solution.

#In higher ed we are faced with a somewhat different
#threat scenario to that of most businesses and we also operate under
#constraints of scale, openness and budget that most business (or
#auditors) have no concept of.  What is sane and sensible in our
#environment may be either hideously lax or over kill for a business and
#vice versa.

That's the beauty of higher ed. :-) Personally, I think we have perhaps 
the best of all environments for practicing cybersecurity. We usually
have a relatively compact, well educated and intelligent user base;
supportive management; good network infrastructure; good colleagues, etc.
Certainly nothing's perfect, but compared to some government, corporate 
or ISP cyber security environments, higher ed's a pretty sweet cyber
security billet, I think. :-)

Regards,

Joe

----
Joe St Sauver (joe () oregon uoregon edu or joe () internet2 edu)
http://www.uoregon.edu/~joe/
Disclaimer: all opinions strictly my own