Security at Disciple

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 every 3-5 weeks. API updates are deployed 2-3 times a week.

Hosting:

Our hosting is provided by Amazon Web Services. AWS has intrusion detection systems in place. As clients, we are not granted server access apart from the ability to deploy code. AWS manages 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.0 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 cannot 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 (AWS, RDS, etc) where we do not have access to the operating system, there are limitations on what we can do.

Disaster Recovery:

All our infrastructure is managed by Terraform which ensures that services are set up correctly. In the case of a 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 PassKey
• Role-based access
• Email approval is 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 it will automatically expire.

There is a separate admin system for each Community (i.e. App). Login is via the Disciple SSO system.

Permissions Model:

The platform has two distinct types of users: Members, and Disciple Console users.  Console users can log into the CMS. Privileges are controlled by the users’ role. Current defined roles are:

2FA is required for 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.

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 the 1Password and LastPass password manager to ensure highly complex passwords 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.