FAQ : Sécurité logicielle

Lokad est avant tout un spécialiste de la supply chain et notre objectif principal est de fournir des décisions supérieures en matière de supply chain grâce à notre ingéniosité technologique. Cela dit, nous traitons quotidiennement des données financières importantes, c’est pourquoi la sécurité de notre plateforme logicielle est une priorité que nous prenons très au sérieux. Au lieu de considérer la sécurité comme une réflexion après coup à gérer par la bureaucratie, nous croyons fermement en 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 dotation en personnel et de formation.

Public cible : Le département informatique
Dernière modification : 21 septembre 2023

Principes de sécurité

L’une des illusions les plus néfastes dans les cercles des logiciels d’entreprise est l’idée que la sécurité peut être abordée avec des listes de contrôle de conformité, des certifications et, plus généralement, toutes sortes de tâches bureaucratiques. Malheureusement, les détails de sécurité évoluent constamment. Des problèmes surviennent lorsque des acteurs mal intentionnés exploitent les logiciels ou les personnes (ou les deux). La sécurité ne peut donc être abordée que par l’application sensée de principes généraux.

Plus sûr par conception

Nous pensons que la conception est l’un des aspects les plus sous-estimés de la sécurité logicielle. Ici, la conception couvre les décisions fondamentales qui ont été prises pour développer le logiciel. Les décisions de conception qu’une entreprise prend ont des implications énormes en ce qui concerne la sécurité, en particulier la surface d’attaque. Grâce à une conception logicielle sensée, 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 de blobs - en tant que couche de stockage strictement passive. Ce choix seul empêche tout un groupe de problèmes de sécurité, tels que les attaques par injection SQL, car il n’y a tout simplement pas de base de données SQL à attaquer. De même, toutes nos couches de persistance sont en mode ajout seulement. C’est comme un système de contrôle de version où les modifications sont ajoutées à la fin des données existantes, plutôt que de les écraser entièrement. Toutes les modifications sont tracées et peuvent être annulées. Cette étape complique considérablement la suppression de données (par n’importe qui, y compris les attaquants), ainsi que la manipulation des journaux de Lokad.

La plupart des fournisseurs de logiciels d’entreprise ne reconnaissent pas le fait que les choix de conception fondamentaux sont le socle même de leurs produits logiciels. Par conséquent, leurs problèmes de sécurité sont sans fin. Par exemple, si la configurabilité - presque toujours une exigence pour les logiciels d’entreprise - est fournie par le biais d’un langage de programmation polyvalent (comme Python ou JavaScript), des problèmes de sécurité se poseront inévitablement. Cela est dû au fait qu’il est presque impossible de sécuriser complètement un langage de programmation polyvalent. En revanche, Lokad a fait le choix de conception conscient de canaliser toute la configurabilité à travers un DSL (langage de programmation spécifique au domaine) appelé Envision. Envision est beaucoup plus sûr car il ne dispose pas - par conception - de 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 culture

Aucune technologie, et certainement aucun processus, ne peut rendre un logiciel sécurisé si les gens s’en soucient peu. Par conséquent, nous faisons de notre mieux pour faire en sorte que Lokad - à la fois ses technologies et ses processus - soit quelque chose qui mérite un véritable intérêt. 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 des motivations individuelles des personnes¹.

Tout d’abord, Lokad aligne, autant que possible, ses messages marketing avec la réalité de son activité. Nous le faisons que cela nous attire des faveurs ou des critiques. Cela contraste fortement avec de nombreux fournisseurs d’entreprise qui font des déclarations publiques déraisonnables (et souvent fantaisistes)². Lorsque cela se produit, les employés avisés - ceux capables de percevoir le décalage entre la réalité de l’entreprise et ce qui est communiqué à l’extérieur - cessent de s’en soucier. Cette indifférence engendre la complaisance, et les problèmes de sécurité s’ensuivent. Souvent, ces employés quittent l’entreprise, laissant derrière eux les “crédules” - ceux qui ne voient pas le décalage. La crédulité, tout comme l’indifférence, n’est pas une caractéristique souhaitable en matière de sécurité.

Ensuite, Lokad favorise chez ses employés un mélange de curiosité et de saine scepticisme à l’égard de tous les aspects de notre activité, qu’ils soient techniques ou non techniques, y compris la sécurité. Cela crée une flexibilité lorsqu’il s’agit de réviser et de mettre à jour les pratiques, car les employés sont formés et encouragés à contribuer. Cette plasticité est utile pour anticiper les acteurs mal intentionnés, étant donné qu’ils sont connus pour concevoir des méthodes d’attaque de plus en plus créatives. Heureusement pour Lokad, cet état d’esprit est également très recherché dans le domaine de la supply chain, car les comportements indésirables - bien qu’ils ne soient pas nécessairement criminels - sont courants dans la supply chain³.

Plus sûr par la formation

Nous formons activement l’ensemble de notre personnel pour mieux comprendre les cybermenaces et comment les atténuer. Contrairement à la conception et à la culture, la formation en matière de sécurité est largement un processus descendant. Bien que la réflexion ascendante ait sa place, ce type de formation est intrinsèquement faible face à la plupart des risques de sécurité informatique. En d’autres termes, même si les gens sont formés pour ne pas faire quelque chose, Lokad ne peut pas supposer que personne ne fera jamais cette chose⁴. Ainsi, nous adoptons une approche plus stricte. Dans le cadre de notre formation, nous décourageons l’utilisation de clés USB et d’autres périphériques USB susceptibles de compromettre les machines. Nous veillons à ce que l’authentification à deux facteurs soit utilisée chaque fois que possible. Nous formons notre personnel à travailler avec le moins de privilèges possible sur leurs postes de travail. Nous nous assurons que tout le monde est conscient du fonctionnement de l’ingénierie sociale, qui peut tromper même les personnes les plus intelligentes.

Plus généralement, la formation en matière de sécurité vise à sensibiliser davantage sur la manière dont les logiciels et les processus peuvent être détournés et corrompus par des acteurs mal intentionnés. Étant donné l’étendue de la formation, des compétences et du savoir-faire nécessaires pour prévenir de telles attaques nuancées, Lokad compte généralement très peu de stagiaires, comparé à la plupart des entreprises de taille comparable dans le secteur. En bref, nous préférons miser sur une équipe stable et hautement formée à long terme.

Foire aux questions (FAQ)

1. Pratiques

1.1 Avez-vous une assurance sécurité ?

Oui. L’assurance sécurité est un terme générique qui englobe diverses pratiques telles que le renforcement de la sécurité, les tests de sécurité et la gestion des vulnérabilités. Chez Lokad, le renforcement de la sécurité est abordé en premier lieu par la conception. Grâce à des choix de conception spécifiques, nous éliminons des classes entières de vulnérabilités, ce qui élimine également la nécessité même du renforcement. Par exemple, Lokad ne repose pas sur une couche de stockage “programmatique” - telle qu’une base de données relationnelle - mais sur un simple magasin clé-valeur. Cela élimine tous les vecteurs d’injection SQL. De plus, les tests de sécurité sont abordés par le biais d’un ensemble diversifié de méthodes, certaines automatisées et d’autres manuelles, telles que des tests de pénétration effectués par des tiers. Pour la gestion des vulnérabilités, nous avons un programme de bug bounty et un processus de gestion des versions largement automatisé pour garantir que les correctifs peuvent être déployés rapidement.

1.2 Êtes-vous conformes à la norme ISO 27001 (ISMS) et/ou SOC 2 ?

Non. Nous sommes fermement convaincus que ces certifications sont des distractions qui rendent les entreprises de logiciels moins sécurisées. Ces processus de conformité mettent l’accent sur une mentalité bureaucratique qui est l’opposée de ce qui est nécessaire pour rendre les logiciels sécurisés. Par exemple, ces certifications nécessitent la production de documents et la mise en place de comités. Franchement, l’idée que les documents et les comités apportent quelque chose de concret à la sécurité des logiciels est profondément discutable et n’est pas quelque chose que Lokad accepte le moins du monde.

Dans les milieux du logiciel, la sécurité est généralement obtenue en faisant moins, pas plus ; en tirant parti des efforts des ingénieurs logiciels spécialisés dans la sécurité des logiciels, plutôt qu’en créant des équipes supplémentaires de non-spécialistes. À titre de preuve anecdotique, 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 de logiciels “certifiées” avaient choisi de donner la priorité à la relecture du code tiers - souvent la cause première des problèmes - plutôt que de poursuivre des sceaux d’approbation commerciaux arbitraires.

Dans l’ensemble, nous pensons que ces certifications sont des artifices marketing qui endorment les entreprises en leur donnant un faux sentiment de sécurité (au sens figuré comme au sens propre).

1.3 Suivez-vous les pratiques OWASP ?

Oui. OWASP fournit, à travers ses guides, une liste exhaustive des vulnérabilités couramment rencontrées 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 contre tous les problèmes identifiés par OWASP. Cependant, grâce à ses choix de conception, Lokad élimine largement des classes entières de vulnérabilités courantes mises en évidence par OWASP. Par exemple :

Gestion des mots de passe : En déléguant l’authentification via la fonctionnalité SSO (authentification unique, recommandée par Lokad), Lokad n’a plus besoin de “gérer” les mots de passe, rendant ainsi toutes les vérifications liées aux mots de passe inutiles.

Journalisation : La conception de l’événement sourcing adoptée par Lokad enregistre tout par nécessité. Si une action n’est pas journalisée, alors, du point de vue du système, elle n’a jamais eu lieu. Cela rend la plupart des vérifications de journalisation inutiles.

Sécurité de la base de données : La couche de persistance de Lokad ne comprend pas de base de données relationnelle, seulement deux composants non programmables ; à savoir une source d’événements et un magasin clé-valeur. Ce choix de conception rend la liste de vérification de la base de données entièrement inutile.

Plus généralement, lorsque cela est possible, nous préférons éviter les modèles de conception d’ingénierie sujets aux erreurs qui créent le besoin de telles listes de vérification en premier lieu.

1.4 Êtes-vous conforme au RGPD ?

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

1.5 Tous les services/solutions tiers (qui impliquent l’accès à des informations personnelles identifiables (PII)) dans la solution de Lokad sont-ils conformes aux exigences du délégué à la protection des données (DPD) ?

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

Il convient de noter que la solution de Lokad a une très courte liste 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’y a pas d’accord généralisé dans l’industrie 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 nouvelles menaces et vecteurs d’attaque habiles. Ainsi, nous ne nous référons pas catégoriquement à des tiers pour déterminer quelles sont les meilleures pratiques de sécurité logicielle. Au contraire, nous définissons ce qui est le mieux pour nos clients. Cela nous permet d’absorber les bonnes pratiques là où elles sont disponibles, 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 de pénétration ?

Oui. Nous effectuons à la fois des tests de pénétration planifiés et non planifiés. Les tests planifiés sont généralement financés par nos grands clients qui peuvent, conformément à l’accord contractuel signé avec eux, engager des entreprises spécialisées pour effectuer des tests de pénétration de leurs principaux fournisseurs de logiciels, y compris Lokad. Il y a généralement une certaine coordination entre l’équipe d’ingénierie de Lokad et ces spécialistes de la sécurité. Les tests non planifiés font généralement partie de notre programme public de bug bounty, où des spécialistes de la sécurité indépendants peuvent tenter de trouver une faille dans notre système qui est susceptible d’être exploitée.

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

Non. Cela dit, nous sommes plus que disposés à subir un audit externe si l’opération est financée par le client. Bon nombre de nos grands clients prévoient de tels audits dans nos accords contractuels. Cependant, à partir de janvier 2023, les tests de pénétration effectués par les clients n’ont pas révélé suffisamment de problèmes pour justifier la réalisation de tels audits.

1.9 Avez-vous un plan de continuité d’activité ?

Oui. La plus grande éventualité à laquelle Lokad a répondu est l’arrêt hypothétique de l’entreprise elle-même. Lokad fonctionne comme une solution SaaS, cependant, certains de nos grands clients prévoient dans leurs accords contractuels la possibilité de demander des instantanés complets de notre base de code. Ces instantanés sont mis en séquestre auprès d’un tiers convenu, de sorte que, en cas de cessation d’activité de Lokad, le client aurait automatiquement accès à la base de code en séquestre et une licence permissive pour recréer leur propre instance du service Lokad.

1.10 Avez-vous un plan de communication de crise ?

Oui. Pour chaque client, nous avons un point de contact identifié au sein de leur organisation. De notre côté, il y a au moins deux employés chez Lokad - un titulaire et un suppléant (généralement deux de nos scientifiques de la supply chain) - qui supervisent la communication de tout message urgent au client. En pratique, la grande majorité des crises auxquelles nous sommes confrontés ne sont pas des problèmes de sécurité logicielle, mais des problèmes de supply chain - des urgences que Lokad identifie en fonction des données qui nous sont fournies par le client. En cas d’événement de sécurité, ce canal est utilisé pour s’assurer que nos clients sont informés en temps opportun.

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

Nous recommandons vivement que Lokad n’ait pas accès aux systèmes informatiques de nos clients ; le système informatique du client ne devrait pousser et tirer que des données de Lokad. Cette approche vise à atténuer la possibilité qu’un événement de sécurité chez Lokad se propage au système informatique du client. De plus, nous recommandons également l’utilisation d’un processus de SSO (authentification unique), car cela élimine le scénario hypothétique où un mot de passe utilisé pour accéder à Lokad serait intercepté (d’une manière ou d’une autre) et utilisé ultérieurement 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 que seules les bonnes personnes sont autorisées à accéder aux données à 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, bien que nous soyons attentifs à la sécurité du réseau, nous nous assurons - en tant que première étape - que la surface d’attaque associée à nos réseaux soit réduite au minimum.

Lokad utilise deux réseaux notables. Le premier est Microsoft Azure, qui est utilisé pour héberger notre solution. La sécurité du réseau Microsoft Azure est entièrement déléguée à Microsoft. Nous n’utilisons pas de fonctionnalités de réseau “avancées” - telles que celles proposées par Microsoft Azure - au-delà des équilibreurs de charge de base.

Le deuxième 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 les composants tiers) et les outils (y compris les outils open-source) intégrés dans la solution sont légalement valides pour le développement et l’utilisation en production ?

Oui. Lokad a, par rapport à la plupart des éditeurs de logiciels d’entreprise, très peu de dépendances. Toutes nos principales dépendances sont des projets open-source crédibles et largement utilisés (par exemple, .NET de Microsoft, React de Facebook). Cela rend notre processus d’audit interne sur ce point spécifique assez 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é sensibles, il est rare qu’un changement de quelque magnitude que ce soit (mineur ou majeur) ait un impact sur la sécurité (même hypothétiquement). Dans toute l’histoire de Lokad, il n’y a que 3 événements qui pourraient être considérés comme vraiment importants d’un point de vue sécurité : la migration vers Microsoft Azure en 2010 ; l’introduction de l’authentification déléguée en 2012 (pour les clients et les employés) ; et, en interne chez Lokad, la migration de l’authentification Google 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 d’ingénierie logicielle de Lokad. Des supports de formation pertinents et des sessions de formation ont été mis en place avant le changement prévu, afin de garantir la préparation de tous les employés de Lokad. Enfin, après chaque événement de migration, nous nous sommes assurés que le “chemin” précédent était éliminé, conformément à la pratique standard de Lokad.

En janvier 2023, nous n’avons aucun changement majeur à venir prévu. Si un tel changement devait être introduit, nous procéderions très probablement 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 qu’il est 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 un risque en termes de sécurité, ce point fait l’objet de discussions avec chaque client et peut donc varier légèrement en fonction du cas. D’un point de vue de sécurité, un acteur mal intentionné pourrait essayer de se faire passer pour le client afin de déclencher une résiliation anticipée du contrat (et perturber les opérations du client). Pour éviter cela, Lokad et le client s’efforceront conjointement d’adopter un processus - contractuellement contraignant - qui ne soit pas facilement vulnérable à 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 annuelle ?

Lokad facture généralement des frais mensuels fixes associés au coût d’exploitation de la plateforme, ainsi que des frais mensuels fixes associés au service fourni par les scientifiques de la supply chain 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 de maintenance supplémentaires, de frais de licence, d’intégrateurs tiers, de consultants tiers, etc. Le forfait est assorti de limites, en termes de portée et d’échelle, qui sont négociées conjointement dans le cadre de l’accord contractuel pour le service.

1.17 Pouvez-vous fournir les conditions générales de Lokad pour 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 de la supply chain, des pays concernés et de la portée 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 de la supply chain envisagée. Cela nous aide à élaborer le cadre contractuel le plus pertinent pour la situation.

1.18 Fournissez-vous une formation (sur site/en ligne) ?

Oui, Lokad propose à la fois des formations sur site et à distance. Les détails de ces sessions sont négociés dans le cadre de l’accord contractuel. De plus, Lokad dispose à la fois d’une documentation technique publique étendue et d’une série détaillée de conférences sur la supply chain. Ces conférences couvrent la technologie et la perspective de la supply chain de Lokad.

1.19 Le système de Lokad est-il conforme aux normes légales/locales pertinentes (par exemple, ISO) ?

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

1.20 Une protection contre les logiciels malveillants est-elle intégrée au niveau du réseau, par exemple sur les pare-feu, les dispositifs proxy et/ou sur le réseau en tant que solutions distinctes ?

Voir Pratiques 1.12

1.21 Le processus de développement logiciel inclut-il une évaluation intégrée des menaces ?

Oui. C’est la principale raison pour laquelle nous privilégions l’approche de résolution des problèmes de sécurité “par conception”. En éliminant des classes entières de menaces à l’étape de la conception, nous rendons la pratique globale d’évaluation des menaces plus gérable. L’évaluation des menaces couvre également les “attaques de la chaîne d’approvisionnement”. C’est une autre raison pour laquelle nous mettons autant l’accent sur la réduction au minimum du nombre de dépendances tierces dans notre pile logicielle, car toute dépendance augmente intrinsèquement 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 rançongiciel, il arrive parfois que les données de Lokad deviennent accidentellement le seul ensemble de données encore accessible. En cas de vol d’identité, il arrive parfois que des tentatives d’accès au compte Lokad soient effectuées à l’aide d’identifiants volés. Les détails des différents processus de gestion des incidents sont établis conjointement avec l’entreprise cliente et supervisés par le scientifique de la supply chain chez Lokad responsable du compte (pour les clients qui optent pour un compte géré).

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

Oui, bien que ces examens soient généralement effectués régulièrement tout au long de l’année. Ces examens sont généralement motivés par des événements importants, 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 soutien qui pourraient avoir un impact sur 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 soutien” en dehors de quelques fondamentaux de base, tels que le stockage Blob 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 les droits d’accès appropriés sont utilisés pour exécuter les processus système. Lokad utilise des démons sous la forme de services systemd, qui s’exécutent toujours en tant qu’utilisateurs avec le moins 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 dicter les droits d’accès des processus planifiés et déclenchés. Ces processus sont catégorisés comme des processus “utilisateur” plutôt que des processus “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 de l’entreprise ?

Oui, nous avons un plan de gouvernance des risques formalisé en place qui a été approuvé par la direction générale.

Ce plan définit 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 dans l’ensemble de l’entreprise de manière structurée et cohérente.

Notre plan de gouvernance des risques est périodiquement examiné et mis à jour pour garantir qu’il reste pertinent et aligné sur nos objectifs organisationnels et 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 direction générale 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 un responsable a-t-il été désigné pour le maintenir et le revoir ?

Oui, nous avons mis en place un programme complet de sécurité physique qui a été approuvé par la direction générale. Ce programme a été largement communiqué à toutes les parties prenantes concernées pour garantir la sensibilisation et le respect.

De plus, nous avons désigné un responsable chargé de maintenir, mettre à jour et revoir périodiquement le programme afin d’en assurer l’efficacité et la pertinence. Ce responsable collabore avec différentes équipes et départements pour traiter les problèmes de sécurité physique émergents et veiller à ce que le programme soit conforme aux meilleures pratiques et à nos objectifs organisationnels.

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

Oui, les évaluations des risques physiques et environnementaux font partie intégrante de notre processus de prise de décision lors de la détermination 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 Microsoft Azure, nous bénéficions du processus rigoureux de sélection et d’évaluation de site de Microsoft. Microsoft Azure effectue des évaluations approfondies des risques potentiels, y compris les risques physiques et environnementaux, avant d’établir l’un de leurs centres de données. Leur processus de sélection implique l’analyse de facteurs tels que le potentiel de catastrophe naturelle, l’accessibilité, la stabilité de l’infrastructure, et plus encore.

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

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

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

En 2001, le scandale Enron a révélé que l’entreprise était impliquée dans une fraude comptable massive, ce qui était évidemment en contradiction avec les principes énoncés dans leur code d’éthique. Il y avait donc une déconnexion totale entre l’éthique professée et écrite d’Enron et les pratiques commerciales réelles et la culture d’entreprise.

Ainsi, Lokad se concentre sur le fait de s’assurer que les employés ont la possibilité de se soucier véritablement de nos clients. “Faisons-nous les bonnes choses ?” est l’un de nos mantras. La conformité et l’éthique sont, selon nous, les produits dérivés d’une culture d’entreprise adéquate, et non le résultat d’un programme en particulier.

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

Oui. Bien que Lokad ne soit pas assez grand pour disposer d’un service autonome dédié à la réalisation d’audits internes, à la gestion des risques ou à la conformité, nous accordons certainement la priorité à ces domaines. Nous avons désigné des personnes compétentes dans ces domaines qui sont spécifiquement chargées de gérer et de superviser ces responsabilités essentielles.

Ces personnes rendent directement compte à la direction supérieure de Lokad, garantissant que la résolution de tout problème réglementaire ou de conformité en suspens est traitée avec la plus grande priorité et bénéficie de la surveillance 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 concernées et un responsable désigné pour en assurer le suivi et l’examen ?

Oui, Lokad dispose d’une politique sans fil bien définie qui a été approuvée par la direction et communiquée à toutes les parties concernées pour garantir le respect de celle-ci. Cette politique fait la distinction entre deux réseaux Wi-Fi indépendants et isolés : l’un dédié aux employés et l’autre spécifiquement réservé aux invités. Cette distinction garantit que nos opérations principales restent sécurisées, même lorsque nous fournissons une connectivité aux invités ou aux visiteurs.

Cependant, il est important de noter que notre mode de connexion principal se fait via Ethernet, privilégié en raison de ses performances supérieures et de sa sécurité renforcée. Les réseaux Wi-Fi sont principalement mis en place pour accueillir des réunions et offrir une flexibilité dans certains scénarios.

De plus, nous avons désigné un responsable de la politique chargé de sa maintenance et de son examen périodique, garantissant ainsi qu’elle reste à jour et efficace pour répondre aux besoins et aux défis en constante évolution.

2. Authentification

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

Oui. L’accès aux données des clients et/ou à toute fonctionnalité importante de la solution nécessite une authentification préalable. Cependant, par nécessité, certains points de contact ne sont pas soumis à une authentification préalable. Par exemple, l’accès à la page de connexion ne nécessite pas d’authentification préalable (puisque l’authentification est l’objectif principal de cette page de connexion).

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

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

Oui. La sécurisation des accès à distance signifie disposer de la bonne authentification, de la bonne autorisation et du chiffrement du canal de transport lui-même, ce que nous imposons. Cette disposition concerne à la fois les utilisateurs clients et les employés de Lokad. Même pour l’équipe d’ingénierie de Lokad, il n’y a pas d’“accès local non sécurisé” à nos systèmes de production. Nous n’utilisons aucune sorte de “localité” réseau comme moyen de contourner la sécurité.

2.3 Proposez-vous une authentification unique (SSO) ? Prenez-vous en charge Active Directory (AD) ?

Oui. Nous proposons une authentification unique (SSO) via le protocole SAML. Active Directory prend en charge 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 une authentification déléguée via SAML. Grâce à SAML, Lokad ne gère ni le premier facteur d’authentification ni le second, car ce processus est 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 pris en charge par les principaux systèmes d’identité fédérés, tels que Microsoft Office 365 ou Google Workspace. Le défi de la prise en charge d’OAuth2 est qu’OAuth2 n’est pas réellement un “protocole d’authentification”, mais un ensemble de directives très étendues pour concevoir des “protocoles d’authentification” qui peuvent diverger de plusieurs façons.

En conséquence, nous constatons que les différentes implémentations d’OAuth2 qui existent dans le domaine des logiciels d’entreprise ont tendance à être largement incompatibles. Ainsi, si OAuth2 est une exigence absolue, en vertu d’un accord contractuel, nous pouvons prendre en charge une variante spécifique d’OAuth2. Cependant, cet arrangement nécessite des ressources dédiées pour garantir la compatibilité avec la variante d’OAuth2 utilisée par l’entreprise cliente.

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

Oui, via une couche intermédiaire de pontage SAML sur LDAP. Cependant, la majorité des systèmes d’identité fédérés prenant en charge LDAP prennent également en charge SAML. Nous recommandons donc d’utiliser directement SAML.

2.7 Exigez-vous une authentification à deux facteurs ?

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

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

Oui, mais dans une certaine mesure. En ce qui concerne la sécurité logicielle, l’exigence d’une complexité minimale des mots de passe est maintenant largement reconnue comme une mauvaise pratique. Les utilisateurs finaux réagissent mal (et de manière prévisible) aux exigences de complexité des mots de passe trop strictes, ce qui nuit au niveau global de sécurité. De plus, nous considérons de telles exigences de mots de passe comme des “logiciels superflus” qui augmentent la complexité d’un logiciel critique en termes de sécurité (gestion des mots de passe), exposant ainsi celui-ci (et la solution globale) à des risques indus. Voir https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Nous recommandons vivement d’utiliser SSO au lieu de mots de passe/stratégies traditionnels. Grâce à 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 planifiées ?

Nous pourrions le faire, mais nous ne le faisons pas. Tout comme la complexité minimale des mots de passe (voir Authentification 2.8), la rotation planifiée des mots de passe est maintenant largement reconnue comme une mauvaise pratique en matière de sécurité logicielle. Les utilisateurs finaux réagissent mal (et de manière prévisible) aux rotations planifiées des mots de passe. La sécurité peut même s’affaiblir car les employés apportent souvent de légères modifications aux mots de passe (afin de réduire la charge cognitive associée aux rotations fréquentes). Tout comme la complexité minimale des mots de passe, nous considérons la rotation des mots de passe comme des “logiciels superflus” qui augmentent la complexité d’un logiciel critique en termes de sécurité (gestion des mots de passe), exposant ainsi celui-ci (et la solution globale) à des risques indus. Voir https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hash et salage des 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 SSO (Single Sign-On) plutôt que d’utiliser des mots de passe/stratégies traditionnels. Grâce à SSO, il n’est pas nécessaire d’introduire un mot de passe dédié à Lokad.

2.11 La solution de Lokad permet-elle d’activer CAPTCHA après un certain nombre d’échecs d’authentification ?

Oui, mais via la délégation d’authentification (via SSO). Bien que les CAPTCHA soient une approche précieuse pour atténuer quelques vecteurs d’attaque, ils font partie des composants logiciels qui sont préférables à laisser entièrement en dehors du champ d’application 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 claire que dans le cas des logiciels B2C, en particulier les logiciels gratuits.

2.12 Avez-vous une politique de sécurité générale pour les mots de passe ? Avez-vous un processus pour l’appliquer ?

Oui. Notre politique de sécurité générale pour les mots de passe est “pas de mots de passe”. Nous recommandons vivement SSO, ce 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é mis en place 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 d’utilisateurs génériques/partagés ?

Non. Lokad impose une relation de 1 à 1 entre les employés et les utilisateurs (tels qu’ils apparaissent dans la plateforme Lokad). Nous déconseillons fortement l’utilisation de comptes d’utilisateurs partagés. En fait, l’une des raisons pour lesquelles nous ne facturons pas par utilisateur est d’éviter de donner à nos clients une incitation à partager des comptes d’utilisateurs entre leurs employés. Cependant, il existe quelques cas où il est acceptable d’avoir un compte d’utilisateur qui n’a pas de correspondant employé. Cela se produit généralement pour le service côté client “robot upload” chargé de pousser des données vers Lokad. Dans le cadre de notre RBAC (Contrôle d’Accès Basé sur les Rôles), nous avons 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 sont utilisées via des canaux chiffrés (typiquement TLS).

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

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

2.17 La solution a-t-elle la capacité de verrouiller et/ou de déconnecter de force un utilisateur (s’il est considéré comme malveillant) ?

Oui. Cette fonctionnalité nécessite des droits d’accès “Propriétaire” dans le compte Lokad.

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

Oui, bien que “l’inactivité” ne soit pas le facteur déterminant. Lokad se déconnecte automatiquement des utilisateurs après une période de temps spécifiée. Les utilisateurs ne peuvent pas retarder la déconnexion en étant “actifs”; une fois la période de temps spécifiée écoulée, les utilisateurs doivent se réauthentifier.

2.19 L’utilisation de comptes partagés et/ou de références d’accès est-elle interdite, et la conformité à ces politiques est-elle surveillé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 médias 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 nous assurons qu’elles sont 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 d’utilisateur et les mots de passe initiaux sont distribués, Azure Active Directory suit ses modèles par défaut, conçus dans une optique de sécurité. De plus, nous imposons l’authentification à deux facteurs pour notre Azure AD, ajoutant ainsi une couche de sécurité supplémentaire au processus d’authentification.

En externe, pour les employés des clients se connectant à nos systèmes, nous recommandons vivement l’utilisation de la connexion unique (SSO) et des systèmes d’identité fédérés. Ces systèmes, par conception, respectent les meilleures pratiques en matière de gestion des informations d’identification, en veillant à ce que celles-ci soient communiquées de manière sécurisée, impliquant souvent des canaux ou des méthodes de communication distincts pour les identifiants d’utilisateur et les mécanismes d’authentification.

Il convient de noter que nous ne recommandons pas l’authentification à un seul facteur, 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 d’utilisateur 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 d’utilisateur pour garantir la sécurité. Pour les employés de Lokad, notre politique prévoit que tous les droits d’accès sont révoqués le dernier jour de leur emploi, garantissant qu’il n’y a pas d’accès après l’emploi pour les anciens employés.

Pour nos clients, nous préconisons l’utilisation de la connexion unique (SSO) et des systèmes d’identité fédérés. Cette approche simplifie la gestion des accès. Par exemple, lorsque le client supprime un employé de son système d’identité, l’accès à Lokad est simultanément interrompu. Cette méthode améliore non seulement la sécurité, mais garantit également l’efficacité de la gestion des utilisateurs.

Remarque : les détails concernant la résiliation de l’accès utilisateur 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. Pour éviter les interruptions involontaires, les modalités 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 sont conformes aux besoins opérationnels de notre client.

3. Autorisation

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

Oui. La solution Lokad comprend un sous-système granulaire de contrôle d’accès basé sur les rôles (RBAC - Role-Based Access Control). Cela permet au client de contrôler les “Projets” et les “Fichiers” accessibles (et par qui) dans le compte Lokad. Le RBAC dispose de sa propre interface utilisateur web (tableau de bord). Il est disponible pour tous les utilisateurs ayant le statut de “Propriétaire” dans le compte Lokad. Consultez notre documentation sur les rôles et les autorisations des utilisateurs pour en savoir plus.

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

Oui. La solution Lokad comprend un sous-système granulaire de contrôle d’accès basé sur les rôles (RBAC - Role-Based Access Control) qui peut être utilisé pour mettre en œuvre le PoLP. Cependant, grâce à Envision (le DSL de la solution), Lokad va beaucoup plus loin que 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 sans pertinence pour l’optimisation de la supply chain. Ce qui reste est rationalisé mais toujours très 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 Appliquez-vous les droits d’accès du moindre privilège ?

Oui, bien que ce qui constitue le privilège “le moins acceptable” soit finalement décidé par nos clients. Lokad ne peut pas déterminer unilatéralement qui bénéficie du statut de “Propriétaire” au sein du personnel de notre client. Cependant, nous pouvons fournir des conseils à cet égard. En pratique, pour nos clients “gérés” - ceux qui sont soutenus 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 du système pour les utilisateurs désignés ?

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

3.5 Avez-vous une classification en place pour les données (niveaux de sensibilité) et des contrôles ajustés en fonction de cette classification ?

Oui. En tant qu’élément intégré, Lokad restreint, par défaut, toutes les données administratives (telles que la liste des utilisateurs ayant un compte) aux “Propriétaires” du compte. Ce statut est le plus élevé et le plus privilégié du RBAC (Role-Based Access Control). Toutes les autres données dans le compte Lokad peuvent être segmentées en fonction d’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 d’origine (telles que téléchargées par le client) et aux données transformées (résultat des transformations de données effectuées dans la plateforme 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 produisent de manière synchrone, ce qui signifie que les mises à jour deviennent actives en quelques secondes (généralement moins). Il n’y a pas de délais perceptibles (comme une période d’attente d’une heure ou d’une journée).

En ce qui concerne l’interruption des transactions, cela n’est pas pertinent car Lokad ne dispose pas d’une base de données transactionnelle. Cela dit, Lokad peut interrompre des opérations asynchrones de longue durée (appelées “exécutions de projet” chez Lokad). Lorsqu’une interruption est déclenchée, elle garantit immédiatement (de manière synchrone) que le traitement n’affectera pas le système, comme l’écrasement de fichiers. Cependant, l’arrêt du traitement est asynchrone et prend généralement effet dans les 20 secondes.

3.7 La solution restreint-elle l’accès aux informations d’identification personnelles (PII) uniquement aux utilisateurs disposant du niveau d’autorisation approprié ?

Oui, bien que la solution ne soit pas destinée à stocker des données PII (au-delà des identifiants d’authentification des employés ayant accès à la solution). Cela est vrai à la fois pour Lokad et pour le client. Dans la solution, seuls les employés ayant la désignation “Propriétaire” ont accès à la liste des utilisateurs. Aux fins d’optimisation de la supply chain, Lokad n’a pas besoin (et ne bénéficie pas) de données PII, et nous avons des stipulations contractuelles en ce sens (expliquées dans Pratiques 1.4 et Pratiques 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 d’interdire les recherches de données PII avec des caractères génériques ?

Oui. Cependant, un utilisateur ayant la désignation “Propriétaire” 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é car nos clients doivent être en mesure d’auditer intégralement 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 de sécurité du “privilège minimal” : un composant se voit accorder d’énormes privilèges afin de fonctionner comme un “homme du milieu”. Cela fait du WAF lui-même une cible privilégiée pour les attaquants et cela étend considérablement la surface d’attaque de la plateforme. Cependant, Lokad surveille de près son trafic web et les comportements anormaux des utilisateurs sur notre propre plateforme. Ces capacités font partie intégrante de la plateforme elle-même et ne sont donc pas déléguées à des composants logiciels tiers isolés privilégiés.

Voir aussi Employés 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 de sécurité du “privilège minimal” : un composant se voit accorder d’énormes privilèges afin de fonctionner comme un “homme du milieu”. Cela fait de l’IPS lui-même une cible privilégiée pour les attaquants et cela étend considérablement la surface d’attaque de la plateforme. Afin de renforcer la sécurité de la plateforme Lokad contre les intrusions, notre conception commence par minimiser la surface d’attaque. Nous pensons qu’il est beaucoup plus sûr d’éliminer les voies d’intrusion dès la conception plutôt que d’essayer de les “prévenir” a posteriori.

Voir aussi Employés 6.6.

3.11 Le service utilise-t-il une technologie de protection contre les attaques par déni de service (DoS) ?

Oui. Lokad utilise ReCaptcha, des limites de débit nginx et nos propres composants spécifiques (comme l’échec précoce lorsque l’authentification est invalide).

3.12 Tout accès administratif à l’environnement de production est-il effectué via des hôtes de saut ou des serveurs bastion ?

Oui. Nous avons 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 d’autorisation clair pour l’octroi d’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), où les droits d’accès administratifs sont vérifiés par rapport à tous les rôles et fonctions modifiés ?

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

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

Deuxième 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 responsable 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/un Supply Chain Scientist.

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

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

Voir aussi Autorisation 3.3.

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

Non, les connexions sortantes de l’environnement de production ne sont pas universellement restreintes. Bien que certains serveurs spécialisés, tels que les équilibreurs de charge, aient des restrictions sortantes, la majorité de nos serveurs n’en ont pas.

Nos machines virtuelles de production nécessitent un accès à plusieurs API externes. Une grande partie de ces API sont hébergées par Microsoft Azure, à quelques exceptions près comme letsencrypt.org. Nous avons déterminé que maintenir une liste blanche rigoureuse d’adresses IP introduirait des complexités qui pourraient compenser les avantages. Restreindre les connexions sortantes pourrait offrir des avantages de sécurité limités, mais pourrait également introduire des complications qui pourraient compromettre 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 heures sur 24, 7 jours sur 7, 365 jours par an pour signaler des incidents de sécurité ?

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

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

Notre fichier security.txt peut être trouvé à l’adresse https://www.lokad.com/.well-known/security.txt et il décrit le processus à jour pour signaler les incidents de sécurité. Cela garantit que toute personne, qu’il s’agisse d’un client, d’un client ou d’un chercheur en sécurité, peut facilement trouver les coordonnées pertinentes et les directives sur la manière de signaler les problèmes de sécurité.

Veuillez noter que bien que le processus détaillé dans le fichier ‘security.txt’ puisse être révisé, les informations les plus récentes et les plus précises seront toujours disponibles à cet emplacement. Nous veillons à ce que les canaux de communication mentionnés dans le fichier, qu’il s’agisse d’un e-mail, d’un formulaire web ou d’un autre moyen, soient disponibles 24 heures sur 24, 7 jours sur 7, 365 jours par an pour traiter rapidement les rapports 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 avons des plans de contingence pour migrer la plateforme vers Dublin. Depuis notre migration vers Microsoft Azure en 2010, nous n’avons jamais été confrontés à 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 possède les données ?

Nos clients restent les seuls propriétaires de toutes les données qu’ils téléchargent sur Lokad. Nos clients restent é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 les données de ses clients à des fins autres que celles qui contribuent directement aux tâches que nos clients nous ont confiées. Lokad ne revend pas l’accès aux données de nos clients à des tiers. Lokad ne partage pas l’accès aux données des clients, sauf pour les quelques fournisseurs d’hébergement qui contribuent directement à la tâche en cours (par exemple, 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 géré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 principale de Lokad ne comprend pas de base de données transactionnelle (voir Autorisation 3.6), car Lokad utilise plutôt un magasin d’événements. Ce magasin d’événements est mis en œuvre et exploité entièrement par Lokad.

4.4 La solution a-t-elle la capacité de passer d’une base de données RDBMS (PostgreSQL, Oracle, MySQL) à une base de données NoSQL (Cosmos) ?

Théoriquement, oui, mais cela est inutile car la solution Lokad n’utilise pas de RDBMS. La couche de persistance des données de la solution Lokad s’appuie sur un magasin d’événements et un magasin clé-valeur. Cette approche diffère considérablement de la conception CRUD (Create-Read-Update-Delete) couramment utilisée 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 l’accessibilité des anciennes données).

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

Oui, notamment la plateforme de cloud computing sous-jacente utilisée par Lokad - Microsoft Azure. La liste des tiers impliqués dans l’exécution de la solution est très courte et se limite à l’hébergement de l’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 de bas niveau des réseaux et des serveurs est déléguée à la plateforme de cloud computing sous-jacente utilisée par Lokad - 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 (par exemple, les couches applicatives n’ont aucun accès en écriture à la gestion du DNS).

4.7 Avez-vous un processus pour assurer la suppression permanente des données ?

Oui, bien que cela puisse prendre plusieurs semaines pour effectuer toutes les étapes. Le processus implique de faire une demande écrite formelle - émise par une partie autorisée au sein de l’organisation cliente - pour que les données correspondantes soient supprimées de manière permanente. En pratique, des dispositions spécifiques pour 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 est la cause de la “lenteur” relative de l’opération. Il s’agit d’un choix de conception, car une fois les données supprimées de notre système principal, elles ne peuvent plus être consultées (sauf via des processus extraordinaires de récupération après sinistre).

Par défaut, la solution Lokad garantit que toutes les opérations de suppression standard sont des suppressions douces (c’est-à-dire non permanentes). Cette conception est nécessaire pour éviter des classes entières 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 nécessaire pour atténuer les attaques d’ingénierie sociale, telles qu’un scénario dans lequel un attaquant se fait passer pour un employé d’un client.

4.8 La solution a-t-elle la capacité de supprimer des données de manière douce ?

Oui. La solution Lokad adopte une conception basée sur l’événement. Ainsi, tout est versionné par défaut, à la fois les entrées utilisateur et les modifications apportées au système de fichiers de Lokad. Ainsi, toutes les suppressions logicielles sont des suppressions douces, et elles peuvent être retracées et annulées, si nécessaire.

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

Oui, dans le sens où le système de fichiers - faisant 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 utilisées en tant qu’entrées ou produites en tant que sorties sont stockées dans ce système de fichiers.

Cependant, Lokad n’ayant pas de base de données transactionnelle, il n’y a pas de base de données sous-jacente qui pourrait être rendue “accessible”. L’équivalent le plus proche dans l’architecture de Lokad est notre journal d’événements et nous n’offrons pas d’accès direct au flux d’événements. Cependant, des dispositions pourraient être prises 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 valide).

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 toutes les données tabulaires raisonnables. Pour en savoir plus sur les capacités d’intégration de données externes de Lokad, consultez Go to IT Perspective on Lokad 2.15.

4.11 Le système a-t-il la capacité de traiter les données de modification en temps réel (CDC) provenant de flux de données ?

Oui, sous réserve d’un accord contractuel spécifique avec le client. La capture de données de modification est un modèle de conception logicielle - pas une norme de données spécifique ou un protocole de transfert de données spécifique - et les attentes en matière de “temps réel” peuvent varier des latences sub-millisecondes aux latences sub-minutes. Les fonctionnalités dans ce domaine doivent être évaluées du point de vue de la supply chain. D’après notre expérience, les flux de données en temps réel sont rarement pertinents pour résoudre les problèmes de supply chain.

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

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

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

Oui, la solution Lokad propose un DSL (domain-specific language) appelé Envision, spécialement conçu pour l’analyse de la supply chain. Envision offre des capacités étendues pour reformater les données dans le compte Lokad.

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

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

4.15 La solution dispose-t-elle d’un chiffrement transparent des données (TDE) des données d’identification personnelle (PII) dans le stockage mobile et en arrière-plan ?

Le chiffrement transparent des données est utilisé à la fois sur le stockage en arrière-plan de Lokad (via le chiffrement du stockage Azure pour les données au repos) et sur les appareils émis par Lokad (via BitLocker). Lokad ne stocke pas de PII sur les appareils sans TDE activé.

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

Oui. Tous les secrets au niveau de la plateforme sont stockés dans Key Vault, un service proposé par Microsoft Azure. Les mots de passe des utilisateurs sont internement salés et hashés avec Scrypt selon les 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 rechercher des contenus malveillants ?

Oui, dans une certaine mesure. En ce qui concerne la taille des fichiers, l’optimisation de la supply chain nécessite fréquemment le traitement de fichiers volumineux. Ces tailles de fichiers reflètent l’extraction des données commerciales historiques que nous traitons ultimement (par exemple, les commandes de vente historiques). Compte tenu de cette réalité, la plateforme Lokad prend en charge des tailles de fichiers allant jusqu’à 100 Go.

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

En ce qui concerne la capacité à rechercher des contenus malveillants, Lokad ne dispose pas de 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. En revanche, grâce à sa conception, la solution Lokad dévalorise le partage de contenu téléchargé par l’utilisateur via Lokad.

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

Lokad est un service SaaS, nous avons donc la responsabilité de choisir la période de conservation des données appropriée, et cette durée varie en fonction du type de données. Les données historiques transactionnelles, transmises à Lokad par le client via le 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, qui reflètent les performances détaillées de notre plateforme. Ces données ne sont utiles que pour résoudre les 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 “Manuel de procédure conjointe”. Il convient de noter que Lokad n’utilise pas de base de données relationnelle, contrairement à la plupart des logiciels d’entreprise. Nous utilisons plutôt un paradigme de sourcing d’événements. Cependant, les structures de données d’intérêt (pour l’entreprise cliente) ne se trouvent pas dans la source d’événements, mais dans les fichiers plats produits par les scripts Envision au sein de la plateforme Lokad. Ces fichiers plats sont conçus pour répondre aux exigences spécifiques de l’entreprise cliente. La documentation de ces fichiers est incluse dans le “Manuel de procédure conjointe” - qui est l’un des livrables d’une initiative Lokad typique.

4.20 La segmentation des données des 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 en back-end. Cette conception empêche les erreurs de programmation qui exposeraient les données d’un locataire à un autre locataire, tout en développant davantage de 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 garantir que les données des clients ne sont pas utilisées dans les environnements de développement et de test ?

Oui, par défaut, l’équipe d’ingénierie logicielle n’a pas accès direct aux données des clients. Nous avons développé des environnements de données “mock” et des ensembles de données “mock” pour permettre à l’équipe d’ingénierie logicielle de fonctionner en douceur sans accéder aux données des clients. Lokad utilise également en interne sa propre plateforme à des fins de traitement des données (par exemple, l’analyse de la consommation détaillée des ressources informatiques en nuage obtenues auprès de Microsoft Azure). Cette pratique du “dogfooding” garantit que Lokad dispose également d’une abondance de données non critiques à utiliser à des fins de développement et de test.

Cependant, nous avons mis en place un pipeline restreint spécial pour accéder à des fragments minimaux (en lecture seule) des données des clients à des fins de diagnostic. Ce pipeline garantit automatiquement une minimisation stricte et entièrement automatisée des données récupérées. Ce pipeline garantit également automatiquement la suppression des données à la fin de l’opération de diagnostic. Voir 4.22 pour plus de détails sur ce pipeline restreint.

4.22 Si le développement ou les tests nécessitent une utilisation limitée des données des clients, 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 mis en place un pipeline de données spécial (en lecture seule) dédié à l’utilisation exceptionnelle des données des clients à des fins de diagnostic - généralement des tests de performance. Ce pipeline de données n’est accessible qu’à une partie restreinte de l’équipe d’ingénierie logicielle.

Ce pipeline de données a été conçu pour minimiser automatiquement le fragment des données des clients récupérées pour le diagnostic d’intérêt. Cette fonctionnalité nous permet de travailler avec ce qui correspond généralement à une très petite fraction des données d’origine (telles qu’elles se trouvent dans le compte client). De plus, cela élimine la nécessité pour l’équipe d’ingénierie de sélectionner manuellement les données à récupérer.

Enfin, ce 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 des clients sont-ils connus et documentés, y compris les systèmes de sauvegarde et de haute disponibilité ?

Oui. Toutes les données des clients 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 des clients localement (c’est-à-dire sur les locaux de Lokad), et les données des clients ne sont pas stockées 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 emplacement auquel Lokad n’a pas accès physiquement. L’emplacement physique des centres de données de Microsoft est une connaissance publique, et le choix de Lokad en matière de centres de données est documenté publiquement.

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

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

Le PAN (Primary Account Number) fait généralement référence au numéro principal d’une carte de crédit ou d’une carte de débit. Il s’agit de 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 lié à la carte.

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

Nous avons quelques PAN - pour les propres 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 des technologies de messagerie utilisées par les utilisateurs finaux (par exemple : par e-mail, messagerie instantanée et chat) ?

Non, les PAN (Primary Account Numbers) non chiffrés ne sont jamais envoyés via des canaux non sécurisés tels que l’e-mail. Lokad propose un canal de communication sécurisé intégré à sa plateforme, qui est une alternative supérieure pour la transmission de documents sensibles. Nous recommandons ce canal chaque fois que l’utilisation d’un canal non sécurisé présente un risque commercial significatif.

Remarque : Par conception, Lokad ne reçoit, ne stocke ni ne gère aucun PAN de client. Par conséquent, il n’y a pas de transferts de PAN non chiffrés.

Voir également le stockage des PAN

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

Oui, Lokad a un accord d’entreprise (EA) avec Microsoft pour les services de cloud computing Azure. L’accord d’entreprise comprend généralement différentes modalités et conditions liées à 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 entreprises.

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 satisfaits que cet accord réponde à nos exigences et normes de sécurité.

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

Non, Lokad ne sous-traite pas le traitement des informations ou des données des clients. En ce qui concerne la plateforme de Lokad, nous achetons des ressources informatiques - principalement des machines virtuelles et du stockage blob - auprès de Microsoft Azure, mais à part cela, aucune tierce partie n’est impliquée en ce qui concerne les données des clients.

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 des clients. Lokad a occasionnellement quelques stagiaires (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 de supply chain scientists seniors.

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

5. Journalisation et surveillance

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

Oui. Lokad fournit des journaux d’accès au format CSV. À l’heure actuelle, ces journaux peuvent être demandés auprès du personnel de support de Lokad. L’extraction des journaux sera placée dans le compte Lokad, dans un endroit accessible uniquement aux utilisateurs ayant la désignation “Propriétaire”. 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 backend de la plateforme Lokad.

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

Oui. La conception de Lokad basée sur l’événementialité 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 avec une petite collection de flux d’événements, gérés par le même magasin d’événements. En interne, les journaux qui n’ont pas d’impact sur l’état de la solution sont séparés de ceux qui en ont.

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

5.3 Enregistrez-vous les modifications et les opérations effectuées dans l’application ? Suivez-vous toutes les transactions ?

Oui. En raison de la conception basée sur l’événementialité de Lokad, tout est enregistré par nécessité. En fait, la solution elle-même est la somme de la collection d’événements enregistrés au sein de la solution. Ainsi, la journalisation est un aspect fondamental de l’architecture de la solution. Cette conception basée sur l’événementialité empêche l’omission accidentelle d’un journal qui reflète un changement d’état. Dans un tel cadre basé sur l’événementialité, il n’y a pas de transactions, du moins pas au sens habituel d’une base de données transactionnelle (par exemple, MySQL, Oracle, etc.). Ces transactions sont remplacées par des événements qui contiennent toutes les informations associées à un changement d’état.

5.4 Normalisez-vous les formats de journal des différents composants à des fins d’investigation ?

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

5.5 Offrez-vous des exportations de journaux à 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 générées dans votre solution ?

Oui. La conception basée sur l’événementialité de Lokad nous permet de suivre toutes les exceptions générées dans notre solution et de reproduire les conditions qui ont conduit au problème en premier lieu. Une fois identifiées, l’équipe d’ingénierie de Lokad élimine toutes les exceptions observées. Nous avons développé des outils dédiés à cette fin spécifique et nous conservons une liste d’exceptions non corrigées très limitée.

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

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

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

5.8 La solution a-t-elle la capacité d’intégrer des outils de surveillance tiers ? La solution prend-elle en charge SNMP ou JMX, ou la possibilité d’envoyer des événements SNMP et JMX à des solutions de surveillance 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 achèvement ?

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 - généralement l’exécution de scripts Envision. Ce planificateur peut être configuré, via une interface utilisateur web, pour spécifier un planning et une plage horaire d’exécution pour toute séquence de tâches.

5.10 La solution a-t-elle la capacité de produire 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 diagnostiquer automatiquement les situations afin de prendre des mesures proactives. Bien que la plateforme Lokad offre cette capacité, elle nécessite toujours l’intervention d’un ingénieur pour implémenter - via Envision - la logique réelle, car les situations de la supply chain qui sont qualifiées d’“erreurs” peuvent varier.

5.11 La solution dispose-t-elle de capacités de conservation 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 basée sur l’événement, la solution Lokad conserve une trace d’audit étendue, bien supérieure à ce qui est obtenu avec des conceptions plus courantes qui utilisent généralement une base de données transactionnelle au lieu d’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 trace d’audit. Plus généralement, Lokad conserve les données de production pendant la durée du service avec le client. À la fin du service, qui dépend des modalités contractuelles négociées, les données du client sont purgées, bien que la suppression finale 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 largement effectuée avec une approche “système”, garantissant que les capacités de la plateforme (y compris son profil de performance) sont conformes aux normes. Nous avons conçu notre propre couche d’instrumentation à cette fin. La surveillance “fonctionnelle” est généralement spécifique à chaque client car elle dépend des spécificités de la supply chain donnée. Cette surveillance est généralement assurée par les équipes de scientifiques de la supply chain (les ingénieurs fournis par Lokad), conformément à l’accord contractuel.

Les scientifiques de la supply chain de Lokad se spécialisent généralement dans une classe particulière de compte client (par exemple, l’aérospatiale). Ils créent une instrumentation de surveillance sur mesure en utilisant le compte Lokad. Cette surveillance inclut notamment la vérification de l’exactitude des chiffres fournis par Lokad, non seulement d’un point de vue technique, mais aussi du point de vue métier du client.

5.13 Les journaux sont-ils examinés et analysés de manière opportune et systématique afin de détecter les anomalies et les indications de violation ?

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 Journalisation et surveillance 5.2.

5.14 Les analyses de vulnérabilités au niveau de l’application sont-elles effectuées périodiquement et systématiquement ?

Oui, bien que de telles analyses ne représentent qu’une très petite partie de nos processus de sécurité. Voir Employés 6.6.

5.15 Existe-t-il un processus défini pour l’examen périodique des règles de pare-feu effectives ?

Oui, notre machine de production est doté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 révision du code. Cette pratique facilite non seulement les examens périodiques, mais atténue également la nécessité de réviser manuellement les règles en premier lieu.

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

Non. IDS est une conception intrinsèquement dangereuse car elle viole le principe de sécurité du “moindre privilège” : un composant se voit accorder des privilèges énormes afin de fonctionner en tant que “homme du milieu”. Cela fait de l’IDS lui-même une cible privilégiée pour les attaquants et étend considérablement la surface d’attaque de la plateforme. Cependant, Lokad surveille de près son trafic web et les comportements anormaux des utilisateurs sur notre propre plateforme. Ces capacités font partie intégrante de la plateforme elle-même et ne sont donc pas déléguées à des composants logiciels tiers isolés privilégiés.

Voir aussi Employés 6.6.

6. Employés

6.1 Les employés sont-ils soumis à des accords de non-divulgation (NDA) ?

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 dispensées 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 Cybersécurité pour la Supply Chain est dédiée aux scientifiques de la supply chain - les personnes qui manipulent les données confidentielles des clients.

6.3 Qui a accès aux données des clients 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 à différentes classes de données du client. Il existe une application web au sein de la solution Lokad dédiée à la gestion des autorisations (nommée “Hub”).

Du côté de Lokad, pour chaque compte client, il existe une liste restreinte d’employés ayant accès. Tout d’abord, cette liste comprend les scientifiques de la supply chain (les ingénieurs fournis par Lokad) qui mettent en œuvre et maintiennent la solution d’optimisation de la supply chain. Ces scientifiques de la supply chain sont censés accéder aux données du client quotidiennement. En interne, Lokad restreint l’accès aux comptes clients uniquement aux scientifiques de la supply chain assignés à ces comptes. Autrement dit, le scientifique de la supply chain A ne peut pas accéder au compte client B à moins que A n’ait été explicitement assigné pour gérer ce compte (comme convenu avec le client).

Ensuite, cette liste comprend 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 des clients est rare et limité à l’investigation de situations signalées soit par les clients eux-mêmes, soit par leurs scientifiques de la supply chain de soutien. Lokad ne partage pas l’accès aux données des 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 travaillent sans privilèges administratifs sur leurs appareils fournis par l’entreprise. Tous les postes de travail sont configurés avec un chiffrement complet du disque pour se protéger contre le vol de données qui pourrait être causé par la perte, le vol ou la confiance accordée à des 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 garder toutes les données des clients sécurisées 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, comme les rappels de calendrier, peuvent être transmises via des appareils personnels (non fournis par l’entreprise), mais les smartphones, comme les postes de travail, ne contiennent pas les données de nos clients. L9 ### 6.6 Utilisez-vous un antivirus ? {#use-an-antivirus}

Oui, nos postes de travail sont équipés de Microsoft Defender, conformément aux configurations de Microsoft Windows 10+. Nous n’avons pas d’autre antivirus en dehors de Microsoft Defender, mais notre attitude est que cette catégorie d’outil a tendance à faire plus de mal que de bien (en termes de sécurité informatique). À titre d’exemple, le piratage SolarWinds de 2020 est considéré comme l’une des plus grandes catastrophes de sécurité informatique de tous les temps, et il a été causé par un logiciel censé améliorer la sécurité en premier lieu. 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. Par conséquent, 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 que l’ajout de pièces de technologie très complexes dans notre paysage applicatif le rend presque invariablement moins sécurisé, pas plus sûr.

6.7 Les développeurs de logiciels sont-ils périodiquement formés aux méthodes d’évaluation des menaces, aux normes de codage sécurisé, aux listes de contrôle de sécurité bien connues et aux frameworks ?

Oui. Cependant, la plupart des listes de contrôle bien connues reflètent principalement des architectures “in-sécurisées par conception”. Dans la mesure du possible, nous préférons éliminer la source des pièges de sécurité dès la phase de conception. Voir aussi Employés 6.2.

6.8 Tous les contrats avec les sous-traitants/la main-d’œuvre externe de Lokad incluent-ils une convention de non-divulgation (NDA) ? Cette NDA couvre-t-elle les informations des clients ?

Oui pour les deux, bien que Lokad - au moment de la rédaction - ne compte pas sur des sous-traitants/une main-d’œuvre externe. Les équipes d’ingénieurs logiciels et de scientifiques de la supply chain de Lokad sont entièrement composées de personnes employées et supervisées directement et de manière permanente par Lokad.

Cependant, si Lokad jugeait nécessaire de faire appel à un sous-traitant, celui-ci serait soumis aux mêmes conditions de propriété intellectuelle (PI) 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 interne de Lokad sur les informations et la sécurité (ainsi qu’une formation continue pertinente) ?

Lokad - au moment de la rédaction - ne compte pas sur des sous-traitants/une main-d’œuvre externe. Les équipes d’ingénieurs logiciels et de scientifiques de la supply chain de Lokad sont entièrement composées de personnes employées et supervisées directement et de manière permanente par Lokad.

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

Comme indiqué précédemment, Lokad ne compte actuellement pas sur une main-d’œuvre externe, donc aucune formation de ce type n’a lieu.

Voir aussi Employés 6.8 L11

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

Lokad - au moment de la rédaction - ne compte pas sur des sous-traitants/une main-d’œuvre externe. Les équipes d’ingénieurs logiciels et de scientifiques de la supply chain de Lokad sont entièrement composées de personnes employées et supervisées directement et de manière permanente par Lokad.

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

Note: Historiquement, bon nombre des incidents les plus importants - et les pires - tels que l’espionnage informatique, sont commis par des personnes ayant des antécédents impeccables. C’est, entre autres raisons, pourquoi Lokad hésite à compter sur une main-d’œuvre externe et préfère vivement les contrats d’emploi directs et sans limite de durée.

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 accorder de droits administratifs car ils ne sont pas nécessaires à l’exécution de leurs fonctions.

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

Oui, des vérifications d’antécédents sont effectuées strictement conformément aux exigences du poste occupé.

Il convient de noter que Lokad ne gère pas en interne les données des cartes de paiement - cela est géré par des tiers. Ainsi, le personnel de Lokad n’a pas accès aux données des cartes de paiement de nos clients.

6.13 Quelles précautions Lokad prend-il pour empêcher les personnes non autorisées d’accéder aux locaux où le travail est effectué ?

Au niveau du bâtiment, Lokad opère dans un immeuble de bureaux bénéficiant d’une surveillance 24h/24 et 7j/7 par des tiers, avec une sécurité sur place.

Au niveau des bureaux, les locaux de Lokad disposent de leurs propres points d’accès sécurisés, indépendants de ceux du bâtiment lui-même. Cette dernière couche empêche les employés d’autres entreprises présentes dans le bâtiment d’accéder aux bureaux de Lokad.

Note: Tout visiteur exceptionnel (comme les clients, les 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 “locaux” signifie “l’endroit où les données des clients sont stockées et traitées”, alors non. Les données des clients 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 parfois des visiteurs dans son siège social. Nos bureaux ne sont pas ouverts au public, mais des circonstances exceptionnelles surviennent parfois, comme la visite de clients, l’attente de candidats à un entretien, etc. Ces visites sont planifiées à l’avance et ces visiteurs sont accompagnés en permanence par des membres du personnel de Lokad dans nos bureaux.

6.15 Les dossiers 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 de dossiers de données 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 avons également un destructeur à côté de l’imprimante. La politique par défaut de Lokad est de ne pas imprimer de document sensible, mais si cela devait être fait théoriquement, notre politique par défaut est également de détruire immédiatement le document imprimé après utilisation.

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

Oui, Lokad applique strictement une politique de bureau vide. Cette politique est appliquée “par conception” grâce à notre environnement numérique.

À l’exception de quelques documents que nous sommes légalement obligés d’imprimer, ou de documents occasionnels imprimés par nécessité (par exemple, une affiche pour un salon professionnel, bien que 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 à “vider”. Une fois que la session informatique de l’employé a été verrouillée - une politique que nous appliquons strictement - le bureau donné est effectivement vidé.

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

Lokad n’a jamais possédé de télécopieur - qu’il soit physique ou virtuel. Nous ne connaissons aucun cas d’utilisation convaincant pour changer notre position sur cette technologie.

6.18 Existe-t-il un processus de vérification du retour des actifs constitutifs (ordinateurs, téléphones portables, cartes d’accès, jetons, cartes à puce, clés, etc.) à la fin de la relation ?

Oui, nous avons non seulement un processus en place, mais aussi un logiciel de gestion des actifs informatiques pour soutenir cet effort et minimiser les erreurs de saisie.

Cependant, nous avons délibérément conçu la sécurité de Lokad de manière à ne pas dépendre du retour en temps voulu des actifs constitutifs. Lokad suppose que tous les actifs constitutifs ont une chance équitable d’être perdus ou volés, quelle que soit la discipline et la formation de nos employés. En pratique, cela arrive très rarement, mais d’un point de vue technique, nous faisons l’hypothèse inverse. Pour cette raison, les actifs constitutifs peuvent être désactivés à distance. De plus, nous appliquons le chiffrement complet des disques chaque fois que cela est possible.

Plus généralement, notre environnement de travail a été conçu de manière à ne pas nécessiter de stockage persistant des données clients sur les postes de travail, les ordinateurs portables ou les téléphones portables. Cette conception atténue considérablement la criticité des actifs constitutifs dans le cas où nos autres mesures préventives viendraient à échouer.

6.19 Les politiques et/ou procédures des ressources humaines (RH) sont-elles approuvées par la direction et communiquées aux parties prenantes, et un responsable est-il désigné pour les maintenir et les examiner ?

Oui, nos politiques et procédures en matière de ressources humaines ont été formellement approuvées par la direction supérieure. Nous accordons une grande importance à la communication claire, et ces politiques et procédures ont donc été largement diffusées à toutes les parties prenantes concernées afin de garantir une compréhension et une conformité totales.

De plus, nous avons désigné un responsable chargé de la maintenance continue, des mises à jour et de l’examen régulier des politiques et procédures. Cela garantit que nos pratiques restent actuelles, pertinentes et conformes aux normes de l’industrie et à nos objectifs organisationnels.

6.20 Des appareils mobiles personnels (BYOD), plutôt que des appareils appartenant à l’entreprise, sont-ils utilisés par des personnes associées à votre organisation qui ont accès aux données des clients ?

Non, Lokad n’autorise pas l’accès aux données des clients sur des appareils mobiles personnels (BYOD). Nous fournissons à nos employés du matériel de haute qualité appartenant à l’entreprise, ce qui élimine le besoin d’appareils personnels. Cette disposition répond au scénario courant où les employés sont amenés à utiliser leurs propres appareils en raison de leur insatisfaction à l’égard du matériel de l’entreprise de qualité inférieure.

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

Notes