The University of Iowa Enterprise Security Architecture

Written by the Information Technology Security Team

March 1998

Table of Contents

Executive Summary
Introduction
A. Information Security Defined
B. What is a security architecture? Why do we need one?
C. Security as a Process
D. Related issues
Security Policy
A. Application
B. Enforcement
Existing Security Services
A. Identification and Authentication
B. Authorization and Access control
C. Confidentiality
D. Data integrity
E. Non-repudiation
Future Direction
A. Risk Assessment and Management
B. Policy
C. Awareness
D. Technology and implementation
E. Security Management
F. Audit
Bibliography
Information Technology Security Team Members
 

Executive Summary
 

A security architecture describes the services, mechanisms, and objects which reflect the security policy, business functions, and technology of an enterprise. The primary function of a security architecture is to ensure a common level of understanding and a common basis for design and implementation, by everyone sharing the same information resources.
 

Securing information resources is an iterative, cyclical process, involving risk assessment and management, policy, awareness, technology and implementation, security management, and audit functions. This document defines what a security architecture is, as well as the process and evolution of one. A security architecture captures a point in time, but it also describes the future in terms of what is to be done next.
 

By sharing this document with the campus, the IT Security Team hopes to educate and inform the campus of the direction we will move in, to improve the efficiency and effectiveness of our IT protections.
 

Specifically, it is proposed that

A notion not specifically described in this document, but inherent in the ideas proposed, is that of opportunity cost. As weeks go by, more directories are created, and more convoluted methods to connect and synchronize them are developed. As weeks go by without a strong, central authentication service, applications are deployed with weak security just to get them going. High level support in the form of resources (staff commitment as well as funds) is critical for our success.
 

Introduction

A. Information Security Defined

Security can be defined as safety, or a state of being free from doubt or danger. As it relates to information, security involves protection from damage or attack, being stable, reliable, and free of failure. Another way to think of it is a guarantee. Securing information is guaranteeing its confidentiality (levels of privacy), integrity (being complete and true), and availability (being accessible).
 

B. What is a Security Architecture? Why do we need one?
 

An architecture is a design, or plan, for constructing something. It can also be looked at as a framework for a system, which includes aspects of appearance, function, location, and materials. A security architecture describes the services, mechanisms, and objects which reflect the security policy, business functions, and technology of an enterprise:



Each service is implemented by the use of an appropriate security mechanism or set of mechanisms. The mechanisms act on the defined security objects (Data, Hardware, Application) providing the service that supports the policy intended. This set of services, mechanisms, and objects are used to select those functions that will implement the defined system security policies.
 

If an organization processes data through interrelated applications, shared or common databases, connected systems, and telecommunication, it has an architecture. It may not be formally documented, but it is there. The primary function of a security architecture is to ensure a common level of understanding and a common basis for design and implementation, by everyone sharing the same information resources. Security architecture involves languages, document and data structure, processes, data exchange, and control interfaces. It allows an enterprise to express its policy (management desire) and strategy (approach) for security in a coherent manner, in order to effectively design protected systems of information technology.
 

C. Security as a Process
 

The process of securing information systems is a cyclical, on-going effort with involvement from all levels of the organization. It can be visualized in terms of six stages:


 

D. Related Issues
 

Business controls are closely related to security, although they involve quality of information and correctness of processing, which are an integral part of application logic. Business controls are different and separate from access controls, and should be not be considered a part of security. The process of access control, which is concerned with the who, how, what and when of accessing information, on the other hand, is a component of security.
 

Continuity involves system availability from the perspective of preventing disruption, or having persistence. It has both preventative and reactive components. Failure reduction (preventive) is often as important as recovery (reactive) in a continuity plan. Availability from the security angle is concerned with obtainable or accessible information.
 

The whole notion of information protection involves all three areas: security, continuity, and control. Other than acknowledging that they are interrelated, however, this architecture focuses on security, rather than continuity or business controls.
 

Security Policy
 

A. Application
 

The University Appropriate Use of Information Technology Resources Policy (Acceptable Use Policy) can be found on the Web. It is a high-level policy that relies heavily on existing University policies and local, state, and federal laws. It is based on the premise that misuse in the IT environment is not fundamentally different from misuse in other venues. Therefore, the existing policies and laws governing acceptable behavior apply equally in the IT environment. The policy sets a standard for ethical behavior, without expressly enumerating examples of acceptable and unacceptable behaviors.
 

Now that the policy has matured (it was adopted in June 1995), it is being revised to more explicitly describe an acceptable standard of behavior. Included in the proposed additional wording is the requirement for maintaining computer security in accordance with best practices.
 

As the time of this writing, the AUP team is wrestling with the wording to precisely express rights and responsibilities under the policy. The team hopes to have the policy out for campus review in 3Q98.
 

Information Technology Services' Administrative Computing security policy can also be found on the Web. The primary points of that policy are that all information will be secured physically and electronically, all users of information will be individually identified, all applications and systems will be password protected, and all access authority requests will be documented.
 

The University of Iowa Hospitals and Clinics Information Security Policy General Statement, similar to the ITS Administrative Computing Security Policy, cites that sensitive information in all its forms, and throughout its life cycle will be protected from unauthorized access, modification, destruction, or disclosure, whether accidental or intentional. This protection will be provided through equipment and software, as well as routine handling procedures used to access, process, store, and transmit the information. The UIHC policy goes on to further describe policy relating to the role of the HIS Advisory Subcommittee (the policy and procedure group for UIHC), for the Ownership of and Accountability for Computer Information, for Computer Information Access, Physical Access to Computer Facilities, and policy regarding Compliance.
 

The University AUP and Administrative Computing security policies are quite broad, leaving them open to interpretation. The UIHC policy is more specific, and directly relates to UIHC-owned patient information, which has unique legal and moral requirements for its protection.
 

A fourth source of direction are the University's Institutional Data Access Policies. A comprehensive methodology needs to be developed to help define and classify our institutional data. Information Technology Services should take a leadership role in developing such a tool. Once classified, controls can be applied to applications and systems which are appropriate to the data involved. The general Institutional Data Access Policy (in draft form) states that access to institutional data will be provided as necessary for the performance of one's job, that University policy and legal requirements will determine the level of confidentiality of institutional data, and finally, that the University will take appropriate measures to assure the integrity of institutional data.
 

Having these University of Iowa policies and standards in place, we apply them towards development of an Information Security Architecture. As previously stated, a security architecture will help us do this in a constructive manner, and will assist with the interpretation of policy.

An alternative way to look at the process of securing an enterprise is through this layered model of validation, which begins with policy and standards, and ends with auditing and monitoring to validate the policy. The hierarchical model illustrates the basis for security, which is policy and standards. Each layer in the hierarchy involves validation of the previous layers.
 

B. Enforcement
 

In the event of violation of University Acceptable Use policies, procedures or laws, the University will follow its current disciplinary policies and any other of its practices and policies, including those regulating the provision of information to law enforcement authorities. The University shall not examine or disclose the contents of electronic files except when authorized by the owner of the information, when approved by an appropriate institutional official, or as required by local, state, or federal law.
 

Sanctions for faculty or staff violations of policy may include a reprimand, loss of user privileges, termination of employment, or, in the case of a student violation of policy, probation, suspension, or expulsion from the University.
 

Existing Security Services
 

A. Identification and Authentication
 

Identification and Authentication is a process for verifying or proving the identity of an individual. Identity is commonly based on a user identifier, or User ID. There are many methods of performing authentication, ranging from a weak User ID/password combination, to a stronger (one time use) password token, to biometrics such as a fingerprint or retina scan.
 

A survey of authentication methods and related information for representative systems on the U of I campus was compiled in the summer of 1997, resulting in the following observations:
 

It is proposed that the University implement an immutable identifier for members of its community as well as other information technology entities (such as servers). This identifier is distinct from a login ID, SSN, employee number, or system name. It is absolutely unique and never changes throughout the time an entity is associated with The University of Iowa. This identifier will be housed in the centralized campus directory service, and will be used in various applications and services to ensure reliable identification.
 

In addition, it is proposed that the University adopt a policy requiring all user identifiers (login IDs) to be unique across campus, and that the definitive source for those unique identifiers be the central campus directory service. The de facto standard for the unique login ID will be first initial and last name up to a maximum of 8 characters. However, since this standard does not ensure uniqueness, other (maximum 8 character) identifiers may be used, as needed, as long as they comply with the proposed campus uniqueness policy.
 

Finally, as the central campus directory service evolves, it is proposed that it be configured into a centralized authentication service as well, using public key (certificate based) technology. Initially, a simple login ID and password form of authentication will be used for the central directory service.
 

B. Authorization and Access Control
 

Who can access information, how it can be accessed, when it can be accessed, and under what conditions it can be accessed are questions answered by authorizations, which can be thought of as permissions and approvals.
 

Administrative Computing policy states that the owner (or custodian) of data is the person or body from which authorizations flow. In our environment as a state-owned public institution, much of our data is considered public. However, it is currently the data custodian's responsibility to determine how and under what circumstances access to institutional data occurs.
 

Operationally, access controls are often in the form of a list. That is, for a given object (file, application, data record, etc.) there is a list of user IDs and/or groups that are authorized to access it. The access control list is the physical implementation of an authorization. Authorizations for central systems are currently documented in paper form, and require multiple signatures before they are processed into access controls.
 

A newer form of access control uses a role-based model, which is based on user attributes. That is, an authorization server (such as an appropriately configured directory) can hold attributes about a person, which can then be used to determine access control within an application. A simple example might be that all objects in a directory that have the "staff" attribute associated with them would have authorization to use MFK (master file key) validation routines. A more complex example might be that all users with the attribute "advisor" would have access to academic class opening lists. The beauty of this access control model is that attributes are maintained in a single location, and changes are automatically and immediately reflected in all applications which utilize it.
 

The following statements describe current authorization and access control methods and procedures:
 

It is proposed that as the central campus directory service evolves, it should be configured into a centralized attribute-based authorization service. Initially, the directory service will provide simple person-attributes, such as "faculty", "staff", and "student". As the directory service evolves, it will be configured to provide the definitive source for other application-specific attributes. Examples might be those persons registered for a specific class, or having a certain degree-major, or persons employed in an advisor capacity.
 

C. Confidentiality
 

Protecting sensitive or private information from disclosure, through access controls or encryption, is the issue of confidentiality. Many types of information are found at the University, from research data, business process data, student records, fiscal data, and programs, to correspondence, designs, and creative works. University policy with regard to confidentiality of Institutional Data and other information repositories owned by the University must be complied with by all information technology service providers on campus. In addition, there are legal and moral issues involved with protecting sensitive information, such as student grades, medical records, and various demographic and personal information.
 

Ensuring confidentiality of data involves applying controls to computer operating systems, files, and databases which comply with policy. Tools are available to provide this level of control, or they can be built into applications and systems for the same outcome.
 

The challenge is for the University to clearly define what is considered private or sensitive. Data classification is essential to a good security program. Data owners classify their data according to a data classification scheme. Classification then provides the security administrator the means to make informed decisions and recommendations on the strength of the security surrounding the data.
 

It is proposed that ITS and/or the proposed Information Security Office take up the task of defining and adopting a data classification methodology, including a tool which data owners can use to assist them in classification of institutional data.
 

D. Integrity
 

System integrity is the ability of an operating system to prevent circumvention or bypassing of its security mechanisms, and is the responsibility of system administrators. Current and complete backup and recovery systems are expected, to protect the investments of the University in the event of a system error, as well as in the event of an intentional attack or unintentional modification of computer systems.
 

Data integrity is the ability to detect unauthorized modification of data, either through transmission errors, or through attack. While backup systems play a part in ensuring the integrity of data, in most instances programmed controls and other checks and balances are the responsibility of the application(s) which process and present the data.
 

E. Non-repudiation
 

Related to data transmission, non-repudiation is verification that a message can be associated with an individual. Digital certificates, similar in nature to a drivers license, are the most common form of non-repudiation in computer systems today. In messaging systems, a certificate can be attached to a message to verify you as the sender. As in the case of a drivers license, in which the state has verified your identity, a digital certificate is verified as being owned by and representing you by the issuer as well as by other certificate authorities who can "sign" it as a form of verification.
 

It is proposed that the University receive, through the public key (certificate based) authentication mechanism described earlier, the dual benefit of a system to provide non-repudiation of messages. This technology will absolutely be required in an environment utilizing electronic commerce (Internet marketing and sales).
 

Future Direction
 

We have identified the components of a security architecture and the process required to construct the architecture. Because the security threats and risks are always changing, we believe the best approach for advancing the security architecture is to take an incremental and iterative approach.
 

A. Risk Assessment and Management
 

A systemic risk assessment framework should be established. Risk assessments form a basis for determining how risk could be managed to an acceptable level. The risk assessment approach should focus on the examination of the essential elements of risk such as assets, threats, vulnerabilities, safeguards, consequences, and likelihood of threat. Risk acceptance should ensure the formal acceptance of any residual risk, depending on risk identification and measurement, organizational policy, and the cost effectiveness of implementing safeguards and controls. Thorough risk assessments should be completed prior to deploying new systems and applications.
 

ITS should continue to participate in the CIC sponsored Risk Assessment sub-team of the Security Team. Special emphasis should be placed on applying knowledge gained from that team to the University environment. Network, server and workstation risk assessments should be performed as described in the Network Security Scanning Service document.
 

B. Policy
 

The revision of the University Acceptable Use Policy should be completed and published. ITS, in partnership with data owners, should continue their work on developing an institutional data access policy. A permanent Policy Repository should be constructed and maintained. All policies should be reviewed prior to being submitted to the Policy Repository.
 

Policies should be re-evaluated regularly, and new or revised policies developed when necessary. The Repository can include more than security-specific policy when applicable, such as the previously mentioned business controls and continuity.
 

C. Awareness
 

Policies should be communicated to everyone covered by that policy, and steps should be taken to ensure understanding and compliance. The Policy Repository should be easily available and understandable.
 

Awareness of security issues will create and foster a positive internal control environment throughout the entire organization. Communication of security aims and directions will aid in compliance. ITS should continue to sponsor security related tutorials and seminars like the CIC NT Security and Network Scanning seminars held last year. The proposed Security Office would function as a primary source of awareness programs.
 

D. Technology and Implementation
 

A comprehensive systems development life cycle (SDLC) methodology for centrally supported applications should include a security test and accreditation before approval and promotion into production status. Within the SDLC framework, the change management component should also include a security test and accreditation before approval and promotion. The SDLC should encompass emergency fixes, master data, hardware and software configuration elements, security updates or changes, and new technology. The SDLC methodology can also be adapted for departmental systems and applications, to provide a similar framework for security testing. It can be as simple as a checklist or form to be included with the documentation for the system, or as complex as an audit visit.
 

The collaborative work of CIC and Big Ten Security related teams should be applied to the University of Iowa environment. Further integration with directory services team efforts should be encouraged.
 

E. Security Management
 

Security management responsibility should be established at an organization-wide level to deal with overall security issues. Assuring both logical and physical security of the University's information assets should be the responsibility of an information security manager. Global security oversight can provide a comprehensive view of the diverse computing environment and help identify and correct unacceptable levels of risk. The efforts to identify a enterprise-wide security management tool suite should continue.
 

F. Audit
 

The audit process should be closely tied with the SDLC in a proactive manner. Auditing can be done by external and internal audit functions, as well as security management and information technology personnel. Auditing is the continuous review of security controls and security events, and is closely tied with risk assessment and management, as well as with data classification efforts. Awareness of internal controls should be promoted, and should be integrated with security programs as they are developed. Procedures would include the regular review of relevant (ex. exception, login) reports, self-assessments, bench-marking, implementation of supporting systems, and the clearing of internal and external audit recommendations.
 

The Internal Auditor's office should continue to promote its partnerships, the concept of preventative measures, and CobiT audit methodology education with the various IT providers and business units on campus.

 

Bibliography
 

"Taking an Architectural View of Security", Harry B. DeMaio, ISPNews, November/December 1990.
 

IBM Security Architecture, SC28-8135-01,Second Edition, June 1995.
 

"An Information Security Policy Framework", G. Lynch, Gartner Group Research Note, April 29, 1996.
 

"Enterprise Security Architecture", William Hugh Murray, Enterprise Security Expo '97 Conference Presentation.
 

CobiT: Control Objectives for Information and Related Technology, Information Systems Audit and Control Foundation, April 1996.

 

Information Technology Security Team Members
 

Cynthia Bartels Internal Audit
Mary Jane Beach Finance and University Services
Deb Cannon Internal Audit
Lee Carmen College of Medicine Administration
Jane Drews Information Technology Services - Systems
Doug Eltoft College of Engineering - ICAEN
David Funk College of Engineering - ICAEN
Romeyn Jenkins Information Technology Services - Application Development
Ila Miller UIHC - Information Systems
Mike Noel Information Technology Services - Institutional Data
Chris Pruess Information Technology Services - Customer Relations
Rex Pruess Information Technology Services - Systems
Ron Rathjens Information Technology Services - Network Engineering
Matt Stilwell Finance and University Services
Dale Wilhelm UIHC - Information Systems

This document last updated May 7, 1998 JED

Copyright © 2005 The University of Iowa. All rights reserved.