Skip to content

Security Mechanisms

Here below some more details are provided on the security mechanisms currently implemented on our cloud-based solution.

TLS 1.2/1.3 protocol

All communications to VeriSaaS API must be done using HTTPS with the protocol TLS 1.2 or TLS 1.3. Lower versions of the protocol are not allowed. Every communication inside VeriSaaS Cloud AWS VPC also uses TLS 1.2/1.3 providing an extra security layer to the HTTP traffic within the AWS VPC. TLS 1.3 is currently the latest security standard for secure HTTP communications.

Supported cipher suites:

  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS-AES-128-GCM-SHA256
  • TLS-AES-256-GCM-SHA384
  • TLS-CHACHA20-POLY1305-SHA256

SSL Certificates

When connecting to VeriSaaS Cloud, the HTTP traffic is encrypted by the server side using a valid certificate issued and maintained by AWS ACM. It is important that the customer should only trust a valid certificate (the CNAME of the certificate must be the correspondent to VerisaaS Cloud URL).

To learn more about AWS Certificates visit: https://aws.amazon.com/certificate-manager/

Note that certificate pinning is not a recommended practice, but in case you require it, please consider pining all of the AWS root CAs published at:

https://www.amazontrust.com/repository/

IP Source AllowList

As depicted in the architecture diagram in section 1, all requests to VeriSaaS Cloud must originate at a customer’s middleware. Veridas Customer Support requires at least one public IP address for the provisioning of a LIVE account, as this is a mandatory requirement for operating the service.

Once delivered the LIVE account for a Verisaas service, the Customer will be able to manage the AllowList associated to that service account by using Keymaker API service.

The AllowList can also be modified by reaching out to Veridas Service Desk (service SLA = 48-72h)

All requests coming from an unregistered source IP will be automatically discarded by VeriSaaS Cloud.

IP source AllowList is a mandatory requirement for all Veridas customers.

WAF

All incoming traffic to VeriSaaS Cloud gets first analized by a Web Access Filter. WAF is basically a firewall for web applications, filtering common attacks, such as SQL Injections or Path Traversal. In addition, WAF includes a DDoS protection (not only for layer 7 but also for 3 and 4 layers) to prevent attacks that could end up in a denial of service.

Veridas WAF also silently drops every incoming request that is not valid or having a malformed syntax or coming from a suspicious source network. By doing this, we protect our AWS VPC from undesired traffic that would only result in an increase of the resources load.

API Key authentication

In order to allow a Customer request to access a service, in addition to the fulfillment of the previous requirements, the incoming request must be authenticated by including an apikey header file with the correspondent Customer credential. A credential or API Key will be provided to the customer by Veridas Customer Support at the time of delivering the service. The customer’s middleware must add this header to all requests to Veridas API.

It is strongly recommended to rotate the apikey by the Customer prior to use it in a production environment. This can be achieved by using Keymaker API service.

Authentication is performed by the Veridas API Manager. Requests with the wrong API Key header will be rejected by the API manager.

Apikey example header: ‘apikey’: ‘wte5bk3273NP5xbbea8bG5Ca7795VyPWNz77’

APIKEYs are passwords randomly generated by VeriSaaS, with a minimum length of 32 characters, and containing uppercase and lowercase letters, and numbers.

Request Throttling & Rate Limiting

In order to avoid problems caused by an accidental increase of traffic which may lead later into high costs to Customers, all customers' cloud accounts are set up with a maximum requests per minute limit. This maximum value is set to an upper limit high enough not to affect any normal operation. However, if for instance a process in the Customer’s middleware gets hung, it is possible that VeriSaaS Cloud could end up receiving an unusually high amount of traffic. To avoid these undesired situations, we implemented a request throttling mechanism that will monitor the amount of workload being received by each cloud service, and will artificially delay the excessed queries instead of dropping them.

Under these circumstances, Veridas operational team will inform the Customer so that proper action is taken. Nevertheless, It is also recommended that Customers anticipate Veridas Service Desk on any unusual traffic that may be reaching Veridas Cloud. This way, we proactively can take whatever measure is required to ensure the best service is provided.

If a Customer is willing to perform a stress or performance test against VeriSaaS Cloud is important to communicate to Veridas Customer Support beforehand, otherwise the test might be treated as an DDoS attack and will be repealed.

Continuous monitoring

Several monitoring tools are used on the VeriSaaS Cloud services and infrastructure, in order to detect any problem that can affect the service provided. Zabbyx, Cloudwatch and the ELK Stack Beats are some of the technologies used for this purpose.

An alerting system is also deployed, so the support team can be notified when any problem arises so they can react as quickly as possible.

Validations Auto-Cleaner

Veridas goal is avoid storing any Customer data in VeriSaaS Cloud for security reasons mainly.

Services like das-Face (face biometry engine) or das-Peak (voice biometry engine) are completely stateless, so each query is independent of the rest, and no data is stored in the cloud after the processing.

Validas on the other hand is a stateful service, as a validation process may require a number of queries to Veridas cloud (ie: upload obverse, upload reverse, upload selfie, etc…). As a consequence, Validas requires an operation database to temporarily cache the validation data before it is processed, and finally downloaded and deleted by the customer. If for some reason any validation is forgotten in the cloud without being deleted by the customer, Veridas takes care of it (deletes it) by means of an Autocleaner process.

Validations Auto-Cleaner deletes all validations that are due the established expiration time. This expiration time can be set up/customized for each customer. This time is usually lower than 30/60mins.

Encryption Data

VeriSaaS Cloud uses AWS KMS capabilities to encrypt data both in transit and at rest, for example in a shared Network File System, or in a database.

File system contents are encrypted using the Advanced Encryption Standard algorithm with XTS Mode and a 256-bit key (XTS-AES-256).

AWS KMS stores the master keys in highly durable storage in an encrypted format to help ensure that they can be retrieved when needed.