Ohio University is open; Water service has been restored to buildings on and around University Terrace

 
OIT Tech 32px
security_4

Registration Process for Academic and Research Systems

Statement of Principles

The development and implementation of the procedures described in the document are governed by these principles:

Academic Freedom is essential for the mission of the University.  Academic, legal use of the network by faculty shall not be restricted unless a reasonable case for network or data security is presented for why an activity cannot be supported. OU is a community of scholars, and our infrastructure -- including IT -- must be aimed at supporting the pursuit of knowledge, and academic investigation and exploration.

Discipline Independence shall be maintained regarding academic computing.  Faculty across disciplines will not receive differential access, control or level of service.  E.g., a member of the Fine Arts faculty may access the same sites, deploy the same systems, and receive the same support as an Engineering faculty member.  Faculty will not be restricted from academic technical pursuits based on discipline or other subjective criteria.

Security is always relative to the risk that a system presents.  Best practices for security controls are always in the context of the particular industry and risk.

Preamble

According to the presidential directive ("Directive One") on the unification of information technology services, dated August 11, 2009, all servers are now the responsibility of the Office of Information Technology. In some cases, systems, and the services they provide, will be physically moved to the central data center at Ohio University.

  1. If there is undue risk associated with a service, then the system should be moved to the OIT data center.

  2. Services that are intended for departmental, administrative, and/or university functions should be moved to the OIT data center.

  3. If a service is already provided by OIT it should not be duplicated outside OIT.

  4. If a service is part of the University mission of teaching, service, research, and creative activity and does not meet the criteria above, then it may be operated outside OIT subject to the provisions in this document. 

The   decision to move services will be made by the College Dean or designee and  representatives from the Office of Information Technology (OIT) based on  the above criteria.  Appeals to this decision will be made to the Chief Information Officer.

Example - Web Server Instruction:  

Dr. Smith teaches a class in which she instructs students on how to develop dynamic web pages.  She has set up her own web server running Linux, Apache, MySQL and PHP (LAMP) so that the students can program on it.  Since the creative and academic activity here occurs at the application development layer, the preferred solution is to have the management (patching, backup, etc.) of the LAMP stack itself performed by OIT (once OIT has the ability to dynamically provision LAMP instances).  However, the professor will retain the ability to manage the accounts in the database, as well as start/stop the web server, and running code on the system. Since the system is operated by OIT, no registration is required.   If creating and configuring the server is part of the educational purpose of the class, Professor Smith will continue to manage her server.  If the servers exist beyond the academic term, she should register them with OIT.

Example - Department of Defense Grant: 

Dr. Foster does research for the Department of Defense.  The information on this system is of a highly classified nature, and requires clearance to access.  The grant for the system details significant penalties if access is granted even to the operating system to individuals who have not gone through the appropriate government clearance process.  Because this system clearly contains sensitive data, it must be registered.  OIT will perform regular vulnerability scans, with the results being provided to the professor for appropriate remediation.  Note that the access control requirements of the grant prevent the system from being moved to the OIT data center.

Example - Physically Attached Equipment:

Dr. Singh has a system that is physically attached to an Electron Microscope.  This system cannot be moved to the Data Center without significant change to all processes.  She will maintain physical possession of the system, but may make arrangements with OIT to assist in managing the operating system.  This system should, however, be registered.

Example - Workstation with Remote Access:

Dr. Jones has a workstation that he is uncomfortable migrating to Active Directory due to some of the material that it contains.  While the decision as to whether it should be joined is to be made by the College’s Dean’s office and OIT, if it is not joined, it should still be registered, in order to take advantage of the registration benefits.

Definitions

System: A system is either comprised of the physical hardware making up a computer, or a virtual machine instance.   The term system incorporates the operating system and applications running under that operating system.

Service: A service is housed on a system, and is defined as the application(s) and the data needed to provide some specified function to a user who accesses this function remotely via the network.

Server: A server is defined as a system that as its primary function provides one or more service(s).

Sensitive Data: If the loss or unauthorized disclosure of a set of data poses a significant threat to the reputation or mission of the University, or to intellectual property, legal compliance, financial health of the institution, or to life and liberty of its personnel, the data is considered sensitive for the purpose of this document.  Data covered by HIPAA, FERPA, ITAR and other export controls, trade secrets, and classified data are all examples of sensitive data.

Statement of Purpose

This document deals with any system that does not meet the criteria for being moved to the OIT data center; the express purpose of the procedures described herein is to insure that systems operated by faculty in pursuit of teaching, research, and creative activity are maintained in a manner that keeps these systems secure and prevents them from interfering with the operation of the Ohio University network.

To accomplish this goal, OIT has established a registration procedure for systems that are connected to the network, but are not administered by OIT.  This registration requirement does not apply under the following conditions (although there is still some added benefit in registering such systems):

  1. The system provide no services as defined in this document, or

  2. The system has been joined to the Ohio University Active Directory domain, or

  3. The system is "temporary", meaning it is intended to operate for no more than 30 days, and contains no sensitive data, or

  4. The system is used during an academic term for educational purposes and contains no sensitive data.

  5. The system is not hosted on the University network.  However, these systems need to follow the Outsourcing Technology process as identified at http://www.ohio.edu/technology/security/Security-Standards.cfm.

All other systems must be registered with OIT using the procedure described below.

Security Threats and Impact

Security Threats generally fall into three categories.

Administrative:

These typically involve the "business processes" around the system. This can include:

  • How information is transferred from one authorized individual to another.  The threat is the 'oops, I didn't mean to post it there'.

  • The handling of the data - accidental deletions, changes, etc.

  • Social Engineering attacks: These attempt to exploit part of the business process and/or trust of an individual to gain undue access to a system, data, or other valuable asset.  

Technical:

Technical threats includes those things that can occur over the network or on the system itself.  These can include:

  • Malware: including worms, viruses and trojans, these programs exploit weaknesses in computer systems, or users trust to achieve a variety of results.  These often (not always) require the user to perform some action to trigger the attack, such as browsing a web site or opening an e-mail attachment.

  • Automated scans: These run constantly on the internet, and are often used by individuals with malicious intent to determine weaknesses in systems.  The motives vary from thrill seeking to financial profit. The purpose of the scan may be in itself an attack (attempt to gain access to the system), or to prepare for a targeted attack.

  • Targeted Attacks: Either as the result of automated scans or having a specific goal, these are from malicious individuals seeking to gain access to a specific system.  They will often employ a variety of tools to achieve their ends.

Physical:

  • Environmental: Flood, power outage, power surge, fire, etc.  These can cause actual physical damage to a system as well as data loss or corruption.

  • Theft: If not adequately secured, the system could be stolen.

  • Vandalism: Even if a system is not stolen, it could be physically damaged (smashed, wires cut, etc.).

If a security incident takes place, it can have an impact both on the individual user as well as the University as a whole:

Individual:

  • Data Breach: Sensitive data is disclosed to an unauthorized party.
  • Data Loss: Sensitive or valuable (research) data is lost (e.g., files are erased or a storage device is corrupted).
  • Denial of Service: The system suffering from a successful attack and other machines on the network become unusable at least for a period of time.
  • Data Corruption: Sensitive or valuable (research) data is corrupted due to the actions of an attacker.

University:

  • Privilege escalation/Foothold: an unauthorized individual may be able to circumvent additional security controls.  This could lead to further attacks either inside or outside the University.
  • Data Breach: Other sources of sensitive data may be disclosed as a result of the initial compromise.
  • Reputation: The University may suffer a loss of reputation, revenue or service.
  • Fines and penalties: The University may have fines and or penalties levied against it as a result of the outcome.
  • Difficulty of securing future grants: It may become more difficult for the faculty member, or University as a whole to secure future grants.

Benefits of Registration:

Every user of the OU network carries responsibility for data and system security.  Faculty with access to sensitive data need to safeguard these data.  In the case of research results, loss or corruption of data has a very immediate impact on faculty.  In all cases, the University faces potential liability and expense if a breach occurs.   Every system on the OU network can, if compromised, disrupt service for other users or be used by an attacker as a spring board to gain unauthorized access to sensitive data.

OIT has systems in place to detect many types of security breaches.  The network is designed to disconnect compromised systems from the network.   Without further information, the owner of the compromised system cannot be notified; rather, the system owner has to discover that the system has been disconnected and contact OIT to begin remediation.

OIT has a wealth of experience and expertise in securing a variety of systems.  OIT also runs a suite of automated tools that can identify a system as being vulnerable to attack; however, without further information OIT cannot contact the system owner to suggest remediation steps before an attack on that system succeeds.   If a system is found to be so vulnerable as to make a successful attack highly probable, the system may be treated as compromised and disconnected from the network.

Registration of a system accomplishes several goals:

  1. It assures the system owner that -- at the time of registration -- all reasonable security measures for the system are in place.
  2. It insures that OIT can contact the system owner if later scans reveals a vulnerability, thereby preventing an attack and the potential loss of data or abuse of the system.
  3. It insures that OIT can reach a system owner quickly in case of a security breach, making it more likely that a disruption of service will be brief, and possibly minimizing or preventing the loss of data.
  4. It makes OIT aware of all information assets across the University.  This allows the University to design the network and other technology resources in a way that more effectively meets campus needs.
  5. The system owner acknowledges their responsibility for maintaining the safety and security of the information assets on their system.

Process for Registering a System

  1. Fill out the form located at https://www.ohio.edu/oit/distributedservers/
  2. Once the system's form has been received, it will be compared with the latest vulnerability scan and reviewed as soon as possible by the Information Security Office.
    1. If a scan hasn't been performed on this system yet, a scan will be performed during the review period.
    2. If any clarification or changes are needed, a member of the Security Office will contact the requestor for follow up.
  3. The Security Office will notify the requestor as to whether the system requires changes to operate securely, and if needed, get the requestor in touch with the right resources if additional support is needed.
  4. On a quarterly basis, the Security Office will generate reports to the CIO, all deans and department chairs to inform them of the systems that have been registered in their department.