Security Assurance Plan
Security Assurance Plan (SAP)
1. Purpose of the document
This document aims to specify the security commitments made by Dashdoc as part of its services relating to the Platform.
2. Issues and Objectives
Dashdoc takes all appropriate security measures, including technical, physical and organisational safeguards, to ensure the confidentiality, preservation and integrity of the data processed.
A Security Assurance Plan is implemented to address the main risks identified:
→ Risk of unavailability of information and the systems processing it
→ Risk of accidental or deliberate disclosure, or loss of confidentiality, of information provided by our customers
→ Risk of alteration, or loss of integrity, which could lead to a loss of information for our customers.
The objectives of implementing the Security Assurance Plan (hereinafter “SAP”) are:
→ To improve and formalise the management of the security of the platform provided by Dashdoc
→ To ensure that Dashdoc complies with its legal obligations concerning the management of personal data (GDPR)
→ To raise awareness of our security policy among Dashdoc employees
3. Organisation of information security
3.1 RESPONSIBILITY AND ROLES
The organisation of information security is the responsibility of Mr Corentin Smith, Dashdoc's CTO.
3.2 SAP UPDATE PROCEDURE
As part of the implementation of the Security Assurance Plan, an annual review procedure is established.
4. Human resources security
4.1 MANAGEMENT OF JOINERS / LEAVERS
Employees joining Dashdoc must follow an internal process called the Onboarding process. During this process, they are made aware of security and data integrity issues.
An internal process for managing an employee's departure ensures that their accounts providing access to the various resources to which they were entitled are closed.
4.2 INFORMATION SYSTEMS SECURITY AWARENESS AND TRAINING
All employees and staff members with access to the organisation's IT systems must comply with the internal password security policy.
5. Logical security
5.1 ACCESS TO RESOURCES / ENCRYPTION
By default, access to the application is always forced to use HTTPS.
Access to the application is protected by a password that can be set by the user or the administrator. Once this password has been set, it is impossible for a third party to discover it by submitting a query to our database, because all passwords are irreversibly encrypted using BCRYPT with 10 rounds.
If an attack is detected, all affected customers are notified within 24 hours.
5.2 APIS
Dashdoc provides you with a set of APIs enabling, in particular, synchronisation of your users with your directory, management of groups for these users, and export of learning statistics relating to learning paths.
A full description of our API is available on our developer portal: https://developer.dashdoc.eu/
Authentication to the APIs uses a unique key called an API key.
5.3 PASSWORD MANAGEMENT POLICY ON THE PLATFORM
The following rules apply to passwords:
The password must not be too similar to your other personal information.
The password must contain at least 6 characters.
The password must not be a commonly used password.
The password must not be entirely numeric.
You can also use your own password management policy by using our SSO login option.
5.5 PERMISSION MANAGEMENT (CUSTOMER)
The platform distinguishes between several roles and permission levels, providing additional logical security. The customer is responsible for assigning the various roles to users. The list of roles and permissions can be viewed at any time on the platform.
ADMINISTRATOR: has access to all features, including payment and settings.
USER: can create and edit documents and invite drivers, but does not have access to settings.
READ ONLY: has access to transports and the directory but cannot edit or create transports.
5.6 MANAGEMENT OF INACTIVE SESSIONS
Once authenticated, a user's session in their web browser remains valid for 7 days.
5.7 TRACEABILITY OF LOGICAL ACCESS
Every connection to the platform is recorded in our logging system and can be viewed by our teams. These logs are retained for at least 90 days.
5.8 ACCESS RIGHTS MANAGEMENT (Dashdoc)
We ensure that your data is not viewed by anyone without legitimate access to it.
However, the operation of our services requires certain employees to have access to the systems that store and process customer data. For example, to diagnose a problem you encounter, we may need to access your data.
All our employees are required to comply with our security rules, and our company treats these issues with the utmost care: only members of the support and operations team are authorised to access customer data, and all access is logged and auditable. Members of the technical and product team may use customer data to resolve user problems or improve features.
5.9 INTERNAL PASSWORD SECURITY POLICY
1. Summary
All employees and staff members with access to the organisation's IT systems must comply with the policy set out below to ensure network security, protect data integrity and protect IT systems.
2. Purpose
The purpose of this policy is to protect the organisation's resources on the network by requiring secure passwords and their protection, and by setting a short interval between password changes.
3. Scope
This policy applies to any staff member with any form of IT account on the organisation's network requiring a password, including but not limited to a domain account and an email account.
4. Password protection
→ Never write down a password
→ Never send a password by email
→ Never include a password in a document stored without encryption
→ Never share your password with anyone
→ Never disclose your password over the telephone
→ Never provide hints about the format of your password
→ Never disclose your password or provide hints about it on an Internet forum
→ Never use your company or network password on an Internet account that does not have a secure connection, whose address in the web browser starts with https:// rather than http://
→ If you have any reason to believe that your password has been compromised, report it to your IT security unit
→ If someone asks you for your password, refer that person to your IT security unit
→ Make sure that nobody is watching you when you type your password
5. ENFORCEMENT
Since password security is essential to the security of the organisation and everyone within it, employees who do not comply with this policy are subject to disciplinary action, up to and including dismissal.
6. OTHER CONSIDERATIONS
Password-protected screensavers must be enabled and must protect computers after 5 minutes of user inactivity. Computers must not be left unattended if the user has an open session and no password-protected screensaver is enabled. Users must get into the habit of not leaving their computers unlocked.
Administrator passwords must be afforded a particularly high level of protection. Administrator accounts must have the minimum access necessary to perform their functions. Administrator accounts must not be shared.
7. USE OF A PASSWORD MANAGER
Using a password manager, Dashlane in our case, makes the points mentioned above easier to implement.
What does it provide?
→ There is only one master password to remember.
→ It enables access to an account to be shared securely, without sharing the password.
→ It enables secure passwords to be generated.
→ 256-bit AES encryption, with systematically repeated PBKDF2 iterations.
→ All sensitive data is encrypted and decrypted locally before synchronisation with Dashlane. The key never leaves the device and is never sent to Dashlane. Our data is accessible to nobody other than us.
5.10 INTERNAL REVIEW OF ACCESS RIGHTS
In addition to our procedures for managing joiners, leavers and internal transfers, access rights are reviewed periodically, at least once a year.
6. Physical security
6.1 Infrastructure
Dashdoc's main infrastructure is hosted in the data centres of our partner Google Cloud. Another provider, Scaleway, hosts our backup infrastructure. Both Google Cloud and Scaleway provide the highest level of security to ensure the availability, integrity and confidentiality of the hosted data.
6.2 Dashdoc premises
Dashdoc premises – Paris 9th arrondissement, France
→ Access to the premises controlled by keypad code and RFID badge
Dashdoc premises – Nantes, France
→ Access to the premises controlled by RFID badge
→ Video surveillance system
→ Intrusion alarm system
6.3 Traceability of physical access
The security and traceability of physical access to our production servers are ensured by our hosting provider Google Cloud:
“Google designs and builds its own data centres, which incorporate multiple layers of physical security protection. Access to these data centres is restricted to only a few Google employees. We use multiple layers of physical security to protect our data centres and implement technologies such as biometric identification, metal detection, cameras, vehicle security barriers and laser intrusion detection systems. In addition, Google hosts servers in third-party data centres where we ensure that physical security measures controlled by Google supplement the security levels provided by the data centre operator. For example, at such sites, we may use independent biometric identification systems, cameras and metal detectors.”
Source: Google Infrastructure Security Design Overview
7. Security of your data
7.1 DATA CLASSIFICATION / GDPR
Dashdoc guarantees that personal data is isolated in a single collection in our databases, and that all other business data (training content, training statistics, groups, learning paths, etc.) uses a random identifier to reference each user, thereby ensuring pseudonymisation of personal data in accordance with GDPR regulations.
7.2 GEOGRAPHICAL LOCATION OF DATA
Our infrastructure is hosted in Google Cloud data centres in the “Europe-West 1” zone, located in Brussels, Belgium.
Our data backups are located in Scaleway data centres in the “FR-Paris” zone, located in Paris, France.
7.3 DATA SEGREGATION
The Dashdoc platform is a multi-tenant SaaS product: each customer sees only their own data. The database is shared between customers but logically segregated by customer. We implement a strict policy of automated testing and code review to ensure that each customer can access only their own data.
8. Security of information systems operations / Service continuity
8.1 SERVICE CONTINUITY PLAN
Dashdoc commits to the following service levels for its customers:
→ Platform availability rate of 99%
→ Response time of 2 hours after discovery of a blocking incident (server errors)
→ Resolution time of 12 hours for a blocking incident (server errors)
→ Support available by email or telephone from 8:00 to 19:00 Paris time, Monday to Friday
→ RPO (Recovery Point Objective) of 24 hours.
8.2 DATA BACKUP
Logical backups (service version and customer data) are performed daily, remotely, on the Scaleway backup infrastructure.
This guarantees an RPO of no more than 24 hours.
Physical backups are performed every day on a dedicated server in a second data centre. The only physical storage locations are our Google Cloud servers and our Scaleway servers.
8.3 REDUNDANCY
Servers are replicated, data centres are supplied by two independent electrical feeds and are also equipped with uninterruptible power supplies.
Generators with 48 hours of autonomy can compensate for a possible failure of the electricity supply grid. Several security loops have thus been implemented to eliminate any risk of unavailability.
This multiplicity of links also enables your data to take the shortest route and therefore achieve minimum latency. Servers are also equipped with dual power supplies and dual network cards: the infrastructure is therefore redundant from end to end.
8.4 SECURITY PATCH MANAGEMENT
The operating systems and software we use are covered by valid support from their publisher or an active community (for open-source software), and only necessary services and applications are installed on our servers to reduce the attack surface. In addition, major updates and security updates are systematically deployed.
8.5 PROTECTION AGAINST MALICIOUS CODE
We ensure that all machines making up our platform are protected by a malware prevention system (antivirus, etc.) that is properly kept up to date.
9. Incident management / Disaster recovery plan
9.1 DISASTER RECOVERY PLAN
The DRP is activated in the event of a disaster affecting data integrity:
→ major logical vulnerability
→ physical destruction of hosting infrastructure
In such a case, the customer is notified immediately and the recovery procedure begins.
The standby infrastructure is hosted by our provider Google Cloud in another physical zone. It takes over and restarts using the latest version of the backed-up data. As mentioned previously, full backups (service version and customer data) are performed automatically once a day on the standby cluster and remotely, with the data never physically leaving its storage location.
This guarantees a maximum RPO (Recovery Point Objective) of 24 hours.
The DRP lasts no more than 12 hours. And where a change of data centre requires the IP addresses of DNS entries to be changed, DNS caches around the world take no more than 24 hours to update.
This guarantees an RTO (Recovery Time Objective) of less than 24 hours.
9.2 MANUAL RECOVERY FOLLOWING A CUSTOMER ERROR
The following provisions apply to Dashdoc's ability to restore data following incorrect handling by a user.
There are 3 types of data that may be lost:
→ Transport data
→ User data
→ Logs and statistics
In the event of data loss due to customer misuse affecting transport data, Dashdoc's R&D team assesses the extent of the loss and the workload. If the data can be restored, the team offers a service charged at 800 euros per person-day of work. In the event of data loss due to customer misuse affecting the other 2 types of data, Dashdoc does not guarantee their restoration.
10. Network security
10.1 ENCRYPTION OF NETWORK TRAFFIC
Exchanges between user workstations and our applications are fully encrypted from your browser to our servers using the HTTPS / TLS 1.3 protocol.
10.2 REMOTE ACCESS TO PRODUCTION SERVERS
Access to our production servers uses the SSH protocol and is therefore secured by a public key/private key system.
An anti-brute-force protection mechanism is also deployed to block IP addresses attempting to connect without authorisation.
10.3 ACCESS TO THE DASHDOC INTERNAL NETWORK
Only Dashdoc employees have access to the internal network. The Wi-Fi network is protected by WPA2 encryption.
10.4 PREVENTION OF EXTERNAL ATTACKS
Prevention of denial-of-service attacks (DDOS)
A DDoS attack aims to make a website unavailable by overloading the server's bandwidth or consuming its resources until they are exhausted. The cases encountered generally involve layer 7 attacks, the highest layer, based on large numbers of requests intended to saturate the system.
Ensuring its customers' online security is one of Dashdoc's main concerns.
To counter these attacks, we use Cloudflare.
Cloudflare's anti-DDoS protection solution secures websites, applications and entire networks while ensuring that legitimate traffic is not compromised.
With a capacity of 67 Tbps, Cloudflare's network blocks an average of 70 billion threats per day, including some of the largest DDoS attacks in history.
Firewall and port filtering
The firewalls installed on Dashdoc's servers provide enhanced security for traffic protection. Only ports essential to the operation and administration of the platform are allowed.
10.6 TRACEABILITY OF NETWORK ACCESS
All incoming HTTP requests are recorded in log files. These logs are retained for at least 90 days.
Every direct connection to our production servers (SSH connection) is also recorded in a logging system. The information recorded (connection time, IP address and public SSH key) makes it possible to trace the person who connected.
11. Development security / Architecture
11.1 ARCHITECTURE
Dashdoc offers SaaS (Software as a Service) software. The SaaS model is based on software being installed on servers rather than on the user's machine.
Our architecture is divided into three layers (see diagram):
→ The interface, written in Javascript, which runs on the client side (mobile or web). It contains some workflows and business logic. This component scales naturally: each client receives it as soon as they connect to the website and runs it themselves. To obtain the data to display and send new data to the platform, this part makes HTTP requests to a REST API.
→ The REST API, exposed by a Python server. This API is divided into basic building blocks.
→ The Python servers then query a PostgreSQL database to read and store data. This database is hosted on the Google Cloud SQL service and can be scaled automatically according to observed use of CPU and memory resources, as well as storage space.
11.2 DEVELOPMENT RULES
Our development rules follow the principles of “Security by design” as defined by OWASP (https://www.owasp.org/index.php/Security_by_Design_Principles)
Our development teams are regularly made aware of security issues.
In addition, every line of code produced is systematically reviewed within the development team. This review procedure ensures that all development work complies with our security policy.
11.3 CHANGE MANAGEMENT
We deploy new versions of the server application several times a day according to Continuous Delivery principles. A suite of automated tests and manual tests in a pre-production environment enable us to detect anomalies before deployment.
11.4 MONITORING AND MANAGEMENT OF TECHNICAL VULNERABILITIES
A periodic dependency review is in place to detect outdated external libraries that may be vulnerable to attacks.
12. Compliance
12.1 GDPR
You can find all our commitments regarding our policy on the confidentiality of your data and GDPR on our public website: https://www.dashdoc.com/en/legal/privacy-policy
12.2 CERTIFICATIONS
Our hosting provider Google Cloud holds the following certifications:
ISO/IEC 27001
ISO/IEC 27017
ISO/IEC 27018
ISO/IEC 27701
PCI DSS
SOC 1
SOC 2
SOC 3
Cloud Computing Compliance Controls Catalog (C5)
CSA STAR
EU Cloud Code of Conduct
OSPAR