Security white paper for CertCare applications

Users: the members of your organization, managed by designated administrators within the organization. All members of the organization are assigned to role(s) which determine the users’ access to features and transactions.

Comments: if flagged as “private”, only users from your organisation have access to it.

All connections to and from the service use HTTPS with the TLS 1.2 protocol, using 2048-bit RSA keys and AES encryption, if clients support this as well.

The older, weaker SSL protocol is disabled.

Sensitive cookies are set with secure and HTTP-only flags.

All user input is validated before processing. Special care is taken to prevent Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF) and SQL Injection.

User-uploaded files are automatically scanned for malware upon upload and rejected if malware is found.

Malware definitions are updated regularly and automatically.

Passwords have a minimum length of 10 characters and must contain at least one lowercase character, one uppercase character and one non-alphanumeric character.

Passwords are stored as salted hashes using the BCrypt algorithm, so CertCare has no knowledge of the actual passwords.

Upon first login from a new device, a confirmation email is sent to the user’s registered email address with a one-time secondary authentication factor. The email confirmation request is repeated monthly (if 2FA feature is enabled).

Data is encrypted in transit and in backups.

All communication over public networks uses HTTPS with TLS 1.2 (where supported by the client). RSA keys have a length of 2048 bits.

The older, weaker SSL protocol is disabled.

Passwords are stored as hashes, using the highly secure BCrypt algorithm.

Outgoing transactional email is handled by our ISO 27001:2022 certified email delivery partner, Amazon Web Services.

DKIM signing is applied to all outgoing email. Sender forgery is prevented using SPF.

Access to the production environments requires private SSH keys.

A limited group of senior system engineers has access to the servers in the production environments.

The least-privilege principle is applied.

Only necessary ports are open. On all servers, all ports and services are blocked by default and only opened when services are required.

CertCare servers are provisioned using a centralized configuration management system which ensures unified secure configuration across all servers. Version control is applied to all configuration data.

Security-critical patches are installed within 24 hours of availability.

CertCare servers are automatically protected against DDoS attacks.

User logins are logged in each instance in a centralized audit log.

Server logs which are relevant to security are stored in each instance and are subject to analysis and automated alerting.

24/7 monitoring and automated alerting ensure CertCare system engineers can act quickly in case of service disruptions (SaaS only).

CertCare guarantees 99% uptime, excluding scheduled maintenance windows.

All critical services are set up redundantly to ensure high availability, in most cases with fully automatic failover.

All customer data is backed up daily and kept for one month so that data can be restored in case of an emergency.

Encrypted backups are stored off-site.

CertCare’s disaster recovery plan helps to quickly recover services in the event of a disaster.

The data centres in which CertCare is hosted are ISO 27001:2017 certified.

Physical access to data centres and servers is restricted to authorized data centre personnel.

CertCare development environments are separated from testing and production environments.

Production data is never used for testing purposes.

Production data is never transferred out of the production environment to test environments without consent of the client.

Scripted test suites are run for every change to CertCare code, and changes are not deployed until all tests pass. In addition, manual testing and quality assurance are done in an isolated testing environment that is not accessible to normal users.

All changes to CertCare code are peer-reviewed by senior developers who have extensive knowledge of application security. The application is developed according to industry best practices and measures are taken to prevent vulnerabilities such as those listed in the OWASP Top 10.

GitHub Dependabot is used to monitor necessary updates to the libraries used by CertCare.

Daily automated SSL server tests ensure our SSL configuration stays up to industry standard (SaaS only).

The access controls of the application are subject to scripted tests which are run on every change and every release.

All changes to the application are subject to an extensive suite of API and integration tests as well as unit tests.

Customers are permitted to conduct their own penetration tests on request.