Educause Security Discussion mailing list archives

Re: <No subject given>


From: "Mclaughlin, Kevin (mclaugkl)" <mclaugkl () UCMAIL UC EDU>
Date: Wed, 2 Apr 2008 11:30:42 -0400

Hi Adrian:
Thank you for the feedback. I would argue that the whole grade posting thing
is as complicated as some want to make it out to be.  The depth of this
discussion thread tends to support that and just two weeks ago I met with
General Counsel and a sub-committee of my faculty senate for a couple of
hours to discuss this very issue.  At the end of the meeting the consensus
was, and still is, that we were being prudent and reasonable by using a 9
digit, internal use only, Student ID number to reference a student on  a
single class grade sheet.  We could find no reference in the FERPA
documentation that said :   You are not allowed to put student class grades
in a public place.(period)   The whole ANY personally identifiable
information or derivative (I'd like to see the actual citation as I don't
remember reading that phrase) lends itself to debate and interpretation.
When we make regulations they should be clear and easy to follow and not
allow "wiggle room" for folks who don't want to comply.  

I still haven't heard why Student ID is now going to have to be protected.
What is the intent?  To prevent it from being used as an authenticator? Or
if used to be protected as non-directory information?  If that is the case
then say that "Student IDs must be treated as non-directory information if
they are used as an authenticator (and then we can debate whether using it
to post an associated grade makes it an authenticator)".  All that will do
is then lead to the publishing of student grades with a secret word or PIN,
and future legislation will have to say that "Student PINs must be treated
as non-directory information if they are used as an authenticator" - this
could become a never ending cycle.   If grades are not to be posted then
just say it... that's my general feedback - simple, clear, no
interpretation, et cetera.

A lot of institutions saw the sense in removing SSNs as a primary identifier
and that lead to the creation of Student IDs to be used instead.  Now if
told we can't use Student IDs we can follow other suggestions (which cost
money, cause re-work, and are very little value add) and use a PIN or Secret
word. If such a device is then controlled and managed by a faculty member
with limited or no InfoSec or IT experience the cause for concern is still
present.

What is the impetus for this change?    Is there different wording that will
make the mandate and intent there of clearer?

On a professional (InfoSec) note I find it sort of odd that FERPA is
mandating to data owners how they should classify their information -  I
would have expected them to take the approach of telling us what they wanted
done and letting us apply due diligence to comply in a reasonable manner.
(that boat has already sailed though)

-Kevin


Kevin L. McLaughlin
CISM, CISSP, GIAC-GSLC,PMP, ITIL Master Certified  
Director, Information Security
University of Cincinnati
513-556-9177 (w)
513-703-3211 (m)
513-558-ISEC (department)
 
-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Irish, Adrian L
Sent: Wednesday, April 02, 2008 2:51 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] <No subject given>

Kevin, I'm somewhat confused by your message.  You state that on your campus
the UC_ID is Directory information.  If that's the case, then your
institution is already in violation of FERPA by posting grades using that
ID.  I'm really curious how your legal counsel could interpret this as OK?

Really, the whole grade posting thing is not as complicated as some want to
make it out to be.  You simply can't post grades by ANY personally
identifiable information or derivatives of such.  If you do, and a complaint
is filed, you WILL lose.

Adrian.

Adrian Irish
IT Security Officer
The University of Montana
SS 126D
Missoula, MT 59812
(406) 243-6375
 
adrian.irish () umontana edu


-----Original Message-----
From: Mclaughlin, Kevin (mclaugkl) [mailto:mclaugkl () UCMAIL UC EDU] 
Sent: Tuesday, April 01, 2008 7:04 AM
Subject: <No subject given>

This potentially hits us hard on the whole Student ID front.  We don't use
SSNs or User IDs as Directory information but we do treat our UC specific
student IDs as Directory (internal use non restricted) data.  These UC IDs
are restricted by policy from being used in any sort of authentication
process and it would make sense for us to continue using these as Directory
data on many of the other regulated fronts.  Now FERPA is saying to restrict
the use of these as well so with my adjunct hat on I am scratching my head
wondering how in the world I can share my student's progress with them in a
manageable way.  Also, I already know, based on previous conversations with
full time faculty, that going to them and telling them that we have now
decided to also restrict the use of Student ID for communicating grades and
progress to students will cause an uproar and protest.  

Any suggestions?

-Kevin

Kevin L. McLaughlin
CISM, CISSP, GIAC-GSLC,PMP, ITIL Master Certified  
Director, Information Security
University of Cincinnati
513-556-9177 (w)
513-703-3211 (m)
513-558-ISEC (department)
 
 
 

CONFIDENTIALITY NOTICE: This e-mail message and its content is confidential,
intended solely for the addressee, and may be legally privileged. Access to
this message and its content by any individual or entity other than those
identified in this message is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of this e-mail may be
unlawful. Any action taken or omitted due to the content of this message is
prohibited and may be unlawful.
 

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Stephen J Smoogen
Sent: Monday, March 31, 2008 7:22 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY]

Subject: Re: [SECURITY] FERPA Notice of Proposed Rulemaking Addresses
Changes
 in IT
In-Reply-To:
<BE7F8D9715234E47955624FF7D429170015B3676 () DO-EX03 PCC-Domain pima edu>
Message-ID: <alpine.LRH.1.10.0803311715280.23798 () xanadu unm edu>
References: <06EA97D7AA1D534682A5F217BA78E2E00502B9A0 () mailco1 educause edu>
<7.0.1.0.2.20080331132546.03829e88 () uic edu>
<BE7F8D9715234E47955624FF7D429170015B3666 () DO-EX03 PCC-Domain pima edu>

 A<7.0.1.0.2.20080331142826.038806c8 () uic edu>
<BE7F8D9715234E47955624FF7D429170015B3676 () DO-EX03 PCC-Domain pima edu>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-WatchGuard-IPS: message checked
X-WatchGuard-Spam-ID: str=0001.0A090204.47F17206.028E,ss=1,fgs=0
X-WatchGuard-Spam-Score: 0, clean; 0, no virus
X-WatchGuard-Mail-Client-IP: 64.106.76.41
X-WatchGuard-Mail-From: smooge () unm edu
X-WatchGuard-Mail-Recipients: SECURITY () listserv educause edu

On Mon, 31 Mar 2008, Basgen, Brian wrote:

Steve,

You raise an interesting point. Yet, student IDs as directory
information can be problematic, since faculty sometimes publicly post
grades with student IDs attached. In this case the faculty member is
confusing identification with authentication, but you know, good luck
explaining that to faculty. :)


Actually good luck with explaining it to most people.. is there a nice 
pop-up book or something similar that explains what identity is, what 
authentication is, and why they are not the same? Something that helps 
everyone from secretaries to Provosts understand when and where the two 
conflict in people's minds.

I mean how often can one get past some sticky point because someone says 
"Listen, we really need to get this done because Provost A has been 
asking about it." Or something else. People will take that name, and 
accept it as identity and authentication that Provost A wants to get 
this done. And we do it because A) Humans are naturally trusting of 
their social monkey group, and B) Asking too many questions to confirm 
authorization and authentication slows things down, makes our fellow 
monkeys cranky and is usually false alarms.


-- 
Stephen Smoogen -- ITS/Linux Administrator
   MSC02 1520 1 University of New Mexico Albuquerque, NM  87131-0001
   Phone: (505) 277-8219  Email: smooge () unm edu
  How far that little candle throws his beams! So shines a good deed
  in a naughty world. = Shakespeare. "The Merchant of Venice"

Attachment: smime.p7s
Description:


Current thread: