Re: stopping students sharing their login credentials

[Christopher Jones <Christopher.Jones () UFV CA>]

Great point and analogy, Jim.  Security policies are meant to express the will and intent of an organization's security 
posture.  Just because a policy may be difficult to enforce does not negate that will and intent.
 
Christopher Jones
IT Security Administrator
University of the Fraser Valley
Christopher.Jones () ufv ca 


> > > "James M. Dutcher - Assoc. VP IS/IT & CIO"             <james.dutcher () SUNYORANGE EDU> 01/23/2009 7:52 AM >>>
Randy, et al,

I would like to offer a counter point.  I believe that there has to be a policy in place. Otherwise, anyone can contest 
that "they did not know" or " you did not say that I could not do it".  Having a policy protects the organization.

Yes you are correct that it is difficult if not impossible to police/enforce, especially in real time.  However, when 
there are digressions encountered/discovered, then the appropriate actions take place and the diggressors are then the 
examples (and precedents) as to what happens when policies are broken.

Take for example highway "speed limits".  There is not enough police/surveillance in place to ensure that everyone 
complies with it.  But there is some in place to catch folks so as to (hopefully) keep the rest of the drivers in 
compliance.

Regards,

Jim

James M. Dutcher - PMP, CISSP, SCP/Security+, CISA
SUNY Orange - Associate Vice President of Info. Tech. Services & CIO
845-341-4651 (office)
845-742-8954 (college cell)
607-760-7455 (personal cell)
james.dutcher () sunyorange edu 
jim () dutcher net 
Yahoo IM: jmdutche
Google Talk: jmdutche



On Fri, Jan 23, 2009 at 10:32 AM, randy marchany <marchany () vt edu> wrote:


One should never put in a policy/standard any item that can not be
enforced. While the spirit of the statement "you must not share your
userid, login credentials with anyone" is certainly clear, the reality
is that this cannot be enforced without additional monitoring such as
2 factor authentication, video feeds or witnesses. The most common
"abuse" of this would be a simple login and computer logs cannot show
that a userid was shared or WHO the person was that actually logged
into the system. Biometrics isn't foolproof since I could login with
my biometrics and let you use my userid. Card swipe access isn't
foolproof since people form trains to enter a facility. Shoot, I
remember visiting a campus, going to a pizza place right across the
street and seeing the building access code written on a piece of paper
on the bulletin board next to the cash register. Apparently, that
pizza place delivered a lot of pizzas to labs in the building :-). So
the "must not share" clause is basically unenforceable and weakens
your policy/standard. Another way to express the intent of the clause
is needed.

Why do people share these things? Could be something as simple as the
site doesn't have a mechanism for guest access. An example of this is
guest wireless access on campus. You have a guest speaker who needs
wireless access, your campus has no mechanism to provide guest access
so you, the sponsor, lets the speaker use your credentials to get
access. Email access, door access are other examples. An email system
doesn't allow sharing of email folders, a dept. head is on travel and
the assistant needs access to those emails. The only alternative is to
share the email password.

So, how do we fix this? The best solution I found was to state "you
are responsible for whatever activities originate from your userid,
computer, id card..." (feel free to include whatever
authentication/authorization mechanism you have). This is easily
enforceable. Computer and access control logs note the "userid/token"
that was used to gain entry. SInce you can identify the owner, that
person is responsible for its use.

I do believe having the "responsible for its use" strategy is more effective.

In Russell's case, the access logs contain the name of the card owner.
You contact the card owner and ask them the necessary questions :-).


Just my .02.

Randy Marchany
VA Tech IT Security Office and Lab





On Thu, Jan 22, 2009 at 9:25 PM, Russell Fulton <r.fulton () auckland ac nz> wrote:
> Background:
>
> Earlier this week we had an incident where the building security officer
> noticed a group of unfamiliar people using machines in one of our labs.  She
> asked them for their ID cards and none could (would?) produce one.  On
> questioning they said they were students from a neighbouring institution and
> that they were using "borrowed" credential.
>
> We have cctv footage and swipe card logs from the door (which may show they
> tail gated someone in).   We are now tracking down which machines were being
> used so we can disable the accounts.
>
> To the point.
>
> We (the security techies) have been asked what measures we can deploy to
> prevent this sort of thing happening in future.
>
> We already do lots of education, posters, page on the back of the student
> handbook. Students have no excuse for not knowing that they should not share
> passwords.
>
> On the social/education side we could make an example of anyone we finger
> for this (assuming we can make charges stick) in the hope that this will
> persuade other students not to share their passwords.
>
> Technical solutions seem to revolve around some form of two factor
> authentication.  I.e. something the student has but which they will be
> reluctant to part with for any length of time.  Like their ID card.
>
> Our ID cards have bar codes and classic mag stripe.   Some labs (like this
> one) also have proximity card locks.  Generally only post grad students or
> students in special coursed (like medicine) have proximity cards.
>
> Anyway I would very much like to know what other are doing in this space.
>
> Cheers, Russell