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 à l’ingéniosité technologique. Cela dit, nous traitons des données financières importantes au quotidien, donc la sécurité de notre plateforme logicielle est une priorité et nous la traitons avec le plus grand sérieux. Plutôt que d’aborder la sécurité comme une réflexion après coup à gérer à travers la bureaucratie, nous croyons fermement en une approche basé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é

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 travaux bureaucratiques. Malheureusement, les détails des problèmes de sécurité sont toujours en évolution. Les problèmes surviennent lorsque des acteurs mal intentionnés profitent des logiciels ou des personnes (ou des 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 croyons que la conception est l’un des aspects les plus sous-estimés de la sécurité des logiciels. 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 massives 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 des groupes entiers 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 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 inversées. Cette étape complique grandement 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. En conséquence, leurs problèmes de sécurité sont sans fin. Par exemple, si la configurabilité - presque toujours une exigence pour les logiciels d’entreprise - est fournie à travers un langage de programmation généraliste (comme Python ou JavaScript), des problèmes de sécurité surgiront inévitablement. Cela est dû au fait qu’il est presque impossible de sécuriser pleinement un langage de programmation généraliste. 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) nommé Envision. Envision est beaucoup plus sûr car il ne possède pas - par conception - la capacité d’interagir directement avec le système d’exploitation (OS) et ses sous-systèmes, comme le système de fichiers.

Plus sûr par culture

Aucune technologie, et certainement aucun processus, ne peut rendre un logiciel sécurisé si les gens n’en ont tout simplement rien à faire. Par conséquent, nous faisons de notre mieux pour faire de Lokad - à la fois ses technologies et ses processus - 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 motivations individuelles des gens¹.

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 affirmations publiques déraisonnables (et souvent fantaisistes) ². Lorsque cela se produit, les employés pointus - ceux capables d’identifier 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é suivent. 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é.

Deuxièmement, Lokad favorise parmi ses employés un mélange de curiosité et de saine scepticisme concernant tous les aspects de notre activité, technique et non technique, y compris la sécurité. Cela crée de la 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 moyens d’attaque de plus en plus créatifs. Heureusement pour Lokad, cet état d’esprit est également très souhaitable pour les besoins en supply chain, car les comportements adverses - bien qu’ils ne soient pas nécessairement criminels - sont monnaie courante dans la supply chain ³.

Plus sûr par la formation

Nous formons activement tout notre personnel pour mieux comprendre les menaces cybernétiques et comment les atténuer. Contrairement à la conception et à la culture, la formation en sécurité est largement un processus descendant. Bien que la pensée ascendante ait sa place, ce type de formation est intrinsèquement faible contre la plupart des risques de sécurité informatique. En d’autres termes, même si les gens sont formés à 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 autres périphériques USB qui pourraient compromettre les machines. Nous veillons à ce que l’authentification à deux facteurs soit utilisée chaque fois que possible. Nous formons notre personnel à opérer 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 sécurité vise à sensibiliser à 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, les compétences et le savoir-faire nécessaires pour prévenir de telles attaques nuancées, Lokad a généralement très peu de stagiaires, par rapport à la plupart des entreprises de taille comparable dans l’espace. En bref, nous préférons parier 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 pour une variété de pratiques telles que le renforcement de la sécurité, les tests de sécurité et la gestion des vulnérabilités. Le renforcement de la sécurité, chez Lokad, est 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 par la même occasion le besoin même de renforcement. Par exemple, Lokad ne repose pas sur une couche de stockage “programmatique” - comme 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 à travers un ensemble diversifié de méthodes ; certains automatisés et d’autres manuels, tels que des tests de pénétration de tiers. Pour la gestion des vulnérabilités, nous avons un programme de prime au bug, 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 à l’ISO 27001 (ISMS) et/ou SOC 2 ?

Non. Nous croyons fermement que ces certifications sont des distractions qui rendent les entreprises de logiciels moins sécurisées. Ces processus de conformité mettent l’accent sur un état d’esprit bureaucratique qui est l’opposé de ce qui est nécessaire pour rendre les logiciels sécurisés. Par exemple, ces certifications exigent que des documents soient produits et que des comités soient installés. Franchement, l’idée que les documents et les comités apportent quelque chose de substantiel à la sécurité des logiciels est profondément discutable et n’est pas quelque chose que Lokad accepte le moins du monde.

Dans les cercles logiciels, la sécurité est généralement obtenue en faisant moins, pas plus ; en exploitant les efforts des ingénieurs logiciels spécialisés en sécurité des logiciels, et non 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 commerciale arbitraires.

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

1.3 Suivez-vous les pratiques de l’OWASP ?

Oui. L’OWASP fournit, à travers ses guides, une liste exhaustive des vulnérabilités couramment trouvées dans les logiciels. Il s’agit d’une compilation extensive et de haute qualité que les ingénieurs de Lokad utilisent pour protéger notre logiciel contre les problèmes identifiés par l’OWASP. Cependant, grâce à ses choix de conception, Lokad élimine largement des classes entières de vulnérabilités courantes mises en évidence par l’OWASP. Par exemple :

Gestion des mots de passe : En déléguant l’authentification via la fonctionnalité SSO (authentification unique, quelque chose recommandé par Lokad), Lokad n’a plus à “gérer” les mots de passe, rendant ainsi obsolète toute la liste de contrôle liée aux mots de passe.

Journalisation : Le design de journalisation adopté par Lokad enregistre tout par nécessité. Si une action n’est pas journalisée, alors, du point de vue du système, elle ne s’est jamais produite. Cela annule la plupart de la liste de contrôle de la journalisation.

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-programmatiques ; à savoir une source d’événements et un magasin clé-valeur. Ce choix de conception annule entièrement la liste de contrôle de la base de données.

Plus généralement, lorsque c’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 contrôle 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 (impliquant l’accès à des informations personnellement identifiables (PII)) dans la solution de Lokad respectent-ils les 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. En janvier 2023, cette liste se limite à Microsoft Azure.

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

Oui. Autrement dit, nous faisons des choix prudents, car il n’existe pas d’accord généralisé dans l’industrie sur ce qui constitue “les meilleures pratiques de sécurité logicielle”. Par sa nature même, la sécurité logicielle évolue constamment, s’adaptant à un environnement rempli de nouvelles menaces habiles et de vecteurs d’attaque. Ainsi, nous ne nous référons pas catégoriquement à des tiers sur ce que sont les meilleures pratiques de sécurité logicielle. Au lieu de cela, 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 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 avons à 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, ce qui inclut 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 ouverte à une exploitation potentielle.

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. Beaucoup de nos grands clients ont des dispositions pour de tels audits dans nos accords contractuels. En janvier 2023, cependant, les tests de pénétration exercés par les clients n’ont pas révélé suffisamment de problèmes pour justifier la tenue de tels audits.

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

Oui. La plus grande contingence à 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 ont des dispositions dans leurs accords contractuels pour pouvoir demander des instantanés complets de notre base de code. Ces instantanés sont mis en séquestre avec un tiers convenu afin que, en cas de cessation d’activité de Lokad, le client puisse automatiquement accéder à la base de code en séquestre et obtenir 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 principal et un remplaç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 notre client ; le système informatique du client ne devrait que pousser et tirer 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 vivement l’utilisation d’un processus 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, ne permettant qu’aux bonnes personnes d’accéder aux données à un moment donné. Être simplement présent sur notre réseau ne confère pas automatiquement un statut ou des privilèges (ce point est développé dans Authentification 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 est réduite au maximum.

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 capacités de réseau “avancées” - telles que celles offertes 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 contribuant à l’environnement de production.

1.13 Garantissez-vous que tous les composants (y compris les tiers) et outils (y compris les 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 fournisseurs 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é des choix de conception et des pratiques de sécurité sensés dès le départ, il est rare qu’un changement de quelque ampleur (mineur ou majeur) ait un impact sur la sécurité (même hypothétiquement). Dans toute l’histoire de Lokad, il n’y a eu que 3 événements qui pourraient être considérés comme vraiment significatifs 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 des 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, pour 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é, comme le veut la pratique standard de Lokad.

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

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

Nos accords détaillent le processus de résiliation à la fin d’un contrat, tel qu’accepté avec le client. Le processus de résiliation se termine par la suppression finale des données du client. Comme ce processus de résiliation représente en lui-même un risque de sécurité, ce point fait l’objet de discussions avec chaque client, et peut donc varier légèrement en fonction des cas. D’un point de vue 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 prévenir cela, Lokad et le client s’efforceraient conjointement d’adopter un processus - contractuellement contraignant - qui ne soit pas vulnérable de manière évidente à 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ût associé, et le modèle de coût 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 détaillé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 termes et conditions 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 de 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 publiques sur la supply chain. Ces conférences couvrent la technologie de Lokad et la perspective de la supply chain.

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

Oui, Lokad opère en conformité avec les 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 à travers l’optimisation de l’allocation des ressources. Ainsi, les normes ISO ne sont pas pertinentes ici (c’est-à-dire, non applicables à Lokad).

1.20 Y a-t-il une protection contre les logiciels malveillants 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 séparées ?

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 raison principale pour laquelle nous privilégions l’adressage des préoccupations de sécurité “par conception”. En éliminant des classes entières de menaces à l’étape de la conception, nous maintenons la pratique globale d’évaluation des menaces plus gérable. L’évaluation des menaces couvre également les “attaques de la supply chain”. C’est une autre raison pour laquelle nous mettons autant l’accent sur la minimisation de la quantité de dépendances tierces dans notre pile logicielle, car toute dépendance augmente inévitablement 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 la propre entreprise cliente soit compromise. En cas de ransomware, cela conduit parfois à ce que les données Lokad deviennent accidentellement le seul jeu de données encore accessible. En cas de vol d’identité, cela conduit parfois à des tentatives d’accès au compte Lokad via des identifiants volés. Les détails des différents processus de gestion des incidents sont établis conjointement avec l’entreprise cliente, et généralement supervisés par le scientifique de la supply chain chez Lokad en charge 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 significatifs, tels que des violations de sécurité notables dans l’industrie logicielle.

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

Oui. Cependant, la plateforme Lokad est essentiellement un monolithe qui ne repose sur aucune “fonction de support” à part quelques fondamentaux de base, tels que le 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 nécessaires - 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 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 aux 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 d’entreprise ?

Oui, nous avons un plan de gouvernance des risques formalisé qui a été approuvé par la direction senior.

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 à travers 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 senior et aux parties prenantes concernées pour assurer une surveillance continue et un soutien.

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 réviser ?

Oui, nous avons un programme de sécurité physique complet qui a été approuvé par la direction senior. 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 examiner périodiquement le programme pour en assurer l’efficacité et la pertinence. Ce responsable collabore avec diverses équipes et départements pour traiter les problèmes de sécurité physique émergents et garantir que le programme est 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ù résident les systèmes ?

Oui, les évaluations des risques physiques et environnementaux font partie intégrante de notre processus de prise de décision lors 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 réalise 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 convaincus que ces évaluations ont été mené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é interne et d’éthique ?

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

En effet, Enron avait un code de déontologie écrit. Ce code mettait l’accent sur le respect, l’intégrité, la communication et l’excellence. Le scandale Enron, révélé en 2001, 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 de déontologie. Il y avait donc un décalage complet 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 réellement la possibilité de se soucier de nos clients. « Faisons-nous les bonnes choses ? » est l’un de nos mantras. La conformité et l’éthique sont, à notre avis, les produits dérivés d’une culture d’entreprise adéquate, et non le résultat d’un programme particulier.

1.30 Y a-t-il un service d’audit interne, de gestion des risques, de conformité ou une fonction de surveillance 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 grande 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 des individus désignés avec une expertise dans ces domaines qui sont spécifiquement chargés de gérer et de superviser ces responsabilités critiques.

Ces individus rendent directement compte à la direction 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 Y a-t-il une politique ou un programme sans fil approuvé par la direction, communiqué aux parties prenantes appropriées, et un responsable désigné pour le maintenir et le revoir ?

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 prenantes pertinentes pour garantir le respect. Cette politique fait la distinction entre deux réseaux Wi-Fi indépendants et isolés : l’un dédié aux employés et un autre spécifiquement pour les invités. Cette distinction garantit que nos opérations principales restent sécurisées, même si nous fournissons une connectivité pour les invités ou les visiteurs.

Cependant, il est important de noter que notre mode de connexion principal se fait via Ethernet, priorisé en raison de ses performances supérieures et de sa sécurité renforcée. Les réseaux Wi-Fi sont principalement en place pour accueillir des réunions et offrir de la 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 qu’elle reste à jour et efficace pour répondre aux besoins et aux défis évolutifs.

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 capacité substantielle 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 s’authentifier est le but 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 aucun type de données sensibles, 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. Sécuriser les accès à distance signifie avoir la bonne authentification, la bonne autorisation et le chiffrement du canal de transport lui-même - tous des éléments que nous imposons. Cette disposition couvre à 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 aucun type 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. À travers 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, comme Microsoft Office 365 ou Google Workspace. Le défi de prendre en charge OAuth2 est que 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 manières.

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 assurer la compatibilité avec la variante d’OAuth2 telle qu’exploitée par l’entreprise cliente.

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

Oui, via une couche intermédiaire de pontage superposant SAML sur LDAP. Cependant, la majorité des systèmes d’identité fédérés prenant en charge LDAP prennent également en charge SAML. Ainsi, nous recommandons 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 en fin de compte, 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, imposer une complexité minimale des mots de passe est désormais largement reconnu 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 un “logiciel superflu” qui augmente la complexité d’une pièce logicielle critique en termes de sécurité (gestion des mots de passe), exposant ainsi celle-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. À travers 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 désormais 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 ne font souvent que 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 un “logiciel superflu” qui augmente la complexité d’une pièce logicielle critique en termes de sécurité (gestion des mots de passe), exposant ainsi celle-ci (et la solution globale) à des risques indus. Voir https://www.sans.org/blog/time-for-password-expiration-to-die/

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

Oui. Nous utilisons scrypt comme fonction de hachage de mots de passe. En règle générale, nous recommandons vivement l’utilisation de SSO au lieu d’utiliser des mots de passe/stratégies traditionnels. À travers 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, 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 entrent dans la catégorie des composants logiciels qui sont préférablement laissés 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 pour les 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 le besoin d’introduire des mots de passe dédiés à Lokad.

2.13 Centralisez-vous la gestion des utilisateurs ?

Oui. Lokad a 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 sont vus par 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 un incitatif à partager des comptes d’utilisateurs entre leurs employés. Cependant, il y a quelques cas où il est acceptable d’avoir un compte 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 fournit 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 permettre l’utilisation de plusieurs appareils). Chaque session est restreinte à une seule adresse IP. Lokad se réserve cependant le droit de modifier cette limite afin de contrer certaines menaces potentielles et/ou abus.

2.17 La solution a-t-elle la capacité de verrouiller de force et/ou de déconnecter 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 déconnecte-t-il automatiquement un utilisateur inactif après une période spécifiée de temps d’inactivité ?

Oui, bien que “l’inactivité” ne soit pas le facteur déterminant. Lokad déconnecte automatiquement les utilisateurs après une période de temps spécifiée. Les utilisateurs ne peuvent pas reporter 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 données d’identification 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 donnons 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 supplémentaire de sécurité 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ée. Ces systèmes, par conception, soutiennent les meilleures pratiques en matière de gestion des informations d’identification, garantissant que les informations d’identification sont communiquées de manière sécurisée, impliquant souvent des canaux ou des méthodes de communication séparés 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 haut niveau de sécurité.

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

Oui, nous gérons et surveillons activement les identifiants d’utilisateur pour garantir la sécurité. Pour les employés de Lokad, notre politique exige que tous les droits d’accès soient révoqués le dernier jour de leur emploi, garantissant qu’il n’y ait pas d’accès post-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 qu’un client supprime un employé de son système d’identité, l’accès à Lokad est simultanément interrompu. Cette méthode renforce non seulement la sécurité, mais garantit également l’efficacité dans 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 telles situations. Pour éviter les perturbations 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 alignées sur les besoins opérationnels de nos clients.

3. Autorisation

3.1 La solution fournit-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). Cela permet au client de contrôler quels “Projets” et “Fichiers” sont accessibles (et par qui) dans le compte Lokad. Le RBAC dispose de son propre interface utilisateur web (tableau de bord). Il est disponible pour tous les utilisateurs ayant la désignation “Propriétaire” dans le compte Lokad. Consultez notre documentation sur les rôles et permissions des utilisateurs pour plus d’informations.

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) qui peut être utilisé pour mettre en œuvre le PoLP. Cependant, à travers Envision (le DSL de la solution), Lokad va bien au-delà de la plupart des logiciels d’entreprise en ce qui concerne ce principe.

À travers 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 largement configurable. De même, le système de fichiers sur mesure offert par Lokad élimine également des groupes entiers de privilèges système inutiles.

3.3 Faites-vous respecter 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 de la désignation “Propriétaire” au sein du personnel de nos clients. 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 dans le système aux utilisateurs désignés ?

Oui. Il s’agit d’une forme de mise en œuvre du PoLP et est couverte 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 avec un compte) aux “Propriétaires” du compte. Cette désignation est la plus haute et la plus privilégiée du RBAC (Contrôle d’Accès Basé sur les Rôles). Toutes les autres données dans le compte Lokad peuvent être segmentées selon une classification de sensibilité définie par l’utilisateur. Cette classification définie par l’utilisateur peut être appliquée à la fois aux données 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 des utilisateurs/rôles/transactions en temps réel ?

Oui, bien que “en temps réel” nécessite des clarifications dans le contexte d’un système informatique distribué (comme la solution Lokad). Les mises à jour du RBAC (Contrôle d’Accès Basé sur les Rôles) 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 retards 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 chez Lokad “Project runs”). Lorsqu’une interruption est déclenchée, elle garantit immédiatement (de manière synchrone) que le traitement n’affectera pas le système, 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 Personnellement Identifiables (IPI) uniquement aux utilisateurs ayant le bon niveau de permission ?

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

Oui. Cependant, un utilisateur avec la désignation “Propriétaire” au sein d’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 pouvoir auditer, en totalité, la liste des utilisateurs ayant accès à leur propre compte.

3.9 Le système est-il équipé de la technologie WAF (pare-feu d’application Web) ?

Non. Le WAF est une conception intrinsèquement dangereuse car elle viole le principe de sécurité du “principe du moindre privilège” : un composant se voit accorder d’énormes privilèges pour 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 (système de prévention des intrusions) ?

Non. L’IPS est une conception intrinsèquement dangereuse car elle viole le principe de sécurité du “principe du moindre privilège” : un composant se voit accorder d’énormes privilèges pour 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 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 par 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 taux nginx, et nos propres composants spécifiques (comme l’échec précoce en cas d’authentification 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 accorder l’accès administratif (et qui produit une piste de vérification fiable) ?

Oui. Voir Journalisation et Surveillance 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 en charge du compte - pour nos comptes gérés. Alternativement, ces droits sont accordés et surveillés par la société cliente elle-même si le compte n’est pas géré directement par Lokad/un Supply Chain Scientist.

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

Oui. Nous appliquons le principe du moindre privilège (PoLP) à tous les niveaux d’accès de notre infrastructure, y compris 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, n’importe où peut accéder, 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. Alors que certains serveurs spécialisés, tels que les équilibreurs de charge, ont des restrictions sortantes, la majorité de nos serveurs n’en ont pas.

Nos VM de production nécessitent un accès à de multiples API externes. Une grande partie de ces API sont hébergées par Microsoft Azure, avec quelques exceptions 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 potentiellement 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/7/365 pour signaler des incidents de sécurité ?

Oui, nous avons mis en place la norme security.txt pour faciliter la signalisation 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é à 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 quiconque, que ce soit un client, un client ou 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é à notre équipe.

Veuillez noter que bien que le processus détaillé dans le ‘security.txt’ puisse être révisé, les informations les plus actuelles et précises seront toujours disponibles à ce point d’extrémité. Nous veillons à ce que les canaux de communication mentionnés dans le fichier, qu’il s’agisse d’e-mail, de formulaire web ou d’un autre moyen, soient pourvus en personnel et disponibles 24/7/365 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 Europe North de Microsoft Azure (basé à Dublin). Nos sauvegardes sont stockées dans le centre de données Europe West de Microsoft Azure (basé à Amsterdam). En cas de défaillance majeure d’un centre de données, nous avons des plans de contingence pour migrer la plateforme à 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 internement les données des 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 : louer des machines virtuelles à partir 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 interne ou externe ?

La gestion de la couche de données de Lokad est effectuée par les équipes d’ingénierie de Lokad. Comme mentionné précédemment, la plateforme de base de Lokad n’inclut 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 implémenté 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 sans objet car la solution Lokad n’utilise pas de RDBMS. La couche de persistance des données de la solution Lokad exploite un magasin d’événements et un magasin de clés-valeurs. Cette approche diffère considérablement de la conception CRUD (Create-Read-Update-Delete) couramment trouvé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 (pour garantir que les anciennes données restent accessibles).

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éseaux, 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 des DNS).

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

Oui, bien que cela puisse prendre plusieurs semaines pour compléter 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 relative “lenteur” 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, pas de suppressions 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, comme 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 doucement des données ?

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 celles-ci peuvent être suivies et annulées, selon les besoins.

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 entrée ou produites en sortie sont stockées dans ce système de fichiers.

Cependant, comme Lokad ne dispose pas d’une base de données transactionnelle, il n’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 magasin d’événements et nous ne proposons 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 charger manuellement des fichiers. La solution Lokad peut intégrer toutes les données tabulaires raisonnablement. Pour en savoir plus sur les capacités d’intégration externe des données de Lokad, consultez Aller à la perspective informatique sur Lokad 2.15.

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

Oui, sous réserve d’un accord contractuel spécifique avec le client. La capture de données de changement est un modèle de conception logicielle - et non 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-minute. Les fonctionnalités dans ce domaine doivent être évaluées d’un point de vue de la supply chain. Dans notre expérience, les flux de données en temps réel sont rarement pertinents pour résoudre les problèmes de la supply chain.

4.12 Toutes les données au sein 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 offre-t-elle des outils pour exporter des données ?

Oui, la solution Lokad propose un DSL (langage spécifique au domaine) nommé Envision, 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 prend en charge de nombreuses options concernant le format des nombres, des dates, des délimiteurs, le codage du texte, les en-têtes, etc.

4.15 La solution propose-t-elle un chiffrement transparent des données (TDE) des données personnelles identifiables (PII) dans le stockage mobile et en back-end ?

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

4.16 Tous les mots de passe et secrets utilisés dans l’application sont-ils chiffrés et non accessibles en texte libre dans le code source, les fichiers de configuration, les paramètres de build, 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 hachés avec Scrypt selon les pratiques standard.

4.17 La solution a-t-elle la capacité de restreindre les téléversements de fichiers en fonction du type et de la taille des fichiers, et de scanner les 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 (ex : commandes de ventes 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. En cas de 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é à scanner les 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 au sein de Lokad sont sécurisés, même si les fichiers d’entrée ne le sont pas. En revanche, à travers sa conception, la solution Lokad dévalorise le partage de contenu téléversé par l’utilisateur via Lokad.

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

Lokad est un SaaS, ainsi, nous avons la responsabilité de choisir la période de rétention 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 pour la durée du service Lokad. En effet, les données historiques valent généralement la peine d’être conservées pendant des périodes arbitrairement longues (en dehors des limites du service Lokad). À l’autre extrémité du spectre, il y a les données d’instrumentation, reflétant les performances détaillées de notre plateforme. Ces données ne sont utiles que pour le dépannage des 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édures Conjoint”. Il convient de noter que Lokad n’utilise pas de base de données relationnelle, contrairement à la plupart des logiciels d’entreprise. Au lieu de cela, nous utilisons 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 à travers les scripts Envision au sein de la plateforme Lokad. Ces fichiers plats sont conçus pour correspondre aux exigences spécifiques de l’entreprise cliente. La documentation de ces fichiers est incluse dans le “Manuel de Procédures Conjoint” - qui est l’une des livrables dans une initiative typique de Lokad.

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. Cette partition est un élément de premier plan 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 courantes 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” étendus pour permettre à l’équipe d’ingénierie logicielle de fonctionner en douceur sans accès 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 de cloud computing obtenues auprès de Microsoft Azure). Cette pratique de “dogfooding” garantit que Lokad dispose également d’une abondante réserve 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 minimes (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 client récupéré pour le diagnostic d’intérêt. Cette capacité 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 le besoin 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 des centres de données de Lokad est publiquement documenté.

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

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

Le PAN (Primary Account Number) fait généralement référence au numéro principal sur une carte de crédit ou de débit. C’est la séquence de chiffres en relief ou imprimée sur la face d’une carte et utilisée pour identifier de manière unique le compte bancaire 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 cryptés ne sont-ils jamais envoyés par des technologies de messagerie de l’utilisateur final (par exemple : par e-mail, messagerie instantanée et chat) ?

Oui, les PAN non cryptés ne sont jamais envoyés par des canaux non sécurisés tels que l’e-mail. Lokad propose un canal de communication sécurisé intégré sur sa plateforme, qui est une alternative supérieure pour transmettre des informations 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 client. Par conséquent, il n’y a pas de transferts de PAN non cryptés.

Voir aussi le stockage des PAN

4.27 Avez-vous un contrat en place 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) en place avec Microsoft pour les services de cloud computing Azure. L’accord d’entreprise comprend généralement divers termes et conditions liés à 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 publiquement les détails spécifiques de notre accord contractuel, après plus d’une décennie de collaboration avec Microsoft, nous sommes satisfaits que cet accord réponde à nos exigences et normes en matière de sécurité.

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

Non, Lokad ne sous-traite pas le traitement des détails ou des données 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, aucun tiers n’est impliqué 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 scientifiques de la supply chain) ont accès aux détails ou aux données des clients. Lokad a parfois 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 des scientifiques seniors de la supply chain.

Remarque : Les stagiaires sont soumis aux mêmes accords de confidentialité que les scientifiques de la supply chain à 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 formatés en fichiers CSV. À l’heure actuelle, ces journaux peuvent être demandés au personnel de support de Lokad. L’extraction des journaux sera placée dans le compte Lokad dans un endroit accessible uniquement aux utilisateurs ayant des désignations de “Propriétaire”. Nous prévoyons d’introduire une méthode d’accès plus directe - via une interface web dédiée - à l’ensemble de l’audit complet qui existe déjà en arrière-plan 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énementialisation centralise non seulement les journaux, mais également 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’impactent pas l’état de la solution sont séparés de ceux qui le font.

D’un point de vue purement technique, certains journaux liés aux performances ne sont pas intentionnellement centralisés dans le magasin d’événements. Ces journaux incluent 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 nécessaires 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 Journalisez-vous les changements 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énementialisation de Lokad, tout est journalisé par nécessité. En fait, la solution elle-même est la somme de la collection d’événements enregistrés dans la solution. Ainsi, la journalisation est un aspect fondamental de l’architecture de la solution. Cette conception basée sur l’événementialisation empêche l’omission accidentelle d’un journal qui reflète un changement d’état. Dans un tel cadre d’événementialisation, 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. Pour obtenir des journaux, la solution Lokad convertit et compile ces événements en fichiers CSV. Nous normalisons les formats de date, les formats numériques 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 lancées dans votre solution ?

Oui. La conception de l’événement sourcing de Lokad nous permet de suivre toutes les exceptions lancé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 un très faible nombre d’exceptions non corrigées.

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

Oui. Nos sous-systèmes ont été conçus avec des points de contrôle de surveillance dédiés aux vérifications de santé. 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. Pour des raisons de surveillance de la santé 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 capacité 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é à l’heure 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 calendrier 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 prend du retard. L’alerte peut être envoyée avant l’achèvement de la séquence. La solution Lokad offre des capacités étendues grâce à Envision (son DSL) pour analyser et s’auto-diagnostiquer 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 supply chain qualifiées d’“erreurs” peuvent varier.

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

Oui. Grâce à sa conception d’événement sourcing, la solution Lokad conserve une piste d’audit étendue ; bien plus grande que 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 séparé. En effet, le flux d’événements est la piste d’audit. Plus généralement, Lokad conserve les données de production pour la durée du service avec le client. À la résiliation du service, qui dépend des termes contractuels négociés, les données du client sont purgées, bien que la suppression finale dans le système de sauvegarde puisse se produire 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 mentalité “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 chaîne d’approvisionnement donnée. Cette surveillance est généralement assurée par les équipes de scientifiques de la chaîne d’approvisionnement (les ingénieurs fournis par Lokad), conformément à l’accord contractuel.

Les scientifiques de la chaîne d’approvisionnement de Lokad se spécialisent généralement dans une classe particulière de compte client (par exemple, l’aérospatiale). Ils conçoivent une instrumentation de surveillance sur mesure en utilisant le compte Lokad. Cette surveillance inclut notamment la vérification que les chiffres fournis par Lokad sont corrects, 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. Examiner 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 systèmes de gestion des journaux sont-ils administrés par des personnes qui ne sont pas impliquées dans l’administration des autres systèmes (c’est-à-dire, séparation des tâches) ?

Oui. La supervision des journaux et de l’activité générale de la plateforme est effectuée par des scientifiques de la chaîne d’approvisionnement, tandis que l’administration générale de notre infrastructure est effectuée par des employés spécifiques au sein de notre division informatique.

5.15 Des 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.16 Existe-t-il un processus défini pour la revue périodique des règles de pare-feu effectives ?

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

5.17 Le réseau est-il équipé de la technologie IDS (Système de Détection d’Intrusion) ?

Non. IDS est une conception intrinsèquement dangereuse car elle viole le principe de sécurité du “principe du moindre privilège” : un composant se voit accorder d’énormes privilèges pour fonctionner en tant que “homme du milieu”. Cela fait de l’IDS lui-même une cible principale pour les attaquants, et cela étend considérablement la surface d’attaque de la plateforme. Cependant, Lokad surveille de près le 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 ont-ils des accords de confidentialité (NDA) ?

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

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

Oui, une sensibilisation à la sécurité et une formation en sécurité sont fournies aux employés de Lokad qui sont en contact avec des données confidentielles et/ou des systèmes d’ingénierie en contact avec des données confidentielles. Pour plus d’informations sur ce point, 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 clients confidentielles.

6.3 Qui a accès aux données 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 brève liste 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 au compte client 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 (tel que 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 clients est rare et limité à l’investigation des 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 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 protéger contre le vol de données qui pourrait être causé par la perte, le vol ou la confiance à 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 garder strictement 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 n’ont 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.

6.6 Utilisez-vous un antivirus ?

Oui, nos postes de travail sont équipés de Microsoft Defender, selon les configurations de Microsoft Windows 10+. Nous n’avons pas d’autre antivirus que Microsoft Defender, mais notre attitude est que cette classe 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. En conséquence, ces produits logiciels deviennent leurs propres vecteurs d’attaque. Notre point de vue sur la sécurité informatique est que moins c’est plus, et 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 à l’utilisation de méthodes d’évaluation des menaces, de normes de codage sécurisé, de listes de contrôle de sécurité bien connues et de cadres ?

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é au stade de la 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 confidentialité (NDA) ? Cette NDA couvre-t-elle les informations des clients ?

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

Cependant, si Lokad devait juger nécessaire de faire appel à un sous-traitant, celui-ci serait soumis aux mêmes termes de PI (Propriété Intellectuelle) et de NDA que nos employés permanents. Ces accords incluent des termes 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 l’information et la sécurité (et une formation continue pertinente) ?

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

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

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

Voir aussi Employés 6.8

6.10 Tous les contrats avec les entreprises fournissant la main-d’œuvre externe de Lokad (tous les entrepreneurs, consultants, etc., participant à 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 repose pas sur des sous-traitants/une main-d’œuvre externe. Les équipes d’ingénierie logicielle et de scientifiques de la supply chain de Lokad sont entièrement composées de personnes employées directement, de manière permanente et supervisées par Lokad.

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

Remarque : Historiquement, bon nombre des incidents les plus importants - et les pires - tels que l’espionnage cybernétique, sont commis par des personnes ayant des antécédents impeccables. C’est, entre autres raisons, pourquoi Lokad hésite à s’appuyer sur une main-d’œuvre externe et préfère fortement les contrats de travail directs et à durée indéterminé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.

Remarque : La plupart des employés de Lokad ne se voient jamais accorder des droits administratifs car ils ne sont pas nécessaires pour l’exécution de leurs tâches.

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 de cartes de paiement - celles-ci sont gérées par des tiers. Ainsi, le personnel de Lokad n’a pas accès aux données de cartes de paiement de nos clients.

6.13 Quelles précautions Lokad prend-elle pour s’assurer que le personnel non autorisé ne peut pas 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 tierce 24h/24, 7j/7, avec une sécurité sur place.

Au niveau des bureaux, les locaux de Lokad ont 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 dans le bâtiment d’accéder aux bureaux de Lokad.

Remarque : tout visiteur exceptionnel (comme des clients, des candidats potentiels, etc.) doit être physiquement accueilli et autorisé à entrer par des membres du personnel de Lokad.

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

Si par “locaux” on entend “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 occasionnellement des visiteurs à son siège social. Nos bureaux ne sont pas ouverts au public, mais des circonstances exceptionnelles se présentent parfois, comme la visite de clients, des candidats à un emploi en attente d’un entretien, etc. Ces visites sont planifiées à l’avance et les visiteurs sont accompagnés en permanence par des membres du personnel de Lokad lorsqu’ils sont 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 coupe-feu sécurisées pendant la nuit ?

Lokad n’opère pas avec des dossiers de données papier, ni avec des supports électroniques amovibles. Comme nous n’avons pas de dossiers physiques à stocker, Lokad n’a pas besoin d’armoires coupe-feu.

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 Y a-t-il une politique de bureau vide en place ? Dans quelle mesure ?

Oui, Lokad opère avec une politique de bureau vide fermement en place. Cette politique est appliquée “par conception” à travers 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 même cela serait généralement externalisé), l’environnement de travail de Lokad est strictement numérique.

Ainsi, à la fin de la journée, les employés de Lokad n’ont rien à ranger. Une fois que la session 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 télécopies et qui pourrait 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 Y a-t-il un processus pour vérifier le retour des actifs constitutifs (ordinateurs, téléphones portables, cartes d’accès, jetons, cartes intelligentes, clés, etc.) à la fin de la relation de travail ?

Oui, nous avons non seulement un processus en place, mais aussi un logiciel de gestion des actifs informatiques pour soutenir cet effort et minimiser le nombre d’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 tout actif constitutif a de fortes chances d’être perdu ou volé, peu importe la discipline et la formation de nos employés. En pratique, cela arrive très rarement, mais d’un point de vue technique, nous 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 applicable.

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. Nous mettons un fort accent sur la communication claire, et en tant que tel, ces politiques et procédures ont été largement diffusées à toutes les parties prenantes concernées pour garantir une compréhension et une conformité complètes.

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

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

Non, Lokad n’autorise pas l’accès aux données clients sur des appareils mobiles personnels (BYOD). Nous fournissons à nos employés du matériel de haute qualité appartenant à l’entreprise, éliminant ainsi le besoin d’appareils personnels. Cette disposition répond au scénario courant où les employés recourent à l’utilisation de 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 clients ne sont pas stockées de manière permanente. Toutes les opérations de traitement des données se font au sein de notre plateforme basée sur le cloud. Sur les appareils des employés, les données clients (si elles sont jamais consultées) sont traitées de manière transitoire et uniquement en segments minimes, garantissant une sécurité maximale.

Notes