All Collections
Privacy & Compliance
Compliance
Australian Code of Practice: Securing the Internet of Things for Consumers
Australian Code of Practice: Securing the Internet of Things for Consumers

How Socrative complies with the Australian Code of Practice

Brinna Smith avatar
Written by Brinna Smith
Updated over a week ago

Socrative has complied with principles 1-2, 5-7, 9, 11 and 13 of the Australian Code of Practice: Securing the Internet of Things for Consumers. This includes all principles recommended for Mobile Application Developers (2, 3, 4, 5, 7, 11, 12, 13) with the exception of principles 3, 4 and 12 which are not applicable to Socrative

Principle

Description

Socrative'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.

Teachers must register an account to use Socrative. Users must meet our password requirements and can use SSO authentication to enforce stronger password policies.

Socrative only collects necessary user data and will never sell your personal data to third parties and does not engage in any personal predictive profiling.

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.

Socrative 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.

Not applicable, Socrative is a web based product with regular updates to address any security concerns.

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.

Not applicable, Socrative is a web based product that does not store credentials locally.

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.

Socrative 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.

Socrative 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.

Socrative maintains a security recovery plan that is executed during or after an event and restores systems affected by cyber security events. Socrative'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.

Socrative users can delete their accounts at any time within their account profile. Users may also submit requests to review, revise or delete data 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.

Did this answer your question?