José-Marie Griffiths, Ph.D.

Archive

Reports

University of Michigan Security Architecture Task Force Report

September 1, 2000 DRAFT

Executive Summary Introduction Tasks and Deliverables Other Relevant Activities Other Issues and Linkages Recommendations Action Plan and Timeline Appendix A: Task Force Charge Appendix B: IT Security Policy Review Work Group Report Appendix C: Benchmark Survey Summary

Tasks and Deliverables

University of Michigan Security Principle

Purpose

The purpose of the Security Principle is to provide a framework for information technology security at The University of Michigan. This statement is intended to guide the review and development of detailed policies and practices by those executive officers or their designees who have responsibility for institutional data and those who provide information technology services to the campus. It will guide the establishment of appropriate expectations for providers and users of digital information, the computers that store and process it, and the networks that transfer it at the University.

Responsibility for maintenance and administration of this statement shall be assigned to the University Chief Information Officer. This statement will be reviewed bi-annually.

Institutional Values

This Security Principle is grounded in the institutional values of the University of Michigan within the context of appropriate federal laws, state laws, and/or requirements of external regulatory organizations. The University is committed to public engagement and empowerment by providing access to information to the immediate and extended University community to encourage the sharing of knowledge. The institutional values, which drive this commitment, include:

• Freedom of speech and artistic expression - providing an environment that does not restrict the rights of its members to pursue academic, scholarly and artistic and often creative objectives.
• Limited right to privacy - protecting individual privacy except in cases where laws or University policies have been violated, where there is reasonable cause, or where the welfare of community members is at risk
• Responsible Stewardship - determining the use and value of information to the University community within their scope of responsibility, insuring the integrity of information, using information entrusted to the University for the purposes for which it was collected
• Diversity - acknowledging the diverse information needs and security requirements of individual University units, communities of interest, and individuals
• Decentralized responsibility - assigning responsibility for development and maintenance of security practices to individual operating units of the University

University of Michigan Security Principle

A key component of the Security Principle is the principle of "appropriate access." Appropriate access means that for IT security, framed by a risk management analysis, one be given the level of access necessary to perform his/her job. In the case of restricted data, this requires identifying the user's job, determining the minimum set of privileges that reduces the window of exposure for the University and is required to perform that job, and thus, restricting the user to a domain only with those privileges.

Data stewards are those business process owners/individuals who are ultimately responsible to the University for the data assets of their process/function.

Identify Initial Security Architecture Requirements

The initial security architecture requirements are:

• To create an environment that supports the U-M security architecture in the selection of IT technical and software solutions.
• To identify IT policy and practice needs by aligning U-M policy standards and the security architecture elements.
• To provide the service structure required to support the on-going vitality of a robust IT security environment.
• To create Guidelines and Checklists for business process owners, IT service provider, and information providers and users as a method of awareness, monitoring, and feedback.
• To provide on-going training and education programs to foster a culture in which data stewardship and security are an integral part of the U-M environment.

The first model, the "University of Michigan Information Technology Security Architecture Model" (Figure 1), identifies the high-level components and relationships required for a robust Information Technology (IT) security architecture..

Figure 1- University of MIchigan Information Technology Security Architecture

The model is composed of four elements:

1. The internal and external environments, forces and trends that impact the formulation of the institution's IT security policy. These are technology strategy and architecture, university values, academic and business processes, legal and regulatory requirements, and risks and vulnerabilities. All are needed inputs to formulate an organization's security policy.
2. The Security Principle provides a framework for institutional information technology security for the U-M to guide the review, development and implementation of detailed policies and practices and guides the establishment of appropriate expectations for providers and users of digital information at U-M.
3. Security Architecture Elements serve to organize the relationship between the University of Michigan Security Principle and the policy standards and guidelines used by data stewards and IT providers to insure a secure environment. These elements include responsibility for security, risk assessment and management, limited right to privacy, technology infrastructure, ownership and stewardship of data, monitoring, auditing, and education.
4. The lower layer of the model identifies specific Actions -- guidelines and checklists -- that responsible information providers, data stewards and IT service providers must have taken and/or have in place to ensure a secure IT environment.

The second model, "U-M IT Security Policy and Practice Matrix" (figure 2), identifies at a greater level of detail the components required to implement an enterprise security architecture.

Figure 2 - University of Michigan IT Security Policy and Practice Matrix

The model depicts the integrated relationships among six elements, including active elements of training and self-monitoring which are critical to the success of the architecture in a highly distributed collegial environment:

1. The establishment of the "University of Michigan Security Principle" which drives the architecture elements, policies, and guidelines for the architecture
2. The elaboration of the Security Principle into a set of organizing principles around which standards and guidelines can be developed.
3. Standard Practice Guide (SPG), regulations, and regental by-laws which define University-wide standards and assign responsibilities for insuring the architecture is implemented
4. Policy guidelines, business unit and IT provider practices, and the service structure required to support the on-going review and maintenance of these practices
5. Training and education programs to insure that the campus community is aware of the Security Principle, the security architecture, and those policies, guidelines, and practices which affect their work at the University; and
6. An active program of self-monitoring, measurement, tracking, and auditing to insure that policies, guidelines, and practices are effectively implemented

Figure 2 shows the linkages between the Security Principle, architecture elements, policy and regulatory requirements, and University policy guidelines implemented by business process owners in cooperation with IT service providers. A good IT security encompasses the relationship between all three -- prevention, detection, and reaction.3 The model is dynamic, with ongoing monitoring, measurement, tracking, and auditing driving the architecture elements, policy standards, and guidelines. An ongoing training and education program fosters a culture in which data stewardship and security are an integral part of the U-M environment, and where all members of the University community are aware of and act upon their responsibilities.

Implications of the Architecture Model for University Units

The Security Architecture Elements sets forth the method or manner in which each Business Unit should structure their individual security initiatives to ensure they are appropriately and consistently addressing security issues in a reliable manner.

Under the security architecture, University business units are responsible for:

• Adhering to the established baseline global security policy as stated in this document.
• Documenting the minimum security requirements for their unit using the Security Principle as a guideline and educating Unit staff to University and Unit expectations in regards to security.
• Documenting each employee or class of employee's responsibility in regards to security of the data they access.

Under the security architecture, University business units would also be responsible for performing self-audits and risk assessments as part of an ongoing program of business unit risk management. Examples of related activities would include:

• Assigning specific responsibility of managing risk for the unit.
• Conducting and documenting an annual vulnerability and risk assessment.
• Requiring a risk assessment as part of the selection process for new technology resources.
• On-going improvement of appropriate security while supporting business needs.
• Supporting decentralized IT providers and their business needs.
• Making data stewardship decisions in light of risk assessment findings, privacy, and business requirements.

Three Work Groups were created as part of the Task Force effort to complete their assigned tasks:

1. Conduct a high-level U-M IT and security policy review
2. Recommend guidelines for the IT Service Providers and business owner implementing of the security principle and architecture elements.
3. Gain input from national and peer groups to benchmark current and best practices in information security

High-Level IT and Security Policy Review

This task was accomplished in two parts. Initially an inventory of all the U-M IT security policies that could be identified was created. Second, a small work group was charged with reviewing existing University of Michigan policies for identification of outdated and/or missing policies in light of the security principle. They reviewed the inventory and discussed the most effective means for determining shortcomings of current policies, especially considering changes in environment since establishment of current policies. Most notably, the University has quickly moved from a tightly controlled centralized environment where most data or information were managed at the Data Systems Center or central business units and where most data owners were readily identified, to a loosely federated, decentralized environment with similarly decentralized data and data stewards who are thus not as easily identified.

The work group was challenged by the number of possibly relevant policies and was struck by the way that data management has become increasingly decentralized. The group believes that a top-down, centralized review of policies is no longer practical, and that such a review needs to take place with wider, distributed input from all those "in the trenches." The input is needed from:

• Business process owners
• Information&3150;responsible parties
• Providers of information
• IT environment - responsible parties
• Data Stewards
• Executive officers or designees
• IT Service providers
• Data Managers

The work group's specific recommendations are incorporated in the overall recommendations. Their detailed report is found in Appendix B.

Security Principle and IT Service Provider Guidelines

The IT Service Provider Guidelines work group was asked to reviewed the Security Principle and the “U-M IT Security Policy and Practice Matrix” created by the Task Force and identify what was needed to implement the Security Principle and Security Architecture requirements at U-M. They defined their charge to include:

1. Identify the method for internal auditing of security procedures.
2. Set forth the expectation of each IT Service Provider in regards to security procedures.
3. Provide a structure by which capturing best practices can be made available to all IT Service Providers.
4. Provide the IT Service Providers with the current University guidelines that may negate the need for creating an additional unit procedure.
5. Create a mechanism to encourage consistency within the University business units.
6. Provide a self-assessment tool - checklist -- to assist Service Providers in complying with University policies.

The Work Group found that:

1. There is no common repository for collecting current IT Service Provider Guidelines.
2. There are “shadow” SPG sites that may or may not be consistent with the documents maintained by Internal Audits.
3. There is need of a method for communicating best practice guidelines across business units.
4. There are areas such as the OVPR that have guidelines that are not specified in the Standard Practice Guide.
5. There are presently no on-going mechanisms to insure that business units and IT service providers are providing adequate security that is consistent with University policies.
6. There is no central organization responsible for security.
7. There are no guidelines to assure that security violations are addressed in the manner prescribed by University policies.

The Work Group did not feel that they could construct a meaningful set of guidelines and/or checklists that adequately fulfilled the needs for the diverse groups that required them. This would be better accomplished by implementing the following recommendations:

1. An organization should be charged with developing and implementing IT security policies to ensure that these recommendations are implemented.
2. Make available the summary of the U-M security policies and procedures before asking the IT Service Providers to examining their security policies and procedures.
3. Create, implement and maintain on the University IT Security Web Site a template or checklist as the method of monitoring and feedback on IT Service Provider Security Guidelines.
4. IT Service Providers will identify risks and perform appropriate risk and cost-benefit analysis ensuring the security processes put in place are appropriate to the assets being protected.
5. Identify and focus on the top 5-10 security issues from all the IT Service Providers to allow a rapid deployment of best practices.
6. Ask IT Service Providers to share via the Web Site their best practice guidelines.
7. Create and deliver training and education about this Task Force report and the Security Architecture Models to address multiple audiences.

Benchmarking and Best Practices in Information Security

The working group members reviewed web sites of recommended institutions to gain an understanding of what types of principles and policies have been created by other institutions and surveys used by other groups to collect similar information. They then developed a survey to collect information that would inform the Task Force on areas specifically related to the draft statement of principle and discussed in the meetings to date.

A distribution list was developed to include peer institutions based on academic and information technology environments. This included the Committee on Institutional Cooperation (CIC) and the Common Solutions Group institutions as well as an association of higher education Risk Management managers. The survey was sent to Chief Information Officers (CIOs) at approximately 30 institutions plus the Risk Management email list with a short turnaround time. Thirteen institutions returned completed surveys with a few from each of the selected groups. A summary of the results was completed and is attached (Benchmarking Work Group Survey Summary - Appendix C).

The survey suggested widespread existence of information security principles and policy statements among our peer institutions. It is important to note that those with such principles and policies would be the most likely to respond to a survey with a tight timeline because the information would be organized and readily available.

All of the respondents had some policies in all the broad categories identified and at least some of their policies were available online.

The major findings from the survey are summarized below, along with the current status of the University in each area:

1. Only half the institutions have policies on data classification. The University has established data classification procedures within the context of its data stewardship model.
2. About two thirds of institutions have retention/archiving policies. Various business units and IT service providers of the University have established retention and archiving policies, and there is at least one SPG entry which addresses retention of electronic mail. These practices are not coordinated between business units, and the retention policy needs to be reviewed.
3. Only one institution has a risk analysis policy in place. The University does not have a risk analysis policy in place.
4. More than half had a person with the function of information security policy officer. Where institutions have security officers, they generally report to the senior IT leader. The University does not have an information security officer position.
5. Policy appears to be determined/set by the CIO or policy officer with support from a committee and legal counsel, and generally approved by the Provost or President. Additional follow-up work with participating institutions is required to determine the specific processes and methods used. The University's policy development structure allows any executive officer to establish a policy. University-wide information technology policies are ultimately approved by the University Chief Information Officer, although there is no formal mechanism in place to insure that this process is always followed.
6. Most institutions do not have a prescribed review period for IT policy review and revision, and many have not reviewed their information technology policies since they were issued. The University does not have a prescribed review period for IT policy review and revision.
7. Policies are generally posted on web sites, and communication via e-mail and print is commonplace. The University posts its IT policies on a public web site, and periodically issues printed communications about policy issues.
8. Faculty/staff training and awareness programs are less common among responding institutions. The University provides training and awareness programs to entering students, within training programs for application systems, and to technical groups on campus.
9. Most institutions still manage multiple password sets for various applications. Some institutions are using external certificates of authority to access secure information, and others are experimenting with digital certificates, although many are implementing digital certificates. The University uses Verisign and the CREN certificate of authority for some applications, and is developing a KX.509 digital certificate application.
10. Most institutions use several security defense tools such as firewalls, intrusion detection systems, and security evaluation software (i.e., server scanning). The University has implemented a campus-wide site license for anti-virus software, performs server scans on Unix and NT servers, and has implemented several firewalls to protect critical assets.

At a recent meeting of Net@EDU, members were asked how many staff they are dedicating to security of networks and information systems. All schools represented have some sort of dedicated staff. Of the twenty-six respondents 6 had 3 or more staff, 10 had approximately 2 staff, and 10 had approximately 1 person.4 (Information about Net@EDU can be found at: http://www.educause.edu/netatedu/.)

Coordination with UMHS Security Architecture Efforts

The Chief Information Officer of the U-M Health Systems was a member of this task force and reports:

Unlike the academic environment, the Health System has a consolidated approach to information management with only the research, or non-clinical information services, being decentralized. The UMHS physical and logical network are centrally operated and funded, and our production servers, databases and applications are all consolidated and not distributed. We are currently in the process of standardizing all 12,000 production desktop computers and printers into a unified design and deployment philosophy. Most of these efforts were coordinated within the Year 2000 project and the remaining changes were implemented in response to recent budget reductions and departmental reorganization.

The UMHS has been pursuing different strategies for the implementation of security measures in relation to business operation practices and HIPAA. It should be noted that UMHS project policies are designed to coexist with the mission of the research and education community. No action that is undertaken will impact the ability of this community to achieve their goals and, in reality, most of the security activities enhance these groups' abilities to achieve their goals. We have agreed that our policy is based upon open access and freedom of direction. With that in mind, all of our efforts are focused on production systems and applications. Compliance with research and educational needs will be coordinated with campus-based directions and services.

HIPAA looms on the horizon like a cloud, yet the extent of the storm is unclear. What we do know is that when the regulations are actually published we will have 24 months to come into compliance with these regulations. In addition, we know that UMHS is better positioned than most institutions to address compliance changes, as we have a firm human and financial infrastructure.

The University of Michigan Health System began addressing HIPAA almost two years ago and reports the following activities in preparation for the potential regulations:

1. Formation of the necessary leadership groups within the Health System to discuss and outline the issues
2. Executive Management has been briefed and is knowledgeable on the issues
3. Proposed policies have been forwarded to key stakeholders, specifically the Health System
Senior Management Team, Faculty Group Practice and several technology and policy committees
4. Creation of application and data inventories, establishment of a repository and review of priorities with administrative and clinical leadership
5. Definition of both operational and technical leadership for all applications

1. Implementation of a commercial grade firewall solution and a corresponding filter policy
2. Implementation of a system to track all requests and reports for technology based security incidents
3. Implementation of commercial grade intrusion detection services
4. Implementation of recurring scanning services for Novell, NT and UNIX services
5. Formation of an incident response team and process for escalation
6. Deployment of virus tools on production workstations and servers

All of these steps have laid groundwork for HIPAA and we will continue to work in this area; however, we do not plan to specifically react to HIPAA until the regulations are published and the 24 month clock begins.

Finally, the Health System has just funded a $3.5 million dollar project to begin a process of password and related policy consolidation. The goal of this project is to standardize the authentication infrastructure and the processes used to access all production applications. A portion of this funding will be allocated to continue the overall audit of security within the Health System technology environment.

Develop Requirements for Policy Development and Change, Technical Security Architecture, and Related Actions

The Task Force report identifies requirements and recommendations that propose an IT security architecture as well as a working agenda for the upcoming and subsequent years.

A web site, sponsored by the University Chief Information Officer, has been established to provide information and awareness regarding U-M IT security and to provide an easily accessed source of current information. (The U-M IT Security website is no longer available)

HOME

---

University of Pittsburgh
School of Information Sciences
I35 North Bellefield Avenue, 601
Pittsburgh, PA 15260
(412) 624-9370
jmgriff@pitt.edu