Overview

This article serves to provide a high-level summary of the security practices in place in the COVID Comply 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
  • Application Programming Interfaces (APIs)
  • 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 a 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 any of our two domain names (covidcomply.org and covidcomply.com.au).

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

Application Programming Interfaces (APIs)

  • This software does not have any APIs.

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.

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 commercial discussion have begun.

For a more nuanced, detailed conversation on data security, feel free to email [email protected] directly.

Did this answer your question?