University of St. Thomas Site Security Policy...

 

Under development according to the guidelines provided by IEEE RFC 2196: Site Security Handbook.

Risk Assessment

Purpose: To identify assets including, but not restricted to hardware, private information, intellectual property, and personnel and identify potential risks to those assets.

 

Asset Identification

• Hardware: routers, switches, hubs, servers, modems, printers, workstations, backup solutions, handheld devices, wireless access points, terminal servers, storage subsystems
• Software: Administrative systems, web servers, email, operating systems, licensed software, personal data and documents
• Data: Removable media (including magnetic tapes, CD-ROMs, floppy disks, Iomega disks, and other formats and form factors); on-line data in databases and files; paper forms, printed reports, and imaged documents
• Personnel: Administrators, hardware maintainers, users (faculty, staff, students, contractors, vendor support technicians)
• Documentation: on programs, hardware, systems, local administrative procedures
  

Threat Identification

• Unauthorized and/or unintended access to hardware, software, data, or documentation
• Unintended and/or unauthorized disclosure of information by personnel or software
• Denial of service attacks against university systems
• Viral infections or worms affecting or propagated by university systems
• Threatening or abusive conduct by personnel
• Use of this site as a base of attack against other sites
  

Security Policy

Purpose: To define the roles of university personnel in protecting university assets, and to provide a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy.

Definitions and Supporting Information

• IRT: Information Resources and Technologies Division
• User: Any person who has authorized access to University owned computer resources.
• Systems Administrator: Staff member responsible for managing a server, group of servers, or service.
• Network Security Manager: Staff member responsible for the security of University computing resources.
• Local Administrator/Technology Support Specialist: Staff member responsible for the administration of University computing resources in a specific location; may be IRT staff or may work for other departments, such as GPS.
• Remote Administration: Any network administration that takes place at a location other than the server.
• Private Information: This includes, but is not limited to social security number, date of birth, religion, marital status, salary and payroll information, home phone number and address, student grades, passwords, donor name and donation, gender, ethnicity, citizenship, citizen visa code, veteran and disability status

Responsibilities

• Security Manager: Assist in the development and maintenance of the Security Policy. Respond to incidents in a timely manner. Investigate methods and technology used to ensure the security of the network. Implement and maintain technology used to secure the network. Probe the network for vulnerabilities used by outside entities to compromise network security. Notify administrators about known exploits and fixes. Audit network for suspicious activity. Assist Public Safety in the investigation of security incidents and with coordinating university efforts with those of the proper authorities.
  
• Central Systems Administrator: Manage user accounts following guidelines presented in the Security Policy. Ensure server security complies with the current best-practices list from IRT. Audit servers for suspicious activity and notify the security manager when such activity is detected.
  
• Local Administrator/Technology Support Specialist: If appropriate to position, maintain groups for resource access using accounts created by the systems administrator. Audit local machines (servers and workstations) to ensure that their configurations comply with current best-practices as published by IRT. Report violations of the Security Policy to their supervisor and the Security Manager.
  
• Network Administrator: Maintain data networks in a secure fashion by disabling default passwords, securing systems with strong passwords, working with encrypted access tools, and keeping equipment operating code patched.
  
• Managers/Supervisors: Ensure workers are aware of the Security Policy. Notify HR of terminations immediately; HR will notify AVP for IRT, and/or Director of Operations, and/or Associate Director of Client Services via request for account suspension. Report violations of the Security Policy to the Security Manager.
  
• Users: Abide by the Security Policy. Report suspicious activity to their manager/supervisor, department chair, or the Dean of Student Affairs’ office. Maintain positive control over University assets in their possession, which includes passwords and PINs for university systems. Users should not leave their workstations unattended while logged in without at least locking the screen.
  
  

Technology Access Guidelines

Technology shall be purchased in conformance with the minimum standards defined by IRT. This includes but is not limited to assets discussed in section 1a. Network security products such as firewalls and intrusion detection systems will be deployed and updated as necessary to protect the university network from unauthorized access and denial of service.

Access

Hardware Assets: Access to mission critical hardware will be limited to those needing direct access. Entry to areas containing such equipment will be controlled.

Software Assets: Access to all central systems, resource servers, and enterprise applications (with the exception of university web sites) will require authentication using a username and password at minimum; further authentication may be required for some systems.

The university network will be divided into security zones with access among the zones being controlled by network security systems such as firewalls and routers. A system’s placement in a particular zone will depend on two things: the degree to which IRT can trust in the security of the system, and the list of other zones from which access to the system is required.

Users requiring access from off-campus to the secure zones or to administer resource servers will be required to use an authenticated, encrypted means of access, such as SecureTelnet or a virtual private network (VPN) client.

Whenever possible, modems on the UST network will be restricted and controlled by IRT. If a department or user requires a modem, IRT will be notified and it will be installed within the following guidelines:

Modems allowing a network connection (e.g. PPP) must not be left in auto answer mode.

Vendors requiring this modem to maintain their product under a service agreement will, whenever possible, contact the administrator so the modem can be turned on only as needed .

If the modem is required for 24 X 7 monitoring, the connections will be audited and those logs periodically reviewed by the administrator to check for suspicious activity.

Administrators should never dial into a server directly for routine maintenance.

Access to a resource or service will, wherever possible, be based on a DENY ALL policy. That is, IRT will begin by denying all access to any server or network, or by shutting down all services/ports on a network, and will then selectively allow access or open ports based on demonstrated need. Only users with need to access a resource will have access to it. Only services or ports which the University needs to have open will be open. Departments experimenting with new network-based services may request the opening of required ports via the IRT Tech Desk.

Where possible, connect messages displaying the Acceptable Use policy or acknowledgement thereof will be presented when users attempt initial access. These messages will not include information regarding system specifics (e.g. name, IP address, and operating system) but will have a check box indicating that the user understands and accepts the policies.

Where possible, anti-virus software will be installed on workstations connected to the University network. The user may not in any way remove or disable this software.

New software as well as upgrades to be installed on University owned computers must not violate the Security Policy, and will only be installed by the machine’s administrator or a designated representative. Software that is found to violate security policy will be reviewed by the security manager, the system administrator, the appropriate technical support specialist and the parties using the software, to determine if the productivity offered outweighs security risk and if a more secure workaround is feasible. If no workaround is possible, then the Security Policy takes precedence. Network connectivity to the system in dispute will be shut off until the situation is resolved.

IRT will maintain local administrator passwords for desktop workstations. A user may be granted administrative rights to their workstation at the discretion of their assigned technical support specialist.

Systems that are compromised or used to breach this policy may be isolated from the network at the discretion of the security manager and without prior notification. Notification after the fact is required, and should include the IRT Tech Desk staff.

Media Assets: Removable media containing private information must be kept secure: stored in locked cabinets or drawers, not removed from campus except where required by business needs (as in delivering information to a federal agency). Private information in printed reports and forms must be handled with similar care, and reports containing sensitive information must be disposed of securely (shredded, for example).

 

Accountability

Where possible, the University will implement a one user/one password policy for access to all resources. Where this is not possible, shared accounts will be audited to ensure that only the minimum required people have access to the shared account, and that the account has the minimum possible level of access to UST systems. A user may be held accountable for any actions performed in their name while using the University network.

Only IRT Tech Desk staff are allowed to ask a user for their password over the phone, and then only when the user has initiated the communication (that is, the Tech Desk can ask when a user calls for help, but will not ask if the call originates from the Tech Desk). No other UST employee is authorized to ask a person for their password over the phone; any such requests from persons purporting to be employees should be reported to IRT as soon as possible.

Staff, faculty, and students must not divulge information which may allow an outside entity access to the university network. Every attempt should be made to verify the identity of those claiming to be affiliated with the University before divulging such information. IRT staff will show ID if they are going to ask users for secure information in person

Logons and resource access will be audited for both success and failure. When suspicious activity is suspected, the following individuals will be notified:

• Security manager
• Systems administrator
• Machine administrator

If a user is involved, that user’s manager or the Dean of Student Life’s office will be notified as well. If IRT staff come to suspect that there was an intentional violation of security policy or the law, the security manager will contact the Public Safety investigations unit, and, where necessary, local law enforcement, and appropriate federal agencies.

Authentication

Internal users will be authenticated via username and password before they are granted access to any private resources. Only IRT staff and processes may create domain level or enterprise systems accounts.

Passwords must meet the following rules:

• Must be at least 6 characters in length
• Must not include any part of your username or full name
• Must include characters from 3 of these 4 sets: the uppercase letters (A-Z), the lowercase letters (a-z), the digits (0-9), and non-alphanumeric characters (such as ,.?:~)

Additionally, passwords should not include words found in the dictionary (e.g. 12-string) or that are popular in the UST environment (e.g. aquin).

Examples: “FizBin2” or “Gimme$$”

User passwords will be changed every 120 days, and a history of previous passwords will be employed to prevent immediate reuse of a password. Administrative passwords will be changed every 90 days.

When asking the Tech Desk to change their password, all users will be required to prove their identity. Any online tool for changing passwords will also seek to verify a user’s identity prior to resetting a password.

 

Network Maintenance and Administration

Accounts for students will be added to the master domain user authentication database automatically, triggered by information in the current system of record for student information. Accounts for faculty and staff will be created by a similar process based on data in the HR system of record.

Accounts are removed from the database only after the relevant system of record indicates that the person no longer has a current faculty, staff, or student relationship with the university. For faculty, current status lapses two years after the faculty member's last active assignment in the HR system. For staff, current status ends immediately with separation. Faculty and staff accounts may be removed at any time during the year. For students, current status lapses with graduation, or one year after the cessation of course registrations. Currently, (2005) these student accounts are deleted once annually, in May. The University sends email notifying the user that the account is to be deleted, via the account to be deleted, a minimum of two weeks before deletion to allow for appeals of the process.

Staff and faculty lose access to their accounts immediately upon separation, voluntary or involuntary. An employee’s supervisor will upon written request from HR be granted access to that employee’s account for the two weeks after the employee loses access. After two weeks, any such accounts (whether a supervisor has looked at them or not) will be removed.

In the event of a student being expelled and upon written request from the Dean of Students, the student will lose access to the account immediately, with Student Affairs determining how long it must remain on the systems before IRT can delete it and whether anyone else is to be given access to it.

In the event of the death of a faculty member, staff member, or student, that person’s accounts will be disabled immediately upon IRT receipt of notice of the death. The disabled account will be retained for thirty days, and access may be granted to faculty or staff members’ supervisors upon written request from Dean of Students and/or Human Resources.

Accounts for others (not regular staff or students) may be added by hand, but such additions will be kept to a minimum, and all such accounts will be set with access expiration dates, to ensure regular review of their presence and usage. Third party maintenance personnel requiring administrative access will be granted a one-time password. If the maintenance period requires several days, the account will be disabled at the end of each day and removed upon completion of the project.

Security Breaches, Event/Incident Reporting and Response

Overview

If a member of the University community wishes to report any sort of security breach (or suspected security breach) he or she should call the IRT Tech Desk or the Department of Public Safety. IRT Tech Desk or Public Safety staff will then contact the network security manager or the Director of Operations in IT to initiate IRT response to the incident.

IRT and Public Safety will act as the investigating offices in issues of misuse of services (such as sending threatening e-mail) and will involve other offices as needed: the Office of the Dean of Student Life in all cases involving students; Human Resources in all cases involving staff; the Office of the VP/Academic Affairs in all cases involving faculty. Outside organizations may also be brought into ongoing cases as appropriate, including the U.S. Postal Inspection Service, the Minneapolis and St. Paul Police Departments, the Minnesota Bureau of Criminal Apprehension, the FBI, and the Department of Homeland Security. If the incident under investigation involves security breaches at other organizations (such as another university) the network staff of that school will also be contacted and every effort will be made to coordinate investigations and responses. Public Safety, IT/Operations, and Client Services will maintain a more detailed set of procedures to follow in various situations.

In cases involving violations of Acceptable Use Guidelines/Unacceptable Use Policy and Data Privacy Statement or other campus codes, the relevant disciplinary offices will be given all information about an incident that IRT can collect. IRT will advise and testify as requested, and if asked to implement sanctions (such as disabling accounts) will do so with all possible speed.

 

Definitions

Event: Abnormal or suspicious activity, which may be a precursor to a denial of service attack, systems compromise, or other hostile act. Examples include network port mapping or service scans.

Incident: Activity indicating a denial of service attack, systems compromise, or other hostile act (e.g. packet storms, email bombs, or unauthorized access of a system)

 

Process

• Form an incident response team (or, if appropriate, initiate an IRT Red Rover Alert and follow that process)
• Designate a command center
• Select response type
• Enact and log response

 

Form Incident Response Team

Core Members:

The following individuals will participate in all response teams:

Network Security Manager

Network Hardware Manager

Director of Operations Director, Telecommunications

AVP of IRT and/or Associate Director of Client Services

Public Safety investigations officer
and/or IRT Red Rover Task Owners

Optional Members:

The following individuals may be asked to participate depending on the system(s) involved:

Central systems administrators (for enterprise, email, web, or other systems)

Database administrator

Technical support specialists

Director, Application Development

 

Designate a Command Center

A command center, if established, will reside in a central area that provides an “out of band” (e.g. If the network has been compromised, use phones as opposed to e-mail) method for communications. It will server as the single point of contact during the investigation of an incident. All parties participating in the investigation will be notified where the command center resides.

Note: A command center in the event of an IRT Red Rover Alert is designated by the named crisis communication coordinator for the alert.

 

Select Incident Response

Determine whether to use a "deny, clean, and continue" response or a "monitor and gather evidence" response.

"Deny, clean, and continue" requires denying access to the compromised device, cleaning the system of any compromises, and continuing on with day-to-day operations. In most cases "deny, clean, and continue" will be the method used to respond.

"Monitor and gather evidence" will be used in situations where local, state, or federal law warrants it, or at the request of on-campus authorities. This procedure involves using tools such as protocol analyzers, monitoring systems, and log examination to determine an intruder's methods, and if possible their location and identity. It may also be used if time permits to determine attack patterns and possible other targets.

In instances where a mission critical device is affected, efforts leading towards restoring that device to service will have precedence except when local, state, or federal law requires otherwise.

Note: Select Incident Response for an IRT Red Rover Alert would include Identification of the Threat; Containment of the Threat; Recovery from the Threat.

 

Incident Response Procedures

Incidents involving outside entities

• The initial responder must notify the following: Network Security Manager, Network Hardware Manager, AVP for IRT, Director of Operations, Director of Telecommunications

• If a device has been compromised the administrator of that device will be notified as well.

• The Network Security Manager will begin logging the incident using the current system of record for incident reporting. The log will include the time and date of the incident, the location of the incident, the nature of the incident, who was responsible for the incident, and the actions taken to eliminate the threat. All individuals involved need to take thorough and accurate notes as they may be needed as evidence in a court of law. If it is determined that the incident may warrant law enforcement response, the system will be immediately isolated and the appropriate agencies will be contacted by the Network Security Manager. No further actions will be taken except under the supervision of law enforcement officials.

• The Network Hardware Manager and the Network Security Manager will work together to determine the source of the incident.

• If the incident involves a system compromise, the Network Security Manager will disconnect the device from the network, working with the system's administrator if possible. The Network Security Manager and the System Administrator will then attempt to determine the source of the compromise. If the source of the compromise cannot be determined at that time, one of two options may be available. Additional monitoring of the device in an attempt to discover the source of the compromise, or reinstall the operating system from distribution media with all current patches.

• Once the source of the compromise is determined, the systems administrator of the outside entity will be notified. Logs will be provided to the administrator as needed. If law enforcement brought in, the outside systems administrator will be requested to save logs from the time period of the incident for possible future subpoena.

• If possible, rules or access control lists will be updated to prevent similar future compromises.

• The Network Security Manager will close the incident.

Incidents involving internal entities

Steps 1 – 5 as above.

• Once the source of the compromise has been determined, additional notifications will be made depending on whether a student, faculty, staff member was involved. If a student, the Dean of Student Life will be notified and provided with evidence. If a staff or faculty member was involved, Human Resources will be notified. Regardless, the individual’s access to computing resources may be terminated pending further investigation.

Steps 7 – 8 as above.

 

Incidents reported by law enforcement

The university will comply with all lawful requests for information or assistance made by local, state, or federal agencies. Whenever such a request is made, university counsel will be consulted to confirm that the request is lawful.

• The initial responder must notify the following: Network Security Manager, Network Hardware Manager, Director of Operations, Director of Telecommunications, Public Safety investigations officer. The Director of Operations will notify the office of the Vice President for IRT. Public Safety will notify university counsel.

• If a device has been compromised the administrator of that device will be notified as well.

• The Network Security Manager will begin logging the incident using the current system of record for incident reporting. The log will include the time and date of the incident, the location of the incident, the nature of the incident, who was responsible for the incident, and the actions taken to eliminate the threat. All individuals involved need to take thorough and accurate notes as they may be needed as evidence in a court of law.

• The Network Hardware Manager and the Network Security Manager will work together with outside agencies in investigating the source of the incident.

• If the incident involves a system compromise, the Network Security Manager will disconnect the device from the network unless another course of action is requested or required by the authorities, such as instituting additional monitoring of the device in an attempt to discover the source of the compromise. Absent such requests, the System Administrator will reinstall the operating system from distribution media with all current patches.

• If possible, once cleared by law enforcement, rules or access control lists will be updated to prevent similar future compromises.

• The Network Security Manager will close the incident.

 

Event Response Procedures

Until an act is determined to be hostile, it will be regarded as an event.

• As above.
• The Network Security Manager (or designated representative), will begin an investigation to better determine the nature of the event.
• The Network Security Manager will log the event to use for possible cross-referencing with past or future events.

 

Logging Procedures

The following information must be included in Incident and Event Logs:

• What system is affected
• The source of the event/incident
• The time and date of the event/incident
• Actions taken to resolve the incident
• Chain of evidence
• The nature of the event\incident

Specific information regarding an ongoing investigation will only be released to the following individuals or agencies:

• Any law enforcement agency
• The Dean of Student Life regarding students
• The Dean of the College regarding faculty
• Human Resources regarding staff
• Any other individual authorized by the security manager or director of network services
• Appropriate IRT staff

The security manager and/or director of operations in partnership with the AVP for IRT will be the primary IRT points of contact for information regarding an investigation.

If you have any questions you may contact the IRT Tech Desk.