Educause Security Discussion mailing list archives
Re: SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124)
From: Karen Stopford <stopfordk () CT EDU>
Date: Thu, 4 Jun 2009 08:51:20 -0400
For the most part I agree, especially with #1. But I'm not so sure it doesn't matter how students get to the data. I'm assuming their work is supervised to some extent, and supervision is a psychological deterrent to bad behavior. Restricting access to times/places where students will be supervised therefore can help prevent data loss where fear of getting caught is present and motive is fairly low. Obviously, if someone really wants to get the data, supervision alone is not a good deterrent. If it's not too cumbersome, you should be able to limit share access to specified machine accounts only. But you are right, you don't want this to lull you into a false sense of security. The other items you listed plus possibly disabling USB should be put in place as a matter of standard practice. Karen It doesn't matter how much you want. What really matters is how much you want it. The extent and complexity of the problem does not matter was much as does the willingness to solve it. -Ralph Marston C. Karen Stopford, CISSP Associate Executive Officer for I.T. Security CT State University System 39 Woodland Street Hartford, CT 06105 (860) 493-0116 -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Peter Charbonneau Sent: Tuesday, June 02, 2009 7:44 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) Chris, Thank you for the clarity and conciseness. Your opinion is certainly valued. p On Jun 2, 2009, at 6:46 AM, Erwin Carrow wrote:
Respectfully (seriously) I think everyone may be over thinking this process ..., 1. Unique accounts should be a requirement and not optional, you have to be able to monitor and manage activity (audit) 2. If they have access to the data at all it really does not matter how they get to it (e.g., as earlier noted -- thumb drive to walkout with confidential or sensitive information 3. Classification, authorization, and method of access should be managed by the business owner (e.g., department director) for their trustees (e.g., worker bees) and the data steward (e.g., CIO and Team) implement their intent per institution policy, standards, and procedures. 4. A change in "identity and Access Control Management (IAM)" stewardship processes (e.g., application or migration to AD) should not dictate a change in the business function goal or objective unless agreed upon by the business owner - in this case it has probably been identified that it was not clear and needs to be better articulated 5. Use of AD system level accounts for IAM is possible, but harder to manage and requires more effort by the data steward working in conjunction with the business owner (but it will work). 6. More complex technical solutions are possible through use of source and destination IPs, account credentialing, data filtering (DAM, IPS, and IDS), etc., but why bother if you have not addressed steps 1-4 7. Technology will be constantly changing (improving or new vulnerabilities and threats identified that must be mitigated) not only for IAM but other areas or requirements as well, therefore it is best to start with a high level methodology that can address the "business needs versus threat" scenario and insure everyone involved takes on their proper role and responsibility for risk mitigation 8. Lastly DON'T BE A TECHNO HERO - it creates and inflates a false sense of security for the folks you support. Because there is no panacea/cure for IAM (from a data stewards perspective), and when "Pandora's Box" is opened it will explode 9. Someone in our educational systems will always want to open the "box" in our "open" transparent world that we live in regardless of the possible consequences - it's the nature of the beast! Comments brought to you by the peanut gallery here in the South. Hopefully I did not offend too many of you! --Chris Erwin (Chris) Louis Carrow, M.Div., MSIS, CISSP, INFOSEC, CCAI, CCNP, CCSP, CQS, CCNA, LCP, LCI, OCM, MCSE, MCP+I IT Auditor II Board of Regents, University System of Georgia 270 Washington Street S.W., Ste. 7087 Atlanta, GA 30334 (404)657-9890 Office, (678)644-3526 Cell, Email: erwin.carrow () usg edu -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU ] On Behalf Of SECURITY automatic digest system Sent: Tuesday, June 02, 2009 12:00 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) There are 13 messages totalling 1094 lines in this issue. Topics of the day: 1. Student workers & shared drive restrictions (13) ---------------------------------------------------------------------- Date: Mon, 1 Jun 2009 13:13:04 -0400 From: "Bazeley, Joseph E." <bazeleje () MUOHIO EDU> Subject: Student workers & shared drive restrictions We're migrating to Active Directory, and I'm looking to use this as an oppo= rtunity to remove generic student worker accounts. Previously, each office= would have their own shared student worker account (i.e., Bursar_Student_W= orker), which all student workers in that area would use to login with. I = want to have each student login with their regular AD credentials, but when= and only when they are using computers in that department will they have a= ccess to the department's shared drive. If they login from a non- departmen= t computer, they are unable to access that share. Anyone have a way to configure accounts in AD so that the following happens= ? User 1 (student worker) logs in to Computer A (dept computer) and gets acce= ss to drive Q: (dept share) User 1 logs in to Computer B (non-dept computer) and is unable to access dr= ive Q: (including if they try to manually map the drive) Joe Bazeley Information Security Officer Miami University Hoyt Hall 314 513-529-9252 ------------------------------ Date: Mon, 1 Jun 2009 12:28:58 -0500 From: Brian Desmond <brian.desmond () MORANTECHNOLOGY COM> Subject: Re: Student workers & shared drive restrictions Couple ways I can think of to do it: --> Have you logon script check the group membership of the computer account and then do the mappings based on that. Put computers in security groups based on office/department/etc. --> You can do all sorts of creative filtering with Group Policy Preferences and you can use that (GPP) to do the drive mapping. Thanks, Brian Desmond brian.desmond () morantechnology com c - 312.731.3132 Active Directory, 4th Ed - http://www.briandesmond.com/ad4/ Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Bazeley, Joseph E. Sent: Monday, June 01, 2009 12:13 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: [SECURITY] Student workers & shared drive restrictions We're migrating to Active Directory, and I'm looking to use this as an opportunity to remove generic student worker accounts. Previously, each office would have their own shared student worker account (i.e., Bursar_Student_Worker), which all student workers in that area would use to login with. I want to have each student login with their regular AD credentials, but when and only when they are using computers in that department will they have access to the department's shared drive. If they login from a non-department computer, they are unable to access that share. Anyone have a way to configure accounts in AD so that the following happens? User 1 (student worker) logs in to Computer A (dept computer) and gets access to drive Q: (dept share) User 1 logs in to Computer B (non-dept computer) and is unable to access drive Q: (including if they try to manually map the drive) Joe Bazeley Information Security Officer Miami University Hoyt Hall 314 513-529-9252 ------------------------------ Date: Mon, 1 Jun 2009 14:01:17 -0400 From: Brad Judy <win-hied () BRADJUDY COM> Subject: Re: Student workers & shared drive restrictions What about simply using the host firewall on the file server to only allow connections from departmental machines? This is the typical way to resolve this issue and I've used it many times. Brad Judy We're migrating to Active Directory, and I'm looking to use this as an opportunity to remove generic student worker accounts. Previously, each office would have their own shared student worker account (i.e., Bursar_Student_Worker), which all student workers in that area would use to login with. I want to have each student login with their regular AD credentials, but when and only when they are using computers in that department will they have access to the department's shared drive. If they login from a non-department computer, they are unable to access that share. Anyone have a way to configure accounts in AD so that the following happens? User 1 (student worker) logs in to Computer A (dept computer) and gets access to drive Q: (dept share) User 1 logs in to Computer B (non-dept computer) and is unable to access drive Q: (including if they try to manually map the drive) Joe Bazeley Information Security Officer Miami University Hoyt Hall 314 513-529-9252 ------------------------------ Date: Mon, 1 Jun 2009 14:46:46 -0400 From: Valdis Kletnieks <Valdis.Kletnieks () VT EDU> Subject: Re: Student workers & shared drive restrictions --==_Exmh_1243882006_4285P Content-Type: text/plain; charset=us-ascii On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:What about simply using the host firewall on the file server to only allow connections from departmental machines? This is the typical way to resolve this issue and I've used it many times.Works great, unless you have other shares that you *do* want accessible from other non-departmental machines (consider the case where some shares are accessible via VPN connections, for instance). A related question would be: What sort of misbehavior is the original poster trying to prevent by only allowing access when they're using computers in the department? Hopefully those systems don't have any user-accessible USB ports on them, or web or e-mail access, or any of the zillions of other ways they could abscond with sensitive information while logged in on the departmental computer... (I'm not saying the original poster doesn't have a legitimate business need, I'm just an idiot and not understanding the problem he's trying to solve yet). --==_Exmh_1243882006_4285P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFKJCIWcC3lWbTT17ARAtr3AKDfBmFvGE3pnmiGRQ3MZNrqEWFRaACfc144 NXOu2kMQcjut2IHvNjrRh40= =7h3q -----END PGP SIGNATURE----- --==_Exmh_1243882006_4285P-- ------------------------------ Date: Mon, 1 Jun 2009 17:01:54 -0400 From: "Bazeley, Joseph E." <bazeleje () MUOHIO EDU> Subject: Re: Student workers & shared drive restrictions I'm the original poster, and I'm trying to replace trade one problem for an= other one. Currently I have areas where 20 student workers all share a set= of credentials which they use when working. The main difference between t= heir regular ID and this one is that this one maps a department share inste= ad of their regular drive mappings. I want to move away them away from using these shared accounts, with my end= goal being accountability. I want to be able to tie an action performed b= y a given account to a specific person, instead of a group of people. The = pushback that I'm getting is that student workers will have access to the d= epartmental shared drives outside of work, and will copy files that they sh= ould not have. This is not a very good argument, as the students could cop= y the files while at work through multiple different methods (USB, our WebD= AV shares, email, etc). In order to gain the accountability that I'm looking for, I need to provide= a method that will be computer-aware in determining which drives to map. = So when a student worker logs in to one of the machines in the department o= ffices they work in, only the department share is mapped. And when they lo= g in anywhere else on campus, only their personal share is mapped. I think that either of the two solutions I've seen before might work in our= environment, but if there are other solutions being used at other schools = I'd like to hear about them. Joe=20 -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LIS= TSERV.EDUCAUSE.EDU] On Behalf Of Valdis Kletnieks Sent: Monday, June 01, 2009 2:47 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:What about simply using the host firewall on the file server to only allo=wconnections from departmental machines? This is the typical way to resol=vethis issue and I've used it many times.Works great, unless you have other shares that you *do* want accessible fro= m other non-departmental machines (consider the case where some shares are accessible via VPN connections, for instance). A related question would be: What sort of misbehavior is the original post= er trying to prevent by only allowing access when they're using computers in t= he department? Hopefully those systems don't have any user-accessible USB por= ts on them, or web or e-mail access, or any of the zillions of other ways they could abscond with sensitive information while logged in on the departmenta= l computer... (I'm not saying the original poster doesn't have a legitimate business need= , I'm just an idiot and not understanding the problem he's trying to solve ye= t). ------------------------------ Date: Mon, 1 Jun 2009 17:17:50 -0400 From: Valdis Kletnieks <Valdis.Kletnieks () VT EDU> Subject: Re: Student workers & shared drive restrictions --==_Exmh_1243891070_4285P Content-Type: text/plain; charset=us-ascii On Mon, 01 Jun 2009 17:01:54 EDT, "Bazeley, Joseph E." said:pushback that I'm getting is that student workers will have access to the departmental shared drives outside of work, and will copy files that they should not have. This is not a very good argument, as the students could copy the files while at work through multiple different methods (USB, our WebDAV shares, email, etc).Oh, OK. You get it, but the pushback generators don't. Been there, done that, got the t-shirt with tread marks on it. You have my condolences. --==_Exmh_1243891070_4285P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFKJEV+cC3lWbTT17ARArAXAJ9BhR0SkzQoOacHKwzO1Yw9CJltAgCghAGZ UaNy95TMSCTCJ7tJ9J7WVUE= =6X3e -----END PGP SIGNATURE----- --==_Exmh_1243891070_4285P-- ------------------------------ Date: Mon, 1 Jun 2009 17:43:21 -0400 From: "Spransy, Derek" <DSPRANS () EMORY EDU> Subject: Re: Student workers & shared drive restrictions What prevents them from mapping a drive while they're not at work using the= generic account now if they know the UNC path? Login scripts and group po= licy preferences can be used to change which drive maps on what computer, b= ut students could always manually map a drive from anywhere in which they h= ave access to the server. Once someone is given access to data, then it's = hard to prevent them from abusing it. You just have to have an audit trail= that can tell you what happened. We have a nearly identical set up for one of our administrative units that = employs a number of work study students. These students move around within= the department quite frequently, and through group membership are allowed = to login to any student worker computer. From there they have permissions = only to the folders within the share that they need access to. We used to = use generic accounts as well, but found the same problems with accountabili= ty. Each semester (or as needed) the department tells us who to remove. Y= ou can't really add computer accounts to the share to accomplish what you w= ish (since the user account makes the request, and not the computer account= ). If they have access to the share, then it would be difficult to prevent= them from mapping the drive somewhere else unless you only allow the depar= tment's subnet to access the file sharing ports on the server. All of our = students have to sign a confidentiality agreement as part of their employme= nt too, which does give you some legal coverage if something should happen.= It's also a best practice to avoid giving students access to data that wi= th a high level of sensitivity as well. Hope that helps! If you'd like mo= re details on our set up I'd be happy to share offline. -Derek =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Derek Spransy IT Security Lead Emory College of Arts & Sciences derek.spransy () emory edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY@LISTSERV.E = DUCAUSE.EDU] On Behalf Of Bazeley, Joseph E. [bazeleje () MUOHIO EDU] Sent: Monday, June 01, 2009 5:01 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions I'm the original poster, and I'm trying to replace trade one problem for an= other one. Currently I have areas where 20 student workers all share a set= of credentials which they use when working. The main difference between t= heir regular ID and this one is that this one maps a department share inste= ad of their regular drive mappings. I want to move away them away from using these shared accounts, with my end= goal being accountability. I want to be able to tie an action performed b= y a given account to a specific person, instead of a group of people. The = pushback that I'm getting is that student workers will have access to the d= epartmental shared drives outside of work, and will copy files that they sh= ould not have. This is not a very good argument, as the students could cop= y the files while at work through multiple different methods (USB, our WebD= AV shares, email, etc). In order to gain the accountability that I'm looking for, I need to provide= a method that will be computer-aware in determining which drives to map. = So when a student worker logs in to one of the machines in the department o= ffices they work in, only the department share is mapped. And when they lo= g in anywhere else on campus, only their personal share is mapped. I think that either of the two solutions I've seen before might work in our= environment, but if there are other solutions being used at other schools = I'd like to hear about them. Joe -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LIS= TSERV.EDUCAUSE.EDU] On Behalf Of Valdis Kletnieks Sent: Monday, June 01, 2009 2:47 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:What about simply using the host firewall on the file server to only allo=wconnections from departmental machines? This is the typical way to resol=vethis issue and I've used it many times.Works great, unless you have other shares that you *do* want accessible fro= m other non-departmental machines (consider the case where some shares are accessible via VPN connections, for instance). A related question would be: What sort of misbehavior is the original post= er trying to prevent by only allowing access when they're using computers in t= he department? Hopefully those systems don't have any user-accessible USB por= ts on them, or web or e-mail access, or any of the zillions of other ways they could abscond with sensitive information while logged in on the departmenta= l computer... (I'm not saying the original poster doesn't have a legitimate business need= , I'm just an idiot and not understanding the problem he's trying to solve ye= t). This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). ------------------------------ Date: Mon, 1 Jun 2009 18:10:33 -0400 From: Dexter Caldwell <Dexter.Caldwell () FURMAN EDU> Subject: Re: Student workers & shared drive restrictions This is a multi-part message in MIME format. ----=_--0dd43d50.0dd43b10.c64a0259 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I understand your pain as many probably do. We've had similar hurdles.=20 IMHO, the real problem is two-fold. =20 1) Students are assigned tasks with access to things that they really shouldn't have access to as non-official workers- or that should be done by FTEs on the basis of accountability alone. =20 2) Departments shares are not appropriately maintained so that data withi= n shares is structured well so that less secure parts of the share (group folder) only contain appropriate data that is accessible by everyone. Both these issues are actually user-generated issues and don't have real good technology solutions in general. =20 Suggestions ---------------- One thing you could possibly consider (is to give the students local machine accounts on the appropriate computers and simply allow those local machine accounts access to the server share. Of course you lose A/= D management so that's not the best idea either. If you do have a well segmented network, you could simply do this with firewalls and routing as one person mentioned, but this can lack granular security when students roam. Finally you might consider giving the students special-use A/D accounts that you only allow to login to those specific machines, during specific hours (Ex, 8-5pm). Then, when they're working, they don't login as thei= r usual jdoe123- they instead use jdoe123atwork. You retain central management, you can pre-set expiration dates if you know how long the students will work, and you can easily use group management to find out exactly where the students are. I would recommend using a special prefix so that you can quickly identify where these accounts are throughout the enterprise. Sorry don't have any better ideas at the moment, but this really is technology trying to handle people issues. Dexter Caldwell Furman University The EDUCAUSE Security Constituent Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> writes:I'm the original poster, and I'm trying to replace trade one problem for another one. Currently I have areas where 20 student workers all share =aset of credentials which they use when working. The main difference between their regular ID and this one is that this one maps a department share instead of their regular drive mappings. I want to move away them away from using these shared accounts, with my end goal being accountability. I want to be able to tie an action performed by a given account to a specific person, instead of a group of people. The pushback that I'm getting is that student workers will have access to the departmental shared drives outside of work, and will copy files that they should not have. This is not a very good argument, as the students could copy the files while at work through multiple different methods (USB, our WebDAV shares, email, etc). In order to gain the accountability that I'm looking for, I need to provide a method that will be computer-aware in determining which drives to map. So when a student worker logs in to one of the machines in the department offices they work in, only the department share is mapped.=20 And when they log in anywhere else on campus, only their personal share is mapped. I think that either of the two solutions I've seen before might work in our environment, but if there are other solutions being used at other schools I'd like to hear about them. Joe=20 -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Valdis Kletnieks Sent: Monday, June 01, 2009 2:47 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:What about simply using the host firewall on the file server to onlyallowconnections from departmental machines? This is the typical way toresolvethis issue and I've used it many times.Works great, unless you have other shares that you *do* want accessible from other non-departmental machines (consider the case where some shares are accessible via VPN connections, for instance). A related question would be: What sort of misbehavior is the original poster trying to prevent by only allowing access when they're using computers i=nthe department? Hopefully those systems don't have any user-accessible USB ports on them, or web or e-mail access, or any of the zillions of other ways they could abscond with sensitive information while logged in on the departmental computer... (I'm not saying the original poster doesn't have a legitimate business need, I'm just an idiot and not understanding the problem he's trying to solve yet).----=_--0dd43d50.0dd43b10.c64a0259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <?xml version=3D=221.0=22 encoding=3D=22UTF-8=22?> <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22> <html xmlns=3D=22http://www.w3.org/1999/xhtml=22> <head> <meta http-equiv=3D=22Content-Type=22 content=3D=22text/html; charset=3DUTF= -8=22 /> <title></title> <style type=3D=22text/css=22> <=21-- body=7Bmargin-left:10px;margin-right:10px;margin-top:10px;margin- bottom:10p= x;=7D --> </style> </head> <body marginleft=3D=2210=22 marginright=3D=2210=22 margintop=3D=2210=22 mar= ginbottom=3D=2210=22> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>I understand your pain as many probably d= o. We've had similar hurdles. IMHO, the real problem is two-fol= d. </font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>1) Students are assigned tasks with acces= s to things that they really shouldn't have access to as non- official worke= rs- or that should be done by FTEs on the basis of accountability alone. &n= bsp;</font></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>2) Departments shares are not appropriate= ly maintained so that data within shares is structured well so that less se= cure parts of the share (group folder) only contain appropriate data that i= s accessible by everyone.</font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Both these issues are actually user-gener= ated issues and don't have real good technology solutions in general.  = ;</font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Suggestions</font></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>----------------</font></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>One thing you could possibly consider (is= to give the students local machine accounts on the appropriate computers &= nbsp;and simply allow those local machine accounts access to the server sha= re. Of course you lose A/D management so that's not the best idea eit= her.</font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>If you do have a well segmented network, = you could simply do this with firewalls and routing as one person mentioned= , but this can lack granular security when students roam.</font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Finally you might consider giving the stu= dents special-use A/D accounts that you only allow to login to those specif= ic machines, during specific hours (Ex, 8-5pm). Then, when they're wo= rking, they don't login as their usual jdoe123- they instead use jdoe= 123atwork. You retain central management, you can pre-set expiration dates = if you know how long the students will work, and you can easily use group m= anagement to find out exactly where the students are. I would recomme= nd using a special prefix so that you can quickly identify where these acco= unts are throughout the enterprise.</font></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Sorry don't have any better ideas at the = moment, but this really is technology trying to handle people issues.</font=</div><br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Dexter Caldwell</font></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22>Furman University</font></div> <br /> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><font face=3D=22Aria= l=22 size=3D=22+0=22 color=3D=22=23000000=22 style=3D=22font- family:Arial;f= ont-size:10pt;color:=23000000;=22><b>The EDUCAUSE Security Constituent Grou= p Listserv <<a href=3D=22mailto:SECURITY=40LISTSERV.EDUCAUSE.EDU=22>SECU= RITY=40LISTSERV.EDUCAUSE.EDU</a>> writes:</b></font></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>I'm the original poster, and I'm trying to replace trade one probl= em for another one. Currently I have areas where 20 student workers a= ll share a set of credentials which they use when working. The main d= ifference between their regular ID and this one is that this one maps a dep= artment share instead of their regular drive mappings.</font></ span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>I want to move away them away from using these shared accounts, wi= th my end goal being accountability. I want to be able to tie an acti= on performed by a given account to a specific person, instead of a group of= people. The pushback that I'm getting is that student workers will h= ave access to the departmental shared drives outside of work, and will copy= files that they should not have. This is not a very good argument, a= s the students could copy the files while at work through multiple differen= t methods (USB, our WebDAV shares, email, etc).</font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>In order to gain the accountability that I'm looking for, I need t= o provide a method that will be computer-aware in determining which drives = to map. So when a student worker logs in to one of the machines in th= e department offices they work in, only the department share is mapped. &nb= sp;And when they log in anywhere else on campus, only their personal share = is mapped.</font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>I think that either of the two solutions I've seen before might wo= rk in our environment, but if there are other solutions being used at other= schools I'd like to hear about them.</font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>Joe </font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>-----Original Message-----</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>From: The EDUCAUSE Security Constituent Group Listserv =5B<a href= =3D=22mailto:SECURITY=40LISTSERV.EDUCAUSE.EDU=22 target=3D=22_blank=22>mail= to:SECURITY=40LISTSERV.EDUCAUSE.EDU</a>=5D On Behalf Of Valdis Kletnieks</f= ont></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>Sent: Monday, June 01, 2009 2:47 PM</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>To: <a href=3D=22mailto:SECURITY=40LISTSERV.EDUCAUSE.EDU=22>SECURI= TY=40LISTSERV.EDUCAUSE.EDU</a></font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>Subject: Re: =5BSECURITY=5D Student workers & shared drive res= trictions</font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:</font></ span></d= iv> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>> What about simply using the host firewall on the file server = to only allow</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>> connections from departmental machines? This is the typ= ical way to resolve</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>> this issue and I've used it many times.</font></span></ div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>Works great, unless you have other shares that you *do* want acces= sible from</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>other non-departmental machines (consider the case where some shar= es are</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>accessible via VPN connections, for instance).</font></ span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>A related question would be: What sort of misbehavior is the= original poster</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>trying to prevent by only allowing access when they're using compu= ters in the</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>department? Hopefully those systems don't have any user-acce= ssible USB ports</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>on them, or web or e-mail access, or any of the zillions of other = ways they</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>could abscond with sensitive information while logged in on the de= partmental</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>computer...</font></span></div> <br /> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>(I'm not saying the original poster doesn't have a legitimate busi= ness need,</font></span></div> <div align=3D=22left=22 style=3D=22text-align:left;=22><span style=3D=22bac= kground-color:=23d0d0d0;=22><font face=3D=22Geneva=22 size=3D=22+0=22 color= =3D=22=23000000=22 style=3D=22font-family:Geneva;font-size: 12pt;color:=2300= 0000;=22>I'm just an idiot and not understanding the problem he's trying to= solve yet).</font></span></div> <br /> <br /> <br/> </body> </html> ----=_--0dd43d50.0dd43b10.c64a0259-- ------------------------------ Date: Mon, 1 Jun 2009 19:26:44 -0400 From: Bob Kalal <kalal.1 () OSU EDU> Subject: Re: Student workers & shared drive restrictions Folks seem to forget that "students" are adult citizens. If they hadn't come to college many would be handling patient files in your doctor's office, training for a job with your local police, maintaining your kids school, fielding help desk questions at your credit institution, or dealing with other "sensitive' tasks. They deserve adequate training and can handle responsibilities. Bob Kalal On Jun 1, 2009, at 5:43 PM, Spransy, Derek wrote:... It's also a best practice to avoid giving students access to data that with a high level of sensitivity as well. Hope that helps! If you'd like more details on our set up I'd be happy to share offline.------------------------------ Date: Mon, 1 Jun 2009 19:50:30 -0400 From: "Spransy, Derek" <DSPRANS () EMORY EDU> Subject: Re: Student workers & shared drive restrictions Agreed, and indeed, I would sometimes trust students to make better securit= y decisions than staff :-) However, they are not permanent employees of th= e University and in practice often receive little training from the departm= ents that hire them. The question of access really belongs more in the han= ds of the data custodians than it does with the security staff. In our cas= e the department makes the access decisions and students don't usually get = access to particularly sensitive information (mostly because the data that = they would have access to includes academic and disciplinary information ab= out other students), and those job responsibilities rest mostly with the st= aff. In the case in question, if the risk of students abusing their access= is considered to be high, then it may be best to put those responsibilitie= s elsewhere. ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY@LISTSERV.E = DUCAUSE.EDU] On Behalf Of Bob Kalal [kalal.1 () OSU EDU] Sent: Monday, June 01, 2009 7:26 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions Folks seem to forget that "students" are adult citizens. If they hadn't come to college many would be handling patient files in your doctor's office, training for a job with your local police, maintaining your kids school, fielding help desk questions at your credit institution, or dealing with other "sensitive' tasks. They deserve adequate training and can handle responsibilities. Bob Kalal On Jun 1, 2009, at 5:43 PM, Spransy, Derek wrote:... It's also a best practice to avoid giving students access to data that with a high level of sensitivity as well. Hope that helps! If you'd like more details on our set up I'd be happy to share offline.This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). ------------------------------ Date: Mon, 1 Jun 2009 20:07:20 -0400 From: Valdis Kletnieks <Valdis.Kletnieks () VT EDU> Subject: Re: Student workers & shared drive restrictions --==_Exmh_1243901240_4285P Content-Type: text/plain; charset=us-ascii On Mon, 01 Jun 2009 19:26:44 EDT, Bob Kalal said:Folks seem to forget that "students" are adult citizens. If they hadn't come to college many would be handling patient files in your doctor's office, training for a job with your local police, maintaining your kids school, fielding help desk questions at your credit institution, or dealing with other "sensitive' tasks.Yes - but would you feel comfortable going to your doctor, or police, or school, or bank, and finding out that your sensitive data was being handled by a person working only 5 or 10 hours a week at close to min wage, and who quite possibly didn't have any real training regarding the handling of sensitive info? It's not that they're not adults - it's that in most places, a work study job simply doesn't have the same level of training and accountability that a FTE has. (Yes, I know there's exceptions - the point is they *are* exceptions) --==_Exmh_1243901240_4285P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFKJG04cC3lWbTT17ARAq3rAJ9wPvddP1gtPE/2vKPSifv2Lad0dACfUXf2 g4IhawEP3WxA7fXvLCAfMto= =9FfQ -----END PGP SIGNATURE----- --==_Exmh_1243901240_4285P-- ------------------------------ Date: Mon, 1 Jun 2009 20:16:03 -0400 From: Charles Buchholtz <chip+educause () SEAS UPENN EDU> Subject: Re: Student workers & shared drive restrictions On Mon, Jun 01, 2009 at 07:26:44PM -0400, Bob Kalal wrote:Folks seem to forget that "students" are adult citizens.Yes, and I'm a strong proponent of trusting student workers with real responsibility. But, students often have a personal interest in the data that they are handling. If I was having an embarrassing medical procedure, I wouldn't want to use the clinic where my sister-in-law handled the charts. Similarly, if I were a student I might prefer that my classmate not handle my student records or email. We often hire students from a neighboring university, partially because they are less likely to be interested in our students' private affairs. --- Chip Charles H. Buchholtz Director of Systems Programming chip () seas upenn edu School of Engineering and Applied Science http://www.seas.upenn.edu/~chip University of Pennsylvania ------------------------------ Date: Mon, 1 Jun 2009 21:16:05 -0400 From: "Witmer, Robert" <r.witmer () SNHU EDU> Subject: Re: Student workers & shared drive restrictions We are currently looking into this topic as well for our work-study student= s. The business requirements for these special accounts are primarily acco= untability and isolation of the student/business environments. The solutio= n we will likely land on is a separate account which the student will use f= or work and will not be associated with their student account. For example= , instead of using ws-finaid (generic acct) or jsmith (student acct) for th= e student worker to access the "work" environment, we will be creating a sp= ecial case account (ws-jsmith) that is enabled only during their work shift= (i.e. 8AM-5PM) as defined by the dept supervisor (account requestor/ owner)= and is automatically set to disable every 90 days. The student worker acc= ount will be enabled at 90 day incriments as requested by the dept supervis= or so the account doesn't live forever. Normal password change rules will = apply to this account as with all others. We also have a policy that states student accounts (i.e. jsmith) will never= be given access business folders and files. So when working, the student = worker (using ws-jsmith account) does not have access to their student serv= ices (email, personal directories, etc). And when the student is not worki= ng, the student doesn't have access to the ws-jsmith account (disabled). A= lso using group policies, the student worker account (ws-jsmith) does not h= ave the ability to copy/save files anywhere but the department's shared fol= der. In this configuration, data can't be saved locally or to a personal (= mapped) drive which the student has access. Obviously, there is additional = overhead associated with managing the student worker accounts, but it appea= rs to be a solution that will enable us to successfully meet our objectives= . ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY@LISTSERV.E = DUCAUSE.EDU] On Behalf Of Spransy, Derek [DSPRANS () EMORY EDU] Sent: Monday, June 01, 2009 5:43 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions What prevents them from mapping a drive while they're not at work using the= generic account now if they know the UNC path? Login scripts and group po= licy preferences can be used to change which drive maps on what computer, b= ut students could always manually map a drive from anywhere in which they h= ave access to the server. Once someone is given access to data, then it's = hard to prevent them from abusing it. You just have to have an audit trail= that can tell you what happened. We have a nearly identical set up for one of our administrative units that = employs a number of work study students. These students move around within= the department quite frequently, and through group membership are allowed = to login to any student worker computer. From there they have permissions = only to the folders within the share that they need access to. We used to = use generic accounts as well, but found the same problems with accountabili= ty. Each semester (or as needed) the department tells us who to remove. Y= ou can't really add computer accounts to the share to accomplish what you w= ish (since the user account makes the request, and not the computer account= ). If they have access to the share, then it would be difficult to prevent= them from mapping the drive somewhere else unless you only allow the depar= tment's subnet to access the file sharing ports on the server. All of our = students have to sign a confidentiality agreement as part of their employme= nt too, which does give you some legal coverage if something should happen.= It's also a best practice to avoid giving students access to data that wi= th a high level of sensitivity as well. Hope that helps! If you'd like mo= re details on our set up I'd be happy to share offline. -Derek =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Derek Spransy IT Security Lead Emory College of Arts & Sciences derek.spransy () emory edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY@LISTSERV.E = DUCAUSE.EDU] On Behalf Of Bazeley, Joseph E. [bazeleje () MUOHIO EDU] Sent: Monday, June 01, 2009 5:01 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions I'm the original poster, and I'm trying to replace trade one problem for an= other one. Currently I have areas where 20 student workers all share a set= of credentials which they use when working. The main difference between t= heir regular ID and this one is that this one maps a department share inste= ad of their regular drive mappings. I want to move away them away from using these shared accounts, with my end= goal being accountability. I want to be able to tie an action performed b= y a given account to a specific person, instead of a group of people. The = pushback that I'm getting is that student workers will have access to the d= epartmental shared drives outside of work, and will copy files that they sh= ould not have. This is not a very good argument, as the students could cop= y the files while at work through multiple different methods (USB, our WebD= AV shares, email, etc). In order to gain the accountability that I'm looking for, I need to provide= a method that will be computer-aware in determining which drives to map. = So when a student worker logs in to one of the machines in the department o= ffices they work in, only the department share is mapped. And when they lo= g in anywhere else on campus, only their personal share is mapped. I think that either of the two solutions I've seen before might work in our= environment, but if there are other solutions being used at other schools = I'd like to hear about them. Joe -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LIS= TSERV.EDUCAUSE.EDU] On Behalf Of Valdis Kletnieks Sent: Monday, June 01, 2009 2:47 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Student workers & shared drive restrictions On Mon, 01 Jun 2009 14:01:17 EDT, Brad Judy said:What about simply using the host firewall on the file server to only allo=wconnections from departmental machines? This is the typical way to resol=vethis issue and I've used it many times.Works great, unless you have other shares that you *do* want accessible fro= m other non-departmental machines (consider the case where some shares are accessible via VPN connections, for instance). A related question would be: What sort of misbehavior is the original post= er trying to prevent by only allowing access when they're using computers in t= he department? Hopefully those systems don't have any user-accessible USB por= ts on them, or web or e-mail access, or any of the zillions of other ways they could abscond with sensitive information while logged in on the departmenta= l computer... (I'm not saying the original poster doesn't have a legitimate business need= , I'm just an idiot and not understanding the problem he's trying to solve ye= t). This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). Please consider the environment before printing this e-mail. ------------------------------ End of SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) **************************************************************
PeteC Peter Charbonneau Sr. Network and Systems Administrator Williams College (413) 597-3408 (office) (413) 822-2922 (cell) OIT will NEVER ask for your password!
Current thread:
- Re: SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) Erwin Carrow (Jun 02)
- <Possible follow-ups>
- Re: SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) Peter Charbonneau (Jun 02)
- Re: SECURITY Digest - 29 May 2009 to 1 Jun 2009 (#2009-124) Karen Stopford (Jun 04)