Security Policy

Your security is very important to us! Here is a summary of what we do every day to guarantee that your data is safe with Zeldesk and that we apply best security practices on our hosted version, the Zeldesk Cloud.

Zeldesk Cloud

Backups / Disaster Recovery

• We keep 14 full backups of each Zeldesk database for up to 3 months: 1/day for 7 days, 1/week for 4 weeks, 1/month for 3 months and backups are replicated in 3 different data centers.

• You can also download manual backups of your live data at any time using the control panel.

• You can contact our Helpdesk to restore any of those backups on your live database (or on the side) .

• Hardware failover: We have implement local hot standby replication with monitoring and a manual failover procedure that takes less than 60 minutes.

• Disaster recovery: In case of complete disaster with a data center entirely down for an extended period, preventing the failover to our local hot standby, we have the following objectives:

(a)RPO (Recovery Point Objective) = 24h.
This means you can lose maximum 24 hour of work if the data cannot be recovered and we need to restore your latest daily backup.

(b)RTO (Recovery Time Objective) = 24h for paid subscriptions, 48h for free trials, education offer, freemium users, etc.

(c)How is this accomplished: we actively monitor our daily backups, and they are replicated in multiples locations on different continents. We have automated provisions to deploy our services in a new hosting location. Restoring the data base on previous day backups can then be performed in few hours (for the largest clusters), with priority on the paid subscriptions. We routinely use both the daily backups and provisioning scripts for daily operations, therefore both parts of the disaster recovery procedure are tested all the time.

Database Security

• Customer data is stored in a dedicated database and therefore no sharing of data between clients

• Data access control rules implement complete isolation between customer databases running on the same cluster and hence no access is possible from one database to another

Password Security

• Customer passwords are protected with industry standard PBKDF2+SHA512 encryption

• Zeldesk staff does not have access to your password, and cannot retrieve it for you, the only option if you lose it is to reset it

• Login credentials are always transmitted securely over HTTPS

• As of Zeldesk, customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.

• Password policies: as of Zeldesk database administrators have a built-in setting for enforcing a minimum user password length.

Staff Access

• Zeldesk helpdesk staff may sign into your account to access settings related to your support issue. For this they use their own special staff credentials, not your password (which they have no way to know)

• This special staff access improves efficiency and security and they can immediately reproduce the problem.

• Our Helpdesk staff strives to respect your privacy as much as possible, and only access files and settings needed to diagnose and resolve your issue

System Security

• All Zeldesk Cloud servers are running hardened Linux/windows distributions with up-to-date security patches

• Installations are ad-hoc and minimal to limit the number of services that could contain vulnerabilities (no PHP/MySQL stack for example)

• Only a few trusted Zeldesk engineers have clearance to remotely manage the servers - and access is only possible using SSH key pairs (password authentication disallowed)

Physical Security

Zeldesk Cloud servers are hosted in trusted data centers in various regions of the world, and they must all exceed our physical security criterions:

• Restricted parameter will be physically accessed by authorized data center employees only

• Physical access control with security badges or biometrical security

• Security cameras will be monitoring the data center locations 24/7

• Security personnel on site 24/7

Credit Card Safety

• We never store credit card information. Your credit card information is transmitted securely directly between you and our PCI-Compliant payment acquirers

Communications

• All web connections to client instances are protected with state of the art 256 bit SSL encryption

• Our servers are kept under a strict security watch, and always patched against the latest SSL vulnerabilities.

• All our SSL certificates use robust 2048-bit modules with full SHA-2 certificate chains

Network defense

• All data center providers used by Zeldesk Cloud have very large network capacities, and have designed their infrastructure to withstand the largest Distributed Denial of Service (DDoS) attacks. Their automatic and manual mitigation systems can detect and divert attack traffic at the edge of their multi-continental networks, before it gets the chance to disrupt service availability.

• Firewalls and intrusion prevention systems on Zeldesk Cloud servers help detect and block threats such as brute-force password attacks.

• As of Zeldesk, customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.

Software Security

Secure by design

Zeldesk is designed in a way that prevents introducing most common security vulnerabilities:

• SQL injections are prevented by the usage of higher level API that does not require manual SQL queries

• XSS attacks are prevented by the use of a high level system that automatically escapes injected data

• The framework prevents RPC access to private methods which makes it harder to introduce exploitable vulnerabilities

Independent Security Audits

Zeldesk is regularly audited by independent companies that are hired by our customers and prospects to perform audits and penetration tests. The Zeldesk Security Team receives the results and takes appropriate corrective measures whenever it is necessary.

We can't however disclose any of those results, because they are confidential and belong to the commissioners.

Top Vulnerabilities

Here is where Zeldesk stands on the top security issue for web applications:

• Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter to execute unintended commands.

Zeldesk relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.

• Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites etc.

The Zeldesk framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.

• Cross Site Request Forgery (CSRF): A CSRF attack forces victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests.

The Zeldesk website engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller to receive a POST request without the corresponding security token. This is the recommended technique for CSRF prevention. This security token is only known and present when the user genuinely accessed the relevant website form, and an attacker cannot forge a request without it.

• Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data resulting in devastating attacks such as total server disaster.

Zeldesk does not expose functions to perform remote file inclusion. However it allows privileged users to customize features by adding custom expressions that will be evaluated by the system. These expressions are always evaluated by a sandboxed and sanitized environment that only allows access to permitted functions.

• Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object such as a file, directory, database record, key and URL. Attackers can manipulate those references to access other objects without authorization.

Zeldesk access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulation those references, because every request still has to go through the data access validation layer.

• Insecure Cryptographic Storage: Web applications rarely use cryptographic functions to protect data and credentials. Attackers use weakly protected data to conduct theft and other crimes such as credit card fraud.

Zeldesk uses industry-standard secure hashing for user passwords (by default PKFDB2 + SHA-512, with key stretching) to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP, in order to avoid storing user passwords locally at all.

• Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

Zeldesk Cloud runs on HTTPS by default.

• Failure to Restrict URL Access: An application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly

Zeldesk access control is not implemented at the user interface level, and the security does not rely on hiding special URLs. Attackers cannot circumvent the access control layer by reusing or manipulating any URL, because every request still has to go through the data access validation layer. In rare cases where a URL provides unauthenticated access to sensitive data, such as special URLs customer use to confirm an order, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient

Go
Cloud