8.0 Operations Security

1. System Access and Authorisation
2. Input and Output Controls
3. Detection and Surveillance
4. Security Incident Reporting
5. Contingency Planning
6. Inventory
7. Change Control
8. Problem Reporting

8.1 System Access and Authorisation

1. All use of computing facilities should be authorised.

2. The university should ensure that no access is permitted to system and data resources without the user being identified. User identifiers should uniquely identify the individual.

   Note An identifier by itself must not grant access privileges.

3. User identifiers should be designed to permit group level identification of individuals:

   a) who have been the same level of system access;
   b) who have the same need-to-know; and
   c) who have the same functional requirements.

4. Procedures should be implemented for the preparation, issue, change, cancellation and audit of user identifiers.

5. Access should not be granted to system and data resources until the individual's identity has been authenticated, and authorised privileges have been confirmed, automatically or manually.

6. Where the authentication process uses unique authentication codes or passwords, the following conditions should apply:

   a) Individual users should have the ability to set their own passwords.

   Note: Individual users should be counselled to use caution in setting passwords, avoiding obvious selections such as birthdates, names of children or pets, etc.

   b) All system password files should be stored in an encrypted file that cannot be read by any other user, including system administrators,
   c) Passwords should contain a minimum of 6 characters,
   d) Passwords should not be displayed in clear text at sign-on, on reports or be trapped in transaction logs,
   e) The security system should force users to set a new password after a password has been reset by the security administrator,
   f) The security system should lock-out a user ID after 3 consecutive failed sign-on attempts,
   g) The ability to reset a password should be restricted to specifically authorised personnel with a log of such personnel maintained by the Security and Privacy Officer.
   h) Passwords should not be hard coded into any system file or routine.
   i) Passwords should be changed periodically (annually, monthly, or more frequently as required).

7. Records concerning system authentication mechanisms used to authenticate identities should be provided the same level of security as university data.

8. Authorisation by the Security and Privacy Officer should be obtained whenever a security feature normally used on the system cannot or will not be used. The actions taken in these circumstances should be documented and reported as a security incident.

9. Where confidentiality is a concern, system display units and hardcopy production units should be positioned or equipped with protective material, eg. limited vision screens or printer covers, such that the data displayed or processed cannot be readily viewed by unauthorised persons.

10. Access to terminals on a computer system which have privileges over and above those of other terminals on the system should be controlled to ensure their use is authorised and audited.

8.2 Input and Output Controls

1. Procedures should be established to ensure the accountability of data being input to a system. These procedures should include measures to provide accountability for:

   a) input materials received over the counter by operational units; and
   b) transactions or other data being input to the system locally or remotely.

2. Data should be checked for accuracy prior to entry.

3. If the system does not have built-in on-line edit checks to catch input errors, the data should be verified by an individual other than the person who originally entered the data.

4. Logs recording all details of transactions together with supporting authorisations should be maintained and safeguarded.

5. Where output is provided on hardcopy or in electronic form:

   a) only the number of copies of output specified by the person requesting the output should be produced;
   b) distribution of all output should be logged;
   c) the appropriate security classification or designation should be marked on all output;
   d) jobs should only be re-run or re-printed under strict controls and with prior authorisation;
   e) output should be delivered only to the owner or to a person who has been authorised to receive it; and
   f) receipts should be obtained when output is delivered.

6. Remote hardcopy/display devices should be positioned to prevent observation by unauthorised personnel.

7. When data is copied for backup purposes, the copy should be verified to ensure the process was successful.

8. Sufficient generations of backup data should be maintained to ensure that data can be recovered. (Consideration must be given to the length of time an error could remain undetected to ensure a backup will recover valid data.)

8.3 Detection and Surveillance

1. The system log should be checked at randomly selected periods to verify that all processing was authorised.

2. The university should produce a report on the type and frequency of system and application errors. The information in this report should be reviewed for security connotations by the Security and Privacy Officer.

3. The Security and Privacy Officer should periodically verify that all work is authorised.

4. All operator errors should be reviewed and analysed for security connotations.

5. The usage meters/recordings on information technology equipment should be regularly read, logged and reviewed for maintenance purposes and to assist in the detection of unauthorised use of the system.

6. Hardcopy logs and records that are used for accountability or control purposes should be designed so that the removal of records can be detected (eg., paper log pages could be sequence numbered).

7. To detect and prevent systems from being infected by computer viruses, the following precautions should be observed:

   a) all media received from external sources, including licensed or copyright software, should be scanned for the existence of viruses,
   b) all original master copies of software should be stored on media with the write-protect security feature activated,
   c) computer systems should be scanned for the existence of viruses after an upgrade or change of software and after each instance of hardware maintenance,
   d) virus scanning software should be installed on personal computers and activated during the boot or logon process. Where PCs are connected to a local area network, scanning software should be installed on the LAN server which will scan each LAN connected PC at each logon to the LAN.

8.4 Security Incident Reporting

1. A security incident reporting procedure should be established and include:

   a) the types of security activities and events to be monitored,
   b) the method of determining how activities and events are to be monitored,
   c) the type of records to be kept, and
   d) how and when the security information is to be reported.
   e) steps to be followed by an employee who observes or becomes aware of a security incident.

2. Security incidents should be investigated by the Security and Privacy Officer and records maintained on each case. If these security incidents constitute a possible breach, they should be reported to the CEO of the university, generally through the Director ITD or the Chair CQU Computer Security Committee.

   Note that state and national legislation, as well as University Policy, require some types of incidents to be reported to AUSCERT and the Federal Police.

8.5 Contingency Planning

1. Contingency plans should be developed, documented and maintained to ensure the essential level of service that will be provided following any loss of processing capability from the loss or destruction of a diskette to the complete destruction of the facility. Plans should cover on-site and off-site recovery and, as a minimum, consider:

   a) recovery from any failure to the system and information resources;
   b) re-establishment of the information system services, following destruction of the facility providing those services, using none of the systems and information resources contained within the primary facility;
   c) forced evacuation of the facility;
   d) strikes and other labour disputes;
   e) bankruptcy of critical suppliers; and
   f) loss of critical support systems.

2. Where plans require the use of facilities not under the control of the university, formal agreements or contracts for the use of such facilities should be entered into and should be reviewed annually.

3. Plans should include the identification of essential systems, information resources, and personnel.

4. Planned responses to contingencies should not compromise confidentiality or integrity requirements.

5. Copies of all contingency plans, procedures and agreements should be maintained in at least two geographically separate locations.

6. Contingency plans should be tested annually to the extent practical.

7. There should be sufficient backup of personnel to assure the confidentiality, integrity and availability of critical systems.

8. Employees required to support an essential level of service should be identified and the up-to-date list should form part of the contingency plans.

9. Employees identified to take an active role in contingency situations should receive training and practice in their assigned duties.

10. Backup copies of the essential information should be taken at regular intervals and stored at an off-site location.

11. Current copies of the critical operational data and material and a sufficient supply of the critical media resources to ensure the continued provision of the minimum essential level of service, as defined in the institution's contingency plan, should be stored at an off-site location. These items should include:

    a) operating system software,
    b) utilities,
    c) applications system software,
    d) data,
    e) documentation,
    f) encryption keys,
    g) access control information (eg. passwords), and
    h) forms.

12. An index of the resources which are stored off-site should also be stored at the off-site location and should contain:

    a) identification of the resources and data,
    b) names of the owners of the data, and
    c) the classification or designation of the data.

13. A contingency procedure should be developed detailing the course of action to be followed when a virus attack is suspected.

8.6 Inventory

1. The university should maintain a detailed inventory of university information assets. The inventory should include:

   a) All hardware components, such as computers, printers, disk drives and other data storage equipment, telecommunications equipment, environmental control equipment, etc.;
   b) All software components, such as office automation programs, financial and clinical application programs, database management programs, communications programs, engineering and scientific programs, design and drawing programs, compilers, etc.;
   c) All databases;
   d) All communication networks, including local area networks, wide area networks, wireless networks, etc.

2. Hardware inventory records should include:

   a) Description;
   b) Manufacturer/supplier;
   c) Model number;
   d) Serial or license number;
   e) Warranty or maintenance conditions;
   f) License conditions;
   g) Location;
   h) Number and identity of authorised users.

3. Software and database inventory records should include:

   a) individual applications,
   b) individual programs,
   c) database and files (libraries),
   d) software procedures (eg. command or script files),
   e) software utilities,
   f) security-relevant software components,
   g) systems software,
   h) software under development or test,
   i) warranty/maintenance conditions (eg. period covered), and
   j) number and identity of valid/licensed users.

4. Software and database inventory records for each item should include the following information:

   a) the number of copies and their locations (eg. library, off-site storage);
   b) identification of owner, custodian, authorised user and maintainer, and
   c) date created or modified, version/level number and any special modifications.

5. Inventories should include up-to-date configuration charts for hardware, software, database and communications components. The charts should illustrate the relationships and dependencies between different components. The minimum configuration to support essential operations should be identified.

6. Copies of current inventory records and configuration charts should be kept at an off-site location to support disaster recovery efforts and to protect against tampering or fraudulent activities.

8.7 Change Control

1. The university should establish formal change control procedures for any change to the system hardware, software, database or communications network. The procedures should include the mechanism for requesting changes, recording and tracking outstanding requests, approval of requests, testing and documentation of changes and incorporation of the changes.

2. All system modifications, maintenance activities and physical or logical re-configurations should be authorised by the Chief Information Officer of the university.

3. Additions, deletions or alterations should not compromise the intended security profile of the system.

4. All changes to the system should be centrally controlled and documented.

8.8 Problem Reporting

1. Procedures should be developed, documented and implemented for reporting, recording, tracking and resolving system problems.

2. Records of problems and their resolutions should be retained for a period of at least one year.

3. System problems affecting security should be immediately reported to the Security and Privacy Officer.

Contents
Background: [1] [2] [3] _Section: [1] [2] [3] [4] [5] [6] [7] [8] [9] _Annex: [1] [2] [3] [4] [Index]
Guidelines for Computer Security at CQU, A C Lynn Zelmer, PhD; Editor/Adaptor
Copyright © 1996 CQU Computer Security Committee

Central Queensland University Home Page