Below is a list of commonly asked IT / Security questions. If you do not see an answer to your question, email us at mydispense1@monash.edu .

The documents on the terms and conditions page also have useful information not covered here.

Personnel

For the purposes of hosting, the MyDispense team consists of two people: Keith Sewell and Keenan Beaumont. The main developer of the project is Keenan Beaumont. It is important to note that we are not an enterprise vendor and the answers to the questions below reflect that.

Keith Sewell and Keenan Beaumont are both employees of Monash University at the Faculty of Pharmacy and Pharmaceutical Sciences. The MyDispense project is not centrally supported by the IT department at Monash University. We are what you get.

Outside of university policy, we do not have any background checks or confidentiality agreements in regards to MyDispense.

Infrastructure

Where is MyDispense hosted?

MyDispense is hosted on Amazon Web Services (AWS) in the closest data centre to the location of your region. Each institution has their own MyDispense instance – we do not host a single MyDispense service.

What is MyDispense hosted on?

We typically host MyDispense on a AWS EC2 t2.small instance. t2.small instances are able to handle class sizes of about 120 students with the caveat that resource intensive features such as PDF export are not used in large amounts. For larger class sizes we will use a t2.medium instance and have used it for handling class sizes of 200 or more.

How do you back up MyDispense?

Backups are securely stored on a AWS S3 bucket in the same region as the MyDispense instance. Thus if your instance is hosted in Sydney, the backup data is also stored in Sydney. Database backups are taken each night, asset files are backed up every week and there are monthly database and configuration backups taken.

Restoration / Recovery

The backups taken are able to fully restore a MyDispense site to the previous backup. In the event of a system failure on AWS we will use the last backup to set up a copy of your MyDispense site on a new AWS instance.

Any data from the previous backup would be lost. The address of the server will change (we have hit the limit on elastic IPs on AWS, so we are unable to allocate more), so this means that the DNS record for the server will need to be updated.

If a failure occurs we can typically have a server up and running with a backup within a couple of hours. The time consuming part of the restoration procedure is waiting for the DNS record to be updated for the server.

To reduce the time taken to restore a server, we have started requesting the use of DNS CNAME records instead of A records for institution domains. The institution record will point to a mydispense.site DNS record that will contain the final server IP address. In the event that a server goes down we will update the A record to the new server IP so we can restore service faster.

In our experience a server failure on AWS is unlikely. We have experienced hardware degradation on AWS in the past and in that event we will contact you to let you know about the degradation and will start setting up a new server.

Why do you request an institution subdomain?

We request a institution subdomain for each instance to formalize the MyDispense site with your institution. Having an institution domain name indicates a degree of trust with the institution and the students using the site.

As noted in the restoration / recovery section above we now request that a CNAME record to a mydispense.site record be created. This allows us to reduce downtime in the event of a server failure and perform server upgrades (that in the background will have an IP address change) with minimal impact.

It also allows us to implement HTTPS and improve security for the site as a whole. For institutions where a subdomain can not be arranged we can host the site directly using a mydispense.site subdomain, but we prefer not to for the trust reasons listed above.

Uptime

We do not guarantee a specific uptime amount for MyDispense. In our experience MyDispense sites are up 99% of the time and only AWS outages (also rare) will stop them from being accessible. Typically we perform server maintenance (MyDispense updates, system updates) out of hours each week for that region.

Europe and North American maintenance occurs on Monday Australian Eastern Time (Sunday night for NA and Europe)

Oceania server maintenance (Australia, NZ, SEA) occurs on Saturday or Suday AEST.

Data privacy and protection

Do you share data with 3rd parties?

We do not share MyDispense instance data with 3rd parties. We will only share data from your instance with you at your request. MyDispense is designed to be self-contained and we do not use any externally hosted libraries. Our default configuration is to block third party scripts and inline scripts can not be run on MyDispense sites.

What data is collected?

We store as little external information about users as possible and only to facilitate the functionality of the software. We collect the following:

  • IP addresses
    • Used to audit access for login and exam purposes
  • Web browser type + Operating system
    • So we know which browser types are in use so we know which ones we should support and test
    • Example: Chrome 45 Windows, Edge 24 Windows
  • Email addresses (optional)
    • Email addresses are only required if account based authentication is used. To facilitate account activation and password resets.
    • If single sign on is used then we do not require the use of email addresses.
  • Passwords (optional)
    • Like emails, password storage is only required if SSO is not in use.
    • All passwords are salted and hashed – we do not store plaintext passwords.

How is data used?

MyDispense site data is used to store backups (as noted in the infrastructure section) and we also store general usage statistics from each site so we know how MyDispense is being used. Statistics are gathered each week. The general statistics we collect are listed below:

  • Health
    • Collects the last date and time an event occurred.
      • Admin user logged in
      • Student user logged in
      • Activity was completed by a student user
    • The data sent is a timestamp. For example: 2020-07-14 11:44:00
    • This is stored against our record of your institution and its MyDispense instance.
    • We use it to track when a site was last used and to contact institutions where a site has not been used in more than a year. This is so we can contact you to determine if you wish to continue using the site.
  • Assets
    • Collects hashes of assets created over the past week to keep track of the growth of new assets added to MyDispense.
    • Assets in MyDispense are defined as medications, patients, patient images and prescribers
    • The data sent is a sha1 hash of an image associated with an asset, or the combined text of an asset without an image (Patients)
      • A hash looks like this: 40c287388a8aa9c4f6aadb5e4eec45b5afcdd8ba
    • The hashes sent are compared against the ones stored in our management site to track overall additions of new assets of a particular type over time.
  • Activities
    • Collects the number of each type of activity completed by students over time, the number of students in the system and the number of student logins made in the past week.
    • For example, if 2000 dispense exercises were completed up to 2020 week 24, then the number 2000 would be sent to our management site.
    • We collect data for the following activities as a number:
      • Dispense exercises completed stand alone
      • Dispense exercises completed as part of a scenario
      • Validation exercises completes stand alone
      • Validation exercises completed as part of a scenario
      • OTC exercises completed stand alone
      • OTC exercises completed a part of a scenario
      • Scenarios completed
      • Prompts completed as part of a scenario
      • Questions completed as part of a scenario
      • Number of students enrolled in the system
      • Number of student logins to the system

We will not share individual institution usage data with any other party than the institution. We will only use aggregate data in presentations – for example the number of exercises completed by all institutions. Institution specific data on its own will only be used with permission.

We may also use a backup of your site for debugging purposes if a problem occurs with your site and we request to use a backup of your site to fix the issue.

Security

Access controls

Physical security of the servers is managed by Amazon Web Services (AWS). We do not have any physical access to any of the systems.

We maintain two user accounts on each MyDispense site for support purposes. Outside of support requests we will not use these accounts to access your site.

Otherwise administrative access to the site is handled by institution staff. After setting up a site we will create an administrator account for the nominated user. Further access would then be managed by creating other users.

Backend server access is only available to Keith Sewell and Keenan Beaumont. This includes shell access to the system. No other users have backend access to the MyDispense systems. Backend access is also handled via SSH keys – only whitelisted keys have remote SSH access to the servers.

Firewall

All MyDispense sites have the following common inbound firewall rules:

  • HTTP – any port
  • HTTPS – any port

SSH access is whitelisted to certain IP addresses. There additional rules allowing the management server access to monitoring systems. The management server hosts our management site (used to keep track of MyDispense instances and stats) and monitoring service (NAGIOS).

Data encryption

By default we will set up HTTPS on all MyDispense sites and will force all connections to the server to use HTTPS by forcing a HTTP to HTTPS redirect. We support LetsEncrypt for 90 day SSL certificates but can issue a CSR if preferred or when LetsEncrypt is not available for a site.

Backups are not encrypted at rest but are stored in a non-public AWS S3 bucket that is stored in the same region as the server.

Standards

We follow the OWASP Top 10 (https://owasp.org/www-project-top-ten/) development guidelines for development of MyDispense. We do not follow formal policies or certification for IT security (SOC3, ISO27001) due to the size of our small team.

If we were an enterprise IT vendor we would consider getting those certifications. However, since we are not we follow the principals of least access. SSH access is whitelisted via IP and uses keys. Our NGINX config uses a strict Content Security Policy (CSP) to prevent any externally hosted materials from running on the site.

We also disable inline Javascript so that even if an injection vulnerability is found, any injected Javascript will not run. Additionally our policy is to store and collect as little external data as possible. This reduces our overall risk factor and in the event of a breach, very little personal data would be lost as a result.

Incident response

In the event of a security incident or breach, we would immediately inform you of the breach. We would work with you to determine how the breach occurred and share any information that we find along the way. If you wish to review the data, you can.

We have not had any breaches on MyDispense so we can not relate our experiences with you. If this changes, we will inform you.

Penetration testing / auditing

Penetration tests can be performed on our sites at your expense. We will work with you to facilitate the test and provide the required level of access. We do not routinely perform these tests as we do not have the personnel to facilitate them.

Single Sign On (SSO)

Is SSO supported by MyDispense?

Yes, we support SAML and CAS based authentication with MyDispense. We will work with you to implement SSO with MyDispense.

How does it work?

When logging into MyDispense using SSO, users are logged into an internal MyDispense account that matches the username attribute we set from the SSO system. For example, if I were to log in and the institution says my account name is jason, MyDispense will log me into an account called jason.

During the set up process the appropriate username attribute is set in the MyDispense configuration. Ideally this will map to student user names so that teaching staff can bulk import students and grant them access to units using CSV files.

If a person logs in and they do not have an MyDispense account already set up, an account will be created for them (on the fly account creation). The account will have no access to the system and they will only see a message telling them that they are not enrolled in any units.

How is administration access managed for SSO accounts?

By default all new SSO accounts are created as student accounts. Once the account has been created administrative access can be granted by an existing administration user using the staff page in admin options. Once access has been granted the user will need to logout, then log back in again for the access change to take effect.

Can admin access / student enrollment be granted automatically?

No, we do not integrate with any access management or student management systems. You will need to manually grant administration access and enroll students in units.

Can you publish SAML metadata into a federation?

No. We are not members of any Metadata federation and will not join one to publish metadata. Each MyDispense site is its own discrete entity – there is no single service that all users log into. Therefore the SAML metadata that we provide to you will only ever be used by your institution.

Multifactor authentication

If your SSO solution supports Multifactor authentication then it should be supported by MyDispense. We do not support multifactor authentication for the internal MyDispense authentication system.