Educause Security Discussion mailing list archives
Re: stopping students sharing their login credentials
From: "Basgen, Brian" <bbasgen () PIMA EDU>
Date: Fri, 23 Jan 2009 09:55:40 -0700
Policy is often defined in different ways, but I think it should be a fairly abstract statement of intent. The essence of policy is that by expressing the will of the organization all constituents can make informed decisions. Policies require mechanisms for implementation to be effective, which include regulations, standards, procedures, guidelines, etc. I think "enforcement" can be misleading criteria for policy in the sense that this is often paired with regulatory requirements, for example, and are often thought to run counter to the purpose of guidelines. Also, I think it is useful to see policy as a constructive antecedent to various implementation means, as opposed to the concept of "enforcement" which implies a negative utility. ~~~~~~~~~~~~~~~~~~ Brian Basgen Information Security Pima Community College
-----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy marchany Sent: Friday, January 23, 2009 9:06 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] stopping students sharing their login credentials Don't get me wrong. There needs to be some sort of "control" in a policy or standard. The control has to be enforceable,however. If not, people will ignore the policy. The "personal responsibility" item provides that control. Your speed limit example is good but given the information available in computer logs, the speeding violation would be "Randy's car was speeding but we don't know who the driver was" so we can't give a ticket out because we can't identify the individual who was actually driving. Remember, computer login logs (your only evidence of account login) only show the userid and not the person. At least, with the responsibility clause, it'd be "Randy's car was speeding and Randy is responsible for its use and therefore accountable". Car insurance companies follow this strategy to some degree. The computer logs would show Randy's userid was used and the policy states that Randy is responsible for its use. You have an actual person to "interview". -r. On Fri, Jan 23, 2009 at 10:52 AM, James M. Dutcher - Assoc. VP IS/IT & CIO <james.dutcher () sunyorange edu> wrote:Randy, et al, I would like to offer a counter point. I believe that there has tobe apolicy in place. Otherwise, anyone can contest that "they did notknow" or "you did not say that I could not do it". Having a policy protectstheorganization. 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 takeplaceand 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 withit. Butthere is some in place to catch folks so as to (hopefully) keep therest ofthe 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, therealityis that this cannot be enforced without additional monitoring suchas2 factor authentication, video feeds or witnesses. The most common "abuse" of this would be a simple login and computer logs cannotshowthat 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 ofpaperon the bulletin board next to the cash register. Apparently, that pizza place delivered a lot of pizzas to labs in the building :-).Sothe "must not share" clause is basically unenforceable and weakens your policy/standard. Another way to express the intent of theclauseis needed. Why do people share these things? Could be something as simple asthesite doesn't have a mechanism for guest access. An example of thisisguest wireless access on campus. You have a guest speaker who needs wireless access, your campus has no mechanism to provide guestaccessso you, the sponsor, lets the speaker use your credentials to get access. Email access, door access are other examples. An emailsystemdoesn't allow sharing of email folders, a dept. head is on travelandthe assistant needs access to those emails. The only alternative istoshare 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 cardowner.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 securityofficernoticed a group of unfamiliar people using machines in one of ourlabs.She asked them for their ID cards and none could (would?) produce one.Onquestioning they said they were students from a neighbouringinstitutionand that they were using "borrowed" credential. We have cctv footage and swipe card logs from the door (which mayshowthey tail gated someone in). We are now tracking down which machineswerebeing used so we can disable the accounts. To the point. We (the security techies) have been asked what measures we candeploy toprevent 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 shouldnotshare 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 thatthis willpersuade 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 theywill bereluctant to part with for any length of time. Like their IDcard.Our ID cards have bar codes and classic mag stripe. Some labs(likethis one) also have proximity card locks. Generally only post gradstudentsor 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
Current thread:
- Re: stopping students sharing their login credentials, (continued)
- Re: stopping students sharing their login credentials Rappaport,Jason (Jan 23)
- Re: stopping students sharing their login credentials Mike Wiseman (Jan 23)
- Re: stopping students sharing their login credentials randy marchany (Jan 23)
- Re: stopping students sharing their login credentials James M. Dutcher - Assoc. VP IS/IT & CIO (Jan 23)
- Re: stopping students sharing their login credentials Christopher Jones (Jan 23)
- Re: stopping students sharing their login credentials randy marchany (Jan 23)
- Re: stopping students sharing their login credentials Mike Wiseman (Jan 23)
- Re: stopping students sharing their login credentials Charlie Reitsma (Jan 23)
- Re: stopping students sharing their login credentials Neil Sindicich (Jan 23)
- Re: stopping students sharing their login credentials Barros, Jacob (Jan 23)
- Re: stopping students sharing their login credentials Basgen, Brian (Jan 23)
- Re: stopping students sharing their login credentials Brad Judy (Jan 23)
- Re: stopping students sharing their login credentials Charlie Reitsma (Jan 23)
- Re: stopping students sharing their login credentials Gary Flynn (Jan 23)
- Re: stopping students sharing their login credentials Valdis Kletnieks (Jan 23)
- Re: stopping students sharing their login credentials Neil Sindicich (Jan 25)
- Re: stopping students sharing their login credentials James M. Dutcher - Assoc of IS/IT & CIO (Jan 25)