Our Commitment to Security
Drum is committed to maintaining a high level of cybersecurity and data integrity across the assets that support the Drum workflow software.
Drum is built with security best practices in place, which at a high level, include:
Automated test suite.
Code best practices for common cybersecurity threads.
Server and software updating requirements in place.
Automated code scanning for vulnerabilities.
A dynamic firewall to block bad actors as required.
Tight access controls on key infrastructure.
Drum is also committed to data integrity for our customers, where we implement:
Scheduled, automated daily backups.
Backup processes prior to major releases.
Automated database upgrades.
Data encryption for sensitive data.
No public access to unnecessary server infrastructure.
Private networks for secure infrastructure.
Hosting within Australian data centres.
We leverage our 10 years of software development experience and prior experience with software security audits and scanning processes to ensure that Drum maintains security best practices.
Drum Application Reliability
Drum is hosted in a Sydney-based data centre through an established provider, DigitalOcean to ensure Australian-based data storage and world-class latency and loading times across the software.
Drum operates our application servers behind a load balancer, which ensures that only servers that are operating correctly receive web traffic, ensuring that we have redundancy when required. The Drum team is notified of any outage as soon as it’s detected by our hosting provider.
The team behind Drum also ensures that our application remains reliable through our automated test suite, which ensures that all automated tests pass for any release of Drum to be valid.
Drum offers live chat and email support during Australian business hours and can respond very quickly (less than 5m in most cases) to any support requests that our customers may have.
Drum Infrastructure Security
Drum has been built using a web framework that ensures web security best practices at its core. This includes mitigations for the most common web security threats such as:
SQL injection.
Session hijacking.
Replay attacks.
Cross-site request forgery.
Brute-forcing of accounts.
Cross-site scripting.
Not only does the underlying framework itself largely mitigate these security risks, but the Drum software application also undergoes an automated static analysis security scan upon each release to identify any security risks and prevent the release from proceeding.
Drum also actively enforces:
HTTPS connections.
Best practice for security request headers.
Strict content security policy.
Strict cross-origin request handling.
No public access to uploaded documents, only accessible by a private key via the application servers.
The Drum servers themselves can only be accessed by individuals with an SSH key that has been pre-verified by the servers themselves, with no public access whatsoever.
The Drum application and database servers are consistently updated upon release of security patches outside of Australian business hours. These updates are staged so that there is no outage of the Drum application from a customer’s standpoint.
The Drum codebase is updated as patches to the underlying framework or dependent modules are released. The Drum team is notified of updates and actions those as soon as possible.
Payments within Drum are powered by Stripe. You can review how Stripe handles security here. Drum itself does not store credit card or any other payment method information.
Maintaining Drum Data Integrity
Drum uses best practices to ensure the integrity of our customer’s data:
We use the established database, PostgreSQL, to store our customer’s data.
Drum data is automatically backed up on a daily schedule.
The Drum database is manually backed up prior to major Drum releases.
A simple data backup process is in place to ensure rapid data restoration if a significant incident was to occur.
Drum user account passwords are encrypted at the database level.
Database records are partitioned based on their account ownership. Account A will only ever be able to access data that belongs to Account A.
The Drum database is dynamically scalable based on load.
The Drum database has automatic failover to a standby node in the event of a failure.
The Drum databases only run within the Drum private network, with no public access.
The Drum team has an established process to restore data to our customers accounts in a timely manner if a significant outage was to occur.
Drum Security Processes & Systems
Where possible, Drum Security processes are automated and implemented in a systematic manner to prevent user error. The automated processes that we have in place include:
A “Continuous Integration” system of development and feature releases where automated test suites and static security scanning takes place prior to any new release of the Drum software.
Automatic patching of database and application servers.
Notifications of security patching requirements for Drum application dependencies.
Automatic, scheduled daily database backups.
Existing “best practice” security implementation for the Drum application and database servers.
Using a code version management system, GitHub.
Our manual processes include:
Systematic updating of servers and application requirements as patches are made available.
Manual snapshotting of the database upon major releases.
A manual testing process of new features and updates.
Peer reviews of code.
Reporting according to the Australian Signals Directorate if we were to detect a security breach.
We are continually reviewing our internal processes as Drum continues to grow to ensure active management of security and data integrity risks.
Reporting
If you have any reason to believe that data within your Drum account has been accessed by a third-party or have any questions regarding the security of your Drum account, contact us directly at [email protected].