Guidelines for IT Custodians

IT Custodians are responsible for the acquisition, maintenance and operations of all University IT—including workstations, servers, web applications, cloud-based services etc.

This guideline provides practical tips for all IT Custodians in order to secure their IT systems and reduce risks of security compromises and data breaches. If you are unsure of anything, please contact the IT Security team at itsecurity@adelaide.edu.au.

The responsibilities of IT Custodians can be summarised as follows:

  1. Secure the IT systems under your management by implementing controls and processes using this guideline, following this guideline and/or by consulting Technology's Risk & Security team.
  2. Respond to requests from Technology's Risk & Security team to address known security issues in a timely fashion.
  3. Report actual or suspected security incidents, as well as any known security risks to Technology's Risk & Security team.
  4. Comply with the IT Acceptable Use and Security Policy, the IT Acceptable Use Procedures, and the IT Security Procedures, as well as this guideline.
  • Data security

     Does your IT application store, process or transmit Class 4 or Class 3 data? If yes, it should have extra countermeasures in place to protect the confidentiality of the data. Class 3 refers to sensitive data such as private information related to people, while Class 4 refers to top-secret data such as defence research. Refer to the CSF Information Classification and Protection Standard for detailed definitions and examples of Class 4 and Class 3 data, and requirements for protecting them.

    Here is some general advice for protecting Class 4 and Class 3 data within your applications:

    • Encrypt data during storage and transmission
    • Where possible, redact, de-identify or anonymize privacy data so that it cannot be identified
    • Grant access based on "least privilege" principle
    • Keep an audit log of who has accessed sensitive data
    • Require authentication by complex password and implement multi-factor authentication
    • Do not send across insecure network and protocols such as unencrypted HTTP and email
    • Educate users on the risk of copying sensitive data to personal devices such as home computers and mobile devices

    For more information, refer to the Protecting my data page and contact ITDS Information Security if you have further queries.

  • Third party hosting

    If you are the IT Custodian of a third-party hosted application (SaaS or "cloud-based" applications), what can you do to protect the security of data stored outside of your control boundary? If you intend to sign-up to a cloud-based application service, please read and follow the University's Third Party Hosting Security Guidelines which includes a handy checklist for ensuring that the service provider meets your security requirements.

    Here are tips to gain a level of assurance that your service provider has sound security practices, and your data is secure in their hands:

    • Check that your service contract and terms and conditions cover security as the provider's responsibilities
    • Ask the provider if they have security governance or certified for international standards such as ISO 27001
    • Ask the provider if they have been audited under the service organisation control (SOC) and ask to see the most recent audit reports
    • Ask if their service has been tested by an independent and professional penetration tester
    • Ask if data is backed up and if they provide an service level agreement (SLA) with financial penalties in case of breaches

    Refer to the Third Party Hosting Security Guidelines and associated checklist for further details.

  • Patching and updating

    Malicious hackers take advantage of vulnerabilities in software at all layers, including the operating system, database system, middleware, application server, and web server to gain unauthorised access. The key to protecting against this type of attack is to keeping your systems up to date with the latest security patches provided by software vendors.

    Here are some tips:

    • Turn on automated updates wherever possible so that your software will remain up to date automatically
    • Subscribe to vendor newsletters and notifications so that you will know of available updates quickly
    • If you are using software that you have developed yourself, understand the platforms and libraries you are using, and update them on a regular basis. If you rely on Java, for example, vulnerabilities in JVM can compromise your application even if your code is secure.

    If you are concerned that you may not be able to keep your IT system current and up to date, contact the Risk & Security Team. We maintain a register of products used outside of Information Technology and Digital Services, and we can monitor for new vulnerabilities and patches available on your systems.

    Finally, IT Custodians should know that software vendors often discontinue support of older versions of software and cease distribution of security patches (e.g., Microsoft has now stopped support of Windows XP and Windows Server 2003 among others) and using these platforms can be a significant risk if new vulnerabilities are found.

  • Account, password and privilege management

    Account and password is the first layer of protection that identifies the person accessing your system, and privilege management provides the level of access that is commensurate with the user function. If your application is multi-user and/or client-server, here are some advice:

    • Avoid issuing a new set of identities--leverage the University's identity and authentication system instead. Please talk to Information Technology and Digital Services in order to leverage single-sign-on (SSO) using CAS or ADFS.
    • Apply the principle of "minimum privilege" by granting people with only access they need to do their function. Don't ever give everyone "admin" access just because it's easy!
    • Do not store passwords in plain-text or using reversible encryption. Use "salted" SHA1 at the minimum.
    • Configure the application to require complex password (greater than 8 characters with character requirements).
    • Configure the application to "lock-out" accounts after multiple failed login attempts.
    • Configure the application to become disabled after more than 90 days of inactivity.
    • Implement an account and privilege management process so that people who no longer need access are removed in a timely manner.
    • Configure auditing wherever possible to detect suspicious use of accounts
  • Secure configuration

    Unfortunately, many software applications are insecurely configured out of the box, and require configuration and fine-tuning to make it secure. Here are some examples:

    • Some applications may come with a default administrator password such as "password". Make sure to change all default passwords!
    • Some applications may have insecure default services such as telnet and ftp open without a password, and may require configuration to disable such service.

    It is important that read the product manuals carefully and implement security configurations to meet your needs. For popular platforms, there may be existing "hardening" or "best practice" guidelines available. For example, there are benchmark documents published by CIS (https://www.cisecurity.org), and there are tools that can automatically audit your configuration and point out to weaknesses.

    If you are unsure, contact the Risk & Security team within Information Technology and Digital Services to ask for a configuration review.

  • Secure development

    If you have a fully customised IT system that you have developed yourself or outsourced to a third party, then implementing security into the program code and keeping it free of vulnerabilities is your responsibility.

    Can you be confident that your application is not vulnerable to buffer overflows, XSS, SQL Injection, Directory Traversal, and other common attack vectors?

    Here are some tips for developing secure software:

    • Follow a secure coding and secure development standard that considers, for example, the OWASP Guide.
    • Implement sound input validation and filters that only accepts legitimate user inputs and forbids potentially malicious inputs.
    • Ensure Class 3 data is encrypted during transmission and storage
    • Implement strict authentication, session management and access controls
    • Make use of code audit tools or ask an independent person to perform a code review.
    • Engage the Risk and Security team to perform an independent review of security, including vulnerability assessment and penetration testing.
    • Follow a sound change management process so that code changes are thoroughly tested before "go-live" to prevent vulnerable code from being introduced into the production environment.

    The Risk & Security team can provide training to developers on the basic concepts of secure application development upon request.

  • Vulnerability assessment

    Despite having followed all of the advice presented in preceding sections, black-box testing is still an important part of security especially if you handle sensitive data. Black-box testing is a kind of assessment where the tester wears the bad guy's hat and use real hacker techniques to try to break into your system. This helps to reveal holes that may have been missed through other activities.

    If you would like a black-box assessment performed on your IT system, please contact Risk & Security team. We can usually provide this service free of charge depending on availability of resources.

  • Backup and disaster recovery

    Ask yourself:

    • Is your IT system or application critical to your research or your business area?
    • How long can you continue your work with the system being unavailable?
    • What are the cost associated with extended downtime or permanent loss of data?
    • Are there legal or policy requirements for data retention?

    Based on your answers, IT custodians should develop a strategy for data backup, retention, and recovery. Having a proper recovery plan ahead of time can save you time and money.

  • Network security

    Think before you decide to make your application accessible to the internet, as exposing it to public network means anyone on the internet can have a go at attacking your system, making it more likely to become compromised.

    If the system is only used by the University community, keep it within the University network and require VPN remote access or ADAPT remote desktop before gaining access.

    Note also that Information Technology and Digital Services can implement segmented network control if required, so that your application can be accessed from only certain network sources, either internally or from the internet.

  • Security software

    Applications hosted on Information Technology and Digital Services infrastructure (e.g., Windows or Linux instances hosted on Information Technology and Digital Services' VMWare environment) will have basic security software installed, including antivirus. If your application stores or processes sensitive information or faces the internet, consider additional security software such as:

    • Host-based Intrusion Detection System (HID)
    • File Integrity Monitoring System (FIM)
    • Application-layer firewall and IDS/IPS