Security of Information and Networked Systems
Plan
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
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.
APPENDICES
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.vulnwatch.org/subscribe.html
Vulnerability Disclosure List includes information on multiple operating
systems related to vulnerabilities and patches.
http://ntbugtraq.ntadvice.com
NTBugTraq is an independent mailing list for vulnerabilities, patches
and discussion of Microsoft NT, 2000, XP and 2003 operating systems.
http://www.microsoft.com/security
Microsoft maintained site for detailed patch information, recommendations
and links.
http://www.linuxsecurity.com/general/newsletter.html
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
Password Policy
This Appendix is derived from a template provided by The SANS (SysAdmin,
Audit, Network, Security) Institute .
General
- 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.
Guidelines
A. 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!
B. 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 "dont's":
- 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 (eg. 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.
C. 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.
Last Updated 7/31/03 by Annette Rivera, IRT. |
