This is the third part of the security overview. Start with Security: Data protection and personal information.

Continuity planning

Kundo has a process in place for when a service disruption occurs, and how to debug and get the service up and running as quickly as possible. Please read the following guide for more details: Continuity plan (Beredskapsplan)

Regarding the war between Russia, Belarus and Ukraine
We have received several questions from our customers if we, or any of our sub-processors, use sub-contractors or sub-processors, that are located within Russia, Belarus or Ukraine. After a thorough review (done at 2022-03-18) we can validate that that is not the case.

Compliance

Kundo always answers questions about compliance through our normal support channels. This does not incur any cost for the customer.

A customer can ask for logs pertaining to their own use in the system given that the customer covers the eventual cost and that Kundo agrees.

Customers have the right to let a third party perform an external security review of Kundo's systems. Before this is done the customer should notify Kundo about the extent of the review. The customer owns the result of the security review, but Kundo reserves the right to read the findings in order to improve the security for all our customers.

Several such reviews have been performed by customers, and all weaknesses have been promptly patched.

Encryption

In transit

Kundo is responsible for protecting our customers' data from unauthorized access. Every time data in transfered it is protected by secure and encrypted protocols.

In the cases where Kundo exposes some part of the information on the internet, we use TLS to encrypt data during transfer. Automated tools are used to verify that encryption adheres to industry standard.

Private keys for our certificates are stored with an extra layer of encryption. Any private keys that are suspected of being tampered with are immediately discarded and new keys are generated.

At rest

All data in our databases is encrypted at rest, protecting both against data leakage as well as securing compliance with EDPB recommendations. Kundo enables AWS KMS for encryption using an AES-256 block cipher implemented in hardware security modules validated under FIPS 140-2. 

Access to encryption keys is limited to Kundo technical staff and all usage is monitored with audit logs in AWS Cloudtrail. For more details on AWS KMS, please view the AWS KMS FAQ.

Password requirements

Passwords are never stored in plaintext in Kundo's systems. Instead they are stored hashed with a strong hashing algorithm. This means that Kundo employees have no way of seeing or accessing the plain text version of the passwords stored.

Passwords are never sent directly to an editor. Instead a time-limited single-use activation key is generated, and is sent to the editor via e-mail. The editor then uses the activation key to set their own password in the system.

Password resets are handled by generating a new activation key that the editor uses to set a new password.

Account information are not disclosed on the login page (or within error messages on the login page). The only information shared is that the supplied combination of username and password is incorrect. This prevents information disclosure attacks where an attacker uses the login page to enumerate valid users in the system.

No standard passwords are used, all editors create unique passwords. All system accounts (including all Kundo employees) have long randomly generated passwords. System accounts are always tied to a specific application.

The following rules are enforced when creating a new editor:

• Passwords can not be to similar to the user's email or name
• Passwords must be at least 12 characters long
• Passwords can not be a among the top 1000 passwords used globally
• Passwords can not contain only numbers

Passwords are never stored on the client. Passwords are never stored in logs. Passwords are never stored in session variables or cookies.

Application development security

Here's a list of specific application development practices that we follow:

• No customer data is stored on developer machines, local development is conducted with dummy data.
• Debug functionality is always disabled in the production environment.
• The application is protected no matter what entry point an attacker uses, not only the start page.
• Usage of Kundo does not require administrator privileges on the user's computer. A normally configured web browser is sufficient.
• User input is always validated on the server side, never just on the client side.
• Validation is always done with whitelists, not with blacklists.
• User input is validated with respect to format, length, and general sanity.
• User input does never consist of filesystem paths, directories or session information to avoid security issues stemming from that.
• Sensitive data is always sent as HTTP POST data to avoid it being logged in browser history and server log files.
• All access control are done serverside, not clientside.
• While uploading files, only a whitelist of file formats are allowed. The max size of files are controlled for. The number of files are controlled for by regularly removing invalid ones.
• All database access is done through an ORM that protects against SQL injections.
• All template variables are by default escaped to avoid XSS attacks.
• Special consideration is taken to make sure a user can't break out of the application and get access through the underlying system.

Glossary

• Kundo: The company that stands behind this document and provides the services.
• Employee:  Person employed at Kundo.
• Customer: The company that has bought the service from Kundo and has signed the contract.
• User: A user that sends support questions to the customer through Kundo's systems.