Issuu on Google+

Contextual Inquiry and Project Management Client:ITSS University Of Michigan Janani B.S Jeremy Canfield Kate Donavan Rebecca McNitt Susan Solo


Hi5: Kate Donovan, Janani Sundar, Susan Solo, Becky McNitt, Jeremy Canfield

Communication Covenant

Hi5 Communication Covenant Communication Plan Team Hi5 has drafted this “Communication Covenant” to serve as a guide for establishing team expectations, agreeing upon guidelines for communications and team meetings, determining how information will be shared among group members, and allocating group work. Hi5 has decided to use Google Groups as a repository for all materials related to the group project for SI 501. The group site, HighFive501 will include group notes, documents, assignments, and group member contact information. Team Roles Susan Solo Project Manager (aka the Whip) Susan will keep draft agendas for team meetings and generally ensure that the group stays on schedule and makes timely progress in completing assignments and meeting project deadlines. Rebecca McNitt Project Secretary (aka the Pen) Becky will record notes from discussion section (as they pertain to group work), group meetings, and brainstorming sessions, as well as serving as the scribe for the initial client meeting. Becky will ensure that the team’s calendar is regularly updated, as appropriate, with meeting dates, scheduled interviews, and project deadlines. Kate Donovan Faculty Liaison and Editor Kate will serve as the group’s liaison to Professor Faniel and GSI Nikhil Sharma. Kate also agrees to serve as Editor and incorporate all group members’ work into a single written document (as per the assignment). However, given that Kate is less adept at creating visuals (such as flow charts and PowerPoint presentations), other group members will assist in that process. Kate will also post completed group assignments to CTools. Jeremy Canfield Client Contact Jeremy graciously agreed to serve as our Client Contact. He will be responsible for coordinating client meetings, communicating with the client contact, and assisting in wrangling all of our schedules together. Janani Sundar Project Coordinator Janani will facilitate in assigning group work and ensuring that all group members are participating equally. She will also ensure that all components of a given assignment are addressed and completed. Communication Agreements Calendar and Documents: The group agrees to use the calendar and documents features in Google Groups to post documents and calendar items.

1


Hi5: Kate Donovan, Janani Sundar, Susan Solo, Becky McNitt, Jeremy Canfield

Communication Covenant

Meeting Schedule: The group has a standing meeting on Monday evenings from 7:00 to 9:00 (we’re on Michigan time!) and agrees to have a second weekly meeting on Thursday evenings after discussion section as needed. Unless the group agrees otherwise, group meetings will take place at the Shapiro Undergraduate Library. Meeting Expectations: All members are expected to attend group meetings. If a group member cannot attend s/he is expected to contact another group member and relay any relevant materials needed for that meeting. Communication: The group will use email as the primary means of communication and each member is expected to check email at least once a day and to reply to emails within 24 hours. If a more urgent response is needed, group members may call each other. The group agrees not to call each other after 9:30 pm. The Google Groups page may also be used to communicate with all group members. Completions of Tasks and Assignments: Missed Assignments: If a team member realizes that s/he will not be able to complete an assigned task that person will notify other group members 48 hours prior to the assignment deadline, and provide alternate suggestions for the completion of the task. Emergency situations will be handled on a case-by-case basis. Penalties for Missed Assignments: The first time a team member fails to complete an assigned task there will be no official penalty. If a person fails to complete a task a second (or subsequent) time, that person will be required to send the GSI an email, copied to the other group members, taking responsibility for the missed deadline, and explaining why it occurred. If a group member repeatedly misses deadlines than the group will consider more severe penalties, such as public humiliation or flogging. Interview/Meeting Minutes Process Team members will take notes during interviews and client meetings. Team members agree to type up detailed versions of meeting notes within 24 hours of interview. Team members will post a digital version of meeting notes, using Google Docs, on the HighFive501 group website within 48 hours of interview.

Team Contact Information:

2


Hi5: Kate Donovan, Janani Sundar, Susan Solo, Becky McNitt, Jeremy Canfield

Communication Covenant

Kate Donovan Email: katemd@umich.edu (preferred) or katemariedonovan@gmail.com

Phone: (319) 331-8754 Susan Solo

Email: susansolo1@gmail.com (after 3pm) or solo@grasslakeschools.com (8am-3pm) Phone: (517)522-5576 (work) 7:00 am until 3:00 pm, (517) 522-5949 (home) Jeremy Canfield

Email: cdjeremy@gmail.com Phone: (202) 306-3644 Rebecca McNitt

Email: rjmcnitt@umich.edu (preferred) or qbqrat@gmail.com Phone: (734) 771-6326 Janani Sundar

Email: sundar.janani@gmail.com Phone: (734) 272-6703

3


Hi5: Kate Donovan, Janani Sudari, Susan Solo, Becky McNitt, Jeremy Canfield

Activity

1 2 3 4 5 6 7 8 9 11

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Tasks

Project Plan

Hi5 Project Plan Estimated Start Estimated End Actual Start Actual End Responsibility Date Date Date Date

Gearing up to start our activities Agreed on a team name Created Google Group for better communication Delegated the roles for each member Created the Google calendar Prepared the draft for communication covenant Prepared the draft for Interview Protocols Schedule the group meetings Prepared the draft for introduction passage Prepared the draft for project plan Finalize and post all the documents in CTools and Google Group Client Meeting Setting up Initial Client Meeting with Maria Sheler Conduct the Initial Meeting Interpret the Initial Meeting Upload the key notes based on our meeting Confirm by phone/e-mail the interview dates Conduct Interviewing and Interpretation Sessions Evaluate and review the project based on the interviews Conduct and Note interview with the chief IT security officer Paul Howell Communicate and Interpret the interview with other members & include affinity notes, models Conduct and Note interview with one of ITSS clients - College of Engineering - Mark Giuffrida Communicate and Interpret the interview with other members & include affinity notes, models Conduct and Note interview with Jeff Tomaszewski - Data Security Analyst Communicate and Interpret the interview with other members & include affinity notes, models Conduct and Note interview with a diff client of ITSS - ISR - Bill Connett Communicate and Interpret the interview with other members & include affinity notes, models

9/6/2012 9/12/2012 9/16/2012 9/16/2012 9/12/2012 9/12/2012 9/12/2012 9/12/2012 9/16/2012

9/6/2012 9/13/2012 9/16/2012 9/16/2012 9/16/2012 9/16/2012 9/12/2012 9/17/2012 9/18/2012

9/12/2012 9/12/2012 9/16/2012 9/16/2012 9/12/2012 9/16/2012 9/12/2012 9/12/2012 9/16/2012

9/12/2012 9/13/2012 9/16/2012 9/16/2012 9/14/2012 9/17/2012 9/12/2012 9/17/2012 9/18/2012

Team Jeremy Team Team Kate Susan Team Rebecca Jeremy & Janani Team

9/17/2012

9/18/2012

9/13/2012 9/20/2012 9/20/2012 9/23/2012 9/21/2012 9/20/2012 9/20/2012 9/24/2012

9/17/2012 9/20/2012 9/23/2012 9/24/2012 9/23/2012 10/24/2012 10/8/2012 9/27/2012

9/16/2012 9/20/2012

9/17/2012 Jeremy 9/20/2012 Team Team Janani

9/27/2012

9/29/2012

Team

10/1/2012

10/3/2012

10/3/2012

10/5/2012

Jeremy & Rebecca Team

10/5/2012

10/8/2012

10/8/2012

10/10/2012

10/11/2012

10/14/2012

10/14/2012

10/16/2012

Team Team Janani & Kate

Susan & Jeremy Team Janani & Rebecca Team

4


Hi5: Kate Donovan, Janani Sudari, Susan Solo, Becky McNitt, Jeremy Canfield

Project Plan

Activity

Tasks

27

Conduct and Note interview with two different clients of ITSS - ISR - Bill Connett & School of Art & Design - Mahendra Kumar Communicate and Interpret the interview with other members & include affinity notes, models Conduct and Note interview with other staff/faculty who participate in the security information flows

10/17/2012

10/19/2012

All

10/19/2012

10/20/2012

Team

10/20/2012

10/22/2012

Communicate and Interpret the interview with other members & include affinity notes, models. Also create the Team Consolidated Model based on the interviews, notes, etc. Create Consolidated Models and Affinity Diagrams Post all the consolidated models End all the interview sessions Create Affinity Walkthrough Diagram

10/22/2012

10/23/2012

Two or Four (Based on the number of faculty available) TBA Team

10/23/2012 10/24/2012 10/28/2012

10/24/2012 10/27/2012 11/2/2012

Team Team Team

Collect all the affinity notes, diagrams, models and upload them Review all affinity notes Get materials for affinity diagramming session Prepare affinity walkthrough script for client meeting Complete affinity walkthrough with client Final Stage - Presentation & Report generation Develop Recommendations

10/28/2012 11/3/2012 11/4/2012 11/4/2012 11/8/2012

11/3/2012 11/4/2012 11/4/2012 11/8/2012 11/10/2012

Team Kate TBA Team Team

11/11/2012

11/14/2012

Brainstorm alternative recommendations Meet to discuss and decide final recommendations, final presentation, final paper Develop Client Presentation Meet to discuss content of client presentation Incorporate team feedback into presentation slide and format final version Practice and time presentation with team Present final recommendation to the client Write Client Report Meet to discuss content of client report Incorporate team feedback on draft report and format final version

11/14/2012 11/16/2012

11/14/2012 11/21/2012

Susan & Rebecca Team Team

11/22/2012 11/26/2012 11/27/2012

11/26/2012 11/27/2012 11/29/2012

Pair work Team Janani

11/29/2012 12/2/2012 12/3/2012 12/7/2012 12/9/2012

12/2/2012 12/5/2012 12/7/2012 12/9/2012 12/10/2012

Team Team Kate Team Kate

28 29

30

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

Estimated Start Estimated End Actual Start Actual End Responsibility Date Date Date Date

5


Hi5: Kate Donovan, Janani Sudari, Susan Solo, Becky McNitt, Jeremy Canfield

Activity 50 51 52

Tasks Read final report and suggest any last minor revisions Finalize paper making any last minor revisions Hand final report to the client

Project Plan

Estimated Start Estimated End Actual Start Actual End Responsibility Date Date Date Date 12/10/2012 12/11/2012 12/11/2012

12/11/2012 12/11/2012 12/12/2012

Team Team Team

Commitments Janani B.S - SI 682 Group Project - Tight Schedule Janani B.S - Thanksgiving Weekend - Trip with friends Jeremy - Thanksgiving Weekend Jeremy - Mid Semester Break Weekend Jeremy - 682 Project Due Dates Kate--Fall Study Break (I'll be doing a lot of grading and other work and will be unavailable to meet. However, our team model is due the following Thursday, so if we'll need to meet about that, I'll need to do it the week of the 13th. Kate--Thanksgiving Weekend--I have three big projects due within about 3 days here, as well as two big grading assignments due. That said, our final presentation needs to be completed by Dec. 5th. So, any work we can do to wrap this up (at least as much as possible) by the week of Nov. 17th would be super. Rebecca - None that I can think of at the moment, apart from being at home football games (but those are all on Saturday), I live in Ann Arbor, so I'll be around most of the time. Susan - MAME Conference Nov. 6-7. Will also be away for Thanksgiving weekend.

6


Hi5: Kate Donovan, Jeremy Canfield, Susan Solo, Becky McNitt, Janani Sudari

Gantt Chart

Month-1 Tasks

Owner

Plan Start

Plan Finish

Days

9/6

9/13

9/20

Month-2 9/27

Month-3

10/4 10/11 10/18 10/25 #

Gearing up to start our activities

6-Sep-12

16-Sep-12

Agreed on a Team name Created Google Group for better communication Delegated the roles for each member Created the Google calender Prepared the draft for communication covenant Prepared the draft for Interview Protocols

Team Jeremy

9/6/2012 9/12/2012

9/6/2012 9/13/2012

1 2

Team Team Kate

9/16/2012 9/16/2012 9/12/2012

9/16/2012 9/16/2012 9/16/2012

1 1 5

Susan

9/12/2012

9/16/2012

5

Schedule the group meetings

Team

9/12/2012

9/12/2012

1

Client Meeting Setting up Initial Client meeting with Jeremy Maria Sheler

13-Sep-12 9/13/2012

24-Sep-12 9/17/2012

5

Conduct the Initial Meeting Interpret the Initial Meeting Upload the key notes based on our meeting

9/20/2012 9/20/2012 9/23/2012

9/20/2012 9/23/2012 9/24/2012

1 4 2

9/21/2012

9/23/2012

3

Team

9/20/2012

10/24/2012

35

Evaluate and review the project based Team on the interviews

9/20/2012

10/8/2012

19

Conduct and note interview with the Janani & Chief IT Security Officer Paul Howell Kate

9/24/2012

9/27/2012

4

Communicate and interpret the interview with other members & include affinity notes, models Conduct and note interview with one of ITSS clients - College of Engineering - Mark Giuffrida Communicate and interpret the interview with other members & include affinity notes, models Conduct and note interview with Jeff Tomaszewski - Data Security Analyst

Team

9/27/2012

9/29/2012

2

Jeremy & Rebecca Team

10/1/2012

10/3/2012

3

10/3/2012

10/5/2012

3

Susan & Jeremy

10/5/2012

10/8/2012

4

Confirm by phone/e-mail the interview dates Conduct interviewing and interpretation sessions

Team Team Janani

11/1 #

Month-4

11/8 11/15 11/22 11/29 12/6 12/13 #

#

12/20 ##

7


Hi5: Kate Donovan, Jeremy Canfield, Susan Solo, Becky McNitt, Janani Sudari

Gantt Chart

Month-1 Tasks

Owner

Communicate and interpret the interview with other members & include affinity notes, models

Team

10/8/2012

10/10/2012

3

Team Team Team Team

23-Oct-12 10/23/2012 10/24/2012 10/28/2012 10/28/2012

10-Nov-12 10/24/2012 10/27/2012 11/2/2012 11/3/2012

2 4 6 7

Kate TBA

11/3/2012 11/4/2012

11/4/2012 11/4/2012

2 1

Prepare affinity walkthrough script for Team client meeting

11/4/2012

11/8/2012

5

Complete affinity walkthrough with client

11/8/2012

11/10/2012

3

11-Nov-12

12-Dec-12

Create Consolidated Models and Post all the consolidated models End all the interview sessions Create Affinity Walkthrough Diagram Collect all the affinity notes, diagrams, models and upload them Review all affinity notes Get materials for affinity diagramming session

Plan Start

Plan Finish

Days

9/6

9/13

9/20

Month-2 9/27

Month-3

10/4 10/11 10/18 10/25

1

11/1

Month-4

11/8 11/15 11/22 11/29 12/6 12/13

12/20

1

1 1

Team

Final Stage - Presentation & Report Generation

1

1

Develop Recommendations Brainstorm alternative recommendations

Susan & Team

11/11/2012 11/14/2012

11/14/2012 11/14/2012

4 1

Meet to discuss and decide final recommendations, final presentation, final paper Develop Client Presentation Meet to discuss content of client presentation

Team

11/16/2012

11/21/2012

6

Pair Team

11/22/2012 11/26/2012

11/26/2012 11/27/2012

6 2

Incorporate team feedback into presentation slide and format final version Practice and time presentation with team

Janani

11/27/2012

11/29/2012

3

Team

11/29/2012

12/2/2012

4

Present final recommendation to the Team client Write Client Report Kate Meet to discuss content of client report Team

12/2/2012

12/5/2012

4

12/3/2012 12/7/2012

12/7/2012 12/9/2012

5 3

Incorporate team feedback on draft report and format final version

12/9/2012

12/10/2012

2

1 1

Kate

8


Hi5: Kate Donovan, Jeremy Canfield, Susan Solo, Becky McNitt, Janani Sudari

Gantt Chart

Month-1 Tasks

Owner

Read final report and suggest any last Team minor revisions Finalize paper making any last minor Team revisions Hand final report to the client Team

Plan Start

Plan Finish

Days

9/6

12/10/2012

12/11/2012

2

12/11/2012

12/11/2012

1

12/11/2012

12/12/2012

1

9/13

9/20

Month-2 9/27

10/4 10/11 10/18 10/25

Month-3 11/1

Month-4

11/8 11/15 11/22 11/29 12/6 12/13

12/20

9


Team Hi5: Kate Donovan, Rebecca McNitt, Janani Sundar, Susan Solo, Jeremy Canfield September 18, 2008 Interview Protocols Over the next three months, our group will look at the flow of information technology security information from the University of Michigan's Information Technology Security Services out to the various groups with whom they work. In our initial client meeting, we hope to learn more about the processes through which ITSS provides security information to the University. We also intend to examine methods that may be used to improve the effectiveness and evenness of the security information provided to the entire campus, and specifically the College of Engineering, The Institute for Social Research and School of Art & Design. Initial Client Interview Questions for Maria Sheler-Edwards, ITSS Communications Specialist Process • What is the process that we should review? What makes the College of Engineering and ISR the focus of your concern? Why is the research community a concern? (Are these similar or separate issues?) • What do you mean by “an uneven reach of security information” throughout the unit communities? Which ones work most effectively? Why? • For these areas of concern, could you explain what distinguishes them from areas that work more effectively? (Size of the unit? Organizational structure? Resources?) • You mention “gaps” between what should be known and what is done. Tell us what you can about possible reasons for these. Do some units work without these gaps and if so, are there indications why? (Better communication? More effective leadership?) • Are there any other variables in the process we should consider? (Peak times? Types of security information distributed? Users targeted?) Personnel • What is the chain-of-command structure for ITSS? Are all UM-ITSS personnel in the same office, or in multiple locations? • What exactly is the function and authority of the security unit liaison? How many are there? How independent are they? • Within each unit, who is involved in the process? What does each person contribute? • What skills and training are involved? Are there different levels of security and access? • How relevant are personnel to the concerns you have?


Team Hi5: Kate Donovan, Rebecca McNitt, Janani Sundar, Susan Solo, Jeremy Canfield September 18, 2008 Communication • How are security policies and issues disseminated among the various units, and do these units communicate regularly with each other? • How often and in what way does communication take place within a unit? Among units? • In your opinion, within ITSS, is communication top-down, or free flowing? • How does ITSS communicate with the users of information (staff, faculty, students)? • Who handles technical issues? Are they quickly resolved? • Is there anything we did not ask that we should? Interview Protocols Process • Describe your role at ITSS. What are your responsibilities and duties? • How much of what you do is dependent on other people? In what way? • What do you see as the areas of concern that brought us to this project? • What do you think could be improved in the process of disseminating information to users of security information? Personnel • How much of what you do is dependent on other people? • Who are the people you work with directly? How would you describe the office culture? • How much contact do you have with the security unit liaison(s) in your unit? Communication • How do you communicate with others in your office? • Do you communicate directly with users of security information (faculty, staff, students)? If so, how? • How do you get feedback from these users of security resources? • Are there lapses in communication, or any frustrations that should be addressed? • Are there technical issues that interfere or limit communication with users, or with each other? • Is there anything we did not ask that we should?


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model

No 1

Date 09/19/2008

Interviewer(s) Group Interview; All Hi5 Members were present.

Interviewee(s) Maria Sheler-Edward(U06) & Esther Friedmann(U05)

2

09/24/2008

Mark Giuffrida – U01

3

09/24/2008

4

09/26/2008

5

09/27/2008

6

10/08/2008

7

10/10/2008

8

10/14/2008

Interviewer: Susan Solo Note Taker: Janani B.S Interviewer: Jeremy Canfield Note Taker: Rebecca McNitt Interviewer: Jeremy Canfield Note Taker: Susan Solo Interviewer: Kate Donovan Note Taker: Jeremy Canfield Interviewer: Rebecca McNitt Note Taker: Janani B.S Interviewer: Kate Donovan Note Taker: Janani B.S Interviewer: Janani B.S Note Taker: Rebecca McNitt

Individual Cultural Flow Models

Kevin Cheek – U02 Jeff Tomaszewski – U03 Paul Killey – U04 Laura Falk – U08 Paul Howell – U07 Maria Sheler-Edward(U06)


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model Consolidated Cultural Flow Model Hi5 Cultural model comprises of U01, U02, U04, U05, U06, U07 & U08

Key MAIS - Michigan Administrative Information Services ITSS – Information Technology Security Services MSS – Managed Security Services SP – Security Plan COE – College of Engineering EECS – Electronics and Computer Science Engineering Department


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model LSA - Liberal Arts & Science Department SU – Security Unit

Cultural Consolidated Model Narrative The consolidated cultural model for team Hi5 details the cultural variations for our contextual inquiry project with Internet Technology Security Services (ITSS) at the University of Michigan. For our project we were tasked with determining how ITSS could improve its communications and working relationship with various colleges and departments on campus. In an effort to narrow the project’s scope, ITSS and Hi5 agreed to focus on ITSS’ work in conjunction with the College of Engineering (CoE). In order to understand ITSS’ relationship with the CoE, Hi5 team members interviewed staff members at ITSS, ITSS Security Liaisons in the CoE, and CoE security and IT personnel. The cultural model as defined shows the influence on people, policies, organizational preferences and values, points of Pride, emotion, personal preferences. I have also jotted down the breakdowns between the units. One of the problems revealed by the model is about the security plan. ITSS sends out the Security Plan template; But the engineering department feels that the security plan is vague and the questions asked in the template sometimes takes a lot of time & effort or cannot be answered at all as every department in the CoE works independently. And the biggest breakdown is there is only one unit liaison for CoE. This liaison has to be both the communication person as well as the security savvy. The other main problem is Information Technology staffs at the College of Engineering report security issues to their department heads rather than to the College of Engineering itself. Although CAEN provides phone and data connectivity, web servers, and storage to the College of Engineering and is the center for IT security at the College of Engineering, none of the other departments report to them. For e.g. Electrical Engineering and Computer Science is very independent, has its own resources (own DNS, etc.) and it is difficult to keep them in compliance with the College of Engineering security plan. Laura Falk the security head of EECS feels that CAEN was introduced much after EECS security unit; EECS has enough resources; So EECS feel it’s not necessary to interact or depend on CAEN. So every department has their own process and therefore it’s difficult for CoE to bring up one security plan. The strength revealed in the model is that LSA and ITSS are culturally happy with each other and this gives our team the confidence that ITSS/MAIS and CoE will also be happy in the mere future if there are proper resources and appropriate roles for CoE. One of the most pressing challenges faced by ITSS in administering security policy is the difficulty it faces in trying to ensure successful implementation of security policies in an environment in which it


Team: Hi5: Janani Bhuvaneswari Sundar Assignment: Individual Consolidated Model: Cultural Model

lacks regulatory authority, so to speak. We need to recommend ideas that would help CoE to overcome their own obstacles within their departments.


Communication Flows: Information Technology Security Services and the College of Engineering “Keeping It Safe at U-M”

December 10, 2008

TEAM HI5: Janani B.S Jeremy Canfield Kate Donovan Rebecca McNitt Susan Solo

ITSS CONTACT: Maria Sheler-Edwards Communications Specialist (734) 615 – 4278 marialyn@umich.edu


TABLE OF CONTENTS

EXECUTIVE SUMMARY

3

PROJECT INTRODUCTION

4

DATA COLLECTION AND ANALYSIS

5

FINDINGS AND RECOMMENDATIONS

6

CONCLUSION

10

APPENDIX A

11

APPENDIX B

13

2


EXECUTIVE SUMMARY Information Technology Security Services is a relatively new organization charged with the prevention of serious security breaches throughout all University of Michigan campuses, including the University Health System. ITSS asked our group to study the coordination of security information as it flows to and from units and departments, specifically regarding the role of Unit Liaisons (ULs) as contact persons. We focused on the College of Engineering (CoE) as an example of a complex and challenging unit to study, hoping that what we learn from the relationship between ITSS and the CoE highlights issues relevant to other units and departments. At the CoE we interviewed the Unit Liaison, the Executive Director, and a System Program Analyst. At ITSS we met with the Program Manager, Communications Specialist, the Chief Security Officer, and two Security Analysts. We used our interview notes and data to create an affinity diagram showing consistent concerns in three areas: communication between ITSS and ULs, location of data and information, and the dissemination of communication materials. We also found that ITSS is sensitive to departmental concerns and works to resolve issues that hinder compliance to their security processes. Much of our interview discussion centered on the submission of the Information Security Plan (ISP), partly because it is a central document in the security program required by ITSS, but also because the College of Engineering was in the process of resubmitting their ISP at the time of our interviews. Team Hi5 submits the following findings and recommendations: FINDINGS: ♦ ITSS is aware of constraints regarding its authority and of the value of cooperative delegation. It offers help in the form of materials, guidance, and services, including Managed Security Services (MSS), and seems to understand the point-of-view of busy, frustrated ULs. ♦ Several people mentioned the need for a centralized repository of data, particularly sensitive data, to minimize the risk of exposure. There was some question as to what exactly qualifies as “sensitive data.” ♦ There was some confusion as to who is responsible for distributing security communication materials, if indeed they are distributed. ♦ The ISP outlines responsibilities for at least five roles that should be assigned within each unit: the Unit Liaison, Security Coordinator, Security Administrator, Communications Coordinator, and Technology Service Provider. Most units combine these roles, sometimes designating one person to handle the responsibilities of all five, almost certainly ensuring inadequate attention. RECOMMENDATIONS: ♦ Keep lines of communication open and remain responsive and flexible. ♦ Consider a revision of the ITSS website to make information quicker and easier to find. ♦ Help units delegate roles, especially the Communications Coordinator, and train them in the responsibilities you wish them to assume. Keep in contact with them. ♦ Increase the dissemination of ITSS communications, perhaps by increasing the number of people contacted. ♦ Continue publicity materials using high-profile incidents, relevant to UM if possible.

3


PROJECT INTRODUCTION Information Technology Security Services (ITSS) at the University of Michigan was created in 2004 as part of Michigan Administrative Information Services (MAIS), with the mandate to spearhead information security initiatives at the University of Michigan. ITSS collaborates with UM units throughout the Ann Arbor, Flint, and Dearborn campuses, including the University Health System, to develop a system-wide security strategy and to implement security best practices at the University. ITSS is, according to Chief IT Security Officer Paul Howell, the “architect of security vision” at Michigan. As part of its security duties, ITSS coordinates and facilitates campus-wide incident responses to security breaches and provides campus units with security services such as assessments, consultations, network scans, and training sessions. Although ITSS is responsible for coordinating information security across the University of Michigan system, it does so with only thirteen staff members. Team Hi5’s project was to study and understand how ITSS works with different university units—including colleges, departments, and administrative units—in order to better understand how ITSS coordinates and communicates IT security information, planning, policy, and best practices with its campus partners. Included in the project scope was the goal of understanding the role of the Unit Liaisons with whom ITSS works. Given its small staff size and the large scope of its mandate, ITSS relies upon Unit Liaisons embedded within each college or unit. These liaisons do not work for ITSS, but were selected by their units to work collaboratively with ITSS to implement security polices and procedures. The Unit Liaisons are charged with collaborating with others in their unit (i.e. delegating some responsibilities) to carry out the security vision as articulated by ITSS. In addition to understanding the Unit Liaison role, Team Hi 5 focused on a document referred to as the Information Security Plan (ISP). In this plan, departments outline the security work they are already doing and their plans for the future. The ISP is large and very detailed; it includes equipment and software surveys, calendars, plans of work, risk assessments, budget information, and breakdowns of security roles and responsibilities. Our team also studied how ITSS and its units promoted information about security, not only to the Unit Liaisons, but also to IT personnel, faculty, students, and other staff members within a given department. We considered such questions as “Were the people responsible for communicating IT security best practices effective in their function?” and “What was working and what wasn't?” In an effort to narrow the project’s scope to a somewhat more manageable size, Team Hi 5 and ITSS agreed to limit the scope of the group’s inquiry to the relationship between ITSS and the College of Engineering (CoE). The CoE is one of the largest units on campus, with thirteen academic units and twenty independent security departments, yet it has only one ITSS-designated Unit Liaison. Due to its size and complexity, ITSS and Team HI 5 agreed that the CoE would present an effective case study for understanding how information regarding IT security flowed from ITSS to campus units, and how those campus units then worked with that information. 4


DATA COLLECTION AND ANALYSIS ITSS Staff CoE Faculty/Staff No 1

Date 09/19/2008

2

09/24/2008

3

09/24/2008

4

09/26/2008

5

09/27/2008

6

10/08/2008

7

10/10/2008

8

10/14/2008

Interviewer(s) Group Interview; All Hi5 Members were present Interviewer: Susan Solo Note Taker: Rebecca McNitt Interviewer: Susan Solo Note Taker: Janani Sundar Interviewer: Jeremy Canfield Note Taker: Rebecca McNitt Interviewer: Jeremy Canfield Note Taker: Susan Solo Interviewer: Kate Donovan Note Taker: Jeremy Canfield Interviewer: Rebecca McNitt Note Taker: Janani Sundar Interviewer: Kate Donovan Note Taker: Janani Sundar Interviewer: Janani Sundar Note Taker: Rebecca McNitt

Interviewee(s) Initial Client Meeting U05—ITSS Administrator U06—ITSS Administrator U01 – Security Unit Liaison U02—Security Analyst U03—Security Analyst U04—CoE Administrator U08—CoE IT Personnel U07—ITSS Administrator U06—ITSS Administrator

In an effort to understand ITSS’ work process and relationship with the College of Engineering, Hi 5 team members interviewed a range of people at ITSS and the CoE who were involved in the creation of the security plan, responsible for the implementation of security policy, and involved in promoting security best practices. We spoke to people at a number of different job levels, from those who implemented policy to those that articulated the entire security vision for the University. In order to organize and best understand the data collected through interviews, the team undertook a number of data analysis processes. We collected interview notes and modeled the information we gathered. We diagrammed flows of communication to find out who was talking to whom, and about what. We created a sequence model to learn how tasks were being completed, and by whom. We also considered how, if at all, the physical layout affected the work processes between the CoE and ITSS. In addition, we studied the documents produced by ITSS and the CoE (including websites, ISP templates, and security guidelines), in an effort to understand workflow and material culture within the CoE and ITSS. Finally, we assembled two models to understand the differences and similarities in organizational culture between ITSS and the CoE. We also converted our interview notes into affinity notes, highlighting important ideas and quotes gleaned during the course of our interviews. We then compiled these notes into a large affinity diagram, where we then categorized them thematically. The Team Hi 5 data collection and analysis process revealed several key findings about communication and work processes between ITSS and the College of Engineering.

5


Recommendation 1: Keep up the good work Findings and Evidence: Our group’s first finding was that ITSS has been making an effort to be flexible and respond to any of the needs of the community. From our observation and interviews, we saw that they are willing to look at security models already in place across the campus and base their template on those models. One of the ways that ITSS has responded to the needs of the communities they serve has been to start the implementation of Footprints to report incidents. The College of Engineering has been using Footprints to report incidents for some time now, and ITSS has begun to use this program recently, reducing the need for the submissions of multiple incident reports for a single incident. Another example of ITSS’ responsiveness has been to create Managed Security Services (MSS), a small group of ITSS employees that functions as an outreach program for ITSS. If a college or department is unable to provide its own security staff because it is too small to have one, or too complex to organize an effective security structure, ITSS will provide it with the assistance of an MSS staff person. In addition, ITSS created a template for units to use when creating their security plan. This 15 page ISP template and its 28 page supplement provide units with the information and directions needed to create an effective security plan. Recommendations: Our only recommendation regarding this finding is that ITSS keep up the good work. Their responsiveness and flexibility will continue to help them in their efforts to organize and implement security practices across the University.

Recommendation 2: Improve the clarity of the ITSS website Findings and Evidence: The ITSS website provides information for students/faculty and also for all IT security staff (Unit Liaisons, ITSS Staff, security staff of each department, MSS staff, etc…). One issue we discovered in most of our interviews was that the ITSS website is not utilized effectively by security staff and Unit Liaisons. We decided there are several reasons for this. Looking through the entire website, we found that there is much useful information available on the ITSS site, but it took some time to find it. From an informal survey of ten students, we learned that the ITSS website is not viewed by them at all; in fact, they confused ITSS with the higher profile “ITCS.” Interviews revealed a lack of clarity on the part of many people as to what constitutes sensitive data and, moreover, where they should go to find this information. For instance, while the ITSS website hosts a "data classification guide" with some of this information, it is not easily findable (Appendix A – website related snapshots). Security staff still have questions like “What kind of tool is used to store incidents”?; “What are other security departments doing?”; “What is ITSS up-to?” One interviewee feels the website is vague and

6


not particularly helpful. On the other hand, ITSS questions the effort put forth by the security staff: “We submit slides, meeting notes and best practices on the website, but we are not sure if security people visit the website.” Recommendations: The most important recommendation that we suggest is to update the website to make security and communications information more visible. The website has a lot of information for the security community like meeting schedules, risk assessment, a Unit Liaisons directory, policies, incident reporting, and more. While there may be some information needing password protection, the majority of the content should be readily available to all, especially the information that pertains to sensitive data. We feel the website could be more user-centered, attractive, and interactive. When email communications are sent, a link to the website with a header saying “click here for more information" may entice more browsing. Also the “Quick Links” on the website should have no more than five links, so users do not have to scroll down the page to view them all. When the website is updated, notification of the changes and the link to the website should go to all the security staff e-mails. News and important information can be in a separate pane (Appendix A – website related snapshots). A good website makes relevant information easy to find and is easy to navigate. If the website allowed annotation and tagging functionality, it would better serve a large and diverse community. It is difficult and cumbersome to coordinate with the security staff of each and every department throughout the University system, and a good web design could encourage participation. A short-term goal could be to create a collaborative tool like a wiki, to encourage an exchange of information. The School of Information offers two courses that provide in-depth knowledge of creating and maintaining a good website: SI-422 Evaluation of Systems and Services and S-682 Interface and Interaction Design. Recruiting an SI student with appropriate credentials to create/maintain the website could be an affordable idea.

Recommendation 3: Improve distribution of communication materials Findings and Evidence: Our third finding was that, although ITSS has been creating and distributing communications materials, some departments report that they have never received materials. Unit Liaisons have either not received their materials from ITSS, or they have received but not distributed them. One of the comments we heard during our interviews was that “there should be a central repository for all ITSS communications materials. If there were a central repository, a Unit Liaison who did not receive materials, or required extra materials, would be able to find them in one place. Another quote we noted was “I create communication materials and give them to the liaisons, but no-one else seems to know about them.” If the Unit Liaisons (like U01 who

7


reported not receiving his materials) are not in possession of these materials and no one else knows about them, the materials will not be distributed and people will continue to be unaware of ITSS and its goals. With only one individual responsible for the dispersal of security materials, there is a “single point of failure.” Recommendations: To improve communications between ITSS and the many units with which they work, Team Hi5 suggests that ITSS help find the best possible people in each unit to serve as the Communications Liaison. ITSS could then work with contact persons specifically trained in communications strategy to ensure communications information and materials are effectively dispersed. Our other recommendation for this finding is to increase the number of people on the ITSS communications e-mail list. Currently, the list consists of Unit Liaisons, other individuals who have gone through the ITSS security training, and people who have been added to the list because of a special request from a department head. We recommend that IT security staffs and anyone named as a Communications Liaison be added to the list, whether or not they have received training.

Recommendation 4: Promote delegation of roles and responsibilities Findings and Evidence: Our fourth and final major finding relates to the delegation of security responsibilities within the College of Engineering. Although the Information Security Plan encourages departments to delegate components of the Unit Liaison's responsibilities, this does not seem to be consistently happening in the CoE. This lack of delegation is partly a constraint of the structure of the college itself: we found that the CoE is only loosely hierarchical with considerable decision authority residing in the departments. While the central IT organization for the college (CAEN) does provide support for many of the college’s systems, it is not in charge of all the systems; many departments maintain their own technical infrastructure. On the whole, the College of Engineering is composed of a collection of semi-independent departments with little formal hierarchy or reporting structure between them. This allows a great degree of intellectual freedom: systems can be designed and maintained to best suit the different departments’ technical requirements. Interviewees felt that even absent this hierarchy, most required security practices were implemented and communicated, through a process they indicated was functional, but informal. In some extreme instances, there isn’t much communication at all: one interviewee noted that the Department of Electrical Engineering and Computer Science does not report to and has “no real interaction” with CAEN. This informality makes assigning of security roles and documentation of security practices very difficult from the college level—lacking an authoritative central control, there is simply not one individual in charge of system security—no person with whom the buck stops. Even the dean, while important for adoption, cannot impose his will on the departments—such an authoritarian model “would interfere with intellectual freedom,” as one interviewee noted.

8


This lack of formal delegation authority likely contributes to many of the problems that the CoE experiences in developing and implementing unit-wide security practices. Because our project focused primarily on communication, we dove most deeply into the constraints and possible mitigation techniques with regard to the role of communications specialist. We found that despite the decentralized nature of the College, there was only one primary contact in charge of distribution of communication material, and not a specific individual within each of the departments. The second contributing factor to the lack of delegation we found was that roles were often bundled due to a lack of resources within the CoE. The interviewees we spoke with in the College of Engineering were very vocal in their protest, calling the additional security requirements an “unfunded mandate” and noting that the College is underresourced and likely to remain so. Interviewees reported not having sufficient time to complete the tasks, or, as one interviewee said it: “I’m frustrated as ITSS comes just to me.” Interviewees also frequently noted that the process of completing the Security Plan was an extremely time intensive process, and, importantly, one that took precedence over other job responsibilities. Among other repercussions, this leaves little time for the dissemination of communication materials: because the role of communications specialist is tied in within the larger Unit Liaison role, it is often overlooked or overshadowed by the other roles deemed more time sensitive or important. This finding bears heavily on finding three: in effect, the communication materials are not being disseminated because there is no one available within the College to make it a top priority. Apart from the priority constraints this bundling places on the communication coordinator role, it also imposes a skill constraint—the Unit Liaison was primarily understood as being charged with security policy formation and technical implementation; individuals with such skills admitted to us that they found the role of communication coordination “less intuitive.” This is yet another clear signal that role assignment needs to be reassessed within the College. Finally, we found that while the Security Plan does specify the need for a communication coordinator as well as this role’s responsibilities in some detail, it may not do so in explicit detail to make certain the role is filled with people adept at navigating the unit’s communication mechanisms. Recommendations: Even recognizing the constraints of limited resources and distributed hierarchy that the College of Engineering is operating within, we feel that there are actions that ITSS can perform that may help the CoE better its delegation, at least in terms of the communication coordinator role. First, we recommend revising the Security Plan’s role definition for the Information Security Communications Coordinator (see expanded role definition in appendix) to include language explicitly stating that the coordinator should have access to the main communication channels employed within their unit. We also think that providing examples of where successful communication coordinators are situated within the organizations of their Colleges may help the CoE to recognize these skills and channels within their own ranks. For example, if successful communication coordinators are often found in the front office for the College (individuals here are already doing 9


communications work within a given unit), an example stating such would help the College to better place their own roles. Also, we feel that the culture and complexity of the College of Engineering necessitates not simply one Communications Coordinator, but a team, with sub-coordinators in each of the departments. This mirrors the recommendation for the third finding—by allowing a wider net of communication coordinators with specific knowledge of their own departments, ITSS guarantees that there is no single point of failure, no one bottleneck to block the flow of security information and awareness materials. Finally, we feel that it may prove beneficial for ITSS to take a more active consultative role in determining who should be responsible for the dissemination of communications information within the Schools. While it is very valuable to have this role explicitly defined in the Security Plan, we think that ITSS may need to help units think critically about who that communications person should be, rather than leaving it to the unit to make this determination alone. This recommendation mimics the success of MSS (see Finding 1) in that it recognizes that when ITSS has a more active, consultative role, it often leads to better outcomes. While ITSS needn't and shouldn't select this individual to perform the communication coordinator role for a given College or Department, by offering its expertise it enables them to find a person with the appropriate qualifications and skills to fill the communications role. CONCLUSION Information Technology Security Services at the University of Michigan is well equipped to handle the mission it is charged with: overseeing the security activities recommended to minimize security risks. We feel much of the resistance to adopting security activities will diminish over time, as the Information Security Plan becomes a more familiar and integrated maintenance program. In the meantime, ITSS should continue its efforts to distribute security communication materials in as many forms, in as many ways, as often as possible. We have outlined recommendations for consideration, based on information gathered for this report. Finally, we would like to thank the staff of ITSS and the College of Engineering for being gracious, active participants in this project—we hope that you find it as enlightening and valuable as we have.

10


Appendix A Website Related Snapshots 1. ITSS or ITCS???

2. Quick Links

Quick Links should have only 5 links and user should not have to scroll the page to view them. Sensitive information found in Data Classification should be easily findable.

3. News and Important Information News /Information can be a separate pane like this so it is useful for students/faculty to visit the website and quickly glance at the latest information.

11


4. Notifications on your email client

This is a sample to show when the website is updated; e-mail is sent to all website owners to show changes and link to the website. This will allow the security staff to regularly visit the website.

12


Appendix B Models 1. Cultural Model It identifies cultural differences that exist in the College of Engineering. It was useful to model the details in the culture of interaction between ITSS and the CoE and also within the CoE departments. Also shown are cultural differences between security staff persons.

13


2. Artifact Model Structure: Unit Information Security document + supplement (in Excel spreadsheet) Intent: Provide baseline for unit security management and budget requests Use: Inventory of high level IT assets and location of sensitive information. Schedule of IT activities.

Considered by some to be an “unfunded mandate.�

ITSS created supplement to show examples for template. (Excel)

14


3. Physical Model While the three miles between ITSS’ headquarters and Engineering’s main computing administration exist may not seem substantial, it could be complicating the Security Plan process. Distance has been shown to increase the complexity and time involved in collaboration. This is even more problematic with respect to the Security Awareness Materials, which are often high-quality posters that must be physically delivered. Indeed, our interviews indicated that these materials are not consistently delivered to the Departmental Security Communication Disseminators.

15


4. Sequence Model Sequence: Submitting a security plan to ITSS for approval Trigger: ITSS requests a security plan from all colleges. Overall Intent: College of Engineering would like to submit a plan that will be accepted and implemented. Activities

Intents

Breakdowns

ITSS recognizes need for security policy, security communication and incident response.

ITSS communications creates security materials to be handed out by unit liaisons to their departments.

ITSS communications delivers materials directly to students at student fairs and festivals. If security plan is not approved, it is sent back to the policy coordinator for alterations.

Security template submitted for approval.

Unit liaisons (sometimes security coordinators and other IT coordinators) hold meetings

Alternative Steps

Security plan devised by ITSS with assistance from advisory board. BD: Unit liaisons do not always hand out their materials and ITSS has no way of monitoring.

ITSS sends approved security plan template to all colleges through unit liaisons.

Abstract Step

Allows faculty and staff of different colleges to see the requirements of the security plan.

BD: Departments do not feel that the template can be altered to their purposes. BD: Some of these meetings have yet to take place, leaving those departments 16


with departments to gain information for the security plan.

CoE's unit liaisons (et al) work together to identify what information is pertinent to the security plan.

without knowledge of the security plan. BD: Departments Establish are unclear timeline, goals on what and qualifies as a objectives, "serious" security risk security risk; assessment CoE uses (RECON), FootPrints to method for document dealing with security security incidents, incidents, ITSS is just security beginning to responsibilities implement this system.

Unit liaison and security coordinator work together to create a draft of the security plan.

Plan is sent to head of department for approval. If approved, plan is "polished" by representatives of ITSS and CoE.

Plan is submitted to ITSS. If approved by ITSS, plan returns to CoE for implementation.

If not approved, plan is sent back to the security coordinator and unit liaison for alterations. Plan is resubmitted.

If not approved, plan returns to CoE for alterations. Plan is resubmitted.

Implementation of plan begins.

17


Information Technology Security Services (ITSS)


Hi5

Susan Solo, Jeremy Canfield, Janani Sundar, Rebecca McNitt, and Kate Donovan


Have you seen these?


Do you know ITSS? • Manages IT security for Ann Arbor, Dearborn, and Flint campuses, as well as the University Health System • A section of Michigan Administrative Information Services (MAIS), but functions independently • One part-time and 10 full-time employees, as well as one part-time student • ITSS is NOT ITCS (Information Technology Computing Services).


Project Scope • Studied how ITSS coordinates information security with various campus and college units • Focused on College of Engineering (CoE) because of its size and complexity


Definition of the Problem • CoE’s IT staff believe that they are doing a good job managing security • Difficulty getting CoE to complete a security plan even with template • CoE has 13 academic departments and 20 security departments, most with their own IT staff • No clear hierarchy for dealing with problems


Data Collection • Consulted individuals participating in different stages of the security plan process • Spoke to technical and communications staffs, administrators at ITSS and CoE


Analysis and Methodology


Analysis and Methodology


Findings • ITSS is responsive and flexible • Security Information is hard to find • Breakdown in distribution of security awareness materials • Lack of delegation of roles and responsibilities


Finding #1: ITSS is Responsive and Flexible • Responsive to needs and willing to learn from other models on campus • Evidence: o o o

“Footprints is the way to go” MSS provides crucial expertise Created security plan template


Recommendation #1 Keep up the good work!


Finding #2: Security Information is hard to find • ITSS website contains a lot of useful information, but users report difficulty locating what they need. • Evidence: “What is sensitive data?” “Where is it located?” “The information on the website is vague and not helpful.” o “It would be good to have a central security repository that would be accessible by every IT/security person so they could identify their roles and take action.” o o o


Example: Is my info sensitive?


Recommendation #2 Update the website to make security and communications information more visible More user centered More readily available content E-mail communications containing links to website for more information o Include an area where Unit Liaisions can communicate with each other to solve problems o o o


Finding #3: Breakdown in Materials Distribution • There is a breakdown in the distribution of communication materials. • Evidence: “There should be a central repository for all ITSS communications materials.” o "I create communication materials and give them to the liaisons, but no-one else seems to know about them." o U01 reported not receiving communication materials. o


Recommendation #3

Increase number and variety of people ITSS sends materials to


Finding #4: Lack of Delegation • CoE not delegating communication role effectively • Evidence: o o

o

IT people report finding this role less-intuitive Hard to comply, due to lack of necessary funds, staff resources, and time: "I’m frustrated as ITSS comes just to me." This role is viewed as secondary to other duties


Recommendation #4 Allow College of Engineering to choose individuals to fulfill the communication role, but provide more advice and assistance in the selection process


Goal Setting • Short Term Goals Increase number and variety of people ITSS sends material to o Provide assistance to College in choosing individuals to distribute communications materials o

• Medium Term Goals o

Update website, make information more user-centric

• Long Term Goals o

Create collaborative tool for Unit Liaisons (Wiki, etc)


Conclusion Room for improvement, but ITSS seems: o Invested

in and committed to getting others on board with their plan o Adaptable without compromising their requirements o Interested in hearing recommendations


Questions?

Photo: Allposters.com


ITSS - Contextual Inquiry and Project Management