Identity Finder Scans Begin Aug 1 – Reminder

3 07 2014

Information Security Officer Adam Edwards sent out a reminder email to all faculty this week about Identity Finder automated scans, which are set to begin for University-provided faculty desktop machines (Windows only) on August 1. Here’s his reminder:

Starting on Aug 1, 2014 the Information Security Office will begin conducting weekly scans of faculty PCs to locate restricted data. These scans will only be conducted on University provided machines. This is an effort to protect University data and prevent data loss as described in the email notice below.  If you have Human Research data, please ensure it is encrypted prior to Aug 1 2014. These weekly scans have already been rolled out to staff and TAG members.

If you have any questions please email security@scranton.edu

Thanks

Adam Edwards

You can take a look at TAG’s Identity Finder FAQ for Faculty to help prepare, and definitely refer to Adam’s instructions for encryption with 7Zip if you have sensitive or confidential data to protect!


Comments : Leave a Comment »
Tags: , , , ,
Categories : Announcements, Security

Encryption with 7-Zip – Instructions

3 07 2014

So there was a bit of internet shock earlier this summer when a surprise announcement came out that the widely used encryption utility TrueCrypt was no longer being developed. Previously, our Information Security Office had recommended TrueCrypt as a tool for encrypting personal and confidential information, like human subject data. Now that TrueCrypt has been discontinued, Security Officer Adam Edwards passed along some instructions (.docx) for using an alternative (also free and open source) encryption tool, 7-Zip.

Adam warns:

**One caveat with this option is that there is no central management.  This is important because if a user loses their password the data will be lost. Manual recovery procedures will need to be put in place to ensure there is alternative access in the event of an emergency.  If no manual recovery procedures are put in place and the password is lost the data will be lost.**

Please contact Information Security with questions or concerns. Thanks to Adam (and Information Security Engineer Scott Finlon) for watching out for us!


Comments : Leave a Comment »
Tags: , , , , , , ,
Categories : Announcements, Security

TAG Meeting Notes 2014-05-07

7 05 2014

TAG Meeting May 7, 2014 12:00pm-1:00pm

Attendees:
Jeremy Brees, Tim Cannon, Teresa Conte, Kim Daniloski, Dave Dzurec, Tara Fay, Jim Franceschelli, Eugeniu Grigorescu, Calvin Krzywiec (guest), Andrew LaZella, Kristen Yarmey

TAG thanks Library Dean Charles Kratz for sponsoring lunch for our meeting today.

1. BYOD Strategy Draft

Calvin Krzywiec joined us as a guest to present and discuss a draft version of IR’s strategy for accommodating the BYOD (Bring Your Own Device) trend. Cal is Assistant Director of Network Security & Engineering and served as chair for the IR Strategy Group tasked with studying BYOD. The group is currently seeking feedback from campus stakeholders to incorporate into a final strategy.

Cal explained that the group’s objectives were driven by increasing demand among students and faculty for access to institutional services from personal mobile devices. The group’s top priority is supporting BYOD for teaching and learning, while a secondary priority is protecting the security of institutional data.

For teaching and learning (see p. 2-4 in the draft), IR’s BYOD objectives include:

  • Investigate and implement untethered teaching/learning solutions
  • Focus classroom upgrades on providing collaborative, flexible workspaces
  • Leverage virtual desktop/application technologies and client devices to reduce reliance on physical lab infrastructure
  • Leverage virtual desktop/application technologies to provide ubiquitous access to lab software resources
  • Investigate and implement secure electronic assessment solutions
  • Expand lecture capture to additional locations

The draft identifies several barriers to BYOD implementation that were also raised by faculty members in TAG’s informal survey on specialized software and computer labs.  These include:

  • Expensive licensing fees for specialized software
  • Potential disparities in student computer ownership
  • Inaccessible and/or limited power sources
  • Security for electronic assessment/computerized testing
  • High demand on wireless network

The draft strategy recommends partnership with CTLE to support faculty needs as well as engagement with faculty during the implementation of BYOD-related strategies. Jim said that IR will work with TAG to recruit faculty volunteers to test out tools and services. While the precise timeline for rolling out these changes isn’t yet determined, there are some pilot projects already in motion. Faculty members in KSOM are piloting software for securing a browser (for computerized testing) using lab computers running thin clients. Teresa noted that the Nursing department would be very interested in piloting computerized testing tools in McGurrin. IR also plans to pilot test untethered teaching/learning options in the fall – TAG will get more information on this in the summer. Tim volunteered to participate in this pilot. IR has already been piloting Panopto lecture capture and will be looking to add this capability to additional classrooms for Fall 2014. Mobile printing is also in process.

Regarding network and authentication issues: Cal said that IR will be replacing the Cisco NAC client with encrypted SSID authentication, so that users will be able to log in to the University network from their device without downloading and installing CNAC. Once a device has been logged in,  it will stay logged in – users won’t have to reauthenticate multiple times during the day to stay on the network.

The second half of the draft (p. 4-9) addresses faculty and staff devices. One issue addressed is primary computing devices (for most faculty, our desktop computer). While currently primary devices are purchased and provided by the University, alternative models such as reimbursement or stipends for equipment and software purchases could be discussed.

Secondly, in order to protect institutional data, the draft proposes a three-tiered mobile device management (MDM) system:

  • Mandatory: This tier applies to all University issued devices and requires an enrollment in a MDM system that enforces the implementation of technical controls on the device, such as lock code, lock when idle, remote wipe capabilities, device encryption, and potentially even location tracking for locating a lost device.
  • Optional: This tier applies to all non-­‐corporate owned staff, faculty, and affiliate devices connecting to University systems, including email. Enrollment in the MDM solution is optional but the expectations of minimal technical controls and the requirement to notify PIR of a lost/stolen device are defined in institutional policy. Employees must agree to allow the University to wipe the device when it is lost/stolen or the employee separates from the institution.
  • Exempt: This tier applies to student devices. This tier has no requirements but offers guidance to students on how to secure their devices.

The draft proposes that a remote wipe could be partial rather than complete, “removing only corporate data.”

Kristen raised concerns about the Optional tier, which would apply to many faculty-owned mobile devices. Firstly, the exact definition of “corporate data” may need to be clarified. According to Appendix VIII (“Copyright”) of the Faculty Handbook, in most (but not all) circumstances, faculty retain copyright over works created as part of their normal teaching, research, and service duties – including research data, lecture notes, videos of lectures, syllabi, etc.  Kristen will look into existing University policies and documents to better understand what types of records (email?) would fall under this policy. Kristen also raised concerns about references to wiping data (including email) upon “employee separation,” which for faculty may take different forms (emeritus, phased retirement, terminal sabbatical, etc).

The BYOD Strategy Group will be compiling feedback into the next draft of the report. Kristen will write up summarized feedback from TAG’s discussion as a formal response to the draft document.

2. Brief Updates 

(The BYOD discussion took up most of the meeting, so updates were rushed.)

Identity Finder automated scans (Kristen)

Kristen has been working with Adam Edwards and Scott Finlon in Information Security to answer faculty questions about Identity Finder automated scans. Kristen has updated the Identity Finder FAQ with clarifications from Information Security.  There are still some faculty concerns about the scanning and reporting process (which was approved by the President’s cabinet back in June 2013); however, we have addressed as many as possible.

Information Security would like to begin the automated scans. TAG members present at the meeting felt ready to move forward with scanning faculty machines. Dave will report at this Friday’s Senate meetings that scans will begin. Kristen will work with Adam to coordinate a schedule and an all-faculty email notification.

Test Scanning Services (Jim)

Jim reported that IR will be changing the hours of Test Scanning Services effective Monday, May 12, 2014.  The service will continue to be provided from Alumni Memorial Hall, Room 001. Tests may be dropped off and results picked up Monday through Friday, from 8:30 am to 4:30 pm.  Based upon demand and operational requirements, immediate service while you wait may not be available.  IR will continue to strive to meet the needs of our customers and will provide a 24 hour turnaround of test scanning results.  Jim asked that faculty please plan accordingly as we approach the end of the Spring term.  Jim will contact regular users of the test scanning service with more details.

Desire2Learn (Eugeniu)

Additional Desire2Learn workshops are being planned for the summer – see CTLE’s workshop calendar for the updated schedule. Eugeniu also reminded TAG members that faculty should back up any student data (including grades, discussion forms, and dropbox submissions) in Angel that they wish to keep. Step by step instructions have been emailed out, but CTLE staff will also hold workshops on this during Senior Week for anyone who needs assistance (see ). Student access to Angel will be turned off as of May 30, but faculty will have access until July 31. After that, data stored in Angel will no longer be available.

PR Department/Program Website Initiative (Dave/Teresa)

We ran out of time for in-person updates on this project. Lori had sent Kristen updates via email. Kristen will post these notes to the TAG site in a separate update.

4. Adjournment

The meeting adjourned at 1:05pm. TAG will not meet again as a full group until Fall 2014, but projects and communication (via email) will continue during the summer.

[Updated immediately after posting with correction to Cal’s title]


Comments : Leave a Comment »
Tags: , , , , , , , , , , , , , , , , ,
Categories : Angel and Desire2Learn, Announcements, Classroom Mediation, Email, Minutes, Mobile, Network and Infrastructure, Security

Heartbleed Update from Information Security

9 04 2014

For those that have been listening to the news about Heartbleed, here’s some information from Information Security Engineer Scott Finlon:

——————————————————

A major security vulnerability named Heartbleed was disclosed Monday night. The vulnerability affects a large portion of websites on the Internet and here at the University of Scranton that use OpenSSL to encrypt webpages (pages that start with https). SSL, or secure socket layer, is a cryptographic protocol which is designed to provide communication security over the Internet.

The security issue allows the stealing of information protected by SSL by stealing the private keys that protect the confidentiality of the information. Sites affected by the security vulnerability can have login credentials stolen as well as other data that would normally be protected by an SSL connection. In addition, once an attacker has the private key for a particular website, they can use the key to decrypt traffic previously sent to the server prior to the bug being disclosed.

Since Tuesday morning, the Information Security Office has been working with Enterprise Systems and other system owners across campus to ensure that their services are securely configured to mitigate risks associated with this issue.

The web servers that maintain CAS, the primary web-based authentication method used by campus services, were not vulnerable to this issue. Other campus services that utilize OpenSSL have been updated as quickly as identified, in order to mitigate the risk associated with the vulnerability.

Although we have no evidence that any University of Scranton sites have been compromised through this exploit, we do know that this bug has existed for 2 years before there was any knowledge of this specific vulnerability. We suggest you pay close attention to all your sensitive user accounts across the Internet and contact the owners of those related services if you have any questions.

Also, watch for fraudulent email claiming to be from companies with which you do business, as criminals will undoubtedly use this issue to create targeted phishing email messages to trick people into divulging their passwords.

If you have any questions or concerns about this issue, please feel free to contact the Information Security Office at <security@scranton.edu> or by calling the Technology Support Center at 570-941-4357.

Scott Finlon, CISSP GCIA GCIH
———————————–
Information Security Engineer
The University of Scranton
email : scott.finlon@scranton.edu
phone : 570-941-6168
———————————–

Comments : Leave a Comment »
Tags: , ,
Categories : CMS and University Website, Security

Identity Finder FAQ for Faculty

25 03 2014

[Note: Significant updates made on 2014-05-13, 2014-05-07, and 2014-04-24. Updates on scheduling and encryption on 2014-07-02.]

Back in April 2013, IT Services Director Jim Franceschelli and Information Security Director Adam Edwards came to TAG with a proposal to automate Identity Finder scans on faculty desktop computers. In June 2013, the President’s Cabinet approved the use of automated scans with Identity Finder on University-owned desktops as part of an overall Information Security Data Loss Prevention program. Then-CIO Jerry DeSanto sent an email announcement about the program to all faculty and staff on June 21, 2013, projecting implementation in December 2013.

Since then, Information Security has been working with TAG to pilot test the scans and try to smooth the process as much as possible for faculty. Automated scans have already started for staff, and Information Security would like to move forward with implementation for faculty machines. Currently, automated scans are scheduled to begin on August 1, 2014. Here’s what faculty need to know:

Why is the University doing this?

  • Data security is serious business for higher ed — we have ethical, legal, and financial obligations to protect the personally identifiable information that we have collected from students, faculty, staff, human subjects, etc.
  • If your computer or external media contracts a computer virus, is lost, stolen, or broken into over the network, files containing restricted information are at risk for theft. This information can be used to steal not only your money and identity, but also the money and identities of anyone else who either shares your computer or whose restricted information you store.
  • If you store restricted information for University work, the University would be obligated under state law to notify everyone affected by the breach and could potentially be legally liable.

Does this benefit me at all?

  • Identity Finder can help you protect yourself — use it to search for sensitive, unprotected information on your computer and then take an action (Shred, Scrub, Secure, Quarantine, etc) to secure that information. (Personally, an Identity Finder scan I ran on my machine found old documents containing my SSN that I had stored unencrypted in Google Drive… not smart.)
  • If your computer gets a virus, IT Services can clean and return it to you much more quickly and easily if they have a recent Identity Finder report for your machine.

What is Identity Finder?

  • Identity Finder is security software that scans your (Windows) computer for sensitive, unsecured Personally Identifiable Information (PII) stored in unprotected files.
  • If you run a scan on your machine, Identity Finder will give you a report showing what it found and where. It then gives you options to take action – you can shred the file, scrub (redact) information, secure the file, or move it to a quarantined location. You can also ignore false positives.
  • It works by looking for patterns – for example, a nine-digit number in the pattern ###-##-#### would be picked up as a possible Social Security number. If it picks up something that looks like a Social Security number but isn’t (a false positive), you can tell it to Ignore that result.
  • Identity Finder has been installed on all University Windows machines (via KBOX) since about 2009.

What kind of sensitive/restricted information are we talking about?

  • Restricted information is any piece of information which can potentially be used to uniquely identify, contact, or locate a single person. Restricted information is generally regulated by law or contract and often used for financial, medical, or research identification. (See the Information Classification Policy for additional info.)
  • Identity Finder looks for most types of Personal Identifying Information:
    • Bank Account Numbers
    • Credit Card Numbers
    • Dates of Birth
    • Driver’s Licenses
    • Passwords
    • Passport numbers
    • Social Security Numbers
  • Identity Finder is NOT looking for:
    • Email addresses
    • Mother’s maiden name
    • Personal addresses
    • Phone numbers
    • United Kingdom National Heath Service Numbers, United Kingdom National Insurance Numbers, Canada Social Insurance Numbers, Australia Tax File Numbers
  • If you’d like to get a better understanding of what kind of information Identity Finder picks up, you can run a non-scheduled Identity Finder scan on your machine whenever you’d like.

What are automated scans? 

  • Right now, Identity Finder only scans your machine when you tell it to.
  • Information Security and IT Services plans to run weekly, automated Identity Finder scans (see the proposal for details) on all University (Windows) computers. The idea is that every Friday at noon, all University computers will automatically initiate an Identity Finder scan.

Where is Identity Finder looking? What folders/locations are scanned?

  • Automated scans include:
    • Local filesystems (like your C: drive) and local registry
    • Browsers
    • Attached devices
    • Email —  If you use a local email client (e.g. Outlook or Thunderbird), Identity Finder will scan through your mailboxes that are cached on your computer, however, if you mainly use OWA or other method through a browser, you don’t have a local cached copy, and Identity Finder won’t be able to scan it.
  • Scans do not include the R: drive or most other remote connections.
  • If you’d like to get a better understanding of what the automated scans will include, you can run a non-scheduled Identity Finder scan on your machine whenever you’d like.

What if I have sensitive/restricted/confidential information saved on my computer?  Like confidential human subject research data or client files?

  • ANY sensitive/restricted/confidential information that you are storing ANYWHERE should be encrypted! Without encryption, your data is vulnerable to attack, misuse, and all sorts of other bad things.
  • Information Security recommends using TrueCrypt (which is free and open source) to encrypt your data. Scott Finlon in Information Security wrote up some brief  instructions (PDF) for encrypting a folder of files using TrueCrypt. Update 2014-07-02: Support for TrueCrypt was discontinued in 2014-05, so Information Security now recommends using 7Zip – see instructions (.docx).
  • Information Security has been in ongoing conversations with the IRB about ensuring confidentiality of human subject research data and client files. Members of the IRB had expressed concerns that Identity Finder scans would violate the confidentiality of human subject data. The good news is that data encryption resolves this concern — encryption protects sensitive data from Identity Finder scans as well as from external malicious attacks.
  • Please contact Information Security if you have any questions about protecting confidential data.

How long do the scans take? Will this affect my computer or my work?

  • Identity Finder scans can take several hours if you have a large number of documents.
  • Thankfully, Identity Finder uses a search history to keep track of what files do and do not have matches. Because of this, the initial scan is much slower than subsequent scans, as it has to scan your entire hard drive. Each subsequent scan will only look at new files, changed files, and files that previously reported matches.
  • TAG members have been piloting automated scans since September 19, 2013. We ran our own scans first, and these often took quite a while. After the initial scan, however, subsequent automated scans have been speedy. So far, none of us have experienced any performance issues – the scans are essentially invisible to the user.

My computer went to sleep during the scan. What happens now? Can Identity Finder wake my computer up to scan?

  • Identity Finder scheduled scans are set locally, so they will only be invoked while the computer is on and running — they can’t wake up your computer.

What if I’m not on campus on Fridays and my desktop machine is turned off? What if I’m not on campus on Fridays but am using my laptop? 

  • Automated scans are currently scheduled in batch for Fridays at noon. They will run as long as your computer is turned on – whether or not you’re on campus (or on the University network).
  • If you are offline, the scan will run as scheduled. The report will be sent to Information Security once you reconnect to a network.
  • If your computer is turned off at 12pm on Friday (that is, if the scheduled scan is missed), it will begin with a randomized start time between 30 minutes and 120 minutes after the computer is back up and running.

What happens after the scan is done?

  • When the scan is done, Information Security will get a report from Identity Finder indicating the level of risk for that machine. The report includes the number of hits, but NOT the actual information that was marked as potentially sensitive – that is redacted. The reports show only a masked version of a potentially problematic file and the location where it was found. Reports are only viewable by the Information Security Director (Adam Edwards) and the Information Security Engineer (Scott Finlon).
  • Based off of these reports, Information Security then works one-on-one with users, recommending that users delete the files (if they’re no longer needed) or move them to a more secure, encrypted location. (Adam said that he is working with staff with the most risk first — e.g., people with 1,000 hits or more.)

What if I have a Mac or Linux machine? 

  • Automated Identity Finder scans will only run on Windows machines.

When is this happening?

  • Automated scans are scheduled to begin on University-provided faculty desktop machines on August 1, 2014. (Information Security Officer Adam Edwards sent out a notification to all faculty on May 28, 2014 and a reminder on June 30, 2014).
  • Automated Identity Finder scans are already running on staff machines (and on TAG members’ machines).

What should I do to prepare?

Questions or concerns?

 


Comments : Leave a Comment »
Tags: , , , , ,
Categories : Announcements, Security

Encryption with TrueCrypt

8 03 2014

Update 2014-07-02: Support for TrueCrypt has been discontinued! Information Security recommends using 7Zip instead – see instructions (.docx).

——————————————————————————-

At our last TAG meeting, Adam Edwards and Scott Finlon from Information Security demonstrated automated Identity Finder scans as well as encrypting files with TrueCrypt (which is free and open source :). At our next TAG meeting, we’ll be starting to identify which departments can move forward with automated scans — so as a reminder, you’ll all want to make sure that any confidential or sensitive information stored on your desktop is safely encrypted.

Scott has sent along some brief  instructions (PDF) for encrypting a folder of files using TrueCrypt — the first page is set up and the second is everyday usage.  Please contact Information Security if you have any questions about encryption.

You can also run your own Identity Finder scan in the meantime – see IR’s Quick Guide if you need help getting started.

Many thanks to Adam and Scott for their guidance on this issue!

 


Comments : Leave a Comment »
Tags: , , , , ,
Categories : Announcements, Security, Technology Training, Tutorials

Adobe Breach – Info for Users

18 11 2013

TAG got a question from a faculty member about the recent Adobe data breach and whether or not it affects campus users. Scott Finlon in Information Security shared a REN-ISAC alert that addresses higher ed implications and recommended that if anyone used the same email address and password on Adobe’s site as any other site, they should change their password immediately.

Quick take-home from the REN-ISAC alert:

“If the same password used for Adobe System accounts was used for work, school, banking, or other accounts, those accounts may be at risk. Repercussions could range from simple to severe, such as account hijacks to send spam, theft of bank deposits, or hackers gaining a foothold in a place of employment to conduct widespread damaging attacks.”

Full alert:

November 12, 2013

ALERT: Threat to computer accounts due to Adobe security breach

BACKGROUND: In October 2013, Adobe suffered a data breach. Their database of 38 million usernames and passwords was stolen and subsequently posted online [1][2]. Adobe did not protect user passwords to industry standards, and attackers were able to exploit that. Also stored with the passwords were the users’ password hints in clear text. Many of the hints are weak and easily exploited by third parties. Security experts agree that it will be trivial for miscreants to discover the passwords.

Of the estimated 38 million Adobe customers affected, analysis indicates that there were over 2 million education-related accounts. We don’t know how many of the email addresses are attached to active institutional accounts.

Adobe reached out to individual affected users via email. The notification thoughtfully included “[we] recommend that you also change your password on any website where you use the same user ID or password”. However, there are reports of non-delivery (it might have been filtered as spam) and users disregarding the e-mail (it might have been thought to be a phishing message).

IMPACT: If the same password used for Adobe System accounts was used for work, school, banking, or other accounts, those accounts may be at risk. Repercussions could range from simple to severe, such as account hijacks to send spam, theft of bank deposits, or hackers gaining a foothold in a place of employment to conduct widespread damaging attacks.

RECOMMENDATIONS: We recommend that you take the following actions:

1. CHANGE PASSWORDS IMMEDIATELY. Persons who used the same password for Adobe and other accounts should immediately change their passwords at the other locations and monitor for unusual activity.

2. ADOBE PASSWORDS SHOULD BE RESET only by manually visiting the Adobe website, and not by clicking on links arriving via email, as there is now a concern that there will be a rise in phishing related to this event.

3. NEVER REUSE YOUR INSTITUTIONAL PASSWORD for external web sites or Internet services. If you reuse a password at multiple locations when the password is compromised at one site the miscreants then can gain access to all sites where you’ve used that password. The best policy is to always use different passwords for different accounts.

4. CREATE STRONG PASSWORDS OR PASSPHRASES [3]. The Wikipedia Guidelines for Strong Passwords [4] is a good starting point.

5. CONSIDER THE USE OF A PASSWORD “WALLET” such as KeePass and LastPass. These tools make it very easy to have a unique password for every web site or service, and to have strong passwords.

6. BE ON THE LOOKOUT FOR PHISHING. Miscreants will be using the Adobe breach as a pretext for phishing.

7. USE INFORMATION THAT IS NOT EASILY GUESSED. When providing password hints use information that is not easily guessed or discovered. For example, if your hint is “dog’s name” and you mention your dog on social networking sites miscreants can discover that information.

REFERENCES:

[1] http://helpx.adobe.com/x-productkb/policy-pricing/ecc.html

[2] http://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/

[3] http://xkcd.com/936/

[4]


Comments : Leave a Comment »
Tags: ,
Categories : Announcements, Security

TAG Meeting Notes – 2013-09-04

5 09 2013

TAG Meeting September 4, 2013 2:00pm-2:50pm

Attendees:

Jeremy Brees, Tim Cannon, Paul Cutrufello, Kim Daniloski, Dave Dzurec, Tara Fay, Jim Franceschelli, Eugeniu Grigorescu, Andrew LaZella, Sandy Pesavento, Kristen Yarmey

1. Introductions

We introduced two new TAG members for this year: Dr. Andrew LaZella (Philosophy, CAS) and Jeremy Brees (Management and Marketing, KSOM). We’re still hoping to recruit an additional faculty representative from PCPS – please let us know if you have any suggestions!

2. Brief Reports

LMS Group (Tara)

The Learning Management System Working Group recommended at the end of Spring 2013 that we switch from Angel to Desire2Learn (see full report for details). TAG members Tara Fay (Biology), Sandy Pesavento (Education), and Teresa Conte (Nursing) all served on the LMS Group, along with fellow faculty members Maureen Carroll (Math) and Julie Nastasi (OT).

The University has since signed on with Desire2Learn. As VP for Planning and CIO Jerry DeSanto announced in July, Desire2Learn will be available for use in Spring 2014, and Angel will be available until June 1, 2014 (so D2L and Angel will run in parallel in Spring 2014).

Staff members in CTLE and ITDA have been working on an implementation plan. We’ve been asked not to share details yet, since the plan hasn’t been finalized, but the LMS Group will be presenting their plans to the Faculty Senate and Deans Conference in the very near future. We’ll post a conversion schedule here when there’s more information available.

Eugeniu noted that CTLE plans to do some pilot course conversions with several faculty members early on in the process – particularly faculty members whose Angel courses have a lot of specialized content.  (Tara has already volunteered to be one of the pilot participants.) There will be trainings and demonstrations available for faculty.  Let TAG know if you have questions or requests related to the LMS transition and we’ll pass them along to CTLE and ITDA.

Website Proposal Group (Dave)

Dave, Jeremy S., Kristen, and Katie met with Hal Baillie, Jerry DeSanto, Gerry Zaboski, and Vince Carilli in May to discuss the Website Maintenance Proposal that members of TAG drafted last year as a solution for the complex issue of maintaining and updating departmental websites. All parties generally agreed that maintaining departmental websites is a serious issue affecting recruitment of students and faculty, but unfortunately a new position (full time or part time) is not an option. TAG will table this issue unless we come up with other options to explore.

On a related note, during the switch to the new responsive design for the University website this summer, some departments were prepared for the conversion and had sized images uploaded in time, but others did not.

Acceptable Use Policy (Dave)

The Acceptable Use Policy drafts are moving forward and will go to the University Governance Council and the Faculty and Staff Senates this semester.

Identity Finder (Kristen)

At our April 2013 meeting, IT Services Director Jim Franceschelli and Information Security Director Adam Edwards brought a proposal for Identity Finder Automated Scans to TAG for faculty feedback. TAG shared two main concerns from faculty:

1) Decreased performance of computers during Identity Finder Scans — Adam had explained that the automated scans would be implemented with IT staff members first, so that he’d be able to smooth out the process before implementing with faculty. Jim noted that the staff rollout had gone smoothly and IT Services had not received any complaints about decreased performance. The *first* Identity Finder scan tends to take the longest, but subsequent scans are quick.

2) IRB data – concerns that Identity Finder scans of machines storing human research subject data or client files would breach subject confidentiality. We were working over the summer on preparing recommendations for faculty members who store IRB data on how to encrypt and password protect their data folders, such that the data would be protected from Identity Finder scans but (perhaps more importantly) also from external malicious attacks. Kristen will check in with Adam to find out the status of the recommendations.

All TAG members in attendance volunteered to serve as pilot participants for faculty implementation of Identity Finder prior to full rollout.

Jim recommended that faculty members run their own Identity Finders scans ASAP due to the increase in malicious attacks on campus computers — IT Services can clean and return faculty desktops much more quickly if a recent Identity Finder scan has confirmed the absence of confidential or sensitive data.

Information Resources Advisory Council (Kristen)

IRAC will meet twice this academic year, in October and March. TAG normally sends two faculty representatives to IRAC meetings. Paul Cutrufello volunteered to continue serving on IRAC this year. Andrew LaZella volunteered to serve as the second representative depending on the schedule for IRAC meetings. Kristen will contact Robyn Dickinson for IRAC meeting dates.

3. Items for Discussion

University Website Changes (Kristen)

During the summer, there were several major changes to the University’s web presence. Kristen opened the floor for feedback or comments on these transitions:

  • Academic server (academic.scranton.edu) decommissioning — Kristen worked with Adam Edwards in Information Security to reach out to faculty members who still had content on academic. CTLE offered support for faculty who needed help moving their content, generally recommending that faculty members use existing templates in the University’s content management system (CMS). While the transition seemed to go smoothly, there is still a need for a place or host for faculty and student web development. At least one faculty member had needs that could not be fulfilled in the CMS.
  • Responsive redesign of www.scranton.edu — There are several reports of templates not quite making a smooth transition – e.g., Faculty/Staff pages like the History Department’s, dropdown links on the Provost’s website, etc.
  • m.scranton.edu takedown — The Library had issues with this, but TAG members hadn’t heard any other concerns. [Update 2014-02-12: Lori Nidoh in PR clarified that m.scranton.edu had not been taken down. Instead, automatic redirects had been implemented.]
  • my.scranton.edu (Luminis) upgrade — TAG members reported several ways in which the new interface unintuitive. Student schedules are difficult (for students) to find, as are the Faculty/Staff directory, class rosters, and course evaluations. However, TAG members agreed that by now most people have figured out where links are, so we don’t want to request changes to the Faculty Tab at this point.

WordPress (Kristen)

The University set up a local WordPress network in late 2011. It now hosts admissions blogs, the Library blog, and the History Department blog. IR staff members had indicated that they were working on developing guidelines for how the WordPress network could be used and creating a process through which sites on the network could be requested.

In the meantime, several faculty members have requested WordPress sites for other uses – internal collaboration, classroom use, etc.  To date, while internal collaboration requests have been accommodated, IR has denied requests for classroom use. Jim explained that IR is working on determining what level of support they can provide. For example, while supporting one faculty member’s WordPress site would not be time intensive, supporting 30-40 classroom sites would be an issue — whose job does this become? There are also other issues IR wants to consider before providing class-based WordPress support – e.g., archiving student work, providing access and security, etc.  IR’s preference would be to provide support for classroom blogs via Desire2Learn once we convert over from Angel. Kristen asked Eugeniu if one of the D2L faculty pilots could include a blogging feature so that faculty members can see what blogging features are or aren’t available in D2L.

IR staff members are meeting to discuss the WordPress service in a few weeks. Kristen asked if faculty members can participate in this conversation, and Jim said that he will let TAG know when faculty input is needed. TAG will expect to see drafted language on service levels for WordPress at our November meeting, in the hopes that the service may be available for use in Spring 2014.

TAG Senate Status (Dave)

Dave (as TAG’s Faculty Senate liaison) reported that Senate president Rebecca Mikesell would like to propose that TAG become a full Senate Committee, (possibly called the Technology Advisory Committee). The membership criteria would be the same as we discussed last year for TAG as a subcommittee of the Academic Support committee — that is, flexible membership aiming for representation from CAS, PCPS, KSOM, and the Library, with at least one faculty Senator, who will serve as TAG’s liaison to the Senate. Dave noted that if TAG is a full Senate committee, TAG’s Senate liaison will serve on the Senate Executive committee.

TAG members had no objections to the proposal, which will likely be brought up for a vote at the September 13 Senate meeting.

4. New Business

Jim gave us some quick updates on changes that will affect or interest faculty:

  • Desktop computer logins — by the end of 2013, logins for desktop computers will change to the user’s R number and my.scranton password – so users will not have to remember a separate desktop password. This is part of the continued implementation of Active Directory authentication.
  • Google Chrome browser — IR will begin providing Google Chrome to University computers via KBOX. There are still some details to be worked out on this – Jim will let us know when it will happen and what will happen for users who already have Chrome installed.
  • Office 365 — We converted to Office 365 from Live@Edu over the summer. We’ve already benefited from increased email storage space and access to “lite” cloud versions of Office software. We will see a few new features later this fall, including Lync instant messaging and SharePoint collaboration software.

Kristen and Dave will meet with Jerry DeSanto, Robyn Dickinson, Lorraine Mancuso, and Jim on September 25 for a full “road map” discussion of what’s coming this year from IR for faculty.

The meeting adjourned at 2:50pm – TAG will reconvene on Wednesday, October 2 at 2:00pm in LSC591 (CTLE Conference Room).


Comments : Leave a Comment »
Tags: , , , , , , , , , , , , , , , , , , , , , ,
Categories : Angel and Desire2Learn, Announcements, CMS and University Website, Minutes, Website Proposal

Reminder: Academic Server non-public as of June 15

5 06 2013

Just a reminder that the academic server (academic.scranton.edu) will not be accessible from off-campus beginning June 15, in preparation for the long-awaited decommissioning, scheduled for August.

TAG and IR have sent out multiple email reminders to all faculty members who still have accounts or folders on the server, and the CTLE TechCons have been busy helping several faculty members move their web content to the CMS before the decommissioning. If you haven’t talked with any of us yet and need assistance moving content off of academic, please let TAG know ASAP!

Many thanks to Adam Edwards, Scott Finlon, Connie Wisdo, John Culkin, and Robyn Dickinson in IR and Aileen McHale and the TechCons in the CTLE for all the assistance and coordination!


Comments : Leave a Comment »
Tags: , ,
Categories : Announcements, CMS and University Website

Identity Finder and confidential data

14 04 2013

At our last TAG meeting, IT Services Director Jim Franceschelli and Information Security Director Adam Edwards invited faculty feedback on their Identity Finder Proposal on Automated Scans. For those just joining us, Identity Finder software scans your (Windows) computer for sensitive, unsecured Personally Identifiable Information (PII). The Information Security Office and IT Client Services are jointly proposing implementation of weekly, automated, required Identity Finder scans (see the proposal for details). During the meeting, TAG members shared some concerns about scheduling and performance effects. After the meeting, we received additional concerns from Bryan Burnham (Psychology), a member of the Institutional Review Board, that Identity Finder scans of machines storing human research subject data or client files (from a counseling practice, for example) would breach subject confidentiality. Concerns are paraphrased here:

There are privacy issues related to data collected on human research subjects that must be considered before automated Identity Finder scans of machines can occur. Specifically, we (IRBs, DRBs, PIs – primary investigators) ensure complete and total privacy of our human research subjects’ data, especially sensitive information (names, emails, Royal IDs, social security numbers), some of which is undoubtedly stored on computer hard drives. [The same is true for client files maintained by counselors or clinicians.]

“Subject confidentiality” means that knowledge of a person’s participation in a research study is between the human subject and only the PI. That is, a subject is guaranteed by the PI that knowledge of their participation as well as their personal and sensitive data will not be open or available to any third party – meaning anyone not associated with the research project. The automated Identity Finder scans would, in effect, view confidential human research subject data and client information that, by definition, cannot be viewed by others.

It should be noted that the Identity Finder reports that the Information Security office receives are redacted, showing a masked version of a potentially problematic file and the location where it was found, and are only accessible to the Information Security Director (Adam) and the Information Security Engineer (Scott Finlon). However, Bryan noted that the scan itself is the issue: third parties (including other University divisions/employees and University-owned software) are not allowed to access or see confidential subject information.

Bryan, Jeremy, Kristen, Adam, and Scott got together on Friday to get a better understanding of this issue and what options there might be for general campus implementation of automated Identity Finder scans without violating subject confidentiality.

We discussed a few options that IR and TAG  could consider for Identity Finder, each with varying advantages/disadvantages. A significant complication, however, is that at this point we don’t know how many researchers on campus have this kind of data, where it’s stored (faculty, staff, student, and/or lab machines? cloud storage?), and whether it’s encrypted or otherwise protected against security breaches (malicious or inadvertent). Bryan stressed that researchers are responsible for their own data and for ensuring subject confidentiality, and neither the IRB nor the University can impose or require specific data management practices, at least under current IRB policies.

Scott noted that the Identity Finder question is only the top layer of broader issues of privacy, security, and digital records management on campus, and that research data stored on a researcher’s hard drive or in cloud storage could be vulnerable to external attack. Both Adam and Scott mentioned that Identity Finder, used appropriately, could help researchers protect subject confidentiality by locating vulnerable information and prompting the researcher to take further steps towards securing it. We agreed, though, that educating researchers about data security and encouraging more secure data management practices (encryption, password protection, etc) will be a longer, more involved, and more inclusive conversation – but a conversation that needs to happen nonetheless.

Next steps: Bryan will bring this discussion to the IRB at their April 16th meeting for additional input and will share any relevant guidelines from grant agencies (e.g., Department of Health & Human Services), and his and others’ own digital data management practices. Adam and Scott will reach out to Identity Finder and other university security offices re: how others have handled this issue. They are willing to continue discussing accommodations for researchers storing sensitive data, if we can find all of them or somehow get them to self-identify. TAG might be able to help survey the faculty on this question (yes/no/unsure) – multiple outlets should be used to try to catch everyone’s attention. The IRB, ORSP, and TAG may want to coordinate a faculty forum on this topic.

We’re still early on in this discussion, so please contact TAG if you have any insight, concerns, or questions that we might not have considered yet.

 


Comments : Leave a Comment »
Tags: , , , , ,
Categories : Announcements, Network and Infrastructure, Security

« Previous Entries