Principle

Description

Showbie's Compliance

1. No duplicated default or weak passwords

IoT device (and associated backend/cloud account) passwords should be unique, unpredictable, complex and unfeasible to guess, and not resettable to any factory default value that is common to multiple devices. Associated web services should use Multi-Factor Authentication, not provide any unnecessary user information prior to authentication, and any password reset process should appropriately authenticate the user.

Teacher, parent and administrator users must meet our strong password requirements and can verify their email address after creating accounts. Users are also encouraged to sign up with and/or enable Single Sign-On via Google, Microsoft, or Feide. Student users must sign up with a unique username or email address and meet our student password requirements. For enhanced security, students are also encouraged to use SSO.

2. Implement a vulnerability disclosure policy

IoT device manufacturers, IoT service providers and mobile application developers should provide a public point of contact as part of a vulnerability disclosure policy in order for security researchers and others to report issues. Disclosed vulnerabilities should be acted on in a timely manner. Implementing a bug bounty program encourages and rewards the cyber security community for identifying and reporting vulnerabilities, thereby facilitating the responsible and coordinated disclosure and remediation of vulnerabilities.

Showbie has a responsible disclosure policy for the reporting of security vulnerabilities via a bug bounty program.

3. Keep software securely updated

Software (including firmware) on IoT devices, including third party and open source software, as well as associated web services, should be securely updateable. Updates should be timely and not impact the device’s functionality. Updates should also not change user-configured preferences, security or privacy settings without prior approval from the user. The need for each update should be made clear to consumers, and updates should be easy to implement and applied automatically by default. The device should verify that updates are from a trusted source e.g. via use of a trusted digital signature. Updates should be distributed via secure IT infrastructure to mitigate the trusted source being compromised. For constrained devices that cannot physically be updated, the product should be isolatable and replaceable. Where possible, vendors should inform the user when their constrained device is no longer fit for purpose. An end-of-life policy should be clear to the consumer including when they acquire the device, which explicitly states the minimum length of time for which a device will receive software updates, the reasons for this timeframe and a commitment and method to warn consumers when the product will no longer receive updates. If a user interface is available it should clearly display when a device has reached its end-of-life, inform the user of the risk of security updates no longer being available and provide suggestions for mitigating this risk.

Showbie is a SaaS product that receives regular updates through the App Store.
​

Updates and end-of-life are managed through App Store updates.

4. Securely store credentials

Any credentials should be stored securely within devices and on services. Hard-coded credentials (e.g. usernames and passwords) should not be embedded in device software or hardware since they can be discovered via reverse engineering.

Showbie Mobile App stores credentials in Keychain following industry best practices.

5. Ensure that personal data is protected

Where devices and/or services process personal data, they must do so in accordance with data protection law e.g. the Privacy Act 1988 and Australian Privacy Principles. Personal data should only be collected if necessary for the operation of the device, and privacy settings on a device should be set to privacy protective by default. Adequate industry-standard encryption, as articulated in the Australian Government Information Security Manual, should be applied to personal data in transit and data at rest. Consumers should be provided with clear and transparent information about what data is being used and how, by whom, and for what purposes, for each device and service. This also applies to any third parties that may be involved (including advertisers). Where personal data is processed on the basis of consumers’ consent, this should be validly and lawfully obtained from an adult, with those consumers being given the opportunity to withdraw it at any time. Several other principles in this document are related to protecting personal data, such as installing and securely configuring devices, as well as deleting personal data.

Showbie is compliant with the Australian Privacy Act, GDPR, ISO 27001 and SOC 2. All data is encrypted in transit and at rest and the only personal data collected is that which is provided by the Data Controller (individual user, or administrator at a managed school).

6. Minimise exposed attack surfaces

Devices and services should operate on the ‘principle of least privilege’. Unused functionality should be disabled; hardware should not unnecessarily expose access (e.g. unrequired ports should be closed, the web management interface should only be accessible to the local network unless the device needs to be managed remotely via the Internet); functionality should not be available if they are not used; and code should be minimised to the functionality necessary for devices and services to operate. Software should run with appropriate privileges, taking account of both security and functionality. To further reduce the number of vulnerabilities, use a secure software development process and perform penetration testing.

Showbie staff operate on the principle of least privilege. User data is encrypted and only made available to staff or sub-processors with a legitimate business need and only the minimum amount of data required is provided. Development follows OWASP guidelines. Penetration testing is performed as needed via external review, as well as via our vulnerability reporting program.

7. Ensure communication security

Data requiring confidentiality or integrity protection, or associated with remote management and control, should be encrypted in transit, appropriate to the properties of the technology and usage. All credentials and certificates should be managed securely. All remote access should be logged, with logs including the date, time and source of access at a minimum.

All data is encrypted in transit and at rest. Our encryption uses 256 bit keys on a symmetric algorithm AES. Data transmissions are encrypted using TLSv1.X protocols. We implement SSL certificates with RSA algorithm and key sizes of 256 bit. Audit logs are kept.

8. Ensure software integrity

Software (including firmware) on IoT devices should be verified using secure boot mechanisms. If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function.

Not applicable

9. Make systems resilient to outages

Resilience should be built into IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power. As far as reasonably possible, IoT devices should remain operating and locally functional in the case of a loss of network, without compromising security or safety. They should recover cleanly in the case of restoration of a loss of power. Devices should be able to return to a network in a sensible state and in an orderly fashion, rather than all attempt to reconnect at the same time. Implementing redundancy and DDoS mitigation helps ensure that IoT services remain online. Architect IoT devices to continue functioning as much as possible if an associated IoT service becomes unavailable, and disclose upfront to the consumer which features will cease working in this case. IoT service providers should also update data when network connection is restored.

Showbie maintains a security recovery plan that is executed during or after an event and restores systems affected by cyber security events. Showbie’s system status can be monitored live and users can subscribe to updates in order to be notified about outages.

10. Monitor system telemetry data

If telemetry data is collected from IoT devices and services, such as usage and measurement data, it should be monitored for security anomalies.

Not applicable

11. Make it easy for consumers to delete personal data

Devices and services should be configured such that personal data can easily be removed when there is a transfer of ownership, when the consumer wishes to delete it and/or when the consumer wishes to dispose of the device. Consumers should be given clear instructions on how to delete their personal data, including how to reset the device to “factory default” and delete data stored on the device and in associated backend/cloud accounts and mobile applications.

Users can submit requests to review, revise or delete their data at any time using this request form.

12. Make installation and maintenance of devices easy

Installation and maintenance of IoT devices should employ minimal steps and follow Australian Government best practice on security and usability. Consumers should also be provided with clear and straightforward guidance on how to securely set up their device and maintain it through its lifecycle. Accessibility options on a device should be enabled by default.

Not applicable

13. Validate input data

Data received via user interfaces, application programming interfaces (APIs) and network interfaces should be validated. Ensure data input is authorised and conforms to expectations.

Applications and databases shall be developed and configured to protect the confidentiality, integrity and availability of restricted information. This includes: Implementation of access control, authentication and session-management; Data validation checks; Do not reveal system information in end-user error messages; Protecting restricted information and using encryption where required; Time-out for user connections after a period of inactivity; Logging of user activity so that actions can be traced to an individual.