A summary of some of the key points regarding security at Disciple
Development
Each development team only has access to the code for the projects they are working on. Access to GitHub code repositories over the web is protected by two-factor authentication and encrypted in transit with TLS. Access to the code through Git is granted via a user-specific and device-specific SSH key and is also encrypted in transit via SSH.
Libraries and external SDKs are automatically monitored for available updates by Dependabot. If an update becomes available, the appropriate change is automatically queued up for review by a developer. Should there be a security release, this process is expedited, particularly for those libraries used in the API.
Any new code that is written is reviewed by at least one other developer to ensure high quality and best practice security features using the GitHub pull request system. No code is merged to the mainline branch until this takes place.
We use programming languages such as Ruby that are resistant to many classes of security vulnerabilities, such as buffer overruns. Every change to our codebase has quality assurance tools automatically run against it, which include some best practice checks that avoid security issues.
We regularly engage an external security firm to assess the vulnerability of the service to unauthorised access and misuse. Should any issues be detected, fixes are applied as soon as possible.
Updated app versions are typically deployed multiple times a week. API updates are deployed 2-3 times a week.
Hosting
Our hosting is provided by Heroku (part of Salesforce) and Amazon Web Services. Heroku and AWS have intrusion detection systems in place. As clients, we are not granted server access apart from the ability to deploy code. Heroku & AWS manage the OS and security.
Customers’ community backends each run on their own 'stack' – this means that each community is completely isolated from other communities.
Databases are deployed by AWS RDS in Multi-AZ. This provides a ‘hot spare’ should the primary instance suffer a failure. Snapshots are taken daily, and in case of catastrophic failure we keep off-site daily encrypted (AES-256) backups for 30 days before they are permanently erased.
The RDS databases have encryption turned on (AES-256) which means data is encrypted at rest before being stored on disk. Encryption keys are stored in AWS KMS (Key Management Service).
All network traffic is encrypted - all requests to our API or web products are enforced to be HTTPS (TLS 1.2 and above).
Access to our production environments is only granted to employees that have a genuine need for access, they are not generally accessible.
We have comprehensive logging that includes authentication events to enable an audit trail. Systems that generate logs do not have the ability to erase or alter earlier logs.
Deployment is done by an automated system that will only deploy code which has passed multiple checks including an extensive suite of automated tests. The final step to deploy to the live environment can only be done by authorized members of staff. Access to the deployment server is only possible through whitelisted static IP addresses or secure VPN connections.
Any tokens or keys that used in production are stored in an encrypted repository using PKCS#7. The encryption keys are only known to senior tech staff.
Customers can choose their hosting location. We currently support:
- us-east-1
- Backups stored in us-west-2
- eu-west-1
- Backups stored in eu-east-1
Data is not transferred outside of the US (or EU for EU hosted apps).
It should be noted that because we rely heavily on managed cloud hosting (Heroku, RDS, etc) where we do not have access to the operating system so there are limitations on what we can do.
Disaster recovery
All our infrastructure is managed by Terraform which ensures that services are setup correctly. In the case of disaster our infrastructure can be recreated in a matter of minutes in another availability zone, and then data can be restored from backups.
Data
Databases are not directly accessible to staff. Encrypted backups are stored on Amazon S3 and only accessible to senior tech staff.
Viewing and downloading of users is restricted to those with the ‘manager’ role in the admin system. (For more information about access to the admin system see below).
Users’ private data (such as messages) is not accessible to any admin users.
Our mobile applications store authentication information securely using the relevant platform support (e.g. Keychain on iOS using AES-256-GCM). This provides hardware-backed encryption where available.
Admin
Access to admin screens by users is controlled by the Disciple SSO system. This features:
- 2 factor authentication using Authy.
- Role-based access
- Email approval required when logging in from a new browser/device
- Detailed logging of successful/failed logins, and audit trail of changes to users
- Future versions will include temporary (time-limited) access, for example if a team member needs temporary access which will automatically expire.
There is a separate admin system for each community (i.e. app). Login is via Disciple SSO system.
Permissions Model
The platform has two distinct types of users: Members, and Disciple Console users. Console users are able to log into the CMS. Privileges are controlled by the users’ role. Current defined roles are:
|
Statistics |
See high level statistics such as user numbers, subscribers, MAUs, DAUs, etc. |
|
Moderator |
See all content and ‘unpublish’ them if they breach guidelines |
|
Publisher |
Post as an artist and update other media in groups or folders |
|
Community Host |
View users, basic actions such as a reset password |
|
Manager |
Manage users, grant premium status and control branding and releases |
|
Administrator |
Manage app products and other technical tasks |
Two Factor Authentication is mandatory for all Console users.
Members can only log in to the mobile apps and public facing web app. They can only access information that has been publicly posted.
In a standard Community setup, people can register for an account to get access. Only once they have logged in are they able to see content. Visibility of content to non-logged in users can be changed in the console.
Member password check: To help make your members accounts and your communities safer, when a member sets a new password we now check it against public data breaches. This helps makes sure members aren’t reusing passwords that have previously been exposed on the internet.
We also support invitation only apps so that only users who are invited by email may log in. If someone has not been invited then they are not able to register.
Members can only access information that has been posted in the groups which they are a member of. By default member posts can be shared publicly - they have a URL which can be accessed by anyone who knows it. However this can be centrally disabled to ensure the privacy of the community.
Members can only see a limited amount of other member’s information.
Member-to-member messages are completely private. CMS users are not able to read these.
Operations
We use company-wide security policies to enforce operational security for things like laptop encryption and locking.
All staff use a password manager to ensure highly complex passwords that are not reused.
Monthly audits of who has access and what roles they have to ensure that staff only have the minimum access they require.