FAQ: Sécurité logicielle

Lokad est, avant tout, un spécialiste de la supply chain et notre objectif principal est de fournir de meilleures décisions supply chain grâce à l’ingéniosité technologique. Cela dit, nous traitons quotidiennement d’importantes données financières, ainsi la sécurité de notre plateforme logicielle est une priorité que nous prenons avec le plus grand sérieux. Plutôt que d’aborder la sécurité comme une réflexion après coup à gérer par la bureaucratie, nous croyons fermement à une approche fondée sur des principes qui met l’accent sur la planification et la proactivité, comme en témoignent nos choix spécifiques en matière de conception logicielle, de recrutement et de formation.

Public visé : Le département IT
Dernière modification : 21 septembre 2023

Principes de sécurité

L’une des illusions les plus dangereuses dans les cercles de logiciels d’entreprise est l’idée que la sécurité peut être abordée grâce à des listes de vérification de conformité, des certifications et, de manière plus générale, à toutes sortes de tâches bureaucratiques. Malheureusement, les détails des préoccupations en matière de sécurité sont en perpétuelle évolution. Les problèmes surviennent lorsque des acteurs malveillants tirent parti du logiciel ou des personnes (ou des deux). La sécurité ne peut donc être assurée que par l’application judicieuse de principes généraux.

Plus sûr dès la conception

Nous pensons que la conception est l’un des aspects les plus sous-estimés de la sécurité logicielle. Ici, la conception englobe les décisions fondamentales prises pour développer le logiciel. Les choix de conception d’une entreprise ont d’immenses implications en matière de sécurité, notamment en ce qui concerne la surface d’attaque. Grâce à une conception logicielle judicieuse, Lokad a éliminé des classes entières de problèmes de sécurité. Par exemple, Lokad n’utilise pas de base de données SQL - mais un simple stockage en blobs - en tant que couche de stockage strictement passive. Ce choix, à lui seul, empêche des groupes entiers de problèmes de sécurité, tels que les attaques par injection SQL, puisqu’il n’existe tout simplement aucune base de données SQL à attaquer. De même, toutes nos couches de persistance sont ajout-only. C’est comparable au contrôle de version où les modifications sont ajoutées à la fin des données existantes, plutôt que de remplacer l’intégralité des données. Toutes les modifications sont tracées et peuvent être inversées. Cette mesure complique grandement la suppression de toute donnée (par quiconque, y compris les attaquants), ainsi que la falsification des journaux de Lokad.

La plupart des fournisseurs de logiciels d’entreprise ne reconnaissent pas que les choix de conception fondamentaux constituent le socle même de leurs produits. En conséquence, leurs problèmes de sécurité sont sans fin. Par exemple, si la configurabilité - presque toujours une exigence pour les logiciels d’entreprise - est assurée par un langage de programmation à usage général (comme Python ou JavaScript), des problèmes de sécurité surgissent inévitablement. Cela s’explique par le fait qu’il est pratiquement impossible de sécuriser complètement un langage de programmation à usage général. En revanche, Lokad a fait le choix délibéré de canaliser toute la configurabilité via un DSL (langage de programmation spécifique au domaine) nommé Envision. Envision est bien plus sûr car il ne possède pas - par conception - la capacité d’interagir directement avec le système d’exploitation (OS) et ses sous-systèmes, comme le système de fichiers.

Plus sûr par la culture

Aucune technologie, et certainement aucun processus, ne peut rendre un logiciel sécurisé si les gens s’en fichent. Par conséquent, nous faisons tout notre possible pour que Lokad - tant par sa technologie que par ses processus - suscite une véritable attention. Dans le contexte des logiciels d’entreprise, cela est difficile, car l’objet d’intérêt est abstrait et déconnecté des perspectives et motivations individuelles des personnes¹.

Tout d’abord, Lokad aligne, autant que faire se peut, ses messages marketing avec la réalité de son activité. Nous agissons ainsi, que cela nous attire la faveur ou la critique. Cela contraste nettement avec de nombreux fournisseurs de logiciels d’entreprise qui font des affirmations déraisonnables (et souvent fantaisistes) en public ². Quand cela se produit, les employés perspicaces - ceux capables d’identifier le décalage entre la réalité des affaires et ce qui est communiqué à l’extérieur - cessent de s’en soucier. Cette indifférence engendre de la complaisance, et les problèmes de sécurité s’ensuivent. Souvent, ces employés quittent l’entreprise, ne laissant derrière eux que les « crédules » - ceux qui ne parviennent pas à percevoir ce décalage. La crédulité, tout comme l’indifférence, n’est pas une qualité souhaitable en matière de sécurité.

Ensuite, Lokad encourage parmi ses employés un mélange de curiosité et de scepticisme sain à l’égard de tous les aspects de notre activité, tant techniques que non techniques, y compris la sécurité. Cela crée une flexibilité favorable à la révision et à la mise à jour des pratiques, les employés étant formés et encouragés à contribuer. Une telle plasticité est utile pour anticiper les acteurs malveillants, qui sont connus pour élaborer des méthodes d’attaque toujours plus créatives. Heureusement pour Lokad, cet état d’esprit s’avère également très souhaitable pour la supply chain, car des comportements défavorables - bien que pas nécessairement criminels - sont monnaie courante dans les supply chain ³.

Plus sûr par la formation

Nous formons activement tout notre personnel afin de mieux comprendre les cybermenaces et les moyens de les atténuer. Contrairement à la conception et à la culture, la formation en sécurité relève principalement d’un processus descendant. Bien que la réflexion ascendante ait sa place, ce type de formation est intrinsèquement moins efficace face à la plupart des risques de sécurité informatique. En d’autres termes, même si les personnes sont formées à ne pas faire quelque chose, Lokad ne peut garantir que personne ne s’y essayera jamais ⁴. Ainsi, nous adoptons une approche plus stricte. Dans le cadre de notre formation, nous décourageons l’utilisation des clés USB et autres dispositifs USB pouvant compromettre les machines. Nous veillons à ce que l’authentification à deux facteurs soit utilisée dès que possible. Nous formons notre personnel à travailler avec le strict minimum de privilèges sur leurs postes de travail. Nous nous assurons que chacun comprenne le fonctionnement de l’ingénierie sociale, qui peut être utilisée pour duper même les personnes les plus intelligentes.

De manière plus générale, la formation en sécurité vise à sensibiliser sur la manière dont les logiciels et les processus peuvent être détournés et corrompus par des acteurs malveillants. Compte tenu de l’étendue de la formation, des compétences et du savoir-faire nécessaires pour prévenir de telles attaques nuancées, Lokad emploie généralement très peu de stagiaires, comparé à la plupart des entreprises de taille similaire dans ce secteur. En bref, nous préférons miser sur une équipe stable et hautement formée sur le long terme.

Questions fréquemment posées (FAQ)

1. Pratiques

1.1 Avez-vous une assurance de sécurité ?

Oui. L’assurance de sécurité est un terme générique englobant une variété de pratiques telles que le renforcement de la sécurité, les tests de sécurité et la gestion des vulnérabilités. Le renforcement de la sécurité, chez Lokad, est avant tout abordé par la conception. Grâce à des choix de conception spécifiques, nous éliminons des classes entières de vulnérabilités, éliminant ainsi le besoin même de renforcer cette sécurité. Par exemple, Lokad ne repose pas sur une couche de stockage « programmatique » - comme une base de données relationnelle - mais sur un simple magasin de paires clé-valeur. Cela élimine tous les vecteurs d’injection SQL. De plus, les tests de sécurité sont effectués au moyen d’une série de méthodes variées, certaines automatisées et d’autres manuelles, telles que les tests d’intrusion réalisés par des tiers. Pour la gestion des vulnérabilités, nous disposons d’un programme de bug bounty et d’un processus de gestion des versions largement automatisé pour garantir que les correctifs puissent être déployés rapidement.

1.2 Êtes-vous conforme aux normes ISO 27001 (ISMS) et/ou SOC 2 ?

Non. Nous croyons fermement que ces certifications sont des distractions qui rendent les entreprises logicielles moins sécurisées. Ces processus de conformité favorisent un état d’esprit bureaucratique, à l’opposé de ce qui est nécessaire pour assurer la sécurité des logiciels. Par exemple, ces certifications exigent la production de documents administratifs et la mise en place de comités. Franchement, l’idée que la paperasserie et les comités apportent quelque chose de réellement substantiel à la sécurité logicielle est hautement discutable et n’est absolument pas acceptée par Lokad.

Dans les cercles du logiciel, la sécurité est généralement obtenue en faisant moins, et non plus, en tirant parti des efforts des ingénieurs spécialisés en sécurité logicielle, plutôt qu’en créant des équipes supplémentaires de non-spécialistes. À titre d’exemple, considérez certaines des catastrophes de cybersécurité les plus graves, telles que Heartbleed ou Log4Shell. Ces désastres auraient probablement été évités si les milliers d’entreprises logicielles « certifiées » avaient choisi de prioriser la relecture du code tiers – souvent la cause première des problèmes – plutôt que de rechercher des sceaux d’approbation commerciaux arbitraires.

Dans l’ensemble, nous pensons que ces certifications sont des astuces marketing qui plongent les entreprises dans un faux sentiment de sécurité (à la fois au sens figuré et littéral).

1.3 Suivez-vous les pratiques OWASP ?

Oui. OWASP fournit, par le biais de ses guides, une liste de contrôle exhaustive contre les vulnérabilités couramment présentes dans les logiciels. Il s’agit d’une compilation étendue et de haute qualité que les ingénieurs de Lokad utilisent pour protéger notre logiciel de tout problème identifié par OWASP. Cependant, grâce à ses choix de conception, Lokad élimine en grande partie des classes entières de vulnérabilités communes mises en évidence par OWASP. Par exemple :

Gestion des mots de passe: En déléguant l’authentification via la fonctionnalité SSO (single sign-on, recommandée par Lokad), Lokad n’a plus besoin de « gérer » les mots de passe, rendant caduque toute la liste de contrôle afférente aux mots de passe.

Journalisation: Le design basé sur l’event sourcing adopté par Lokad enregistre tout par nécessité. Si une action n’est pas enregistrée, alors, pour le système, elle n’a jamais eu lieu. Cela annule la majeure partie de la liste de contrôle concernant la journalisation.

Sécurité de la base de données: La couche de persistance de Lokad n’inclut pas de base de données relationnelle, mais uniquement deux composants non programmatiques, à savoir une source d’événements et un magasin de paires clé-valeur. Ce choix de conception annule entièrement la liste de contrôle relative aux bases de données.

De manière plus générale, lorsque cela est possible, nous préférons éviter les schémas de conception sujettes à erreurs qui créent le besoin de telles listes de contrôle dès le départ.

1.4 Êtes-vous conforme au GDPR ?

Oui. Cependant, l’optimization de la supply chain - telle que fournie par Lokad - ne nécessite pas de données personnelles. Nous considérons les données personnelles comme une responsabilité plutôt que comme un atout. Ainsi, nous recommandons fortement à nos clients de ne pas nous transférer de données personnelles. Cette recommandation fait généralement partie de nos accords contractuels. En n’ayant pas de données personnelles en notre possession et donc en ne les traitant pas, nous éliminons en grande partie les préoccupations et protocoles liés à leur protection, tels que le GDPR ou des réglementations similaires.

1.5 Tous les services/solutions tiers (impliquant un accès aux informations personnelles identifiables (PII)) dans la solution de Lokad sont-ils conformes aux exigences du Data Protection Officer (DPO) ?

Oui. Cependant, comme indiqué dans Pratiques 1.4, l’optimization de la supply chain - telle que fournie par Lokad - ne nécessite pas de données personnelles. Ainsi, nous recommandons fortement à nos clients de ne pas nous transférer de données personnelles.

Il convient de noter que la solution de Lokad dispose d’une liste très restreinte de tiers ayant accès aux données PII. À partir de janvier 2023, cette liste est limitée à Microsoft Azure.

1.6 Suivez-vous les meilleures pratiques en matière de sécurité ?

Oui. Autrement dit, nous faisons des choix prudents, car il n’existe aucun consensus industriel sur ce qui constitue « les meilleures pratiques de sécurité logicielle ». Par nature, la sécurité logicielle évolue constamment, s’adaptant à un environnement rempli de menaces astucieuses et de nouveaux vecteurs d’attaque. Ainsi, nous ne déléguons pas catégoriquement aux tiers la définition de ce que sont les meilleures pratiques de sécurité logicielle. Au contraire, nous définissons ce qui est optimal pour nos clients. Cela nous permet d’adopter de bonnes pratiques lorsque cela est possible, sans suivre rigidement celles qui sont moins recommandables simplement parce qu’elles sont populaires. Tout cela se traduit par des pratiques de sécurité logicielle actuelles, applicables et efficaces.

1.7 Effectuez-vous régulièrement des tests d’intrusion ?

Oui. Nous réalisons des tests d’intrusion planifiés et non planifiés. Les tests planifiés sont généralement financés par nos grands clients qui peuvent, conformément aux accords contractuels signés avec eux, faire appel à des entreprises spécialisées pour tester les principaux fournisseurs de logiciels, y compris Lokad. Il existe généralement un certain niveau de coordination entre l’équipe d’ingénierie de Lokad et ces spécialistes de la sécurité. Les tests non planifiés font typiquement partie de notre programme public ouvert de bug bounty, où des spécialistes indépendants de la sécurité peuvent tenter de trouver une faille dans notre système susceptible d’être exploitable.

1.8 Effectuez-vous régulièrement des audits externes ?

Non. Cela dit, nous sommes tout à fait disposés à subir un audit externe si l’opération est financée par le client. Beaucoup de nos grands clients prévoient de tels audits dans leurs accords contractuels. Cependant, à partir de janvier 2023, les tests d’intrusion menés par les clients n’ont révélé aucun problème suffisant pour justifier la mise en place de tels audits.

1.9 Disposez-vous d’un Plan de Continuité d’Activité ?

Oui. La plus grande éventualité envisagée par Lokad est l’hypothétique cessation d’activités de l’entreprise elle-même. Lokad opère en tant que solution SaaS, toutefois, certains de nos grands clients disposent de clauses dans leurs accords contractuels leur permettant de demander des instantanés complets de notre codebase. Ces instantanés sont mis en séquestre auprès d’une tierce partie convenue de manière à ce que, dans le cas où Lokad cesserait ses activités, le client obtienne automatiquement l’accès à la codebase en séquestre et une licence permissive pour recréer sa propre instance du service Lokad.

1.10 Avez-vous un plan de communication de crise ?

Oui. Pour chaque client, nous avons un interlocuteur identifié au sein de leur organisation. De notre côté, il y a au moins deux employés chez Lokad – un principal et un remplaçant (typiquement deux de nos Supply Chain Scientist) – qui veillent à communiquer tout message urgent au client. En pratique, la grande majorité des crises que nous rencontrons ne concerne pas la sécurité des logiciels, mais la supply chain – des urgences que Lokad identifie sur la base des données mises à notre disposition par le client. En cas d’événement de sécurité, ce canal est utilisé pour s’assurer que nos clients en soient informés en temps utile.

1.11 Comment garantissez-vous que les systèmes informatiques du client sont sécurisés ?

Nous recommandons fortement que Lokad n’ait pas accès aux systèmes informatiques de nos clients ; le système informatique du client ne doit qu’envoyer et recevoir des données depuis Lokad. Cette approche vise à réduire la possibilité qu’un événement de sécurité chez Lokad se propage au système informatique du client. De plus, nous recommandons vivement l’utilisation d’un processus SSO (single sign-on), car il élimine le scénario hypothétique dans lequel un mot de passe utilisé pour accéder à Lokad serait intercepté (d’une manière ou d’une autre) et ensuite utilisé pour compromettre l’un des systèmes informatiques du client.

1.12 Comment sécurisez-vous votre réseau ?

Notre conception adopte une architecture Zero Trust, c’est-à-dire qu’elle ne permet l’accès aux données qu’aux bonnes personnes à un moment donné. Le simple fait d’être présent sur notre réseau ne confère pas automatiquement un statut ou des privilèges (ce point est développé dans Authentication 2.1). Ainsi, tout en étant vigilants quant à la sécurité du réseau, nous veillons – en première étape – à réduire au maximum la surface d’attaque associée à nos réseaux.

Lokad utilise deux réseaux notables. Le premier est Microsoft Azure, qui héberge notre solution. La sécurité du réseau Microsoft Azure est entièrement déléguée à Microsoft. Nous n’utilisons pas de capacités réseau « avancées » – telles que celles offertes par Microsoft Azure – au-delà des équilibreurs de charge de base.

Le second est le réseau local de notre siège à Paris. La sécurité du réseau local est gérée en interne par l’équipe d’ingénierie de Lokad. Notre réseau local n’héberge aucun composant ou système qui contribue à l’environnement de production.

1.13 Garantissez-vous que tous les composants (y compris ceux de tiers) et outils (y compris les outils open source) intégrés dans la solution sont légalement valides pour un usage en développement et en production ?

Oui. Comparé à la plupart des fournisseurs de logiciels d’entreprise, Lokad a très peu de dépendances. Toutes nos principales dépendances sont des projets open source crédibles et largement utilisés (ex : .NET de Microsoft, React de Facebook). Cela rend notre processus d’audit interne sur ce point relativement simple.

1.14 Comment gérez-vous les changements majeurs dans l’organisation et les processus en termes de sécurité ?

Comme Lokad a adopté dès le départ des choix de conception et des pratiques de sécurité pertinents, il est rare qu’un changement, qu’il soit mineur ou majeur, ait un impact sur la sécurité (même hypothétiquement). Dans toute l’histoire de Lokad, il n’existe que 3 événements pouvant être considérés comme véritablement significatifs du point de vue de la sécurité : la migration vers Microsoft Azure en 2010 ; l’introduction de l’authentification déléguée en 2012 (pour les clients comme pour les employés) ; et, en interne chez Lokad, la migration de Google Authentication vers Microsoft Azure AD en 2022.

Pour chacun de ces événements, la migration avait été préparée plusieurs mois à l’avance par l’équipe de développement logiciel de Lokad. Des supports et sessions de formation pertinents avaient été mis en place avant le changement programmé, afin d’assurer la préparation de tous les employés de Lokad. Enfin, après chaque événement de migration, nous nous sommes assurés que l’ancienne « voie » était éliminée, conformément aux pratiques standards de Lokad.

À partir de janvier 2023, nous n’avons prévu aucun changement majeur à venir. Si un tel changement devait être introduit, nous procéderions presque certainement de la même manière.

1.15 Comment gérez-vous la fin d’un contrat ?

Nos accords détaillent le processus de résiliation à la fin d’un contrat, tel que convenu avec le client. Le processus de résiliation se termine par la suppression définitive des données du client. Comme ce processus de résiliation représente en lui-même un risque de sécurité, ce point fait l’objet d’une discussion avec chaque client et peut donc varier légèrement selon le cas. Du point de vue de la sécurité, un acteur mal intentionné pourrait tenter de se faire passer pour le client afin de déclencher une résiliation anticipée du contrat (et ainsi perturber les opérations du client). Pour éviter cela, Lokad et le client s’efforcent conjointement d’adopter un processus – contractuellement imposé – qui n’est pas vulnérable de manière triviale à une attaque d’ingénierie sociale. Ce processus implique généralement des confirmations écrites et un délai obligatoire.

1.16 Quelle est la stratégie de licence de Lokad, le modèle de coûts associé, et le modèle de coûts de maintenance annuel ?

Lokad facture généralement des frais mensuels fixes associés au coût d’exploitation de la plateforme, ainsi qu’un forfait mensuel fixe lié au service fourni par les Supply Chain Scientist dédiés au client (c’est-à-dire les ingénieurs fournis par Lokad). Les détails sont négociés et précisés dans le contrat de service entre le client et Lokad. Ces deux frais représentent un forfait « tout compris » avec Lokad. Il n’y a pas de frais supplémentaires de maintenance, de licence, d’intégrateurs tiers, de consultants tiers, etc. Le forfait comporte des limites, tant en termes de portée que d’échelle, négociées conjointement dans le cadre de l’accord contractuel pour le service.

1.17 Pouvez-vous fournir les termes et conditions de Lokad pour la ou les licences, les services, le support, la maintenance et les formations ?

Oui, sur demande du client, nous pouvons fournir un modèle contractuel qui représente un accord « de base ». Cependant, les situations varient considérablement en fonction de l’ampleur de l’initiative supply chain, des pays concernés et de l’étendue des services attendus par Lokad. Ainsi, si possible, nous préférons engager une discussion initiale avec un client potentiel, afin de clarifier les spécificités de l’initiative supply chain envisagée. Cela nous aide à élaborer le cadre contractuel le plus pertinent pour la situation.

1.18 Fournissez-vous des formations (en présentiel/en e-formation) ?

Oui, Lokad propose des formations à la fois en présentiel et à distance. Les détails de ces sessions sont négociés dans le cadre du contrat. De plus, Lokad dispose d’une documentation technique publique étendue (public technical documentation) ainsi que d’une série détaillée de conférences supply chain. Ces conférences couvrent la technologie de Lokad et sa perspective sur la supply chain.

1.19 Le système de Lokad répond-il aux normes légales/locales pertinentes (c.-à-d. ISO) ?

Oui, Lokad opère conformément aux normes pertinentes. Cependant, Lokad propose une optimisation prédictive de la supply chain, et en tant que telle, Lokad ne contrôle pas directement les opérations. Notre influence est largement indirecte, généralement par l’optimisation de l’allocation des ressources. Ainsi, les normes ISO ne sont pas pertinentes ici (c.-à-d. non applicables à Lokad).

1.20 Existe-t-il une protection contre les logiciels malveillants intégrée au niveau du réseau, par exemple sur les pare-feux, les dispositifs proxy et/ou sur le réseau en tant que solutions distinctes ?

Voir Practices 1.12

1.21 Le processus de développement logiciel intègre-t-il une évaluation des menaces ?

Oui. C’est la principale raison pour laquelle nous privilégions l’approche de la sécurité « by design ». En éliminant des catégories entières de menaces dès la phase de conception, nous rendons la pratique globale de l’évaluation des menaces plus gérable. L’évaluation des menaces couvre également les « attaques supply chain ». C’est une autre raison pour laquelle nous mettons un accent particulier sur la réduction au minimum des dépendances tierces dans notre pile logicielle, car toute dépendance augmente inherently la surface d’attaque.

1.22 Le processus de gestion des incidents est-il répété au moins une fois par an ?

Oui. Il existe de nombreux types d’incidents. L’un des plus fréquents est que l’entreprise cliente elle-même soit compromise. En cas de ransomware, cela conduit parfois à ce que les données de Lokad deviennent accidentellement le seul ensemble de données encore accessible. Dans les cas de vol d’identité, cela conduit parfois à des tentatives d’accès au compte Lokad via des identifiants volés. Les détails des divers processus de gestion des incidents sont établis conjointement avec l’entreprise cliente et sont généralement supervisés par le Supply Chain Scientist de Lokad en charge du compte (pour les clients optant pour un compte géré).

1.23 La cartographie des risques et des menaces est-elle revue au moins une fois par an ?

Oui, bien que ces revues soient généralement effectuées régulièrement tout au long de l’année. De telles revues sont souvent motivées par des événements significatifs, tels que des violations de sécurité notables dans l’industrie logicielle.

1.24 L’évaluation des risques est-elle également effectuée sur les fonctions de support pouvant impacter la disponibilité, la qualité et/ou la sécurité de la solution ?

Oui. Cependant, la plateforme Lokad est essentiellement un monolithe qui ne repose sur aucune « fonction de support » à part quelques fondamentaux de base, tels que le Blob Storage et les machines virtuelles Linux fournies par Microsoft Azure.

1.25 Des comptes système dédiés - avec uniquement les droits d’accès requis - sont-ils créés pour exécuter les processus système ?

Oui, des comptes système dédiés avec des droits d’accès appropriés sont utilisés pour exécuter les processus système. Lokad utilise des démons sous forme de services systemd, qui s’exécutent toujours sous des utilisateurs avec le minimum de privilèges possible.

Bien que Lokad n’utilise pas de base de données SQL, la plateforme utilise un système basé sur les rôles pour définir les droits d’accès aux processus planifiés et déclenchés. Ces processus sont catégorisés comme des processus « userland » plutôt que « système ».

1.26 Existe-t-il un plan de gouvernance des risques formalisé, approuvé par la direction, qui définit les exigences du programme de gestion des risques d’entreprise ?

Oui, nous disposons d’un plan de gouvernance des risques formalisé qui a été approuvé par la haute direction.

Ce plan décrit les exigences et les lignes directrices de notre programme de gestion des risques d’entreprise (ERM). Il est conçu pour identifier, évaluer, gérer et surveiller les risques à l’échelle de l’entreprise de manière structurée et cohérente.

Notre plan de gouvernance des risques est périodiquement revu et mis à jour afin de garantir qu’il demeure pertinent et en adéquation avec nos objectifs organisationnels ainsi que l’évolution du paysage des risques. De plus, la mise en œuvre et l’efficacité du programme ERM sont régulièrement rapportées à la haute direction et aux parties prenantes concernées pour assurer une surveillance et un soutien continus.

1.27 Existe-t-il un programme de sécurité physique approuvé par la direction, communiqué aux parties prenantes, et pour lequel un responsable a été désigné pour le maintenir et le revoir ?

Oui, nous disposons d’un programme complet de sécurité physique qui a été approuvé par la haute direction. Ce programme a été communiqué de manière exhaustive à tous les constituants concernés afin d’assurer la sensibilisation et le respect des consignes.

De plus, nous avons désigné un responsable chargé de maintenir, mettre à jour et réviser périodiquement le programme afin d’en assurer l’efficacité et la pertinence. Ce responsable collabore avec diverses équipes et départements pour traiter toute préoccupation émergente en matière de sécurité physique et veille à ce que le programme soit en adéquation avec les meilleures pratiques et nos objectifs organisationnels.

1.28 Des évaluations des risques physiques et environnementaux sont-elles effectuées avant de déterminer l’emplacement ou le site d’une installation où résident les systèmes ?

Oui, les évaluations des risques physiques et environnementaux font partie intégrante de notre processus de prise de décision lors du choix de l’emplacement ou du site d’une installation pour nos systèmes. Étant donné que nos systèmes résident dans les centres de données de Microsoft Azure, nous bénéficions du rigoureux processus de sélection et d’évaluation des sites de Microsoft. Microsoft Azure réalise des évaluations approfondies des risques potentiels, y compris des risques physiques et environnementaux, avant d’établir l’un de ses centres de données. Leur processus de sélection implique l’analyse de facteurs tels que le potentiel de catastrophes naturelles, l’accessibilité, la stabilité des infrastructures, et plus encore.

En tirant parti des centres de données Azure, nous sommes convaincus que ces évaluations ont été menées de manière exhaustive afin d’assurer les plus hauts niveaux de sécurité physique et de résilience environnementale pour nos systèmes.

1.29 Existe-t-il un programme interne documenté de conformité et d’éthique ?

Oui, bien que nous ne croyions pas que l’« éthique » puisse être imposée de manière descendante. Ce type d’approche produit invariablement des résultats indésirables qui vont à l’encontre des objectifs initiaux.

Célèbrement, Enron possédait un code d’éthique écrit. Ce code mettait l’accent sur le respect, l’intégrité, la communication et l’excellence. Le scandale Enron, qui a éclaté en 2001, a révélé que l’entreprise avait été impliquée dans une fraude comptable massive, ce qui était – évidemment – en contradiction avec les principes énoncés dans son code d’éthique. Il y avait, par conséquent, un décalage total entre l’éthique professée et écrite d’Enron et ses pratiques commerciales réelles ainsi que sa culture d’entreprise.

Ainsi, Lokad se concentre sur le fait que les employés aient réellement à cœur le bien-être de nos clients. « Faisons-nous les choses correctement ? » est l’un de nos mantras. La conformité et l’éthique sont, selon nous, les sous-produits d’une culture d’entreprise adéquate, et non le résultat d’un programme particulier.

1.30 Existe-t-il un département d’audit interne, de gestion des risques ou de conformité, ou une fonction de supervision similaire, chargé(e) de suivre la résolution des problèmes réglementaires ou de conformité en suspens ?

Oui. Bien que Lokad ne soit pas assez grande pour disposer d’un département autonome dédié aux audits internes, à la gestion des risques ou à la conformité, nous accordons une grande priorité à ces domaines. Nous avons désigné des personnes ayant une expertise dans ces domaines, spécifiquement chargées de gérer et de superviser ces responsabilités essentielles.

Ces individus rendent directement compte à la couche supérieure de direction de Lokad, garantissant que la résolution de tout problème réglementaire ou de conformité en suspens soit traitée avec la plus haute priorité et bénéficie de la supervision nécessaire au plus haut niveau de notre organisation.

1.31 Existe-t-il une politique ou un programme sans fil approuvé par la direction, communiqué aux parties prenantes appropriées, et pour lequel un responsable a été désigné pour en assurer la maintenance et la révision ?

Oui, Lokad dispose d’une politique sans fil bien définie, approuvée par la direction et communiquée à tous les acteurs concernés afin d’en garantir le respect. Cette politique distingue deux réseaux Wi-Fi indépendants et isolés : un dédié aux employés et un autre spécifiquement aux visiteurs. Cette distinction permet de garantir que nos opérations principales restent sécurisées, même lorsque nous fournissons une connectivité pour des invités ou des visiteurs.

Cependant, il est important de noter que notre mode de connexion principal est l’Ethernet, privilégié pour sa performance supérieure et sa sécurité renforcée. Les réseaux Wi-Fi sont essentiellement mis en place pour faciliter les réunions et offrir une flexibilité dans certains scénarios.

De plus, nous avons désigné un responsable pour la politique qui est chargé de sa maintenance et de sa révision périodique, veillant ainsi à ce qu’elle reste à jour et efficace pour répondre aux besoins et défis évolutifs.

2. Authentification

2.1 Exigez-vous une authentification pour tous les accès ?

Oui. Pour accéder aux données clients et/ou à toute fonctionnalité importante de la solution, une authentification préalable est requise. Toutefois, par nécessité, certains points de contact ne font pas l’objet d’une authentification. Par exemple, l’accès à la page de connexion ne nécessite pas d’authentification préalable (puisque l’authentification est précisément l’objet de cette page de connexion).

Dans l’ensemble, très peu de points d’accès techniques ne nécessitent pas d’authentification, et ils font généralement partie de l’instrumentation de la plateforme (ex : un point d’accès utilisé uniquement pour vérifier qu’une machine est opérationnelle). Il convient de noter que les points d’accès non authentifiés n’exposent aucune donnée sensible, et encore moins des données clients réelles.

2.2 Exigez-vous que tous les accès à distance soient sécurisés ? Appliquez-vous le HTTPS pour les connexions web ?

Oui. Sécuriser les accès à distance signifie mettre en place la bonne authentification, la bonne autorisation et le chiffrement du canal de transport lui-même – autant d’éléments que nous appliquons. Cette disposition concerne aussi bien les utilisateurs clients que les employés de Lokad. Même pour l’équipe d’ingénierie de Lokad, il n’existe aucun « accès local non sécurisé » à nos systèmes de production. Nous n’utilisons aucun type de « localité » réseau comme échappatoire en matière de sécurité.

2.3 Proposez-vous le SSO (Single Sign-On) ? Prenez-vous en charge Active Directory (AD) ?

Oui. Nous proposons le SSO (Single Sign-On) via le protocole SAML. Active Directory supporte SAML et peut être utilisé pour accéder à Lokad.

2.4 Prenez-vous en charge l’authentification à deux facteurs comme EZToken, Google Authenticator ou Microsoft Authenticator ?

Oui. L’authentification à deux facteurs est réalisée via l’authentification déléguée par SAML. Grâce à SAML, Lokad ne gère ni le premier ni le second facteur d’authentification, ce processus étant délégué.

2.5 Prenez-vous en charge le protocole d’authentification OAuth2 ?

Par défaut, Lokad prend en charge le protocole d’authentification SAML. Ce protocole est supporté par les principaux systèmes d’identité fédérés, tels que Microsoft Office 365 ou Google Workspace. Le défi d’intégrer OAuth2 réside dans le fait qu’OAuth2 n’est en réalité pas un « protocole d’authentification » à proprement parler, mais un ensemble de directives très étendues pour concevoir des « protocoles d’authentification » pouvant diverger de dizaines de façons.

En conséquence, nous constatons que les différentes implémentations d’OAuth2 existant dans le domaine des logiciels d’entreprise tendent à être largement incompatibles. Ainsi, si OAuth2 est une exigence absolue, selon l’accord contractuel, nous pouvons prendre en charge une variante spécifique d’OAuth2. Toutefois, cette configuration nécessite des ressources dédiées pour garantir la compatibilité avec la variante OAuth2 utilisée par l’entreprise cliente.

2.6 Prenez-vous en charge l’intégration LDAP ?

Oui, via un middleware qui superpose SAML à LDAP. Toutefois, la majorité des systèmes d’identité fédérés supportant LDAP prennent également en charge SAML. Ainsi, nous recommandons d’utiliser directement SAML.

2.7 Imposer-vous l’authentification à deux facteurs ?

Pour les employés de Lokad, oui. Pour les employés du client, nous le recommandons fortement, mais en fin de compte, nous ne pouvons l’imposer (puisque l’authentification est généralement déléguée via le SSO). Cette question relève du service informatique de notre client, et non du nôtre.

2.8 Pouvez-vous imposer une complexité minimale des mots de passe ?

Oui, mais dans une mesure limitée. En ce qui concerne la sécurité logicielle, imposer une complexité minimale des mots de passe est désormais largement reconnu comme une mauvaise pratique. Les utilisateurs réagissent mal (et de façon prévisible) à des exigences de complexité de mot de passe trop strictes, ce qui nuit au niveau général de la sécurité. De plus, nous considérons ces exigences comme du « bloatware » qui augmente la complexité d’un logiciel critique pour la sécurité (la gestion des mots de passe), l’exposant ainsi (ainsi que l’ensemble de la solution) à des risques indus. Voir https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Nous recommandons vivement l’utilisation du SSO plutôt que des mots de passe ou stratégies traditionnels. Grâce au SSO, il n’est pas nécessaire d’introduire un mot de passe dédié à Lokad.

2.9 Pouvez-vous imposer des rotations de mots de passe programmées ?

Nous pourrions le faire, mais nous ne le faisons pas. Tout comme la complexité minimale des mots de passe (voir Authentification 2.8), les rotations de mots de passe programmées sont désormais largement reconnues comme une mauvaise pratique en matière de sécurité logicielle. Les utilisateurs réagissent mal (et de manière prévisible) aux rotations de mots de passe programmées. La sécurité peut même être affaiblie, car les employés ne font souvent que des modifications mineures aux mots de passe (afin de réduire la charge cognitive associée aux rotations fréquentes). Comme pour la complexité minimale des mots de passe, nous considérons la rotation des mots de passe comme du « bloatware » qui augmente la complexité d’un logiciel critique pour la sécurité (la gestion des mots de passe), l’exposant ainsi (ainsi que l’ensemble de la solution) à des risques indus. Voir https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hasherez-vous et salez-vous les mots de passe ?

Oui. Nous utilisons scrypt comme fonction de hachage des mots de passe. En règle générale, nous recommandons vivement d’utiliser le SSO au lieu d’utiliser des mots de passe ou stratégies traditionnels. Grâce au SSO, il n’est pas nécessaire d’introduire un mot de passe dédié à Lokad.

2.11 La solution de Lokad active-t-elle un CAPTCHA après un nombre défini d’échecs d’authentification ?

Oui, bien que l’authentification soit déléguée (via SSO). Bien que les CAPTCHA soient une approche précieuse pour atténuer certains vecteurs d’attaque, ils appartiennent à la catégorie des composants logiciels qu’il vaut mieux laisser entièrement en dehors du périmètre d’une solution d’optimisation de la supply chain telle que celle de Lokad. De plus, la valeur ajoutée des CAPTCHA dans le contexte des logiciels d’entreprise est moins évidente que pour les logiciels B2C, en particulier les freeware.

2.12 Avez-vous une politique de sécurité générale pour les mots de passe ? Avez-vous un processus pour la faire respecter ?

Oui. Notre politique générale de sécurité pour les mots de passe est « pas de mots de passe ». Nous recommandons vivement le SSO, qui élimine la nécessité d’introduire des mots de passe dédiés à Lokad.

2.13 Centralisez-vous la gestion des utilisateurs ?

Oui. Lokad dispose de sa propre gestion centralisée des utilisateurs pour la solution que nous exploitons. Ce sous-système a été implémenté par Lokad et couvre également les accès des employés de Lokad, y compris nos équipes d’ingénierie.

2.14 Autorisez-vous des comptes utilisateurs génériques/partagés ?

Non. Lokad impose une relation 1-à-1 entre les employés et les utilisateurs (telle que perçue par la plateforme Lokad). Nous déconseillons fortement l’utilisation de comptes utilisateurs partagés. En fait, l’une des raisons pour lesquelles nous ne facturons pas par utilisateur est d’éviter d’inciter nos clients à partager des comptes utilisateurs entre leurs employés. Cependant, il existe quelques cas où il est acceptable d’avoir un compte utilisateur sans employé correspondant. Cela se produit typiquement pour le service « robot upload » côté client chargé de transmettre des données à Lokad. Dans le cadre de notre RBAC (contrôle d’accès basé sur les rôles), nous disposons d’un rôle dédié (appelé « uploader ») qui offre des droits minimaux pour ce cas d’utilisation unique.

2.15 Proposez-vous des connexions VPN sécurisées ?

Non. Les connexions des utilisateurs finaux se font via des canaux chiffrés (généralement TLS).

2.16 Autorisez-vous les utilisateurs à se connecter depuis plusieurs appareils ?

Oui, dans certaines limites. En général, la limite maximale est de 6 appareils par utilisateur (nous ne facturons pas l’utilisation de plusieurs appareils). Chaque session est limitée à une seule adresse IP. Lokad se réserve toutefois le droit de modifier cette limite afin de contrer certaines menaces potentielles et/ou abus.

2.17 La solution a-t-elle la capacité de verrouiller et/ou de déconnecter de force un utilisateur (en cas de comportement malveillant) ?

Oui. Cette fonctionnalité nécessite des droits d’accès « Owner » au sein du compte Lokad.

2.18 Le système déconnecte-t-il automatiquement un utilisateur inactif après une période d’inactivité spécifiée ?

Oui, bien que l’« inactivité » ne soit pas le facteur principal. Lokad déconnecte automatiquement les utilisateurs après un certain temps. Les utilisateurs ne peuvent pas retarder la déconnexion en restant « actifs » ; une fois le délai écoulé, ils doivent se réauthentifier.

2.19 L’utilisation de comptes et/ou d’informations d’authentification partagés est-elle interdite et la conformité à ces politiques est-elle contrôlée ?

Oui. Voir Authentification 2.14.

2.20 Les identifiants d’utilisateur et les mots de passe sont-ils communiqués/distribués via des supports séparés (par exemple, e-mail et téléphone) ?

Oui, nous accordons la priorité à la sécurité des informations d’identification des utilisateurs et nous veillons à ce qu’elles soient communiquées de manière conforme aux meilleures pratiques. En interne, nos systèmes utilisent Azure Active Directory pour l’authentification des utilisateurs. Lorsque les identifiants et mots de passe initiaux sont distribués, Azure Active Directory suit ses schémas par défaut, conçus dans une optique de sécurité. De plus, nous appliquons une authentification à deux facteurs pour notre Azure AD, ajoutant une couche supplémentaire de sécurité au processus d’authentification.

Pour les employés clients se connectant à nos systèmes, nous recommandons vivement l’utilisation du Single Sign-On (SSO) et des systèmes d’identité fédérés. Ces systèmes, par conception, prennent en charge les meilleures pratiques en matière de gestion des informations d’identification, garantissant que celles-ci soient communiquées de manière sécurisée, souvent en recourant à des canaux de communication ou des méthodes distincts pour les identifiants utilisateurs et les mécanismes d’authentification.

Il convient de noter que nous ne recommandons pas l’authentification à facteur unique, que ce soit pour les utilisateurs internes ou externes, si l’objectif est de maintenir un niveau de sécurité élevé.

2.21 Les identifiants des utilisateurs inactifs sont-ils désactivés et supprimés après des périodes d’inactivité définies ?

Oui, nous gérons et surveillons activement les identifiants des utilisateurs pour garantir la sécurité. Pour les employés de Lokad, notre politique impose que tous les droits d’accès soient révoqués dès leur dernier jour de travail, garantissant ainsi qu’aucun accès postérieur à l’emploi n’est accordé aux anciens employés.

Pour nos clients, nous préconisons l’utilisation du Single Sign-On (SSO) et des systèmes d’identité fédérés. Cette approche simplifie la gestion des accès. Par exemple, lorsqu’un client supprime un employé de son système d’identité, l’accès à Lokad est simultanément résilié. Cette méthode permet non seulement d’améliorer la sécurité, mais aussi d’assurer une gestion efficace des utilisateurs.

Note : les détails relatifs à la résiliation de l’accès des utilisateurs sont précisés dans nos accords contractuels avec chaque client. Lokad reconnaît fermement l’impact opérationnel potentiel de la désactivation prématurée d’un compte et prend des mesures actives pour éviter de tels scénarios. Afin d’éviter des perturbations involontaires, les conditions de résiliation de l’accès utilisateur sont explicitement définies, soit dans le contrat, soit dans une procédure convenue conjointement, garantissant que les mesures de sécurité de Lokad s’alignent sur les besoins opérationnels de nos clients.

3. Autorisation

3.1 La solution offre-t-elle des droits d’accès granulaires ?

Oui. La solution Lokad inclut un sous-système RBAC (contrôle d’accès basé sur les rôles) granulé. Cela permet au client de contrôler quels « Projects » et « Files » sont accessibles (et par qui) dans le compte Lokad. Le RBAC dispose de sa propre interface web (tableau de bord). Il est accessible à tous les utilisateurs ayant la désignation « Owner » au sein du compte Lokad. Consultez notre documentation user roles and permissions pour plus d’informations.

3.2 La solution permet-elle au client de configurer les accès conformément au principe du moindre privilège (PoLP) ?

Oui. La solution Lokad inclut un sous-système RBAC (contrôle d’accès basé sur les rôles) granulé qui peut être utilisé pour mettre en œuvre le principe du moindre privilège. Cependant, grâce à Envision (le DSL de la solution), Lokad va bien au-delà de la plupart des logiciels d’entreprise en ce qui concerne ce principe.

Grâce à Envision, Lokad a éliminé des ensembles entiers de privilèges système qui sont tout simplement hors de propos pour l’optimisation de la supply chain. Ce qui reste est simplifié, tout en restant largement configurable. De même, le système de fichiers sur mesure proposé par Lokad élimine également des groupes entiers de privilèges système inutiles.

3.3 Imposer-vous des droits d’accès basés sur le moindre privilège ?

Oui, bien que ce qui constitue le privilège le « moins acceptable » soit en définitive décidé par nos clients. Lokad ne peut pas déterminer unilatéralement qui bénéficie de la désignation « Owner » parmi le personnel de notre client. Cependant, nous pouvons fournir des conseils à cet égard. En pratique, pour nos clients « managed » – ceux qui sont supportés par l’équipe de Supply Chain Scientists de Lokad – nous clarifions (par écrit) l’organisation souhaitée et les droits d’accès correspondants.

3.4 La solution a-t-elle la capacité de masquer une entité particulière dans le système pour certains utilisateurs désignés ?

Oui. Il s’agit d’une forme de mise en œuvre du PoLP et est couvert dans les réponses 3.1, 3.2 et 3.3.

3.5 Disposez-vous d’une classification pour les données (niveaux de sensibilité) et de contrôles adaptés à cette classification ?

Oui. En tant qu’élément intégré, Lokad restreint par défaut toutes les données administratives (comme la liste des utilisateurs possédant un compte) aux « Owners » du compte. Cette désignation est la plus élevée et la plus privilégiée dans le RBAC (contrôle d’accès basé sur les rôles). Toutes les autres données au sein du compte Lokad peuvent être segmentées selon une classification de sensibilité définie par l’utilisateur. Cette classification définie par l’utilisateur peut être appliquée à la fois aux données originales (telles que téléchargées par le client) et aux données transformées (le résultat des transformations de données effectuées au sein de la plateforme de Lokad).

Pour plus d’informations sur les contrôles d’accès et les désignations, veuillez consulter les réponses 3.1, 3.2 et 3.3.

3.6 La solution peut-elle autoriser ou bloquer les utilisateurs/rôles/transactions en temps réel?

Oui, bien que “en temps réel” nécessite une clarification dans le contexte d’un système informatique distribué (comme la solution Lokad). Les mises à jour du RBAC (Role-Based Access Control) se font de manière synchrone, ce qui signifie que les modifications deviennent actives en quelques secondes (généralement moins). Il n’y a aucun délai perceptible (tel qu’une attente d’une heure ou d’une journée).

Quant à l’interruption des transactions, cela n’est pas pertinent puisque Lokad ne dispose pas d’une base de données transactionnelle. Cela dit, Lokad peut interrompre les opérations asynchrones de longue durée (appelées chez Lokad “Project runs”). Lorsqu’une interruption est déclenchée, elle garantit immédiatement (de manière synchrone) que le traitement n’affectera pas le système, par exemple en écrasant des fichiers. Cependant, l’arrêt du traitement est asynchrone et prend généralement effet en 20 secondes.

3.7 La solution restreint-elle l’accès aux Personal Identifiable Information (PII) uniquement aux utilisateurs disposant du bon niveau de permission?

Oui, bien que la solution ne soit pas destinée à contenir de données PII (au-delà des identifiants d’authentification des employés ayant accès à la solution). C’est le cas tant pour Lokad que pour le client. Au sein de la solution, seuls les employés désignés “Owner” ont accès à la liste des utilisateurs. Pour l’optimization de la supply chain, Lokad n’a pas besoin (et ne bénéficie pas) des données PII, et nous avons des stipulations contractuelles à cet effet (expliquées dans Practices 1.4 & Practices 1.5).

Pour plus d’informations sur les contrôles d’accès et les désignations, veuillez consulter les réponses 3.1, 3.2 et 3.3.

3.8 La solution permet-elle aux filtres de recherche de données PII d’interdire les recherches par caractères génériques?

Oui. Cependant, un utilisateur désigné “Owner” dans un compte Lokad peut accéder à tous les utilisateurs (y compris le personnel du client) autorisés à accéder au compte. Lokad ne peut pas restreindre cette capacité puisque nos clients doivent être en mesure d’auditer, dans leur intégralité, la liste des utilisateurs ayant accès à leur propre compte.

3.9 Le système est-il équipé de la technologie WAF (Web Application Firewall)?

Non. Le WAF est une conception intrinsèquement dangereuse car elle viole le principe du “least privilege” : un composant se voit accorder d’énormes privilèges afin de fonctionner en tant qu’“man in the middle”. Cela fait du WAF une cible privilégiée pour les attaquants et étend considérablement la surface d’attaque de la plateforme. Toutefois, Lokad surveille de près son trafic web et les comportements anormaux des utilisateurs sur notre propre plateforme. Ces capacités font néanmoins partie intégrante de la plateforme et ne sont donc pas déléguées à des composants logiciels tiers isolés et privilégiés.

Voir aussi Employees 6.6.

3.10 Le réseau est-il équipé de la technologie IPS (Intrusion Prevention System)?

Non. L’IPS est une conception intrinsèquement dangereuse car elle viole le principe du “least privilege” : un composant se voit accorder d’énormes privilèges afin de fonctionner en tant qu’“man in the middle”. Cela fait de l’IPS une cible privilégiée pour les attaquants et étend considérablement la surface d’attaque de la plateforme. Afin de renforcer la plateforme Lokad contre les intrusions, notre conception commence par minimiser la surface d’attaque. Nous estimons qu’il est bien plus sûr d’éliminer les voies d’intrusion par conception, plutôt que d’essayer de les “prévenir” a posteriori.

Voir aussi Employees 6.6.

3.11 Le service utilise-t-il la technologie de protection contre les attaques DoS (Denial-of-Service)?

Oui. Lokad utilise ReCaptcha, les limites de taux d’nginx, ainsi que ses propres composants spécifiques (tels que l’early-fail lorsque l’authentification est invalide).

3.12 Tout accès administratif à l’environnement de production se fait-il via des jump hosts ou des bastion servers?

Oui. Nous disposons d’un système essentiellement similaire à «Teleport». Cela offre non seulement une traçabilité complète de tous les accès, mais facilite également la révocation sécurisée des droits d’accès des employés.

3.13 Existe-t-il un processus clair d’autorisation pour accorder un accès administratif (et qui produit une piste d’audit fiable)?

Oui. Voir Logging and Monitoring 5.1 et 5.11.

3.14 Existe-t-il un processus systématique et régulier de révision des droits d’accès (effectué par une personne autorisée), dans lequel les droits d’accès administratifs sont vérifiés par rapport à tous les rôles et responsabilités modifiés?

Oui. Il existe deux niveaux de droits d’accès administratifs.

Premier niveau: les droits administratifs pour supporter l’infrastructure de Lokad. Ces droits sont accordés et surveillés par la division informatique de Lokad.

Second niveau: les droits d’accès administratifs au sein de chaque compte Lokad. Ces droits sont accordés et surveillés par le Supply Chain Scientist en charge du compte – pour nos comptes gérés. Alternativement, ces droits sont accordés et surveillés par la société cliente elle-même si le compte n’est pas géré directement par Lokad/a Supply Chain Scientist.

3.15 Votre politique de restriction d’accès suit-elle le principe du “least privilege”, où seul le trafic nécessaire et approuvé est autorisé?

Oui. Nous appliquons le principe du moindre privilège (PoLP) à tous les niveaux d’accès de notre infrastructure, y compris au trafic réseau. La sévérité des restrictions d’accès varie selon les cas d’utilisation. Par exemple, pour certains accès, un utilisateur spécifique, authentifié et provenant d’une adresse IP déterminée, est le seul autorisé. Dans d’autres cas, n’importe qui, de n’importe où, peut accéder, comme c’est le cas pour le contenu de notre CDN (Content Delivery Network).

Voir aussi Authorization 3.3.

3.16 Les connexions sortantes depuis l’environnement de production sont-elles restreintes?

Non, les connexions sortantes depuis l’environnement de production ne sont pas restreintes de manière universelle. Alors que certains serveurs spécialisés, tels que les load balancers, disposent de restrictions sortantes, la majorité de nos serveurs n’en ont pas.

Nos VMs de production nécessitent un accès à de multiples API externes. Une grande partie de ces API est hébergée par Microsoft Azure, avec quelques exceptions comme letsencrypt.org. Nous avons déterminé que le maintien d’une liste blanche rigoureuse d’adresses IP introduirait des complexités susceptibles de compenser les avantages. Restreindre les connexions sortantes pourrait offrir des avantages de sécurité limités, mais pourrait également introduire des complications qui compromettent potentiellement la sécurité de notre environnement de production.

3.17 Existe-t-il une forme de communication avec du personnel (par exemple, e-mail, formulaire web, téléphone, etc.) disponible pour les clients 24/7/365 afin de signaler des incidents de sécurité?

Oui, nous avons mis en place la norme security.txt pour faciliter le signalement des incidents de sécurité.

L’approche security.txt est un modèle largement reconnu en sécurité web dans lequel un fichier texte spécifique est placé sur le site. Ce fichier détaille comment signaler les vulnérabilités de sécurité.

Notre fichier security.txt est accessible à l’adresse https://www.lokad.com/.well-known/security.txt et décrit le processus actualisé de signalement des incidents de sécurité. Cela garantit que toute personne - qu’il s’agisse d’un client, d’un utilisateur ou d’un chercheur en sécurité - puisse facilement trouver les coordonnées et directives pertinentes pour nous signaler ses préoccupations en matière de sécurité.

Veuillez noter que, bien que le processus détaillé dans le ‘security.txt’ puisse être révisé, l’information la plus récente et précise sera toujours disponible à ce point d’accès. Nous veillons à ce que les canaux de communication mentionnés dans le fichier, qu’il s’agisse d’e-mail, de formulaire web ou d’un autre moyen, soient dotés de personnel et disponibles 24/7/365 pour traiter rapidement les signalements de sécurité.

4. Gestion des données

4.1 Où hébergez-vous et traitez-vous les données?

Notre plateforme SaaS (Software as a Service) est hébergée à 100% sur Microsoft Azure ; plus précisément, elle est hébergée dans le centre de données Microsoft Azure Europe North (basé à Dublin). Nos sauvegardes sont stockées dans le centre de données Microsoft Azure Europe West (basé à Amsterdam). En cas de défaillance majeure d’un centre de données, nous disposons de plans de contingence pour migrer la plateforme à Dublin. Depuis notre migration vers Microsoft Azure en 2010, nous n’avons jamais rencontré cette situation. Toutes les données de nos clients résident en Europe, où elles resteront même en cas de défaillance majeure d’un centre de données.

4.2 À qui appartiennent les données?

Nos clients restent les seuls propriétaires de toutes les données qu’ils téléchargent sur Lokad. Ils demeurent également les seuls propriétaires de toutes les données qu’ils génèrent, via leur compte Lokad, sur la plateforme Lokad. Lokad n’utilise pas en interne les données des clients à des fins autres que celles qui contribuent directement aux tâches qui nous ont été confiées. Lokad ne revend pas (et ne revendra pas) l’accès aux données de ses clients à un tiers. Lokad ne partage pas l’accès aux données clients, à l’exception des quelques fournisseurs d’hébergement qui contribuent directement à la tâche concernée (ex : la location de machines virtuelles auprès d’une plateforme de cloud computing pour exécuter les calculs demandés par nos clients).

4.3 La gestion de la base de données est-elle effectuée en interne ou en externe?

La gestion de la couche de données de Lokad est assurée par les équipes d’ingénierie de Lokad. Comme mentionné précédemment, la plateforme centrale de Lokad n’inclut pas de base de données transactionnelle (voir Authorization 3.6), car Lokad utilise à la place un event store. Ce event store est mis en œuvre et exploité entièrement par Lokad.

4.4 La solution a-t-elle la capacité de basculer entre une base de données RDBMS (PostgreSQL, Oracle, MySQL) et une base de données NoSQL (Cosmos)?

Théoriquement, oui, mais cela est secondaire puisque la solution Lokad n’utilise pas de RDMBS. La couche de persistance des données de la solution Lokad s’appuie sur un event store et un key-value store. Cette approche diffère sensiblement du design CRUD (Create-Read-Update-Delete) couramment rencontré dans les logiciels d’entreprise. Étant donné que Lokad est une solution SaaS, nous assumons l’entière responsabilité de la persistance des données et de la compatibilité ascendante (afin de garantir que les anciennes données restent accessibles).

4.5 Des tiers sont-ils impliqués dans l’exploitation de la solution?

Oui, notamment la plateforme de cloud computing sous-jacente que Lokad utilise - Microsoft Azure. La liste des tiers impliqués dans l’exploitation de la solution est très courte et limitée à l’hébergement d’infrastructure de bas niveau. Lokad n’utilise pas de tiers pour développer, administrer ou exploiter sa propre solution. En particulier, nos équipes d’ingénierie et nos équipes de support technique sont internes.

4.6 Séparez-vous les couches (réseau, serveurs et applications)?

Oui, cependant la gestion des réseaux et des serveurs à bas niveau est déléguée à la plateforme de cloud computing sous-jacente que Lokad utilise - Microsoft Azure. Ainsi, la séparation des couches réseau et serveur se situe principalement en dehors du périmètre géré par Lokad. Au sein de la solution Lokad, nous restreignons fortement les privilèges accordés aux couches applicatives afin qu’elles ne puissent pas administrer leur propre infrastructure (ex : les couches applicatives n’ont aucun accès en écriture à la gestion du DNS).

4.7 Disposez-vous d’un processus pour garantir la suppression permanente des données?

Oui, bien que cela puisse prendre plusieurs semaines pour accomplir toutes les étapes. Le processus implique de faire une demande formelle par écrit - émise par une partie autorisée au sein de l’organisation cliente - pour que les données correspondantes soient définitivement supprimées. En pratique, des dispositions spécifiques à de telles demandes sont incluses dans l’accord contractuel entre Lokad et ses clients. Les données seront d’abord supprimées de notre système de production principal, puis de notre système de sauvegarde. Cette dernière étape explique la relative “lenteur” de l’opération. C’est un choix de conception, car une fois les données supprimées de notre système principal, elles ne pourront plus être accessibles (sauf via des processus extraordinaires de récupération après sinistre).

Par défaut, la solution Lokad s’assure que toutes les opérations de suppression standard sont des suppressions logiques (c’est-à-dire, non définitives). Cette conception est nécessaire pour éviter toute une catégorie de problèmes de sécurité, tels que la suppression accidentelle de données par un employé du client ou la suppression malveillante par un attaquant. De plus, un processus de suppression permanente intentionnellement lent est requis pour atténuer les attaques d’ingénierie sociale, comme dans le cas où un attaquant se ferait passer pour un employé du client.

4.8 La solution a-t-elle la capacité d’effectuer des suppressions logiques des données?

Oui. La solution Lokad adopte une conception basée sur l’event sourcing. Ainsi, tout est versionné par défaut, tant les entrées utilisateur que les modifications apportées au système de fichiers de Lokad. Par conséquent, toutes les suppressions effectuées par le logiciel sont des suppressions logiques, et elles peuvent être tracées et annulées, si nécessaire.

4.9 Proposez-vous un accès direct à la base de données?

Oui, dans le sens où le système de fichiers - qui fait partie de la solution Lokad - peut être accédé via des protocoles tels que FTPS et SFTP. Cet accès est étendu, dans la mesure où toutes les données, qu’elles soient utilisées comme entrées ou produites en sortie, sont stockées dans ce système de fichiers.

Cependant, comme Lokad ne dispose pas d’une base de données transactionnelle, il n’existe pas de base de données sous-jacente pouvant être rendue “accessible”. L’équivalent le plus proche dans l’architecture de Lokad est notre event store et nous n’offrons pas d’accès direct au flux d’événements. Toutefois, des dispositions pourraient être prévues dans l’accord contractuel si un client devait demander des extractions spécifiques de ce flux d’événements (à condition qu’il y ait un cas d’utilisation valable).

4.10. Comment la solution intègre-t-elle des données externes?

La solution peut utiliser plusieurs protocoles pour intégrer des données externes, notamment FTPS et SFTP. Une interface utilisateur web est également disponible pour télécharger manuellement des fichiers. La solution Lokad peut intégrer toute donnée tabulaire raisonnable. Pour en savoir plus sur les capacités d’intégration de données externes de Lokad, voir Go to IT Perspective on Lokad 2.15.

4.11 Le système a-t-il la capacité de gérer le CDC (Change Data Capture) à partir de flux de données en temps réel?

Oui, sous réserve d’un accord contractuel spécifique avec le client. Le CDC est un modèle de conception logiciel - et non une norme de données ou un protocole de transfert de données spécifique - et les attentes en terme de “temps réel” peuvent varier de latences inférieures à la milliseconde à celles inférieures à la minute. Les fonctionnalités dans ce domaine doivent être évaluées d’un point de vue supply chain. D’après notre expérience, les flux de données en temps réel sont rarement pertinents pour résoudre des problèmes de supply chain.

4.12 Toutes les données contenues dans la solution peuvent-elles être exportées?

Oui, toutes les données accessibles via le système de fichiers au sein du compte Lokad peuvent être exportées via des protocoles tels que FTPS ou SFTP.

4.13 La solution offre-t-elle des outils pour exporter les données?

Oui, la solution Lokad offre un DSL (langage spécifique au domaine) nommé Envision, conçu pour l’analyse de supply chain. Envision offre de vastes capacités pour reformater les données au sein du compte Lokad.

4.14 Quel sera le format des données exportées ?

La plateforme Lokad supporte tous les formats tabulaires courants, y compris CSV et XLS (Microsoft Excel). La plateforme prend en charge de nombreuses options concernant le format des nombres, des dates, des délimiteurs, du codage de texte, des en-têtes, etc.

4.15 La solution utilise-t-elle le chiffrement transparent des données (TDE) pour les données d’informations personnellement identifiables (PII) dans le stockage mobile et back-end ?

Le chiffrement transparent des données est utilisé à la fois sur le stockage back-end de Lokad (via le chiffrement Azure Storage pour les données au repos) et sur les appareils fournis par Lokad (via BitLocker). Lokad ne stocke pas de PII sur des appareils sans TDE activé.

4.16 Tous les mots de passe et secrets utilisés dans l’application sont-ils cryptés et non accessibles au format texte clair dans le code source, les fichiers de configuration, les paramètres de compilation, etc. ?

Oui. Tous les secrets de niveau plateforme sont stockés dans Key Vault, un service offert par Microsoft Azure. Les mots de passe utilisateurs sont salés et hachés en interne avec Scrypt, conformément aux pratiques standard.

4.17 La solution a-t-elle la capacité de restreindre les téléchargements de fichiers en fonction du type et de la taille des fichiers, et de scanner le contenu malveillant ?

Oui, dans une certaine mesure. En ce qui concerne la taille des fichiers, l’optimization de la supply chain requiert fréquemment le traitement de fichiers volumineux. Ces tailles de fichiers reflètent l’extraction des données historiques de l’entreprise que nous traitons finalement (ex : commandes de ventes historiques). Étant donné cette réalité, la plateforme Lokad supporte des fichiers allant jusqu’à 100GB.

En ce qui concerne le type de fichier, nous disposons d’une liste blanche d’extensions connues et de formats attendus. Dans le cas d’un cas d’utilisation valable, ce paramètre pourrait être ajusté. Cet ajustement serait reflété dans notre accord contractuel.

En ce qui concerne la capacité de scanner le contenu malveillant, Lokad ne possède pas cette fonctionnalité. Notre solution met l’accent sur le partage de contenu généré par la plateforme. De plus, la conception même que nous avons adoptée garantit que les fichiers générés dans Lokad sont sûrs, même si les fichiers d’entrée ne le sont pas. Inversement, par sa conception, la solution Lokad met moins en avant le partage de contenu téléchargé par les utilisateurs via Lokad.

4.18 Quelle est la période de rétention des données recommandée ?

Lokad est SaaS, ainsi, nous avons la responsabilité de choisir la période de rétention des données appropriée, et cette durée varie selon le type de données. Les données transactionnelles historiques, transmises à Lokad par le client via la pipeline d’extraction de données, sont généralement conservées pendant la durée du service Lokad. En effet, les données historiques valent généralement la peine d’être conservées pendant des périodes arbitrairement longues (en dehors des limites du service Lokad). À l’autre extrémité du spectre, il y a les données d’instrumentation, reflétant la performance fine de notre plateforme. Ces données ne sont utiles qu’à la résolution de problèmes de ralentissements inattendus au sein de la plateforme. Ces données sont extrêmement granulaires et ne sont généralement pas conservées pendant plus de quelques semaines.

4.19 Fournissez-vous une documentation de la structure des données ?

Oui, dans le cadre du “Joint Procedure Manual”. Il convient de noter que Lokad n’utilise pas de base de données relationnelle, contrairement à la plupart des logiciels d’entreprise. À la place, nous utilisons un paradigme d’event sourcing. Cependant, les structures de données qui intéressent (pour l’entreprise cliente) ne se trouvent pas dans la source d’événements, mais dans les fichiers plats produits via des scripts Envision dans la plateforme Lokad. Ces fichiers plats sont conçus pour correspondre aux exigences spécifiques de l’entreprise cliente. La documentation de ces fichiers est incluse dans le “Joint Procedure Manual” - qui est l’un des livrables d’une initiative typique de Lokad.

4.20 La segmentation des données d’autres clients fait-elle partie de la conception du système ?

Oui, bien que Lokad soit une application multi-locataire, les données sont séparées au niveau de la conception entre les locataires, c’est-à-dire les comptes clients. Ce partitionnement est un élément de premier ordre de notre conception back-end. Cette conception empêche les erreurs de programmation qui exposeraient les données d’un locataire à un autre, tout en développant d’autres fonctionnalités banales au sein de la plateforme. Le stockage sous-jacent principal utilisé par Lokad – Blob Storage de Microsoft Azure – facilite ce type de partitionnement strict au niveau de la conception.

4.21 Des mesures efficaces sont-elles prises pour s’assurer qu’aucune donnée client n’est utilisée dans les environnements de développement et de test ?

Oui, par défaut, l’équipe d’ingénierie logicielle n’a pas accès directement aux données des clients. Nous avons développé des environnements de données « mock » étendus et des jeux de données « mock » pour permettre à l’équipe d’ingénierie de fonctionner sans accès aux données des clients. Lokad utilise également en interne sa propre plateforme pour l’analyse des données (par exemple, l’analyse de la consommation fine des ressources de cloud computing obtenues de Microsoft Azure). Cette pratique de « dogfooding » assure que Lokad dispose également d’une abondance de données non critiques à utiliser pour le développement et les tests.

Cependant, nous avons conçu une pipeline restreinte spéciale pour accéder à des fragments minimaux (en lecture seule) des données client à des fins de diagnostic. Cette pipeline assure automatiquement une minimisation stricte et entièrement automatisée des données récupérées. Cette pipeline garantit également la suppression automatique des données à la fin de l’opération de diagnostic. Voir 4.22 pour plus de détails sur cette pipeline restreinte.

4.22 Si le développement ou les tests requièrent une utilisation limitée des données client, existe-t-il un processus défini pour garantir la destruction sécurisée et complète des données dans les environnements de développement et de test ?

Oui, nous avons conçu une pipeline de données spéciale (en lecture seule) dédiée à l’utilisation exceptionnelle des données client à des fins de diagnostic - généralement pour des tests de performance. Cette pipeline de données est accessible uniquement à une partie restreinte de l’équipe d’ingénierie logicielle.

Cette pipeline de données a été conçue pour minimiser automatiquement le fragment des données client récupérées pour le diagnostic concerné. Cette capacité nous permet de fonctionner avec ce qui constitue généralement une fraction très petite des données d’origine (telles qu’elles se trouvent dans le compte client). De plus, elle élimine le besoin pour l’équipe d’ingénierie de sélectionner manuellement les données à récupérer.

Enfin, cette pipeline de données supprime automatiquement les données récupérées à la fin de l’opération de diagnostic.

4.23 Tous les emplacements physiques des données client sont-ils connus et documentés, y compris les systèmes de sauvegarde et de haute disponibilité ?

Oui. Toutes les données client sont stockées dans les centres de données physiquement sécurisés de Microsoft Azure, y compris les sauvegardes. Nous ne conservons pas les données client localement (c’est-à-dire sur les locaux de Lokad), ni sur les appareils des employés.

4.24 L’accès aux emplacements physiques des serveurs est-il limité aux employés qui en ont besoin pour effectuer leur travail ?

Oui, bien que les données des clients de Lokad soient stockées dans les centres de données sécurisés de Microsoft Azure - un lieu auquel Lokad n’a pas accès physiquement. L’emplacement physique des centres de données de Microsoft est de notoriété publique, et le choix des centres de données par Lokad est documenté publiquement.

4.25 Le numéro de compte principal (PAN) est-il stocké uniquement si cela est absolument nécessaire à des fins commerciales légitimes ?

Lokad ne reçoit, ne stocke, ni ne gère aucun PAN client.

Le PAN (Primary Account Number) se réfère généralement au numéro principal sur une carte de crédit ou de débit. C’est la séquence de chiffres en relief ou imprimée sur la face d’une carte et utilisée pour identifier de manière unique le compte bancaire associé à la carte.

Pour traiter les paiements, nous nous appuyons exclusivement sur des tiers qui gèrent les PAN pour nous. Cependant, il faut noter que la majorité des transactions reçues par Lokad sont effectuées par virement bancaire, éliminant ainsi entièrement le problème de gestion des PAN.

Nous avons quelques PAN – pour les cartes de Lokad – que nous gérons de manière sécurisée, en suivant les directives fournies par les banques elles-mêmes.

4.26 Les numéros de compte principal (PAN) non chiffrés ne sont-ils jamais envoyés par les technologies de messagerie aux utilisateurs finaux (par exemple : par email, messagerie instantanée et chat) ?

Oui, les PAN non chiffrés (Primary Account Numbers) ne sont jamais envoyés par des canaux non sécurisés comme l’email. Lokad fournit un canal de communication sécurisé intégré à sa plateforme, qui est une alternative supérieure pour la transmission de matériaux sensibles. Nous recommandons ce canal chaque fois que l’utilisation d’un canal non sécurisé présente un risque commercial significatif.

Note: Par conception, Lokad ne reçoit, ne stocke, ni ne gère aucun PAN client. Ainsi, il n’existe aucun transfert de PAN non chiffré.

Voir aussi le stockage des PAN

4.27 Avez-vous un contrat en place avec votre ou vos fournisseur(s) de services de cloud computing et ce contrat contient-il des clauses relatives aux dispositions de sécurité de l’information du ou des fournisseur(s) de services de cloud computing ?

Oui, Lokad a un Enterprise Agreement (EA) en place avec Microsoft pour les services de cloud computing Azure. L’Enterprise Agreement inclut généralement diverses modalités relatives à l’utilisation des services, y compris des engagements concernant la sécurité de l’environnement cloud.

Microsoft Azure, en tant que l’un des principaux fournisseurs de services cloud, accorde une grande importance à la sécurité. Azure dispose d’un ensemble complet de fonctionnalités et de pratiques de sécurité pour protéger les données dans le cloud, et celles-ci se reflètent souvent dans leurs accords contractuels avec les clients d’entreprise.

Bien que nous ne puissions pas divulguer les détails spécifiques de notre accord contractuel publiquement, après plus d’une décennie de collaboration avec Microsoft, nous sommes convaincus que cet accord répond à nos exigences et standards de sécurité.

4.28 Des sous-traitants sont-ils impliqués dans le traitement des détails/données du client ?

Non, Lokad ne sous-traite pas le traitement des détails ou des données client. Concernant la plateforme Lokad, nous achetons des ressources de calcul - principalement des machines virtuelles et du blob storage - auprès de Microsoft Azure, mais à part cela, aucun tiers n’est impliqué en ce qui concerne les données client.

En ce qui concerne la fourniture des services professionnels de Lokad, seuls les employés à temps plein de Lokad (dans ce cas, les supply chain scientists) ont accès aux détails ou aux données client. Lokad accueille occasionnellement quelques stagiaires (bien que bien moins que la plupart des entreprises comparables) pour des stages de longue durée, mais ils opèrent sous la supervision directe et stricte d’un supply chain scientist senior.

Note: Les stagiaires sont soumis aux mêmes accords de confidentialité que les supply chain scientists à temps plein.

5. Journalisation et surveillance

5.1 Proposez-vous des journaux d’accès (utilisateur, date, dernière date de connexion, etc.) ?

Oui. Lokad fournit des journaux d’accès formatés en fichiers CSV. À ce jour, ces journaux peuvent être demandés auprès du support de Lokad. L’extraction des journaux sera placée dans le compte Lokad à un emplacement accessible uniquement aux utilisateurs ayant la désignation “Owner”. Nous prévoyons d’introduire une méthode d’accès plus directe - via une interface web dédiée - à la piste d’audit complète qui existe déjà dans le back-end de la plateforme Lokad.

5.2 Centralisez-vous les journaux de tous les composants de la solution ?

Oui. La conception d’event sourcing de Lokad centralise non seulement les journaux, mais aussi tous les changements d’état qui se produisent dans la solution. Les journaux, ainsi que les autres changements d’état, sont centralisés au moyen d’une petite collection de flux d’événements, gérée par le même magasin d’événements. En interne, les journaux qui n’impactent pas l’état de la solution sont séparés de ceux qui l’affectent.

D’un point de vue purement technique, il existe certains journaux liés à la performance qui ne sont intentionnellement pas centralisés dans le magasin d’événements. Ces journaux incluent des mesures de performance fines, telles que celles produites par l’instrumentation de profilage de performance interne de Lokad (ex : le nombre de millisecondes passées pour chaque appel de fonction lors de l’exécution d’un script Envision). Ces journaux de performance ne contiennent rien qui puisse être qualifié de matériel “lié à la sécurité”.

5.3 Journalisez-vous les changements et les opérations effectuées dans l’application ? Conservez-vous une trace de toutes les transactions ?

Oui. En raison de la conception d’event sourcing de Lokad, tout est journalisé par nécessité. En effet, la solution elle-même est la somme des événements enregistrés au sein de la solution. Ainsi, la journalisation est un aspect fondamental de l’architecture de la solution. Cette conception d’event sourcing empêche l’omission accidentelle d’un journal reflétant un changement d’état. Dans un tel cadre d’event sourcing, il n’existe pas de transactions, du moins pas dans le sens habituel d’une base de données transactionnelle (ex : MySQL, Oracle, etc.). Ces transactions sont remplacées par des événements contenant toutes les informations associées à un changement d’état.

5.4 Normalisez-vous les formats des journaux des différents composants à des fins médico-légales ?

Oui. Les “journaux”, du point de vue de l’audit et/ou de la sécurité, sont les transformations des événements sous-jacents. Les événements sont techniquement des objets sérialisés. Pour obtenir des journaux, la solution Lokad convertit et compile ces événements en fichiers CSV. Nous normalisons les formats de date, les formats de nombres, et les identifiants d’utilisateur utilisés dans l’extraction CSV.

5.5 Proposez-vous des exportations de journaux vers un tiers via un protocole de requête ?

Oui, sous réserve d’un accord contractuel avec le client.

5.6 Suivez-vous toutes les exceptions levées dans votre solution ?

Oui. La conception d’event sourcing de Lokad nous permet de suivre toutes les exceptions levées dans notre solution et de reproduire les conditions qui ont conduit au problème initial. Une fois identifiées, l’équipe d’ingénierie de Lokad élimine toutes les exceptions observées. Nous avons conçu des outils dédiés à cet effet spécifique, et nous conservons un backlog très limité des exceptions non corrigées.

5.7 La solution a-t-elle la capacité de surveiller en temps réel la santé des différents composants/services ?

Oui. Nos sous-systèmes ont été conçus avec des points de terminaison de surveillance dédiés aux contrôles de santé. Nous disposons d’outils de surveillance, accessibles uniquement - depuis janvier 2023 - aux équipes d’ingénierie de Lokad, qui consolident en continu les informations mises à disposition par ces points de terminaison.

Comme mentionné précédemment, “en temps réel” est assez vague en ce qui concerne les systèmes distribués. Pour la surveillance de la santé du système, la latence attendue varie de quelques secondes à environ une minute.

5.8 La solution a-t-elle la capacité d’intégrer des outils de monitoring tiers? La solution supporte-t-elle SNMP ou JMX, ou la capacité d’envoyer des événements SNMP et JMX vers des solutions de monitoring tierces?

Oui, sous réserve d’un accord contractuel dédié.

5.9 La solution a-t-elle la capacité de surveiller les travaux par lots qui n’ont pas démarré selon le planning et de surveiller leur terminaison?

Oui. La solution Lokad dispose de son propre planificateur de tâches interne (appelé “Runflow”) pour orchestrer les tâches de longue durée au sein de la plateforme Lokad - typiquement l’exécution de scripts Envision. Ce planificateur peut être configuré, via une interface web, pour spécifier un planning et une plage de temps d’exécution pour toute séquence de tâches.

5.10 La solution a-t-elle la capacité de générer des alertes proactives ? A-t-elle la capacité de corréler et d’analyser les erreurs, puis de prendre des mesures proactives ?

Oui. Runflow, le planificateur de tâches de la solution, peut alerter le client/Lokad qu’une séquence d’exécution en cours est en retard. L’alerte peut être envoyée avant l’achèvement de la séquence. La solution Lokad offre des capacités étendues grâce à Envision (son DSL) pour analyser et s’auto-diagnostiquer les situations afin de prendre une action proactive. Bien que la plateforme Lokad offre cette capacité, elle nécessite néanmoins qu’un ingénieur implémente - via Envision - la logique effective, car les situations de supply chain qui qualifient d’“erreurs” peuvent varier.

5.11 La solution dispose-t-elle de capacités de rétention des données d’audit ? Les données sont-elles archivées et purgées dans une base de données MIS pour l’audit de l’activité des utilisateurs ?

Oui. Grâce à sa conception en sourcing d’événements, la solution Lokad conserve une traçabilité d’audit étendue ; bien plus importante que celle obtenue avec des conceptions plus classiques qui s’appuient généralement sur une base de données transactionnelle plutôt que sur un magasin d’événements. La solution Lokad n’isole pas un système d’information de gestion (MIS) en tant que sous-système distinct. En effet, le flux d’événements constitue la traçabilité d’audit. Plus généralement, Lokad conserve les données de production pendant toute la durée du service avec le client. À la fin du service, selon les termes contractuels négociés, les données du client sont purgées, bien que la suppression définitive dans le système de sauvegarde puisse intervenir quelques mois après la fin du contrat.

5.12 Votre système intègre-t-il un mécanisme d’auto-surveillance (technique et fonctionnel) ?

Oui, la plateforme Lokad intègre plusieurs mécanismes d’auto-surveillance à différents niveaux.

La plateforme hébergée dans le cloud est surveillée par les équipes d’ingénierie logicielle de Lokad. Comme la plateforme Lokad est multi-locataire, cette surveillance est en grande partie effectuée avec une mentalité “système”, garantissant que les capacités de la plateforme (y compris son profil de performance) répondent aux normes. Nous avons conçu notre propre couche d’instrumentation à cet effet. La surveillance “fonctionnelle” est généralement spécifique aux clients car elle dépend des spécificités de la supply chain concernée. Cette surveillance est normalement assurée par les équipes de supply chain scientists (les ingénieurs fournis par Lokad), selon l’accord contractuel.

Les supply chain scientists de Lokad se spécialisent généralement dans une classe particulière de comptes client (par exemple, l’aérospatiale). Ils élaborent des instruments de surveillance sur mesure en utilisant le compte Lokad. Cette surveillance comprend de s’assurer que les chiffres fournis par Lokad sont corrects, non seulement d’un point de vue technique, mais également du point de vue commercial du client.

5.13 Les journaux sont-ils examinés et analysés en temps opportun et de manière systématique, afin de détecter des anomalies et des indications de faille ?

Oui. L’examen de l’activité en cours de la plateforme Lokad fait partie de notre routine quotidienne. La conception de notre plateforme facilite ce processus.

Voir aussi Logging and Monitoring 5.2.

5.14 Les systèmes de gestion des journaux sont-ils administrés par des personnes qui ne sont pas impliquées dans l’administration des autres systèmes (c’est-à-dire, la séparation des tâches) ?

Oui. La supervision des journaux et de l’activité générale de la plateforme est assurée par les Supply Chain Scientists, tandis que l’administration générale de notre infrastructure est effectuée par des employés spécifiques au sein de notre division informatique.

5.15 Des scans de vulnérabilité au niveau des applications sont-ils effectués périodiquement et de manière systématique ?

Oui, bien que ces scans ne représentent qu’une très petite partie de nos processus de sécurité. Voir Employees 6.6.

5.16 Existe-t-il un processus défini pour la révision périodique des règles de pare-feu effectives ?

Oui, notre machine de production est équipée de règles très strictes, telles que l’ouverture d’un nombre très limité de ports (configurés via Microsoft Azure). La configuration de notre infrastructure est scriptée, et son évolution suit notre processus habituel de revue de code. Cette pratique facilite non seulement les révisions périodiques, mais atténue également le besoin de revoir manuellement les règles en premier lieu.

5.17 Le réseau est-il équipé de la technologie IDS (Intrusion Detection System) ?

Non. L’IDS est une conception intrinsèquement dangereuse car elle viole le principe de “moindre privilège” : un composant se voit accorder d’énormes privilèges afin d’opérer comme un “man in the middle”. Cela fait de l’IDS une cible de choix pour les attaquants, et il étend considérablement la surface d’attaque de la plateforme. Cependant, Lokad surveille de près son trafic web, ainsi que les comportements utilisateurs anormaux sur notre propre plateforme. Ces capacités font partie intégrante de la plateforme et ne sont donc pas déléguées à des composants logiciels tiers isolés et privilégiés.

Voir aussi Employees 6.6.

6. Employés

6.1 Les employés ont-ils des accords de confidentialité (NDAs) ?

Oui, tous les employés de Lokad sont soumis à une clause de NDA dans leurs contrats de travail.

6.2 Les employés suivent-ils une sensibilisation à la sécurité et une formation en sécurité ?

Oui, une sensibilisation à la sécurité et une formation en sécurité sont fournies aux employés de Lokad qui sont en contact avec des données confidentielles et/ou des systèmes d’ingénierie en contact avec des données confidentielles. Pour plus d’informations à ce sujet, la conférence Cybersecurity for Supply Chain est dédiée aux supply chain scientists - les personnes qui traitent des données confidentielles des clients.

6.3 Qui a accès aux données client chez Lokad ?

Le client définit explicitement une liste d’utilisateurs ayant accès à son compte Lokad. Ces utilisateurs, en fonction de leurs droits d’accès configurés dans le compte Lokad, peuvent avoir accès à diverses catégories de données du client. Il existe une application web au sein de la solution Lokad dédiée à la gestion des permissions (appelée “Hub”).

Chez Lokad, pour chaque compte client, il existe une liste succincte d’employés ayant accès. Tout d’abord, cette liste inclut les supply chain scientists (les ingénieurs fournis par Lokad) qui implémentent et maintiennent la solution d’optimisation de la supply chain. Ces supply chain scientists sont censés accéder quotidiennement aux données du client. En interne, Lokad restreint l’accès au compte client uniquement aux supply chain scientists assignés à ces comptes. C’est-à-dire, le Supply Chain Scientist A ne peut pas accéder au compte client B à moins qu’il n’ait été expressément assigné à gérer ce compte (selon les dispositions convenues avec le client).

Deuxièmement, cette liste inclut l’équipe d’ingénierie chargée de l’administration système de notre plateforme. En règle générale, l’accès direct aux données clients est rare et limité à l’investigation de situations rapportées soit par les clients eux-mêmes, soit par leurs supply chain scientists de soutien. Lokad ne partage pas l’accès aux données clients avec des tiers, à l’exception de la plateforme de cloud computing.

6.4 Comment sécurisez-vous les postes de travail des employés ?

À l’exception de l’équipe d’ingénierie logicielle, les employés de Lokad opèrent sans privilèges administratifs sur leurs appareils fournis par l’entreprise. Tous les postes de travail sont configurés avec un chiffrement intégral du disque pour protéger contre le vol de données pouvant survenir en cas de perte, de vol ou de mise en confiance du matériel auprès de tiers (par exemple, pour des réparations).

Les postes de travail utilisés par nos employés ne contiennent pas les données de nos clients. Selon la tâche à accomplir, un employé peut télécharger quelques feuilles Excel sur sa machine - pour faire une présentation, par exemple - mais notre politique est de strictement conserver toutes les données des clients de manière sécurisée dans le cloud.

6.5 Comment sécurisez-vous les smartphones des employés ?

Les employés de Lokad ne disposent pas de smartphones fournis par l’entreprise. Les données non critiques, telles que les rappels de calendrier, peuvent être transmises via des appareils personnels (non fournis par l’entreprise), mais les smartphones, tout comme les postes de travail, ne contiennent pas les données de nos clients.

6.6 Utilisez-vous un antivirus ?

Oui, nos postes de travail disposent de Microsoft Defender, conformément aux configurations de Microsoft Windows 10+. Nous n’avons pas d’antivirus autre que Microsoft Defender, mais notre position est que ce type d’outil tend à faire plus de mal que de bien (en termes de sécurité informatique). À titre d’exemple, le piratage de SolarWinds en 2020 est considéré comme l’une des plus grandes catastrophes en matière de sécurité informatique de tous les temps, et il a été causé par un logiciel censé améliorer la sécurité à la base. Plus généralement, presque tous les produits logiciels destinés à des fins de sécurité nécessitent des privilèges système assez élevés. En conséquence, ces produits logiciels deviennent leurs propres vecteurs d’attaque. Notre point de vue sur la sécurité informatique est que moins, c’est plus, et qu’ajouter des technologies très complexes dans notre paysage applicatif le rend presque invariablement moins sûr, et non plus sécurisé.

6.7 Les développeurs logiciels sont-ils formés périodiquement à l’utilisation de méthodes d’évaluation des menaces, de normes de codage sécurisé, de listes de vérification de sécurité bien connues et de cadres de référence ?

Oui. Cependant, la plupart des listes de vérification bien connues reflètent principalement des architectures qui sont “insecure by design”. Chaque fois que possible, nous préférons éliminer la source des pièges de sécurité dès la phase de conception. Voir aussi Employees 6.2.

6.8 Tous les contrats avec les sous-traitants/main-d’œuvre externe de Lokad incluent-ils un accord de confidentialité (NDA) ? Cet accord couvre-t-il les informations relatives aux clients ?

Oui pour les deux, bien que Lokad - au moment de la rédaction - ne fasse pas appel à des sous-traitants/à une main-d’œuvre externe. Les équipes d’ingénierie logicielle et de supply chain scientists de Lokad sont entièrement composées de personnes sous contrat d’emploi permanent et sous la supervision directe de Lokad.

Cependant, si Lokad jugeait nécessaire de faire appel à un sous-traitant, il serait soumis aux mêmes conditions de propriété intellectuelle (IP) et de NDA que nos employés permanents. Ces accords incluent des clauses concernant les informations sur les clients de Lokad.

6.9 Toute la main-d’œuvre externe de Lokad a-t-elle reçu la formation d’intégration aux informations internes et à la sécurité de Lokad (ainsi que la formation continue pertinente) ?

Lokad - au moment de la rédaction - ne fait pas appel à des sous-traitants/à une main-d’œuvre externe. Les équipes d’ingénierie logicielle et de supply chain scientists de Lokad sont entièrement composées de personnes sous contrat d’emploi permanent et sous la supervision directe de Lokad.

Cependant, si Lokad jugeait nécessaire de faire appel à une main-d’œuvre externe, cela serait une exigence. Tous les sous-traitants/travailleurs externes seraient soumis aux mêmes processus de sécurité et exigences de formation que nos employés permanents.

Comme indiqué précédemment, Lokad ne fait actuellement pas appel à une main-d’œuvre externe, par conséquent aucune formation de ce type n’a lieu.

Voir aussi Employees 6.8

6.10 Tous les contrats avec les entreprises qui fournissent la main-d’œuvre externe de Lokad (quelques ou tous les entrepreneurs, consultants, etc., qui participent à la prestation des services de Lokad) exigent-ils que les travailleurs externes soient soumis à des vérifications des antécédents ? Ces vérifications des antécédents correspondent-elles au niveau d’accès aux informations et à la criticité du rôle de l’employé ?

Lokad - au moment de la rédaction - ne fait pas appel à des sous-traitants/à une main-d’œuvre externe. Les équipes d’ingénierie logicielle et de supply chain scientists de Lokad sont entièrement composées de personnes sous contrat d’emploi permanent et sous la supervision directe de Lokad.

Cependant, si Lokad jugeait nécessaire de faire appel à une main-d’œuvre externe, cela serait une exigence. Tous les sous-traitants/travailleurs externes seraient soumis aux mêmes processus de sécurité, vérifications des antécédents et exigences de formation que nos employés permanents.

Note: Historiquement, bon nombre des incidents les plus importants - et les plus graves - tels que le cyberespionnage, sont commis par des personnes ayant un casier judiciaire impeccable. C’est, entre autres raisons, pour cela que Lokad hésite à faire appel à une main-d’œuvre externe et préfère fortement les contrats d’emploi directs et ouverts.

6.11 Les comptes administratifs sont-ils automatiquement désactivés ou supprimés à la fin de l’emploi ?

Oui. Tous les employés de Lokad reçoivent leurs droits d’accès via un fournisseur d’identité fédéré (Microsoft Azure Active Directory). À la fin de leur emploi, le cas échéant, cet accès est révoqué, désactivant ainsi automatiquement tous les droits administratifs associés.

Note: La plupart des employés de Lokad ne se voient jamais attribuer de droits administratifs car ceux-ci ne sont pas nécessaires à l’exécution de leurs fonctions.

6.12 Effectuez-vous des vérifications des antécédents criminels sur l’ensemble du personnel ayant accès à des données sensibles, des données financières, des données bancaires, des données de carte de paiement, etc. ?

Oui, des vérifications des antécédents sont effectuées strictement en fonction des exigences du poste occupé.

Il convient de noter que Lokad ne gère pas en interne les données de carte de paiement - celles-ci sont gérées par des tiers. Ainsi, le personnel de Lokad n’a accès à aucune donnée de carte de paiement de nos clients.

6.13 Quelles précautions Lokad prend-elle pour s’assurer que le personnel non autorisé ne puisse pas accéder aux locaux où le travail est effectué ?

Au niveau du bâtiment, Lokad est implanté dans un immeuble de bureaux bénéficiant d’une surveillance tierce 24h/24 et 7j/7, avec une sécurité sur site.

Au niveau des bureaux, les locaux de Lokad disposent de leurs propres points d’accès sécurisés, indépendants de ceux de l’immeuble lui-même. Cette dernière couche empêche les employés d’autres entreprises situées dans l’immeuble d’accéder aux bureaux de Lokad.

Note: Tout visiteur exceptionnel (tel que des clients, candidats potentiels, etc.) doit être accueilli physiquement et autorisé à entrer par les membres du personnel de Lokad.

6.14 Les visiteurs sont-ils autorisés dans les locaux ?

Si “facility” signifie “le lieu où les données client sont stockées et traitées”, alors non. Les données client sont stockées dans les centres de données de Microsoft Azure. Ces centres de données ne sont pas ouverts au public - Lokad lui-même ne peut pas y accéder.

Cependant, Lokad accueille occasionnellement des visiteurs dans son siège social. Nos bureaux ne sont pas ouverts au public, mais des circonstances exceptionnelles surviennent parfois, telles que la visite de clients, ou des candidats attendant un entretien, etc. Ces visites sont planifiées à l’avance et ces visiteurs sont systématiquement accompagnés par des membres du personnel de Lokad lorsqu’ils se trouvent dans nos bureaux.

6.15 Les enregistrements de données papier (et les supports électroniques amovibles contenant des données) sont-ils stockés dans des armoires ignifuges sécurisées pendant la nuit?

Lokad n’utilise pas d’enregistrements de données sur papier, ni de supports électroniques amovibles. Comme nous n’avons pas de dossiers physiques à stocker, Lokad n’a pas besoin d’armoires ignifuges.

Bien que nous puissions occasionnellement imprimer un document (Lokad imprime très peu de documents, voire jamais), nous disposons également d’une déchiqueteuse à côté de l’imprimante. La politique par défaut de Lokad est de ne pas imprimer de document sensible, mais si cela devait théoriquement être nécessaire, notre politique par défaut consiste également à déchiqueter immédiatement le document imprimé après usage.

6.16 Existe-t-il une politique de bureau épuré? Si oui, dans quelle mesure?

Oui, Lokad applique une politique de bureau épuré fermement en place. Cette politique est imposée “par conception” via notre environnement numérique.

À l’exception de quelques documents que nous sommes légalement contraints d’imprimer, ou de documents occasionnels imprimés par nécessité (par exemple, une affiche pour un salon professionnel, bien que même cela soit généralement externalisé), l’environnement de travail de Lokad est strictement numérique.

Ainsi, à la fin de la journée, les employés de Lokad n’ont rien à ranger. Une fois que la session de l’ordinateur de l’employé a été verrouillée - une politique que nous appliquons strictement - le bureau en question est effectivement libéré.

6.17 Où arrivent les fax et qui pourrait y avoir accès?

Lokad n’a jamais possédé de machine à fax - qu’elle soit physique ou virtuelle. Nous ne connaissons aucun cas d’utilisation convaincant pour changer notre position sur cette technologie.

6.18 Existe-t-il un processus pour vérifier le retour des actifs constituants (ordinateurs, téléphones portables, badges d’accès, jetons, cartes intelligentes, clés, etc.) lors de la cessation d’activité?

Oui, nous disposons non seulement d’un processus en place, mais aussi d’un logiciel de gestion des actifs informatiques pour soutenir cet effort et minimiser le nombre d’erreurs administratives.

Cependant, nous avons intentionnellement conçu la sécurité de Lokad pour ne pas dépendre du retour en temps voulu des actifs constituants. Lokad suppose que tout actif constituant a une chance raisonnable d’être perdu ou volé, peu importe la discipline et la formation de nos employés. En pratique, cela arrive très rarement, mais d’un point de vue technique, nous partons de l’hypothèse contraire. Pour cette raison, les actifs constituants peuvent être désactivés à distance. De plus, nous appliquons un chiffrement complet des disques chaque fois que cela est applicable.

De manière plus générale, notre environnement de travail a été conçu pour ne pas nécessiter de stockage persistant des données client sur des postes de travail, des ordinateurs portables ou des téléphones portables. Cette conception réduit considérablement la criticité des actifs constituants dans l’éventualité où nos autres mesures préventives échoueraient.

6.19 Les politiques et/ou procédures de Ressources Humaines (RH) sont-elles approuvées par la direction et communiquées aux parties concernées, et un responsable est-il désigné pour les maintenir et les réviser?

Oui, nos politiques et procédures en Ressources Humaines ont été formellement approuvées par la haute direction. Nous mettons un fort accent sur une communication claire, et, en conséquence, ces politiques et procédures ont été largement diffusées à toutes les parties concernées afin d’assurer une compréhension et une conformité complètes.

De plus, nous avons désigné un responsable chargé de la maintenance continue, des mises à jour et de la révision régulière des politiques et procédures. Cela garantit que nos pratiques restent actuelles, pertinentes et alignées à la fois sur les normes de l’industrie et sur nos objectifs organisationnels.

6.20 Existe-t-il des appareils mobiles personnels (BYOD), plutôt que propriété de l’entreprise, utilisés par des individus associés à votre organisation et qui ont accès aux données client?

Non, Lokad n’autorise pas l’accès aux données client sur des appareils mobiles personnels (BYOD). Nous fournissons à nos employés du matériel de haute qualité, propriété de l’entreprise, éliminant ainsi le besoin d’appareils personnels. Cette disposition répond au scénario courant dans lequel les employés se tournent vers l’utilisation de leurs propres appareils en raison d’une insatisfaction vis-à-vis d’un matériel d’entreprise de qualité médiocre.

De plus, nos protocoles opérationnels sont conçus de sorte que, même sur nos appareils appartenant à l’entreprise, les données client ne soient pas stockées de manière permanente. Tout le traitement des données s’effectue au sein de notre plateforme basée sur le cloud. Sur les appareils des employés, les données client (si jamais elles sont consultées) sont traitées de manière transitoire et uniquement en segments minimaux, garantissant une sécurité maximale.

Notes