For a better experience, click the Compatibility Mode icon above to turn off Compatibility Mode, which is only for viewing older websites.

Security of Information and Networked Systems - Drexel

Overview
Statement of Purpose
Definitions
General
Requirements
Appendices

Overview

Drexel University ("University"), to provide services to its constituents, records a large amount of extremely confidential data, transmits the information over extensive wired and wireless networks, and stores the information on numerous computing systems. Any breach in the security of these systems or networks could disrupt the University and/or allow such confidential information to be transmitted quickly, silently and without geographic or constituency limits.

Recognizing these vulnerabilities and the need for institutions to limit access to such information, the Federal Government has passed numerous laws concerning personal information. As a result, the University must comply with a complex array of legislation including, but not limited to, FERPA , HIPAA , GLB . Failure to comply with legislation can have significant adverse consequences on the University, its academic program, research funding and reputation.

Statement of Purpose

In order to ensure the continued availability, confidentiality, and integrity of University information, to protect critical networks and systems, and to comply with federal law, the Office of Information Resources & Technology (IRT) and the Office of General Counsel (OGC) have established a number of policies and practices, including the Security of Information and Networked Systems Plan ("Plan"). The goal of the Plan is to assure ongoing compliance with federal statutes and regulations related to the Plan and to position the University for likely future privacy and security regulations.

The Plan outlines requirements for all areas of the University, including but not limited to, administrative offices, academic departments, researchers, third party contractors (including food services and the book store), and operators of personal computers connected to the University networks. Accordingly, all handheld, laptop and desktop computers, servers, and other computing systems operated by or for the University or connected to a University network are governed by this policy.

Each person who accesses information or uses or manages a computer by or for the University or connected to the University network must abide by the Plan. All levels of management must ensure that, for their areas of responsibility, each individual knows his responsibilities as outlined in the Plan.
1. The Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g, et seq.
2. The Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191)
3. The Financial Services Modernization Act of 1999,15 U.S.C. § 6801, et seq.

Definitions:

Institutional Data is information relating to the administration of the University.

Protected Data is Institutional Data that that can be linked to any individual, including, but not limited to students, faculty, staff, patients or contractors. Examples of protected data include social security number and credit card information as well as other attributes such as class schedules, grades, and medical diagnosis.

Enterprise Systems are University-wide systems, such as the Banner System, Cactus, Signature, Exeter Student Marketing System, SCDConline (CoOp), Web*Finance, Web*Salary and the BSR Institutional Advancement System. Additional systems may be added in the future.

Computing System is any handheld, laptop or desktop computer, server, or other computing system operated by or for the University and/or connected to a University network.

Server is any Computing System or device that performs functions for other network-connected Computing Systems, including, but not limited to, file sharing (making files available to other systems), web serving, remote control (allowing the computer to be controlled from another location), and peer-to-peer sharing. Computing Systems may perform as Servers unless specifically configured not to.

System Administrator is the individual, either in the Office of Information Resources and Technology or other University departments, who controls and operates a Computing System.

End User is an individual who accesses Institutional Data or uses or manages a computer by or for the University or connected to the University network. End Users may also be the System Administrators for their personal computers; in these cases, they are responsible for the requirements of both roles.

General Policy

At the enterprise level, great care has been taken to ensure that Enterprise Systems, networks, and Institutional Data are protected, secure, and backed up; System Administrators and End Users are required to take reasonable steps to do the same. The Plan and its associated policies provide an outline for meeting this requirement.

Security components of Enterprise Systems include on-going multi-product virus detection and filtering; network monitoring and scanning; the application of patches to repair vulnerabilities in operating systems, databases, and applications; strong passwords and password aging; and external, vaulted protected storage. In order to ensure compliance with recognized standards, external auditors review and test Enterprise Systems and applications on a yearly basis.

In the research area, in order to ensure compliance with federal regulations related to human subjects, the Institutional Review Board evaluates proposals before research begins. The IRB also sets rigorous standards for maintaining the confidentiality of research data.

It is important that the same rigor utilized at the Enterprise Systems level and the research proposal level be applied to the Colleges, Departments and individuals that have access to or may knowingly or unknowingly possess Institutional Data.

Security of Institutional Data

The University is the ultimate owner of all Institutional Data residing in all Enterprise Systems. All Institutional Data, whether maintained in an Enterprise System or copied into other applications and/or computers, remains the property of the University and as such, are governed by the Plan. All levels of management must ensure that, for their areas of responsibility, each End User knows his responsibilities as outlined in this Plan. Each End User, who uses an Enterprise System, prior to accessing the system, must read and abide by this Plan.

All Institutional Data residing on or copied from Enterprise Systems is considered confidential and is intended exclusively for purposes related to the University's administration. All Institutional Data must be used only for the legitimate business of the University and specifically not for commercial, personal and/or political purposes.

Generally, departments and individuals should not have Protected Data on any Server.

Security of Departmental and Personal Computers

Listed below are the policies and guidelines that must be adhered to for Protected Data resident on College or Departmental systems as well as individual devices. The Policies and Procedures are a result of external audit (Deloitte and Touche) recommendations, the recent University-wide risk assessment (Price Waterhouse Coopers), the Office of General Counsel and the Office of Information Resources and Technology (IRT). Compliance with all of the terms and conditions as set forth in this document is mandatory. Failure to do so may result in and may lead to disciplinary action, including termination.

Each End User and System Administrator who accesses Institutional Data or uses or manages a Computing System must abide by the Plan. All levels of management must ensure that, for their areas of responsibility, each System Administrator and End User knows his responsibilities as outlined in this policy.

Requirements

Security Updates

System Administrators must regularly look for and promptly apply security updates for the operating system, operating system components, applications, and anti-virus software. Information about such updates is available from a variety of vendor and user mailing lists and security sites; notification about such updates may also be part of a support contract for the operating system or applications installed on the system. For additional information on security updates, see Appendix 1.

Computing System Registration

Computing Systems acting as Servers must be registered with IRT. Effective in late 2003, unregistered Computing Systems will not be accessible from off-campus. Registration provides IRT with technical and administrative contacts along with information about what kinds of services are running on each Computing System and the risks likely to increase should a registered system suffer a security breach.

Physical Security

System Administrators must maintain adequate physical security to prevent unauthorized access to Enterprise Systems, Computing Systems and Institutional Data.

Accounts Management

Each account on a Computing System or within a software application on a Computing System should be associated with a person; that person is to be held responsible for actions performed by the account. Guest accounts are permitted provided that such accounts are sponsored by a University employee, are given the minimum access required, have a limited life-span, and are disabled when the life-span terminates. Anonymous guest accounts must have limited access that prohibits access to Institutional Data.

Accounts must be disabled when the account owner's affiliation with the University ends. When an employee is terminated for cause, his accounts must be disabled immediately. System Administrators should disable any local accounts and call the Accounts Office (215-895-1958) to notify them of the change.

Password Policies

Computing Systems must use password policies that meet or exceed those of Enterprise Systems. Such policies include activating "strong password" features of the operating system and a minimum password length of 6 characters. All System Administrators must take care to protect the privacy of their passwords and thus may not share passwords or post them on publicly-viewable locations. System Administrators are encouraged to use different passwords for different computing systems so that a security breach on one system does not easily lead to breaches on others. System Administrators must use unique passwords for each "system" account on the computing systems that they manage. For additional information on password policies, see Appendix 2.

Authorization/Access Control

End Users are to be provided with the minimum access privileges required to perform permitted tasks.

Backup and Recovery

System Administrators must have and use backup software to ensure that Institutional Data is protected from loss. It is essential that all Institutional Data on all Computing Systems be backed up daily since recovery from a security breach or hardware failure will likely require a complete reinstallation of the operating system, applications, and data. Recovery methods should be tested to ensure that they function. Offsite storage is recommended for essential data whose recreation would be either time-consuming or unreasonably costly to the University. Servers maintained by IRT are backed up daily, and may be an option for departments unable to provide their own backup service.

Anti-Virus, Firewalls and Intrusion Detection

All Computing Systems that contain or may contain copies or extracts of Institutional Data must run up-to-date anti-virus software. To the extent such software is available and financially feasible, firewall software must be installed and always active; intrusion detection software may also be warranted. In some cases, IRT may elect to manage the firewall and/or intrusion detection software on a Computing System. For additional information on firewalls and intrusion detection, see Appendix 3.

Security Scans

All Computing Systems are subject to security scans by IRT. The technical and administrative contacts of registered Computing Systems will generally be told of a scan in advance and will be provided with the results of the scans. In the event that it is determined that the Computing Systems are susceptible to high- and medium-security risks, the System Administrator must cure the problem within 5 working days or be expressly excused by the IRT. Systems Administrators should routinely monitor system logs to check for anomalies.

In Case of Breach

System Administrators who believe that the security of their Computing Systems has been breached must contact the IRT Security Staff (215-895-6666). System Administrators shall not delete or otherwise alter any programs, data, or other files on the system without prior express permission from IRT; doing so could result in the destruction of valuable evidence. If IRT Security Staff becomes aware of a possible breach before the System Administrators, IRT may disconnect the system from the network to minimize risk and liability for the University. No one may reconnect a disabled device to the network without prior express permission from IRT.

Enforcement

Failure to comply with the above policies may result in disconnection of network service and/or disciplinary action against the End User, System Administrator, and/or department head of the department operating a Computing Systems outside of these policies.

Appendix 1

Security Updates

Computing System security requires vigilance. Software or practices that were considered secure yesterday may be vulnerable today. Consequently, it is essential that System Administrators stay current. Tools for doing so have proliferated in the last few years.

All System Administrators of Microsoft Windows machines should use the Windows Update site installed. Microsoft also provides a free tool called the Baseline Security Analyzer which is helpful in understanding and correcting vulnerabilities. Other operating systems have their own sites and mailing lists for staying abreast of vulnerabilities and patches.

Below are some IRT recommended sites for information and tools:

http://windowsupdate.microsoft.com
Windows update site for patch downloads and installation

http://www.microsoft.com/technet
Security tools from Microsoft including the IIS lockdown and Baseline Security Analyzer)

http://www.microsoft.com/security
Microsoft maintained site for detailed patch information, recommendations and links.

http://www.linuxsecurity.com
Linux Security Newsletter and Security Advisories Weekly are mailing lists for security related information, both Linux specific and more general.

http://www.sun.com/security
Sun maintained site with links for mailing lists, patches, recommendations, education and other useful security sites. To receive security bulletins directly from the Sun Security Coordination Team, send an email to security-alert@sun.com and include subscribe cws [your email address] in the subject. For example: subscribe cws alex.smith@sun.com

Appendix 2

General Password Policy

This Appendix is derived from a template provided by The SANS (SysAdmin, Audit, Network, Security) Institute .

Overview

  • All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed every 30 days.
  • All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every 63 days.
  • User accounts that have system-level privileges granted through group memberships or programs such as "sudo" must have a unique password from all other accounts held by that user.
  • Passwords must not be inserted into email messages or other forms of electronic communication.
  • Where SNMP is used, the community strings must be defined as something other than the standard defaults of "public," "private" and "system" and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
  • All user-level and system-level passwords must conform to the guidelines described below.


General Password Construction Guidelines

Passwords are used for various purposes at the University. Some of the more common uses include: user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), End Users must be aware of how to select strong passwords.

Poor or weak passwords have the following characteristics:

  • The password contains fewer than six characters
  • The password is a word found in a dictionary (English or foreign)
  • The password is a common usage word such as:
    • Names of family, pets, friends, co-workers, fantasy characters, etc.
    • Computer terms and names, commands, sites, companies, hardware, software.
    • Organization, place or event names like "Drexel", "Philly", "SuperBowl" or any derivation.
    • Birthdays and other personal information such as addresses and phone numbers.
    • Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
    • Any of the above spelled backwards.
    • Any of the above preceded or followed by a digit (e.g., secret1, 1secret)

    Strong passwords have the following characteristics:

    • Contain both upper and lower case characters (e.g., a-z, A-Z)
    • Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-=\`{}[]:";'<>?,./)
    • Passwords for Banner and WebFinancials must begin with a letter and cannot contain these characters: $ ! & " or '
      • Are at least seven alphanumeric characters long.
      • Are not a word in any language, slang, dialect, jargon, etc.
      • Are not based on personal information, names of family, etc.

      Passwords should never be written down or stored on-line. End Users should try to create passwords that can be easily remembered. For example, an End User can create a password based on a song title, affirmation, or other phrase, e.g. the phrase might be: "This May Be One Way To Remember" and the password could be: "TmB1w2R!" or "Tmb1W>r~" or some other variation. NOTE: Do not use any of these examples as passwords!

      Password Protection Standards

      End Users should not use the same password for University accounts as for other non-University access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, End Users should not use the same password for various University access needs. For example, End Users should select one password for the Engineering systems and a separate password for IRT systems. Also, End Users should select separate passwords for a Windows domain account, a UNIX account, an Oracle account, and an LDAP account.

      End Users must not share University passwords with anyone, including administrative assistants, secretaries, graduate assistants, or the help desk/technical support staff. All passwords are to be treated as sensitive, confidential University information.

      Here is a list of "don'ts":

      • Don't reveal a password over the phone to ANYONE
      • Don't reveal a password in an email message
      • Don't reveal a password to the boss
      • Don't talk about a password in front of others
      • Don't hint at the format of a password (e.g., "my family name")
      • Don't reveal a password on questionnaires or security forms
      • Don't share a password with family members
      • Don't reveal a password to co-workers while on vacation
      • Don't reuse passwords in the course of one year
      • When changing a password, don't derive it from a previous password (e.g. TmB1w2R!-1 becomes 1TmB1w2R!-2)

      If someone demands a password, the End User should refer him to this Plan.

      End Users should not use the "Remember Password" feature of applications (e.g. Internet Explorer, Outlook, etc.).

      End Users should not write down passwords or store them anywhere in their offices. End Users should not store, without encryption, passwords in a file on ANY Computer System, including PDAs..

      End Users must change their passwords at least once every nine weeks (except system-level passwords which must be changed monthly); the recommended change interval is every month or two.

      When an End Users suspects that his account or password has been compromised, he must report the incident to IRT and change all of his passwords.

      IRT may, on a periodic or routine basis, test the security of End User passwords. If IRT determines that password is weak, the End User will be required to change it.

      Application Development Standards

      • Application developers must ensure their programs contain the following security precautions. Applications:
      • Should support authentication of individual users, not just groups.
      • Should not store or transmit passwords in clear text or in any easily reversible form.
      • Should provide for some sort of role management, such that one user can take over the functions of another without having to know the other's password.
      • Should support RADIUS and/or X.509 with LDAP security retrieval, wherever possible.
      Appendix 3

      Anti-Virus, Firewalls and Intrusion Detection

      All Windows or Macintosh Computing Systems should have anti-virus software installed. Anti-virus software for Windows- and MacOS-based Computing Systems is available at no charge from IRT. Mail Servers should have anti-virus scanning software installed.

      Servers should have firewalls and, in some cases, intrusion detection software installed. Sample rule sets for firewalls will be provided upon request for most software configurations.

      IRT recommends the following security tools for Servers:

      http://coombs.anu.edu.au/~avalon/
      Solaris and FreeBSD servers and workstations install and configure the IPFilter firewall suite.

      http://www.netfilter.org/
      IRT recommends Linux servers and workstations install and configure the IPTables firewall suit.

      http://www.zonelabs.com/
      IRT recommends Windows servers and workstations install and configure the Zone Alarm Firewall suite.

      http://www.snort.org
      For both windows and Unix operating systems IRT recommends the SNORT intrusion detection system.