Members Attending: Ed Anapol, Mike Baptiste, Landen Bain, Pakis Bessias, John Board, Wayne Miller (for Dick Danner), David Ferriero, Nevin Fouts, Tracy Futhey, Ed Gomes, Alan Halachmi, Peter Harrell (for Patrick Halpin), Alfred Trozzo (for Paul Harrod) Billy Herndon, Bob Newlin (for David Jamieson-Drake), Ken Knoerr, Andrew Keck (for Roger Loyd), Kyle Johnson (for Caroline Nisbet),George Oberlander, Mike Pickett, Rafael Rodriguez, Mike Russell, Jeffrey Taekmann, Clare Tufts, Fred Westbrook, Robert Wolpert, Stephen Woody

Guests: Rob Carter, Paul Conway, Chris Cramer, Debbie DeYulia, David Jarmul, Rob Little, Chris Meyer

Call to Order: Meeting called to order 4:05 PM

Review of Minutes and Announcements:

  • Nominations have been made for the video services subcommittee group, there are 10 people in the large group, and 4 people on the steering committee.
  • SISS Registration: Privacy Issue for Registering Seniors: Upcoming seniors who attempted to log into ACES from 7:00 to 7:20 found themselves logged in as other users. It appears there was no malicious behavior, but that some part of the web support or authentication portions of the system experienced problems due to excessive load. About 8 people reported this problem to the help desk. Around Noon, the Chronicle called Mike Pickett, and communicated that they believed that actually 30% of the people had logged in as another person during the period of heavy load.

    Testing has been taking place around the clock, but the whole system cannot be tested from end-to-end until registration is over. They are testing what they can, but need to wait to do real testing with simulated load once registration is over to avoid impacting the registration process. A letter is being sent out to notify the people whose privacy may have been affected. Although there is no indication that password privacy was breached, the letter also asks them to change their passwords.

NetID password cracking update and password strength proposals

Chris Cramer

Chris spoke 2 weeks ago and came back with options for a password strength policy. There are 3 options.

Option 1: (Traditional password policy)

Make use of the Kerberos built-in support for password strength checking mechanisms. The following policy would likely meet the Internal Audit guidelines for good password policies:

  • Maximum Password Lifetime: 180 days
  • Minimum Password Lifetime: 10 days
  • Password History: 3 previous passwords
  • Minimum Password Length: 7 characters
  • Minimum Character Classes: 3
  • Current passwords would be expired over a period of time

Pros:

  • Very easy to implement technically
  • Policy would be likely to be enforced by all Kerberos clients
  • Expiring the current passwords over a period of time should reduce the load on the Help Desk
  • Easy to defend to auditors (internal and external)

Cons:

  • Does not necessarily create strong passwords (e.g. "Cramer!" would be acceptable to the above policy)
  • Frequent password changing may encourage poor password management (writing it down, etc)
  • Keeping a Password History may require additional hardware for the Kerberos servers (master KDC)

Option 2: (recommended)

Make use of some of the internal support that Kerberos has for password management while enforcing better strength checking in the password changing clients we control (e.g. passwd script, web-based password changer, etc.)

  • Maximum Password Lifetime: 1 year
  • Minimum Password Length: 7 characters
  • Modify the password changing scripts that we control to include the password strength checks made by crack
  • Run "crack" on a monthly basis, contact users with weak passwords recommending (then requiring) password changes
  • Current passwords would be expired over a period of time

Pros:

  • The bulk of clients used to change passwords would not allow weak passwords and could provide information to the user on why it was a weak password
  • Yearly password changes would help defend against passwords being compromised by shoulder surfers or accidental use in an unencrypted manner
  • Yearly password changes would allow passwords to be used long enough to encourage good password management
  • Periodic runs of crack would protect against weak passwords chosen on clients we do not control
  • Expiring the current passwords over a period of time should reduce the load on the Help Desk

Cons:

  • Modifying the password changing clients will take time, so this option may not be implemented as quickly
  • May require education with auditors as well as the planned user education.

Option 3:

Make use of some of the internal support that Kerberos has for password management without necessarily changing clients

*Maximum Password Lifetime: 1 year *Run "crack" periodically, recommending (then requiring) passwords changes on accounts failed *Current passwords would be expired over a period of time

Pros:

  • No changes are required in any applications
  • Yearly password changes would help defend against passwords being compromised by shoulder surfing or accidental use in an unencrypted manner
  • Yearly password changes would allow passwords to be used long enough to encourage good password management
  • Periodic runs of crack (monthly, perhaps sooner for recently-changed pwds and new accounts) would limit exposure due to weak passwords
  • Expiring the current passwords over a period of time should reduce the load on the Help Desk
  • Provides better password protection than Option 1

Cons:

  • May require education with auditors as well as the planned user education. Option 3:

George Oberlander: Can we mix up the options?
Chris Cramer: We could start with Option 3 as soon as the education piece is ready Motion to start with Option 3, password history with 1 year, goal of moving to Option 2 ITAC approves - Chris will move forth on it.

Clinical use of IT in the Health System

  • Departmental Clinical IS systems
  • Clinical Documentation
  • Browser Enhancements
  • PIN Outpatient
  • PDA Initiatives
  • Physician Order Entry
  • DOC - Inbox, MedQuest
  • MDEverywhere
  • Dr. Mike Russell - Dr. Russell presented a powerpoint presentation on Clinical Informatics what

    Major Topics:

  • Clinical Content Object Workgroup (CCOW) - there are a lot of applications running on the desktops and nurses, etc have to login to them all, once they login to them all, the patient's information is linked to all the applications
     
  • A key issue in clinical systems is making the authentication and startup time very short. If it drags too long, it won't be used or security issues may arise.
     
  • Emergency Dept IS - Clinical workflow and documentation, assists with workflow to assist with emergency cases
     
  • Philips TraceVue - for pregnancy, a lot of times a mother starts out at one clinic or hospital and ends up delivering at another, this keeps track of all the information
     
  • Peri-Ops Notes - Used for scheduling, inventory management in the operating rooms
     
  • CareVue - Intensive care units, nurses can document vital signs
     
  • Eye Center- looking into solutions for images that the eye center is required to do
     
  • PACS - signed a contract with GE, X-Rays are digitized
     
  • Deployment of PCs- started in clinics, not centrally funded before, transferred how doctors took care of patients. Somewhere around 500-700 IBM All-In-One workstations were deployed. They solved an ergonomic problem as well. No renovations were needed.
     
  • CCWS- PIN stations, get information quickly The goal is to convert the use of paper charts to electronic documents. Not only is paper difficult to track down, it is difficult to search through to find pertinent information. PCs in the clinics decreased paper cost 85% Trying to centralize questions that are asked over and over
     
  • Palm/Pocket OS - find mechanism for centrally managing, put the browser on the Pocket PC, there is a need for a lot of PDA infrastructure planning.
     
  • HIPPA and security is a large project - passwords,audit trails, etc.

Web/Content Management Systems

Tracy Futhey

Tracy described a proposal for a charter for subcommittee to come together and come up with one Content Management System.

It is important that this is done with speed. The subcommittee will be kept small. The group will look at what we need in a CMS tool and report back to ITAC in a few weeks. Give names of people for the committee to Rob Little, at rob.little@duke.edu(link sends e-mail)

The goal is to send a clear signal that OIT wants to move together toward a common tool. It is a stake in the ground.

ITAC Web Content Management System Evaluation Subcommittee

Purpose: The success of Duke's Web activities depends increasingly on better approaches for managing content. Several groups across Duke have begun exploring ways of meeting this need with content-management systems. There is considerable interest among them and others in implementing joint systems that might enable the Duke community to share content more widely, thereby serving audiences more effectively and leveraging available expertise and resources. The subcommittee's charge is to identify the user and system requirements for such a Duke CMS systems, evaluate prospective CMS product vendors, and make recommendations for implementation.

Timeline and Desired Outcomes:

  • April 4 - Futhey and Jarmul present CMS subcommittee proposal to ITAC Subcommittee meets to begin identifying CMS user and system requirements, including meeting with stakeholders and interested individuals from ITAC and other parts of campus. It drafts a document and seeks feedback from ITAC (Time requirements for members: 4-5 hours)
  • April 18 - Subcommittee incorporates ITAC feedback and establishes selection criteria for the CMS vendor and product. Subcommittee begins to evaluate possible CMS software, focusing initially on benchmarking against other university installations (Time requirements: 3-5 hours, mainly for benchmarking)
  • May 2 - Subcommittee incorporates benchmarking feedback and aggressively begins to evaluate candidate CMS software. (Time requirements: 3-8 hours, mainly for product evaluation and vendor presentations, with time requirements varying by subcommittee member.)
  • May 16 - Subcommittee continues to update ITAC and evaluate CMS software, including selected testing systems and following up in greater detail with the most promising vendor(s). (Time requirements 2 - 10 hours, mainly for testing and electronic document review and varying greatly for those with differing levels of personal interest in the eventual CMS toolset)
  • May 30 - Subcommittee presents to ITAC its proposed recommendation May 31 - Subcommittee officially submits CMS recommendations to Futhey/Jarmul

Subcommittee Core Team:

Facilitator: Rob Little
DCRI Rep to be named
Medical Center Rep to be named
Ginny Cake
Rob Carter
Paul Conway
Randy Haskin
Robert Wolpert

The following people would be asked to assist the subcommittee core team, as needed:

Melissa Mills,
Tom Dominick,
Susan Siemko,
Wayne Miller,
Ken Hirsh,
Nick Drury,
Jim Coble,
John Little,
Jeffrey Taekman,
Fred Westbrook,
Dennis Meredith,
Mike PIckett,
Billy Herndon,
Jocelyn Bailey,
Chris Meyer,
Kyle Johnson,
Engineering rep.

Net ID and ACPUB account purging process

Rob Carter

There are too many old accounts, and some need to be removed. This will be done in a phased approach:

Phase 1: 11,000-12,000 accounts to be deleted, there are records of the owners having left and no record of them being at Duke anymore.

Phase 2: 10,000 accounts that don't appear to be here now but there is no evidence that they are gone. The account holders will be notified before accounts are deleted.

In 6-8 weeks the process will be completed

Discussion included that account information should be archived for 1 year. Students are given a one year extension

Kyle Johnson asked about alumni keeping their Kerberos principle in order to authenticate to services, Rob Carter said that they are working with alumni department and talking about this