7.0 Software Security

1. Software Development
2. Software Purchase
3. Quality Assurance and Testing
4. Software Library Control
5. Access Control
6. Software Security Features
7. Data and Database Administration
8. Database Linkage

7.1 Software Development

1. A system development life cycle (SDLC) methodology should be used for the development of any application. The SDLC should ensure that:

   a) security concerns are addressed,
   b) test criteria are met prior to implementation of operational software,
   c) change control procedures for operational software are implemented, and
   d) discrepancies for all data and software are reported, monitored and resolved.

2. A review of the security requirements and compliance with security and privacy guidelines should be conducted and signed off by the Security and Privacy Officer during each phase of the SDLC.

7.2 Software Purchase

1. All acquired software should be examined for viruses, logic bombs or other extraneous malicious features.

2. The university should strictly enforce the conditions of software licenses, and respect software copyright requirements.

7.3 Quality Assurance and Testing

1. Responsibilities for software quality assurance should be established and should include:

   a) development and distribution of test standards and criteria,
   b) performance of quality assurance testing,
   c) reporting on test results, and
   d) custody and retention of test results.

2. Test criteria should be established to ensure adequate quality assurance and user acceptance testing.

3. Test results of all quality assurance and user acceptance testing should be reviewed and approved to ensure that established test criteria are met prior to implementation of production software.

4. Production data should not be used for testing purposes. When it is not feasible to create test data, only copies of production data should be used and the confidentiality requirements of the production data should be adhered to.

5. Software testing should be conducted in an environment separate from the production system.

6. When security concerns warrant, testing should include:

   a) line-by-line code reviews, and
   b) comparison checks of executable routines.

7. When software is transferred to quality assurance testing or production status, the transferred source code should be re-compiled/re-assembled within the recipient libraries to ensure compatibility between source and executable code.

7.4 Software Library Control

1. Responsibilities and Standard Operating Procedures for software library maintenance and control should be established and include:

   a) custody;
   b) access control for production, audit, and change control purposes;
   c) adequacy of the number of backup versions (generations) of software for both on-site and off-site storage; and
   d) maintenance of the records of access and changes.

2. Software should be maintained in both source code and executable format.

   Note: Source code may not be available for some commercial packages, or a source code escrow agreement may be required by the manufacturer.

3. Update privileges should be restricted to individuals responsible for:

   a) development of software, in the case of development program libraries;
   b) quality assurance testing, in the case of quality assurance testing libraries; and
   c) transferring software to production status, in the case of production libraries.

7.5 Access Control

1. Access control software should be implemented to control and monitor access to the system and data resources.

2. Application access control mechanisms should use the user identification obtained by the system during initial sign-on (ie. the user should not be required to log on to each application).

3. At the time of initial system access, the user should be informed of the date and time of the last successful log-on and any subsequent failed log-on attempts. The system should display a banner indicating that the user has accessed a private and restricted system, that all usage will be monitored, that all communications such as data and e-mail are not considered private, and unauthorised activity may result in prosecution.

   If a user recognises that an unauthorised access attempt has been made using their user ID or password, the user (or user's supervisor) must report the incident to the Security and Privacy officer.

4. Access to directories and/or data within a system should be based on user identity and only be granted based on pre-defined authorisation.

5. When access to system and data resources is denied, no indication of the reason for denial should be provided. The user should be directed to contact the security administrator or Security and Privacy Officer.

7.6 Software Security Features

1. Passwords, or similar authenticators, should be obscured by one-way encryption.

2. The following privileges should be restricted and monitored:

   a) changing computer system privileges or controls;
   b) changing protective features or parameters affecting another user;
   c) allocating resources;
   d) halting the computing system; and
   e) controlling the allocation and sharing of system and data resources (eg. memory, file space, CPU cycles, etc.).

3. The system should automatically terminate or re-authenticate an interactive user's session when a predefined period of inactivity has been exceeded.

4. Display screens and all associated memory should be cleared upon user sign-off, and after a predetermined period of inactivity.

5. User authentication information should not be included on computer output.

6. All transactions should be logged automatically, making it possible to re-create the chain of events leading to any addition, deletion or modification of such software or data without recourse to the input source documents.

7. Controls should be implemented to ensure that the integrity is maintained while the data is stored or processed on the system. Examples of such controls include batch totals, file record counts, file release dates and version numbers, block counts, check sums, hash totals, data edit routines, and file and message authentication coding.

8. Where 100% availability of the system is required:

   a) redundant hardware, communications and software should be used to process the transactions simultaneously,
   b) hardware and/or software techniques should be used to detect hardware/software failures in the primary and backup systems,
   c) in case of failure of the primary system, the backup system should automatically switch the required hardware, software and communications equipment to primary status, and
   d) the application software program processing the transactions on the primary system should be logically different from the backup system.

9. The system should record security-relevant events. Such events include:

   a) job entry, initiation, completion, deletion, restart, abort
   b) terminal connects, disconnects, configuration changes
   c) user log-on and log-off
   d) file, volume, and/or database creation, deletion, access, close, rename, backup and restore
   e) network-related status messages
   f) computer operator(s) commands and responses
   g) system and sub-system start-up, shutdown, dump, generated messages or requests, volume mounts and dismounts, configuration changes
   h) use of functions affecting logs (eg. printing, deleting, renaming, altering)
   i) overflow of logging system
   j) changes to access control information
   k) changes to lists of authorised users
   l) detected security incidents

   Note: Security-relevant information whose confidentiality must be protected, ie. changes to access control information and lists of authorised users, should not be recorded; only the fact that a change has been made should be recorded.

10. For each security event, the following information, if applicable, should be recorded:

    a) event, name or type,
    b) date and time,
    c) user identification,
    d) terminal identification,
    e) job identification,
    f) file identification,
    g) file owner,
    h) account number,
    i) mode of access,
    j) volume identification,
    k) configuration details, and
    l) nature of incident.

11. Where log records are machine readable and of sufficient volume to make manual recognition of security-relevant incidents impractical, software routines should be utilised to highlight security-relevant incidents.

12. When a security-related incident is detected, an alarm should be activated.

    Note: Alarms should include a message to a console or printer to be utilised for further analysis, or appropriate notification of the Security and Privacy Officer.

7.7 Data and Database Administration

1. Responsibilities for data administration and/or database administration should be established and include:

   a) access control,
   b) definition and creation,
   c) data dictionary,
   d) integrity,
   e) backup, and
   f) recovery.

2. Database audit checks should be conducted at regular intervals to verify the logical and physical consistency of the database and identify discrepancies such as lost records, open chains and incomplete sets.

3. A data dictionary should be used to document, standardise and control the naming and use of data.

4. Database maintenance utilities that bypass controls should be restricted and monitored.

5. Following a system or application software failure, the system should be capable of automatically recovering the database.

6. Where 100% availability of the system is essential, duplicate databases should be maintained on separate physical devices and all database maintenance transactions should be performed simultaneously on both databases.

7. Automated or manual controls should be implemented to protect against unauthorised disclosure by means of inference search techniques.

8. Data integrity verification techniques such as message (record) authentication coding or hash total techniques should be implemented.

9. To facilitate the auditability and authorisation of data records stored on the database the following measures should be implemented:

   a) The user identification and authentication process should positively identify the authoriser.
   b) The user identification of the authoriser should be retained on the transaction record.
   c) The user identification of the data entry person should be retained on the transaction record.
   d) All critical data elements, including transaction date and time, data entry and authoriser user identifiers, should be included in the data integrity verification process.

7.8 Database Linkage

1. Policies and procedures should be established for the approval of requests to link databases.

2. Databases should be designed to inhibit the linking of data between databases, except as expressly authorised by the university. Steps to inhibit linking may include:

   a) Separation of databases that contain client identifying data and service/diagnostic data.
   b) Encryption of patient and provider identifiers in databases containing service or diagnostic data.
   c) Encryption of extremely sensitive patient service/diagnostic data.

3. Where university data from a database is downloaded into PCs or laptop computers, the data should be encrypted, with security mechanisms built into the portable or stand-alone device. university data should be erased from the device when it is no longer required.

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