INFORMATION TECHNOLOGY SECURITY POLICY STANDARDS AND GUIDELINES FOR SCHOOL-BASED SYSTEMS Table of Contents 1. SCHOOL-BASED COMPUTER SYSTEMS 1.1. Definition 1.2. Management of School-Based Systems 1.3. Security Responsibilities 1.4. Physical Security 1.5. Physical Access 1.6. User Access 1.7. Fire Detection and Control 1.8. Business Continuity 1.9. Data Integrity 1.10. Password Aging 1.11. Documentation 1. School-Based Computer Systems 1.1. Definition "School-Based" systems are non-strategic servers (i.e. not desktops) that are the responsibility of Departments, Schools, Offices, or Units (DSOU’s). 1.2. Management of School-Based Systems Responsibility for the management and operation (i.e. custodianship) of school-based systems resides with the DSOU that owns the system. 1.3. Security Responsibilities The day-to-day managers of school-based systems must: Be thoroughly familiar with the University IT Security Policy in its entirety. Ensure compliance to this policy by all of its users. Report any serious breaches of security to ITS. 1.4. Physical Security The following standards of physical security of school-based platforms* must be met: Premises must be physically strong and free from unacceptable risk from flooding, vibration, dust, etc. There must not be an inordinate amount of combustible material (e.g. paper) stored in the same room as the computer system. Air temperature and humidity must be controlled to within acceptable limits specified for the equipment. (* A 'platform' is the physical hardware and Operating System Software of a system. ) Depending on the criticality of the school-based systems, computing equipment should be electrically powered via UPS to provide the following: Minimum of 15 minutes’ operation in the event of a power blackout. Adequate protection from surges and sags. Trigger an orderly system shutdown when deemed necessary. 1.5. Physical Access There must be procedures in place to assure that only authorized staff enter the premises. 1.6. User Access Access provided to school based systems should be on the same basis as that provided centrally, although it may be administered separately. New userids should be handled as follows: The process of creating user IDs must establish formally that the applicant is a member of staff or a matriculated student and therefore entitled to access the system. Either application must be made on an official form signed by someone in authority (e.g. Dean, Head of School or Department), or the authority to create a user-id comes from a recognised source (e.g. HR Department, Student Records). If the Operating System supports a password aging facility then it should be set to force password change on the first login. The process of creating and maintaining user IDs must have a formal mechanism to identify members of staff who have left the University, and students who have left. User IDs for these people must be removed from the system immediately that it becomes known they have left. 1.7. Fire Detection and Control There should be smoke and thermal detectors on the premises. Underfloor areas should have smoke and water detectors. 1.8. Business Continuity There should be a Business Continuity evaluation along the following lines: 1.8.1. A statement of the impact to the Unit of loss of the system, and therefore its criticality. 1.8.2. An identification of all of the threats to the system such as: Hardware Failure. Electrical Power Failure. Fire. 1.8.3. Contingency Plans for restoring services within a timeframe agreed to be acceptable by the Unit. ITS can give advice on risk management and contingency planning. 1.9. Data Integrity Security backups of all data should be made at least once per working day. The backup regime should meet the following criteria: Enable recovery to at least the start of business on any weekday of a failure. Provide at least one more level of backup to a previous time, to cover the case of the failure of the primary backup media. There should be offsite* storage of security backup media to enable a full data recovery to no earlier than one working week. (* This means another building sufficiently separate from the system such that there is negligible risk of both the offsite backup and system being destroyed by a single incident. ) There should be an audit* of security backup media at least once every six months. (* This means actually restoring data from the backup tapes. ) 1.10. Password Aging If the Operating System provides the facility, automatic Password Aging should be enforced. The life of a password should be no more than three months 1.11. Documentation Procedures reflecting these policies should be documented in the site Operations instructions.