MURDOCH     INDEX     SEARCH     PEOPLE  
Policies Index >>  Facilities & Services >>  Information Technology >> 

Standards and Guidelines for Strategic Systems

Version 1.0

TABLE OF CONTENTS

  1. Strategic System Platforms.
    1. Definition of ‘Strategic’.
    2. Management of Strategic Systems.
    3. Physical Security.
    4. Physical Access.
    5. User Access.
      1. New Users.
      2. Terminating Users.
    6. Fire Detection and Control.
    7. Data Integrity.
    8. Password Aging.
    9. Disaster Recovery Plan.
    10. Documentation.
  2. Software Change Control.
    1. Definition.
    2. General Obligations.
    3. Change Control Responsibilities.
    4. Change Control Environment.
    5. Documentation.
  3. Communications.
    1. Campus Local Area Networks.
      1. Physical Security.
      2. Physical Access.
      3. Data Integrity.
    2. The Modem Interface.
    3. Inter-campus Network.
    4. Regional and Wide Area Networks.
  4. AVCC AARNET Access Policy.
    1. Access by AARNet Members.
    2. Access by Non-Members.
    3. Situations where interim access may be provided.
    4. Indemnities.
    5. Register of non-members and referral of policy matters.

  1. Strategic System Platforms.

    1. Definition of ‘Strategic’.

      A strategic system is one that meets several of the following criteria specified in the university IT Project Inception Form:

      1. Is critical to the mission of the University.
      2. Affects large parts of the University.
      3. Yields university-wide benefits.
      4. Is large.
      5. Is expensive.

    2. Management of Strategic Systems.

      The following policies apply in the management of strategic systems:

      1. Strategic platforms will be managed and operated by ITS.
      2. Strategic Applications will be managed by the designated custodian of the application.

    3. Physical Security.

      The following standards of physical security of strategic platforms must be met:

      • Premises must be physically strong and free from unacceptable risk from flooding, vibration, dust, etc.
      • Air temperature and humidity must be controlled to within acceptable limits.
      • Platforms must 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.

    4. Physical Access.

      • Premises will be staffed and controlled by designated ITS staff.
      • External doors will remain locked, preferably with electronic locks.
      • There will be security screens on all external windows.

    5. User Access.

      1. New Users.

        New userid’s will be handled as follows:

        • Written application must be submitted on an official form.
        • The application form must have been signed by someone in authority (e.g. Dean, ITLO).
        • The applicant must present suitable personal identification.
        • The application form will be kept indefinitely by ITS.
        • The new userid and password will be given orally to the applicant, unless special delivery has been authorized due to special circumstances (e.g. applicant is overseas).
        • If the Operating System supports a password aging facility then it must be set to force password change on the first login.
        • The access level will be no higher than required as approved by the custodian.

      2. Terminating Users.

        The userids of persons leaving the University or no longer requiring access will be disabled. All files will be referred to the system custodian for disposal.

    6. Fire Detection and Control.

      • There will be smoke and thermal detectors on the premises.
      • Underfloor areas will have smoke and water detectors.

    7. Data Integrity.

      • Security backups of all data will be made daily.
      • The backup regime must 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 must be offsite storage of security backup media to enable a full data recovery to no earlier than one working week.
      • There must be a validation of security backup media at least once every six months.

    8. Password Aging.

      If the Operating System provides the facility, automatic Password Aging will be enforced. The life of a password should be no less than six months and no more than 12 months.

    9. Disaster Recovery Plan.

      There will be a Disaster Recovery Plan for every Strategic system.

    10. Documentation.

      Procedures reflecting these policies must be documented the ITS Computer Operations Instructions.


  2. Software Change Control.

    1. Definition.

      Software Change Control covers the control of all aspects of strategic systems software including the operating system, its associated packages (DBMS etc.) and utilities, third party and university developed applications, together with any command procedures and documentation to support and run them.

    2. General Obligations.

      When changes are required to systems software, associated packages and utilities, applications software, command procedures, or documentation, it is essential that the changes are :

      • appropriately authorized and approved
      • made in consultation with the university Audit & Review section, where appropriate.
      • thoroughly tested
      • sufficiently documented
      • implemented at an appropriate time.

      Any change must only be transferred into the production environment when approved by the appropriate System Custodian.

      Sound software security management requires the procedures to manage the change control for applications and systems changes be clearly defined. There must be a set of Software Change Control Procedures to assist the process.

      All operational software relating to strategic systems should be placed under appropriate Configuration Management.

    3. Change Control Responsibilities.

      Specific personnel will be given the responsibility for the implementation of changes by undertaking appropriate testing in the test environment, and, subject to the appropriate approvals, moving the changes to the production environment. All elements of the system will be subject to Software Change Control Procedures.

      There should be a separation of responsibilities in the transfer of software from test into the production environment.

    4. Change Control Environment.

      Where possible, three separate environments should be maintained for each strategic system :

      • development
      • testing
      • production

      Migration of software between environments should only be undertaken after obtaining the appropriate sign-offs as specified in the Software Change Control Procedures.

      New software and changes to existing software should be prepared in the Development Environment by appropriately authorized development or applications support staff. Applications should be specified, designed and coded according to the University’s systems development methodology (APT).

      Once assessed as satisfactory, the new or modified software should be transferred to the Testing Environment for systems and acceptance testing by an appropriate testing group, according to an agreed test procedure. Changes to software are not permitted in the testing environment.

      Following successful completion of testing and approval by the appropriate systems custodian, the new or modified software should be transferred to the Production Environment for implementation under the control of ITS Operations staff. A contingency plan to enable the software to be restored to its previous version in the event that the implementation is unsuccessful should be prepared where appropriate.

    5. Documentation.

      • Change Control Procedures
      • Procedures reflecting these policies must be documented in the ITS Software Change Control Procedures.

      • Software Change Request
      • No software change is to be undertaken without an appropriately authorized software Service Request. The Service Request is also the principal documentation to be completed for the software change management process.

      • Technical, Operations and End User Documentation
      • Appropriate documentation in respect of each software change must be completed in sufficient detail and accepted before the change is implemented in the production environment.


  3. Communications.

    Network access can be categorized into five major areas:

    1. Campus Local Area Network
    2. External Access via Modem link
    3. Intercampus Network (between Murdoch campuses)
    4. Regional Networks (Parnet, and Aarnet)
    5. Wide Area Network (Internet)

    The university has varying degrees of control decisions affecting security management of these areas:

    1. Total control over the campus LAN Modem links, and Intercampus Network, given that university staff plan, install, manage, and maintain these systems.
    2. Limited control over the Regional networks, which are managed by either a consortium of universities and CSIRO (Parnet), or the AVCC (Aarnet).
    3. No control over the Internet.

    1. Campus Local Area Networks.

      1. Physical Security.

        The following standards of physical security campus local area networks must be met:

        • Premises housing network control equipment must be physically strong and free from unacceptable risk from flooding, vibration, dust, etc.
        • External building ducts must conform to university standards of service reticulation.
        • Internal building distribution of cables within ceiling, wall or floor cavities, must be reticulated within protective conduits.
        • Air temperature and humidity must be controlled to within equipment defined limits.
        • Network electronics must be powered via Un-interruptable Power Supplies to provide the following:
          1. Minimum of 15 minutes’ operation in the event of a power blackout.
          2. Adequate protection from surges and sags.

      2. Physical Access.

        • Access to areas housing network electronics will be controlled by designated ITS staff.
        • Doors to areas housing network electronics will be locked with a unique key, the distribution of which will be determined by ITS staff.

      3. Data Integrity.

        1. Eavesdrop Protection.

          With our present security strategy, users are categorized into security sub-groups (students, administrative staff, general staff). However, the creation of each security sub-group requires a duplication of physical network infrastructure and increased central management. The end result of which is not always totally effective - e.g. the Chancellery users are an isolated networking sub-group, but if chancellery staff connect to the network from any other location on campus, then they forfeit all of the security of their designated sub-group.

          By utilizing eavesdrop protection at the network hardware level, full network flexibility on campus is retained at the user end, with an unbreakable system of eavesdrop protection.

          • Murdoch University Campus Local Area Networks should all be protected by a hardware level of eavesdrop protection.

        2. Intrusion Protection.

          Within the boundaries of the LAN, intrusion protection is required to prevent:

          1. non-university staff or students from indiscriminately plugging laptop computers into any access port of the campus network
          2. unauthorized access of staff and students to the Universities strategic systems.

          • Only those computers belonging to staff and students will be allowed to function when connected to the University network. Visiting personnel wishing to access the network must have authorization from a staff member, who must apply to ITS for temporary access rights.
          • No undergraduate student should be allowed Telnet or FTP access to strategic computing systems.

    2. The Modem Interface.

      One form of external access to the University network is via the University managed modem pools. Modem usage is significant, with most activity being out of normal business hours, and in this respect represents a higher than normal security risk. Both students and staff use the facility which operates at (90-100)% most evenings and on weekends.

      • No individual staff member or section of the university will connect a modem capable of receiving incoming calls to the university network without the express permission of the ITS section, who will stipulate a minimum set of operating criteria to ensure that security of the network is not compromised.
      • The ITS section will operate and managed the university modem facility using the following criteria:
        1. There will be physical separation of staff and student modem pools.
        2. Staff and student modem pools will be connected to separate physical networks.
        3. All modem pools will be password protected.
        4. Staff passwords will be activated on request for service and will be mirrored from the central ITS computer system. Password security policy for the central system will therefore apply to the modem authentication system.
        5. Student passwords will be pre-set for all newly enrolled students at the beginning of semester and will be based on a combination of the unique student number and the student’s date of birth. Students will be encouraged to re-set their passwords when they login for the first time. Student passwords are maintained on the central student computing system and mirrored by the student modem pool.
        6. Notification of staff resignation, redundancy or retirement must be given by the Human Resource Section, and those accounts must be disabled or removed from the central system - and therefore the modem authentication system.
        7. Those students who do NOT enroll in new semesters must be removed from the central student system and the student modem pool before the beginning of new semesters.

    3. Inter-campus Network.

      The inter-campus network is a private microwave system operated and managed by the University ITS section. ITS will ensure that:

      • Appropriate SMA (Spectrum Management Authority) licensing is sought for all microwave frequencies being used for data transmission between campuses.
      • Microwave equipment uses "focused" transmission techniques between transmitting and receiving dishes and that "non-focused" transmission is only used for non-secure data (e.g. broadcasting teaching material into the public arena.
      • Microwave repeater sites are secure - refer to Campus Local Area Network physical and access security.

    4. Regional and Wide Area Networks.

      Protection from illegal entry from public Regional and Wide Area networks is usually provided by network firewalls. However, with the diverse nature of the University’s business and the public nature of the services that it delivers, firewall solutions are not sufficient. Many of the University’s customers are external to the campus and use the public networks to access university teaching, research and library material. Also, academic staff can be highly mobile, requiring access to the University network from various external locations, often from overseas.

      Because of the nature of Wide Area Networks (WAN) there are only limited security measures that can be taken. Security Policy for Strategic Systems must rely heavily on software applications and general computer controls. The risks of transmitting information over the WAN must be considered when:

      • Determining the nature of information to be sent over the WAN.
      • Granting approval for new applications which involve the transmission of information over the WAN.

  4. AVCC AARNET Access Policy.

    The Australian Vice-Chancellors’ Committee

    Policy on Allowed Access to the Internet via AARNet Members

    The development of this policy derived from the need for a clearer definition of the categories of access to the Internet that should and shouldn’t be allowed via AARNet members. The policy was developed with the benefit of feedback from meetings of Regional Hub representatives, the briefing session on the AARNet/Telstra agreements and the considerations of the AARNet Board of Management and the AVCC.

    While the provision of Internet access via AARNet members is restricted to the categories listed below, AARNet members may publish electronic information which would then be accessible to the wider community through other Internet access providers. However, an AARNet member should not publish material where it has no control over content and which could result in the AARNet member being liable.

    AARNet Members (AVCC member institutions, CSIRO, DSTO, ANSTO and AIMS) are required to abide by the following statement of principles:

    1. Access by AARNet Members.

      Access should normally be allowed by:

      (i)staff, students and associated individuals (e.g. visiting fellows; honorary research associates) of the AARNet member in undertaking their duties and studies related to the operations and mission of the AARNet member;

      (ii)units of the AARNet member housed in another organization, (e.g. teaching and research departments of the AARNet member within hospitals, but not to servicing the hospitals themselves);

      (iii)University controlled entities and agencies that are wholly owned or operated by AARNet members and which do not provide Internet access to other parties.

      Access should NOT be allowed by:

      individuals, groups or organizations with accounts on machines belonging to an AARNet member for purposes that are not related to the operations and mission of the AARNet member.

    2. Access by Non-Members.

      Access should normally be allowed by:

      (i)Tertiary Admission Centres associated with AARNet members;

      (ii)Cooperative Research Centres, Cooperative Multimedia Centres, and other collaborative ventures where:

      • The principle objectives are the advancement of university teaching and/or research; and
      • The partners that are not AARNet members:
        • do not provide Internet access to other parties; and
        • do not use their Internet access rights to undertake activities unrelated to the collaborative venture.

      (iii)publicly funded not-for-profit research agencies with teaching and/or research links with the AARNet member (e.g. the Anglo Australian Observatory);

      (iv)conferences, congresses and workshops where there is an educational, research or professional society association with the AARNet member, but not where the program is primarily commercial.

      Access should not be allowed by:

      (i)vendors and commercial clients of AARNet members;

      (ii)organizations based in Technology Parks, unless allowed under (2.1) above;

      (iii)government departments and agencies, unless allowed under (2.1) above; and

      (iv)members of Alumni associations.

      These categories have commercial options available to them for the provision of IP and Internet services.

      Institutions may provide services to Alumni associations (e.g. Web pages), but access to these services by members should be provided by commercial Internet service providers.

    3. Situations where interim access may be provided.

      The Government’s intention is that Schools and TAFE will eventually be serviced by EdNA. Interim access by Schools and independent TAFE should be allowed until other alternative services are available.

      All former AARNet Affiliate Members and Value Added Resellers must make alternative Internet access arrangements prior to 1 January 1996.

      All other clients who currently obtain Internet access via AARNet members, but will not be allowed to do so under this policy, must make alternative arrangements prior to 1 January 1996 unless Telstra or other service providers are unable to provide access (as may occur in some regional areas), in which case AARNet members may continue to provide Internet access until other alternative services are available. Interim arrangements extending beyond 1 January 1996 should be referred to the AARNet Board of Management.

    4. Indemnities.

      If any AARNet member allows access under the principles set out, it is the responsibility of the AARNet member to ensure that it is adequately protected by putting in place suitable indemnities.

    5. Register of non-members and referral of policy matters.

      Each AARNet member must maintain a list of non-members to which it provides Internet access and make this information available for annual review by the AARNet Board of Management. AARNet members should seek advice from the AARNet Board of Management before providing Internet access to any client category that is not covered by the categories specified above.