Please use the recommended channels to report security issues, either phone or e-mail. Avoid reporting security issues via public channels.

Intro

Security of our customers' data is a main priority at Kundo. This document describes our security processes and how we work with security in general.

This document is updated whenever new security policies are added to our processes.

Note that individual customers might have additional safeguards in place as part of their agreement with Kundo. Text in a separate signed agreement supersedes this document.

For any security related question, contact security@kundo.se.

Data Protection and personal information

Data storage

All customer data is stored on Amazon's services, strictly within the EU/EEA. All access to Amazon is strictly made through encrypted connections.

The customer have ownership of all data that they have stored as part of the service. If the customer terminates its subscription with Kundo, the customer may request a full data dump in a standardized format from Kundo.

Upon termination of the contract all data on Kundos services that belongs to the customer will be deleted within 30 days. Within another 30 days all data is also removed from all backup systems. Note that the customer is responsible for managing data on external services (i.e. social media) where Kundo is not the main processor of data.

External data processors

As part of Kundo service, several data processors are used by Kundo. Before a new service is added its security implications for Kundo is carefully vetted, for instance regarding proper use of encrypted communication and data storage policies.

See the full list of external data processors that use customer data.

Personal information

Kundo stores personal information and is therefore subject to subject to GDPR and Swedish law (2018:218). Kundo is in compliance will all requirements following that storage.

General Security

Risk classification

All customers should do their own risk classification of the data they store in Kundo's systems.

This list of statements about the data we store can be used to assess the risk level:

• Kundo stores customer information about the users. The information includes the name, e-mail address, and IP-number of each interaction.
• Kundo also stores the name, e-mail address, and (a securely hashed) password for each logged in editor in the system.
• Kundo stores the contents of each user's questions, which can include sensitive information, that will then be stored in unstructured form with us. Editors are responsible to prune information that users accidentally post to Kundo.
• Kundo stores information about how its services have been accessed in the form of log files. These log files exist for 30 days and are then deleted.
• Some of our customers store extra data for each user such as membership numbers or social security numbers. If that is the case, that information should be included in the risk assessment.

Employees

All Kundo employees share responsibility for customer support. To make the customer support flow efficient, Kundo employees with a direct need has access to customer data. All access to customer data is made through a web interface with user access controls in place, so that access for a user can be withdrawn at any time. Access is always withdrawn on end of employment, as part of our offboarding process.

Customer data is never stored on employee computers. For instance, all developers use dummy data during development instead of customer data.

All employees are given a walkthrough of our security policy upon employment, and are required to follow the procedures outlined there strictly. The security policy includes a password policy that states: 

• All employees should use a password manager 
• All employees should use 2-step verification for our own systems and everywhere else were possible

All employees are part of keeping our customers' data safe at all times and are educated to do so. The Security practices is developed and maintained by the Security team within the Development function.

Logging

Logging is done within Kundo's systems mainly for debugging purposes. Logs are only available to Kundo employees.

Examples of data that is logged in our systems:

• All web traffic to each public context hosted by Kundo, including IP and web browser
• All login attempts made at the SSH level against our servers
• All errors that occur thanks to usage of the service
• All e-mails sent by the service
• All backups saved, including the specific point in time they were made

A customer can ask for logs pertaining to their own use in the system given that the customer covers that cost and that Kundo agrees. Full logs can not be handed over since they may contain data the originates from other customers of Kundo's system.

All logs are automatically deleted after 30 days due to privacy agreements with our customers.

Logs are stored on a separate server from where log events originate. Since access control to the log server is handled separately from other servers, an intruder is prevented from tampering with logs.

Computer clocks are regularly synchronized to make sure all timestamps are as exact as possible.

Physical security

Kundo owns no physical servers and instead rents them from Amazon. Amazon is responsible for the physical security of the servers and has comprehensive security documentation.

Gaining access to the Kundo office where we work day-to-day does not automatically give anyone access to any of our services.

Operational security

Kundo has monitoring setup for all critical infrastructure. The goal of the monitoring is specifically focused on security but also performance and to find unusual traffic patterns.

All data transfer happens digitally, so no physical transfer of data is ever conducted.

All traffic flows and to, from and between our services are encrypted, including all employee access to sensitive data.

All encryption, access, and otherwise secret keys are stored in encrypted form and are only available on the specific environment where they are used.

We continuously monitor industry standards and make updates to our setup accordingly.

Access security

There are three different kinds of users of Kundo's systems:

• Visitors can ask questions and comment on other's questions. If the customer only uses Kundo products without an interface for visitors (Kundo Mail), this role does not apply.
• Editors can edit and deleted questions and comments in the specific context they have given access rights in. When given the correct permissions they may also view statistics, edit channel settings and adjust account settings.
• Administrators are employees at Kundo and have access to all data in all contexts.

Access rights for different kinds of users:

• Editors must login with an e-mail address and password to access the service.
• Administrators must also log in, but need to have first been given administrator access by another administrator.
• To gain administrator access to the servers an administrator needs to identify with Two Factor Authentication.
• It is possible to limit the access of visitors and/or editors based on a custom integration scheme. If you are interested in this, contact us for more detailed information. The most straightforward custom integration is to only allow access for users that originate from a specific IP-range.

Day to day administration of who has editor access is controlled by the customer. If assistance is needed from an administrator the customer can ask for help through the normal support channels.

If an intrusion attempt that affects customer data is detected the customer is promptly contacted.

Development processes

Security solutions are based on industry best practices for protocols, authentication and encryption. We don't build our own security solutions and instead trust the proven work of others.

Software development is conducted in a way that ensures high quality, with testing built into the process throughout the process. All code is checked by at least two developers before being set into production.

Environments used for testing are clearly separated from production systems.

Security incidents

Security incidents are handled according to Kundo's incident management process. 

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.