Introduction

Objectifs et périmètre

L'objectif de ce document est de présenter l'approche générale de la sécurité au sein du groupe Nexedi. Ce document sera la base d'une future mise en place formelle des règles et politiques de sécurité du groupe Nexedi basée sur une approche inspirée de l'ISO 27001.

${WebPage_insertTableOfReferences}

Objectifs de sécurité et hypothèses

Comme nous l'a appris M. Espie [RD], chercheur en cybersécurité et développeur clé d'OpenBSD, la cybersécurité consiste à définir ce contre quoi nous voulons nous protéger et comment nous prévoyons d'assurer cette protection. M. Espie nous a également appris que « si vous avez beaucoup de données de valeur dans un système informatique, soit elles ont déjà fait l'objet d'une fuite, soit elles n'ont aucune valeur ».

M. Espie nous a appris que nous voulons parfois nous protéger contre la « honte », même si nous savons qu'il n'existe pas de solution concrète à certains problèmes de cybersécurité. Dans d'autres mondes, les mesures de cybersécurité sont parfois nécessaires pour cacher le fait qu'il n'y a pas de solution contre les fuites de données dans un monde où tous les systèmes d'exploitation contiennent des milliers de portes dérobées ou de vulnérabilités.

Une autre source d'inspiration pour nous est Mark Burgess, l'un des inventeurs du Cloud Computing, qui explique que la capacité à réagir rapidement à une cyberattaque compte plus que l'ajout de procédures rigides dans une entreprise [RD].

Une autre source d'inspiration est Yoshinori Okuji, créateur du bootloader GRUB2 et ancien CTO de Nexedi, qui nous a toujours appris à régler les problèmes de sécurité à la racine plutôt que d'ajouter des couches sans régler la cause première.

L'approche de Nexedi en matière de sécurité s'inspire de ces personnalités clés tout en gardant à l'esprit que, dans une économie de marché, l'effort à investir dans la sécurité doit être proportionnel aux risques en jeu, ce qui conduit à des compromis.

Expérience

Sur une période de 24 ans, nous avons eu connaissance des événements suivants liés à la cybersécurité chez Nexedi :

1. client perdant toutes ses données ERP malgré l'utilisation d'un SAN et d'une sauvegarde Veritas (2 occurrences) - heureusement, nous avions conservé une copie supplémentaire ;
2. en raison d'une erreur d'un membre du personnel permanent, nous avons perdu les données du SlapOS Master et avons dû le restaurer (1 occurrence) - les nœuds de calcul SlapOS ont continué à fonctionner sans problème jusqu'à ce que le Master soit restauré ;
3. perte d'accès à l'application du client en raison d'une erreur de configuration de routage dans une entreprise de télécommunications de niveau 1 (3 occurrences) ;
4. perte d'accès à l'ERP de production du client en raison de l'interférence du logiciel antivirus McAffee, qui a épuisé les ressources du serveur ;
5. intrusion du serveur avec un rootkit et installation d'un botnet en raison du mauvais mot de passe d'un utilisateur (2 occurrences) ;
6. personnel permanent forcé de divulguer des données clients au département de la défense (1 occurrence) ;
7. personnel permanent forcé de remettre le disque dur du serveur à la police sans décision de justice (1 occurrence) ;
8. personnel permanent divulguant un mot de passe par erreur (1 occurrence) ;
9. hameçonnage d'un stagiaire par attaque sociale (1 occurrence) ;
10. accès à une liste de dispositifs utilisés par diverses agences de renseignement pour surveiller des personnes ou des ordinateurs ;
11. offre d'obtenir une copie gratuite de NSO Pegasus (nous avons refusé, car c'est illégal).

Nous avons également étudié les différents risques de perte de données dans un système en cloud dans le cadre du International Working Group on Cloud Resilience (IWGCR) [RD].

Objectifs

Sur la base de notre expérience, nous voulons nous protéger en priorité contre :

1. La perte de données (nos données, celles de nos clients) ;
2. La perte d'accès à des services (nos services, ceux de nos clients) ;
3. La fuite de données sensibles (nos données, celles de nos clients) ;
4. La honte (de ne pas faire quelque chose qui est censé être évident).

Ne faire confiance à rien

D'après notre expérience, nous ne pouvons pas faire confiance :

1. au personnel (en raison de l'intimidation des agences gouvernementales sur leur famille) ;
2. au LAN (en raison des vulnérabilités des routeurs, des pare-feux ou de l'utilisation de dispositifs de surveillance) ;
3. au Wifi public (en raison des vulnérabilités des routeurs et de l'utilisation de dispositifs de surveillance dans de nombreux hôtels, aéroports et gares) ;
4. au Wifi privé/personnel (en raison de la présence d'appareils Windows avec des virus sur le même réseau) ;
5. aux logiciels propriétaires (en raison de l'exigence de la Foreign Intelligence Surveillance Act et de la China Cybersecurity Law d'inclure des portes dérobées) ;
6. aux éléments de réseau propriétaires, y compris le matériel de pare-feux propriétaires [RD];
7. aux logiciels libres, y compris les distributions Linux, en raison d'anciennes versions de logiciels, d'attaques de la chaîne d'approvisionnement ou de vulnérabilités non divulguées ;
8. aux services dans le Cloud exploités par des sociétés américaines, nationales ou européennes (en raison de l'obligation d'inclure des portes dérobées en vertu de la loi sur la surveillance du renseignement étranger, de la loi chinoise sur la cybersécurité ou de la loi sur les services numériques) ;
9. aux ordinateurs portables équipés d'un processeur récent (en raison de portes dérobées dans le moteur de gestion du processeur récent) ;
10. au matériel de serveur (en raison de portes dérobées dans le moteur de gestion du processeur) ;
11. à l'Intelligent Platform Management Interface - IPMI (en raison de portes dérobées dans le Baseboard Management Controller - BMC des serveurs).

Hypothèses

Nous considérons que :

1. le personnel partage parfois avec des tiers inconnus ses identifiants pour accéder aux données sensibles des clients sans que la direction puisse l'empêcher ;
2. des tiers sont en mesure d'accéder à n'importe lequel de nos serveurs, ordinateurs portables et smartphones à l'aide d'outils de pénétration qui exploitent des portes dérobées dans les logiciels propriétaires et des vulnérabilités "zero-day" dans les logiciels libres ;
3. les ordinateurs portables, serveurs dans le Cloud et smartphones du personnel sont connectés à des réseaux non sécurisés contenant des dispositifs de surveillance et des réseaux de zombies par l'intermédiaire, éventuellement, d'une adresse IP publique.

Topologie

Dans notre modèle de sécurité, nous supposons que chaque nœud (ordinateur portable, serveur, smartphone, etc.) est un système autonôme faisant face à l'internet.

Solutions techniques

Nous présentons dans ce chapitre les solutions techniques mises en œuvre pour atteindre nos objectifs de cybersécurité.

Objectif 1 : conserver les données

Toutes les données sont stockées sur des serveurs dont les services sont gérés automatiquement par SlapOS. Nous répartissons les serveurs dans des centres de données indépendants (fournisseur d'électricité différent, pays différent, fournisseur de transit différent). Nous automatisons la procédure de reprise après sinistre avec sauvegarde, archivage, restauration, construction reproductible. Nous utilisons plusieurs distributions Linux. SlapOS comprend un mécanisme d'automatisation des tests quotidiens de reprise après sinistre.

SlapOS comprend une protection contre la "suppression globale" résultant d'une attaque sur l'orchestrateur principal. Chaque nœud a un "délai de rétention" qui empêche une demande de suppression d'être effective avant le délai de rétention, ce qui laisse le temps de l'annuler. Nous utilisons, autant que possible, une technologie "Append-only" de base de données avec un historique complet afin de pouvoir récupérer un "effacement ciblé" en remontant l'historique ou en annulant certaines transactions.

Améliorations prévues :

• application d'une politique de définition du "délai de conservation" ;
• séparation des droits d'accès aux serveurs de sauvegarde et aux serveurs d'archivage.

Objectif 2 : maintenir l'accès

Chaque nœud lance au hasard dix tunnels (OpenVPN, gre, wireguard, etc.) vers d'autres nœuds et détruit 30 % d'entre eux toutes les 5 minutes pour les remplacer par de nouveaux. Cela crée un "maillage vivant" de tunnels entre tous les nœuds du système dans le monde entier. Aucun cryptage n'est mis en œuvre lors du transit afin de respecter les lois internationales en vigueur dans les différents pays. Au-dessus de ces nœuds, un protocole de routage (babel) est utilisé pour minimiser la latence et maintenir le trafic.

Ce système est exploité comme un AS avec deux passerelles frontalières (BGP). Des communautés sont utilisées sur l'AS pour mettre en œuvre diverses politiques d'accès ou de routage.

Seuls les nœuds bien identifiés peuvent rejoindre ce réseau (certificat X.509 géré dans un registre central). Tout nœud de ce système peut être révoqué à tout moment. HMAC (en cours de déploiement) est utilisé pour limiter les capacités de routage dans les réseaux locaux et empêcher les intrusions dans ce réseau. Un pare-feu est mis en place au niveau de la passerelle frontalière pour restreindre certains trafics. Un système anti-DDOS est mis en œuvre par la plupart de nos fournisseurs de transit.

Cette solution nous permet de maintenir l'accès lorsque :

• l'un de nos fournisseurs de transit est confronté à un DDOS (le trafic est redirigé vers un autre fournisseur de transit par babel) ;
• l'un de nos fournisseurs de transit est confronté à une panne de routage (le trafic est redirigé vers un autre fournisseur de transit par babel) ;
• notre passerelle frontalière est confrontée à un DDOS (notre fournisseur de passerelle frontalière, BSO, fournit un anti-DDOS et notre pare-feu peut être configuré de manière à bloquer tout le trafic).

Objectif 3 : réduire les fuites de données

Il est impossible d'empêcher les fuites de données dans les systèmes informatiques en raison de l'existence de portes dérobées dans tous les processeurs modernes et dans le flux binaire de la bande de base des smartphones. Si nous devons échanger des informations sensibles, nous utilisons le papier ou des réunions en face à face dans des environnements bruyants. Malheureusement, il n'y a pas d'autre moyen.

Nous ne nous considérons pas non plus comme des experts en cybersécurité.

Toutefois, nous pouvons réduire la probabilité de fuite d'informations. Voici les mesures que nous appliquons :

• éliminer l'utilisation de tous les logiciels comportant des portes dérobées (par exemple, tous les logiciels Microsoft, tous les logiciels Huawei, tous les réseaux centraux 4G/5G conformes à l'UIT) en raison de la législation FISA (États-Unis), CSL (CN) ou UIT (ONU) ;
• éliminer l'utilisation de tous les services Cloud comportant des portes dérobées (par exemple, AWS, Azure, Alicloud, etc. ) en raison de la législation FISA (États-Unis), CSL (CN) et bientôt DSA (UE) ;
• éliminer tout le matériel de réseau doté de portes dérobées (ex. CISCO, Huawei, etc.) ;
• éliminer l'utilisation d'IPMI car les BMC ne sont pas fiables ;
• n'utiliser que des logiciels libres dont l'absence de portes dérobées peut être vérifiée par nos soins (ex. Linux OS sur les ordinateurs portables ou les serveurs, /e/ OS sur les smartphones), sauf exception explicite ;
• placer un proxy inverse (CDN) entre les clients Internet et les applications dorsales (pas de contact direct avec Internet) ;
• éliminer l'utilisation d'un utilisateur non supervisé (root), sauf pour un processus (slapgrid) ;
• crypter tout le trafic entre l'utilisateur et le serveur (ex. TLS entre le navigateur de l'utilisateur et le CDN) ;
• crypter tout le trafic entre les services déployés sur notre infrastructure (ex. TLS entre le serveur d'application et la base de données) ;
• dans certains systèmes, mettre en œuvre fail2ban (et bientôt crowdsec) pour limiter le nombre de demandes par adresse IP ou bloquer certaines IP ;
• utiliser un contrôle d'accès basé sur les rôles dans les applications (ex. accès aux documents du client par projet) ;
• utiliser le mode invité sur les ordinateurs portables (effacement complet à chaque redémarrage) ou chiffrer les disques SSD au niveau du système d'exploitation sur les ordinateurs portables,
• chiffrer les disques SSD au niveau du système d'exploitation à chaque fois que cela est demandé sur les serveurs (nécessite une présence sur place pour redémarrer le serveur, ce qui est acceptable pour les ordinateurs portables) ;
• chiffrer les fichiers stockés dans la base de données de documents à l'aide d'un outil de chiffrement externe (par ex. GPG) à chaque fois que cela est demandé ;
• utiliser le courrier électronique crypté (ex. delta.chat) ;
• distribuer des informations sur de nombreux sites différents avec des propriétaires différents pour rendre plus difficile la collecte de toutes les informations en une seule fois par la saisie du serveur ;
• utiliser des unités centrales de différents pays pour empêcher un gouvernement étranger d'accéder à des informations sensibles dans un autre pays (ex. le gouvernement américain accède à des données sensibles en Europe, le gouvernement chinois accède à des données sensibles aux États-Unis, etc.) ;
• utiliser par défaut un pare-feu sur chaque nœud (ordinateur portable, serveur et, espérons-le, smartphone) pour réduire la surface d'attaque, sauf exception explicite ;
• automatiser la configuration du pare-feu "par processus" avec des listes blanches via SlapOS ;
• mettre à jour le système d'exploitation de base et les dépendances en cas de CVE ;
• mettre en œuvre un système anti-fraude sur les ordinateurs portables et les serveurs (signer tous les fichiers du système d'exploitation de base et les comparer à la base de données de référence pendant le processus de démarrage lorsque les disques sont en lecture seule) ;

Améliorations prévues :

• utilisation de Nitrokey pour X.509 au lieu de fichiers ;
• utilisation de crowdsec plus globalement, si possible pour fonctionner sans droits de superutilisateur ;
• suppression de l'accès root ssh à tous les serveurs (comme l'a fait Google après 10 ans d'efforts) ;
• utilisation d'un antivirus sur /e/OS [RD] ;
• mise en œuvre des règles susmentionnées.

Objectif 4 : garder la face

Nous sommes en train d'implémenter le traitement automatisé des CVE dans SlapOS afin d'automatiser la mise à jour de certains composants dans les services qui sont déployés. Cela évitera d'avoir honte de ne pas avoir mis à jour certains composants, même s'ils ne sont pas impliqués dans une attaque.

Nous mettons en œuvre l'orchestration de la cybersécurité avec le logiciel « Patrowl ». Cela permettra de s'assurer que tout ce que nous livrons a automatiquement passé les tests de pénétration courants.

Recherche

Notre recherche se concentre sur les « promesses de cybersécurité » et la « résilience de l'horizon divisé ». Nous prévoyons d'inclure dans SlapOS différentes approches pour surveiller les attaques potentielles. Nous prévoyons d'ajouter au protocole SlapOS différentes approches pour continuer à orchestrer les composants en cas de « splinternet » (par exemple, la Chine et les États-Unis déconnectant complètement leurs réseaux).

Solutions sociales

Outre les solutions techniques, nous mettons en œuvre des solutions sociales avec toujours cet objectif de résoudre la cause première plutôt que de traiter le symptôme.

Assurance Cybersécurité

Nexedi a contracté une assurance Cybersécurité pour un montant de garantie proportionné à l'activité de l'entreprise. Cette assurance vise à minimiser les conséquences directes d'une attaque numérique et protéger les données de Nexedi et celles de ses clients. Cette assurance nous permet également de bénéficier d'un accompagnement en cas de crise couvrant la restauration des systèmes informatiques, la communication de crise et l'assistance juridique.

Formation du personnel

Nous formons nos collaborateurs dès leur embauche [RD], pendant leur travail [RD] [RD] et en veillant à ce qu'ils se sentent responsables de la cybersécurité des solutions que nous déployons pour nous mêmes et nos clients.

En outre, il est demandé à chaque chef de projet de :

• s'abonner aux listes de diffusion sur les vulnérabilités ;
• mettre à jour les composants de SlapOS ou le noyau de l'hôte dont il sont en charge en temps voulu ;

Nous avons également mis en place des simulations d'hameçonnage à destination de l'ensemble des membres du personnel afin de leur apprendre à reconnaître, éviter et signaler des attaques de "phishing". Ces tests d'hameçonnage sont complétés par des sessions de formation et sensibilisation en ligne aux cybermenaces pour les salariés qui se lasseraient abuser par un email de test d'hameçonnage reçu sur leur boîte email professionnelle.

Tests de vulnérabilité et de pénétration

Nous mettons en œuvre des tests de vulnérabilités périodiques et automatiques de l'ensemble de la surface d'attaque externe de Nexedi. Ces tests sont réalisés par un prestataire externe et donnent lieu mensuellement à la formalisation d'un rapport de risque détaillant les vulnérabilités identifiées dans l'infrstructure de Nexedi ou la configuration des nos services de messageries (emailing).

Nous suggérons par ailleurs à nos clients d'effectuer des tests de vulnérabilité et de pénétration indépendants des systèmes que nous mettons en œuvre pour eux.

Processus de publication des patchs de vulnérabilité

Pour tous les logiciels créés par Nexedi (ex. code source ERP5, code source re6st), les patchs de sécurité suivent un processus bien défini :

1. mettre le correctif de sécurité dans un dépôt privé accessible uniquement aux développeurs de Nexedi ;
2. informer sur le forum interne du risque de sécurité, et expliquer aux chefs de projet :
   1. comment vérifier s'ils ont été affectés ;
   2. comment appliquer le correctif
3. avant de diffuser le correctif, vérifier auprès de chaque chef de projet si le correctif a été appliqué avant de le diffuser au public.

De cette manière, nous nous assurons que les vulnérabilités trouvées dans notre propre code n'affectent pas les projets de nos clients.

Question fréquentes

Comment votre organisation aborde-t-elle le risque de cybersécurité dans sa chaîne d'approvisionnement ?

Réponse : en appliquant la politique « ne faire confiance à rien » décrite dans le présent document :

• ne faire confiance à rien ;
• ne faire confiance à personne ;
• demander l'accès au code source et aux plans pour vérifier ou construire par nous-mêmes.

Quels sont les mécanismes de contrôle du réseau mis en œuvre par votre organisation ?

Réponse : considérant le champ d'application des politiques décrites dans le présent document, nos principaux mécanismes sont :

• détection des intrusions (détection et déconnexion des IP qui font trop de requêtes, détection des exécutables anormaux) mais pas d'IDS en tant que tel car l'IDS augmente la surface d'attaque ;
• prévention des intrusions (par exemple, les backends ne sont pas accessibles directement, mais par l'intermédiaire d'un CDN ou d'un proxy).

Vos dispositifs de contrôle d'accès au réseau sont-ils configurés de manière à ce que l'accès ne soit pas accordé par défaut ?

Réponse basée sur le fait que re6st joue le même rôle que le LAN dans la plupart des entreprises :

• l'accès au réseau re6st n'est accordé qu'aux détenteurs d'un certificat.

Votre organisation dispose-t-elle d'une politique et d'un processus permettant d'identifier les vulnérabilités et d'y remédier en temps utile ?

Réponse : considérant le champ d'application des politiques décrites dans le présent document, nos principaux processus sont :

• l'abonnement aux listes de diffusion sur les vulnérabilités et la mise à jour régulière des composants de SlapOS ;
• la prise en charge, par le chef de projet, des décisions de corriger le noyau / mettre à jour les dépendances sur les hôtes dont il est responsable ;
• la prise en charge, par le gestionnaire d'infrastructure, des décisions de mise à jour du noyau sur toutes les infrastructures dont il est responsable.

Comment protégez-vous spécifiquement les applications Internet soutenant un service critique ou hébergeant des informations secrètes de clients ?

Réponse : considérant que les backends ne sont pas directement en prise avec l'internet et en tenant compte des orientations de notre recherche :

• toutes les applications sont hébergées sur le réseau re6st et accessibles via un proxy CDN, et ne sont donc pas directement tournées vers l'internet ;
• il est prévu d'exécuter les services d'orchestration de cybersécurité patrowl sur toutes les Softwares Releases de SlapOS qui sont livrés au client.

Votre organisation dispose-t-elle d'un logiciel de prévention des logiciels malveillants ou d'un logiciel antivirus pour les systèmes hébergeant des informations sur les clients ?

Reponse :

• nous utilisons l'antivirus libre ClamAV [RD] pour détecter des logiciels malveillants infestant potentiellement des documents stockés dans les applications de gestion mises à disposition de nos clients avant d'organiser la mise en quarantaine de ces documents ;
• nous n'utilisons pas d'antivirus systématiquement sur chaque noeud car nous n'utilisons que des systèmes d'exploitation libres (Linux, xBSD, etc.) pour lesquels ils ne sont pas utiles [RD] ;
• nous utilisons un logiciel anti-tampering sur une part croissante de nos serveurs pour détecter les logiciels malveillants basés sur cutom initrd [RD] et les clés UEFI [RD].

Quelles techniques utilisez-vous pour vous protéger contre les courriers électroniques malveillants ?

Réponse : 

• nous utilisons un filtre anti-spam ;
• nous n'utilisons pas d'outil de détection de l'hameçonnage car nous préférons apprendre à notre personnel à ne se fier à rien dans ce domaine afin qu'il puisse s'adapter à l'évolution constante des méthodes d'hameçonnage ;
• nous pourrions envisager d'utiliser certains outils pour faciliter l'analyse des URL par notre personnel ;
• nous n'utilisons pas outlook, gmail, etc. parce que leur utilisation est illégale en Europe pour manipuler des informations protégées par le secret commercial.

Référence

• https://github.com/BushidoUK/Open-source-tools-for-CTI/blob/master/Anti-Phishing%20Tools.md
• https://snyk.io/product/open-source-security-management/?utm_medium=paid-search&utm_source=google&utm_campaign=nb_ba_open-source&utm_content=open-source-_-category&utm_term=open%20source%20application%20security&gad_source=1&gclid=Cj0KCQjwsaqzBhDdARIsAK2gqnfBHod0JdWQCkqreIISKYZM4wbSNgjOGcmCKHYURIds240kaR-PJdUaAs_aEALw_wcB