Overview
This article serves to provide a high-level summary of the security practices in place in the Comply Group platform. For simplicity purposes, there are 10 core areas of security that we'll run through in this guide:
Transit security
Traffic screening
Server level security
Data encryption
Data backups
Database record ID management
Account security
Email security
Penetration tests
Note, we also have a high-level Incidence Response (IR) plan - available here
Transit security (SSL)
We strictly enforce encryption on all traffic at multiple layers;
An edge SHA256 SSL certificate managed and distributed by Cloudflare (our CDN and external WAF).
An origin SHA256 SSL certificate managed by Cloudflare and installed directly into our servers.
We enforce all requests to be secure (HTTPS) using TLS 1.2 or greater and by enabling HSTS with a 6 months maximum age.
We have 24/7 monitoring of the production and distribution of certificates using our domain name, comply.group.
CDN & External WAF
We use Cloudflare to filter bad actors from using the platform.
Enforce JS Captcha scripts for all traffic outside of our primary supported countries (UK, Ireland, Australia, United States, Canada).
Block countries with a high rate of bad request attempts (Russia, Nigeria, Pakistan, India, Ukraine, China, North Korea, and more).
DOS & DDOS protection (with escalation polices) enabled.
OWASP Top Ten filters enabled (and other platform-specific recipes)
Internal WAF & request monitoring
We use Sqreen to filter bad actors within the application.
Automatically blocked IP addresses behaving strangely within the platform architecture.
Direct integration into the authentication library to monitor; failed login attempts, password reset attempts, non-human authentication behaviour, etc.
DOS protection (with escalation policies) enabled.
OWASP Top Ten filters enabled (and other platform-specific recipes).
Server security & compliance standards
We use AWS as our exclusive hosting provider.
Data centre compliance (ISO 27001, SOC 1, SSOC 2, PCI Level 1, FIDMA Moderate, SOX).
Automated application and infrastructure vulnerability monitoring and server operating system security updates management.
Data encryption
Databases (and their backups) are encrypted at rest.
All data is encrypted in transit (described above in "Transit security").
Check-in data that is personally identifiable (email, phone, address, identification number, etc) is encrypted within the database.
Check-in data downloaded for a location is stored in a password-protected Zip file with a different, random password for each download.
Data backups
All databases are backed up on a 30-day rolling basis with Point in Time Restores.
All s3 buckets (used to store files) are fully versioned controlled (since creation) and are fully recoverable when updated or deleted.
We have our servers and database distributed across two independent zones in Sydney providing real-time geographic/zonal-based failure redundancy.
Database record ID management
Each record in our database has a unique ID.
These unique IDs are not exposed to the web. RESTful requests using database record IDs in the URL are rejected.
Each record's ID is obfuscated with a unique, 12 character minimum, alphanumeric hashid which is uniquely salted and peppered.
Account security
Account passwords are salted and peppered.
Account passwords must be alphanumeric and a minimum of 8 characters.
Every account authentication interaction is recorded and logged.
Every check-in data download is recorded and logged.
Every change to a location is recorded and version controlled.
All actions throughout the platform have authentication and authorization RBAC policies documented, implement, and tested.
Multi-Factor Authentication is available for all users (read feature guide).
Email security
Send Policy Framework (SPF) is configured and enforced
DomainKeys Identified Mail (DMARC) is configured and enforced
Penetration tests
We conduct penetration tests when it makes sense for us to do so, most typically on an annual schedule or sooner if large changes are made to critical areas.
If you'd like to conduct a specific penetration test to get a specific report type, if you pay for it we will commit to conducting any necessary remediation.
If you'd like to request a copy of our most recent penetration test report, we'd be happy to oblige, but only after the commercial discussion has begun.
For a more nuanced, detailed conversation on data security, feel free to email [email protected] directly.