Security, Privacy, and Access FAQ

Follow

We take security very seriously here at Countly. Privacy by Design is not just a buzz word, but an intrinsic principle. Our main focus is privacy of your data. We have worked with many companies to date and we have extensive knowledge in this domain, especially when it comes to General Data Protection Regulation (GDPR), HIPAA and COPPA, collaborating with several parties and conforming to their standards and regulatory laws. This has enabled us to make Countly the platform of choice when it comes to data privacy and security. Below are some of the unique features of Countly that are aimed at securing sensitive information.

  • Self-hosting options: Countly can be installed on-premise (i.e. either in your own data center or with a trusted hosting partner), allowing for greater depth and breadth of security and control. Self-hosting means that no third party (not even Countly) ever has access to your data unless you permit it.
  • Secure transmission: Data collected from devices are sent over a secure channel, and cannot be tampered with — this eliminates intruders and potential man-in-the-middle attacks.
  • 'Right to be forgotten' rule: If an EU citizen asks for his data to be removed, it can be done in Countly such that his data is completely wiped out. Countly also has a 'Filtering Rules' plugin, which blocks data from reaching Countly database using several criteria like username, email, IP address, deviceID etc.
  • Do not track: GDPR also stipulates that individuals have a right to ‘block’ or suppress processing of personal data. If an individual decides not to be tracked, Countly has a function to support this; if it is invoked, then we do not track that user at all.
  • Data-at-rest encryption: When data is stored, we can use data-at-rest encryption, further enhancing the security of personal data, making it impossible for a rogue employee to reach this data.
  • Extensive system audit logs: There are more than 30 different system logs collected, and this helps system administrators know what is happening inside the server. In case of an emergency or an audit, logs can be viewed, allowing organizational insight into what has happened and the cause of any issue.
  • Login security: We have several methods to keep logins secure — Countly can require strong passwords, only permit logins via HTTPS, and ban users when there is a brute force attack.
  • Access levels: Countly dashboard users can only view what has been enabled for them. Administrators have the ability to disable a menu item or a view (e.g. User Profiles) for specific users. This way, only necessary and required data is shown.
  • No IP address storage: Countly doesn’t store any IP address, but rather converts IP to user’s city and then discards the IP. For customers where this is an issue, Countly has the ability to completely remove city and country information.
  • Data portability: Our database schema is completely open, allowing any Countly client to transfer data from Countly to another service easily.

We know and understand how important the responsibility of safeguarding user and personal data is to our customers. There are several measures we have undertaken for Countly to support this requirement, and below, you'll find a list of all questions you may have regarding security, privacy, and access features in order to make your instance more secure.

How do I enable password expiration?

You may enable password expiration under Management → Configuration → Security → Password expiration. You can set it to 0 (no password expiration), or to a number like 20, where password expires after 20 days and must be changed.

Is it possible to block logins after failed login attempts?

Yes, this is configurable under Management → Configuration → Security → Allowed Login attempts. The default value is 3 attempts, after which account will be locked for a specific amount of time configurable under Management → Configurations → Security → Incorrect Login block time increment. On consecutive failed logins account will be blocked with increased time; if configured value is 5 minutes, then after 5 minutes expire, if a user fails to login 3 more times, it will be locked for 10 minutes, then 15 minutes, and so on.

How do I enable password rotation?

Countly can be configured so that a user may not be able to use one of his previous passwords. In order to enable this, go to Management → Configurations → Security → Password rotation and define number of previous passwords a user should not be able to reuse.

How to add authentication to MongoDB?

See this documentation for adding a username and password to MongoDB.

How do I configure Countly to accept HTTPS connections?

This documentation can be used to configure Countly to accept HTTPS connections.

How do I use Let's Encrypt certifications for HTTPS?

In order to use Let's Encrypt certificates, please follow this guideline.

How can I enable pinning public key of SSL certificate for extra security?

Pinning can be used to provide extra security for Android and iOS. Use this documentation for Android certificate pinning and this one for iOS certificate pinning.

How do I use parameter tampering protection?

Countly can be configured to use a salt (from Management → Applications and inside the SDK) to add checksum to SDK requests in order to prevent parameter tampering. For more information about parameter tampering, see this documentation.

For iOS, configuration can be done using guidelines here, and for Android, see this link (under Parameter Tampering).

How do I allow an IP access to dashboard and disallow others?

This can be done by modifying nginx configuration file (/etc/nginx/conf.d/sites-enabled/default.conf or /etc/nginx/conf.d/default.conf depending on your operating system). Below you can see which parts to add for a server without HTTPS connectivity:

Note that for servers where HTTPS is configured, there are two server { blocks instead of one, hence this configuration should be applied on both blocks.

Since allow parameter accepts IP masking, you may use allow 192.168.1.0/24 to let all IPs inside 192.168.1.0 IP block to access dashboard and disallow other IPs.

What does Countly collect from SDKs?

Countly has different properties available, and collected from end users via SDK:

  • Default metrics, or properties: This is explained in the following section.
  • Custom user properties: This is much like default metrics, but they are custom metrics and they can hold not only key:value pairs but also array like more complex objects more modifier examples. Custom user properties are also saved into app_usersAPPID collection (for the Enterprise Edition); also all drill documents have a field as "custom" which contains values of custom user properties at the time of session, event, crash or view occurrence.
  • Event level metrics (called segmentations): Event segments work in a one-time logic, which means that there is no history or automatic association that exists in default metrics and custom user properties.

What are the access credentials to Countly users?

There are three levels of access in Countly, and the rule of thumb is:

  • "User" can only read and not write/modify;
  • "Admin" can read and write/modify, but only in context of app that is given to them; and
  • "Global Admin" can read and write/modify all apps and server wide things.

More information in how to determine the access levels is provided here.

Does Countly JavaScript automatically track changes that are made to a website page, such as adding a widget?

No, Countly will need to be told to track the widget, or anything else, that was added to the website.

Does Countly send audit reports for GDPR purposes like SOC 1?

Countly as a company is, ISO27001 and SOC2 certified. Countly lets the users be GDPR, HIPAA, and COPPA compliant.

Looking for help?