Your data is everything.
This is how we keep it secure.

CTL-023 Data Encryption 

Disclaimer: We are committed to securing and protecting the privacy of your data stored in our services. Your data stored in our database can only be accessed by authorized personnel to ensure service reliability. Access is restricted tightly and monitored using both logical controls and management processes. 

‍

Data encryption is the process that transforms plain text data into encrypted data. Encrypted data is commonly referred to as ciphertext, while unencrypted data is called plaintext. Data, or plaintext, is encrypted with an encryption algorithm and an encryption key. The process results in ciphertext, which can only be viewed in its original form if decrypted with the correct key. This allows only authorized parties possessing valid decryption keys to read the data.
‍

Data created, exchanged, and stored in an organization is one of its most valuable assets. Securing that data from compromise and unauthorized access is one of our very top of your priorities.
‍

Our databases use encryption in transit from application client to server and within intra-cluster communications by using a set of certificates for the servers. We use Let's Encrypt known certificates to authenticate TLS enabled clients once they pass access and authentication controls.
‍

Authentication and authorization are not enough to fully secure your data, which must be encrypted over the wire or on disk. Our databases encryption offers the following features:
‍

• Network isolation and access - Users' data and underlying systems are isolated from other users. User's data are associated with a user group, often called as "company", and only members of that group can access group-related data.
• Encryption in flight and at rest - In a nutshell, encryption at rest is a protection layer to guarantee that the written files or storage is only visible once decrypted by an authorized process/application. Our databases have built-in encryption at rest for disks by default with every node in your cluster.
• Granular database auditing - Granular database auditing allows administrators to answer detailed questions about systems activity by tracking all commands against the database.

‍

Note: Technical and organizational measures protect these servers against unauthorized persons' loss, destruction, access, change, or distribution of your data. A few authorized persons can only access your stored data. These persons are responsible for providing technical, editorial, and commercial support for the servers. However, despite regular checks, it is impossible to provide complete protection against all dangers.

‍

CTL-006 User Access Management (IAM) (Digital external certificate configuration) 

Disclaimer: All connections between our apps use TLS v1.3 protocol

TLS stands for Transport Layer Security and is the successor to SSL (Secure Sockets Layer). Transport Layer Security (TLS) provides secure communication between servers and web browsers. The connection itself is secure because cryptography is used to encrypt the data transmitted.
‍

As a cryptographic protocol, TLS encrypts data and authenticates connections when moving data over the internet via HTTP—an extension of the protocol known as HTTPS (Hyper Text Transfer Protocol Secure). When a user visits a website, their browser checks for a TLS certificate on the site. 
‍

If one is present, their browser performs a TLS handshake to check its validity and authenticate the server. Once a link has been established between the two servers, TLS encryption and SSL decryption enable secure data transport.
‍

Private keys are generated uniquely for each connection and based on a shared negotiated secret at the beginning of the session, also known as a TLS handshake.
‍

HTTPS performance has been made faster and safer for every user and device. TLS 1.3 protocol provides unparalleled privacy and performance by reducing latency and hardening the security of your encrypted connections compared to previous versions of TLS and non-secure HTTP. 
‍

TLS 1.3 offers several improvements over earlier versions, most notably a faster TLS handshake and simpler, more secure cipher suites and Zero Round-Trip Time (0-RTT) key exchanges further streamline the TLS handshake. Together, these changes provide better performance and stronger security.

Benefits of TLS v1.3:

• A faster TLS handshake - TLS encryption and SSL decryption require CPU time and latency to network communications, which is a somewhat degrading performance. With TLS 1.2, the initial handshake was carried out in clear text, meaning that even it needed to be encrypted and decrypted. A default handshake involves 5 – 7 packets exchanged between the client and server, which added a considerable overhead to the connection. With TLS 1.3, server certificate encryption is adopted by default. That makes it possible for a TLS handshake to be performed with 0 – 3 packets, reducing or even eliminating this overhead and allowing faster, more responsive connections.

‍

• Simpler and stronger cipher suites - In addition to reducing the number of packets exchanged during the TLS handshake, TLS 1.3 has also shrunk the cipher suites' size for encryption. In TLS 1.2, and previous versions, the use of ciphers with cryptographic weaknesses had posed potential security vulnerabilities. TLS 1.3 includes support only for algorithms with no known vulnerabilities, including any that do not support Perfect Forward Secrecy (PFS). The update has also removed the ability to perform "renegotiation," in which a server and client that already have a TLS connection can negotiate new parameters and generate new keys, a function that can increase risk.

‍

• ‍Zero Round-Trip Time (0-RTT) - As with SSL, TLS relies on key exchanges to establish a secure session. In earlier versions, keys could be exchanged during the handshake using one of two mechanisms: a Diffie-Hellman key or a static RSA key. In TLS 1.3, RSA has been removed, along with all static (non-PFS) key exchanges, while retaining ephemeral Diffie-Hellman keys. In addition to eliminating the security risk posed by a static key, which can compromise security if accessed, relying exclusively on the Diffie-Hellman family allows the client to send the requisite randoms and inputs needed for key generation during its "hello." Eliminating an entire round-trip on the handshake saves time and improves overall site performance. Additionally, when accessing a site that has been visited previously, a client can send data on the first message to the server by leveraging pre-shared keys (PSK) from the prior session—thus "zero round-trip time" (0-RTT). 

‍

CTL-006 User Access Management (IAM) (API authentication and protection)

Disclaimer:  All externally exposed API queries require successful authentication. Only a logged-in and authenticated user can make requests to our available APIs.

To authenticate a user, a client application must send a JSON Web Token (JWT) in the authorization header of the HTTP request to your backend API. 

API Gateway validates the token on behalf of your API, so you don't have to add any code in your API to process the authentication.

A JSON Web Token will be returned when the user logs in using their credentials. 

JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties.

We are using JSON Web Tokens for the following scenarios:

‍

• Authorization: This is the most common scenario for using JSON Web Tokens (JWT). Once the user is logged in, each request will include the JWT, allowing the user to access routes, services, and resources that couldn't access without that token.
• Information Exchange: JSON Web Tokens (JWT) are a good way of securely transmitting information between parties. Because JSON Web Tokens (JWT) can be signed—for example, using public/private key pairs—you can ensure the senders are who they say they are. In addition, as the signature is calculated using the header and the payload, you can verify that the content hasn't been tampered with.

‍

‍

CTL-009 Privileged Access Management (PAM) 

The term "privileged access management" is used in an enterprise environment to designate special access or abilities above and beyond a standard user. Privileged access allows organizations to secure their infrastructure and applications, run the business efficiently and maintain the confidentiality of sensitive data and critical infrastructure.

Privileged access can be associated with human and non-human users, such as applications and machine identities.

‍

While privilege management encompasses many strategies, a central goal is the enforcement of least privilege, defined as the restriction of access rights and permissions for users, accounts, applications, systems, devices (such as IoT) and computing processes to the absolute minimum necessary to perform routine, authorized activities.

‍

The domain of privilege management is generally accepted as falling within the broader scope of identity and access management (IAM). Together, PAM and IAM help provide fined-grained control, visibility, and auditability over all credentials and privileges.

‍

While IAM controls provide authentication of identities to ensure that the right user has the right access at the right time, PAM layers on more granular visibility, control, and auditing over-privileged identities and activities.

‍

By dialing in the appropriate level of privileged access controls, PAM helps organizations condense their organization's attack surface and prevent, or at least mitigate, the damage arising from external attacks as well as from insider misconduct or negligence.

‍

All available roles:

• Admin - An account used by IT system administrators and limited personnel that can be used to make configurations to a system or application and have access to all application-wide data, including users, teams, products, audiences.
• Team Owner - An owner is a limited user that can only manage data on their own space. Has the ability to invite team members and remove them and delete his account with all team data or transfer team ownership to other team members.
• Team Manager - Team member with more privileges, invited by the team owner. Has access to team data (tests, payment data, billing history). Can create new tests, add/edit payment methods, can remove his account but cannot remove the team or another team member.

‍

CTL-008 Multi-Factor Authentication

One of the biggest shortcomings of a traditional user ID and password logins is that passwords can be easily compromised, potentially costing organizations millions of dollars. Brute-force attacks are also a real threat, as bad actors can use automated password cracking tools to guess various combinations of usernames and passwords until they find the right sequence.
‍

An authentication factor is a special category of security credential used to verify the identity and authorization of a user attempting to gain access, send communications, or request data from a secured network, system, or application.

‍

Disclaimer: We are currently supporting 2FA (two-factor authentication) via Google.

‍

Clear incident response to patching and security issues

The SaaS provider has a clearly defined policy for patching internal systems and dealing with security issues.

Below is a summary of the process, and in the following sections, we’ll go into more depth about each step:

1. Preparation—review and codify an organizational security policy, perform a risk assessment, identify sensitive assets, define critical security incidents the team should focus on, and build a Computer Security Incident Response Team (CSIRT).
2. Identification—monitor IT systems, detect deviations from normal operations and see if they represent actual security incidents. When an incident is discovered, collect additional evidence, establish its type and severity, and document everything.
3. Containment—perform short-term containment, for example, by isolating the network segment that is under attack. Then focus on long-term containment, which involves temporary fixes to allow systems to be used in production while rebuilding clean systems.
4. Eradication—remove malware from all affected systems, identify the root cause of the attack, and take action to prevent similar attacks in the future.
5. Recovery—carefully bring affected production systems back online to prevent additional attacks. Test, verify, and monitor affected systems to ensure they are back to normal activity.
6. Lessons learned—no later than two weeks from the end of the incident, perform a retrospective of the incident. Prepare complete documentation of the incident, investigate the incident further, understand what was done to contain it and whether anything in the incident response process could be improved.

‍

Details on a product's security features

The system is being developed and checked in accordance with the following security features:

1. Basic Application Security

1.1 Input and Data Validation

• HTML Input validation 
• Queries input validation 
• Server-side validation in addition to client-side validation 
• Misuse of file names, URLs, or user names for security decisions
• Validation data read from file inputs and network resources
• Validation of cookies, query string parameters, HTTP headers, network resources 

1.2 Authentication

• Strong passwords policy
• Encrypted configuration files 
• Preventing clear text credentials transfer over the network
• Limited session time

1.3 Authorization

• Lockdown application areas in accordance with privileges
• Limit database access to specified objects
• Reasonable separation of privileges

1.4 Configuration Management

• Use least privileged service accounts 
• Credentials not stored in clear text
• Strong authentication and authorization rules

 1.5 Sensitive Data

• Sensitive data encryption and integrity
• Securing a transmission channel

1.6 Session Management

• Separation of anonymous and authenticated users areas
• Limiting session timeouts 

1.7 Exception Management

• Structured exception handling
• Sensitive or application information is not revealed 
• Private and sensitive data is not part of logging information 

1.8 Auditing and Logging

• Malicious behavior detection
• Error logging
  
  

2. Specific Application Features Security 

2.1 Tenant Data Isolation

2.2 Tenant Data Privacy

• Tenants data security access 
• Tenants media content security access 

‍

3. Operating System and Network Security     

3.1 Firewall Protection

3.2 Anti-virus Protection

3.3 Operating System updates & Hot Fixes

3.4 Frequent updates to the system platform to protect from known vulnerabilities

‍