Product Security

All customer data stored within Verified cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.3 to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Verified use AES-256 encryption at rest. Data encryption at rest helps guard against unauthorized access and ensures that data can only be accessed by authorized roles and services with audited access to the encryption keys.

Verified uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.

Tenant isolation ensures that, even though customers are sharing a common IT infrastructure, they are logically segregated so that the actions of one tenant cannot compromise the data or service of another tenant.

This concept ensures that, in this shared environment :

• Each customer’s data is kept logically segregated from other tenants when at-rest; and
• Any requests that are processed by Verified have a “tenant-specific” view so other tenants are not impacted.

Our approach to vulnerability management for our products consists of internal and external security testing.

This approach spans planning, development and testing phases, each test building on previous work and progressively getting tougher. We have an established approach to static and dynamic code analysis at both the development and testing phases. In the development phase, we focus on embedding code scanning to remove any functional and readily identifiable, non-functional security issues.

In the testing phase, both our development and security engineering team switch to an adversarial approach to attempt to break features using automated and manual testing techniques.

Our security engineering team has developed a wide range of security testing tools to automate common tasks and make specialized testing tools available to our product teams. These tools are beneficial for the security team and they empower developers to “self-serve” security scans and take ownership of the output.

Our security engineering team are subject matter experts, but it’s ultimately every developer in our company who is responsible for their own code.

When a vulnerability is identified by one of our users during standard use of a product, we welcome notifications and respond promptly to any vulnerabilities submitted. We keep the submitter updated as we investigate and respond to the issue.

Specialist security consultants are used to complete penetration tests.

Our approach to penetration testing is highly targeted and focused. Tests will generally be:

• White box: Testers are provided design documentation and briefings from product engineers to support their testing
• Threat-based: Testing focuses on a particular threat scenario, such as assuming a compromised instance exists, and testing lateral movement from that starting point

We do not make these reports or extracts available externally due to the extensive information made available to the testers in conducting these assessments.

We take innovative approaches to building quality software.

We step outside the traditional realm of Quality Assurance (QA) to ensure new features are introduced quickly and safely by adopting the notion of Quality Assurance. We focus on fostering a “whole team” mentality to quality by changing the role of QA to a facilitator rather than the person who does the actual QA work. We also are actively working to empower and educate developers to test their own features to our quality standards.

While we consistently strive to reduce the number of vulnerabilities in our products, we recognize that they are, to an extent, an inevitable part of the development process.