Business Central permet de se conformer à NIS 2

Conditions de la directive NIS 2

Ce complément à NIS (pour Network and Information Security) élargit le spectre d’entreprises concernées par des normes de sécurité de plus en plus strictes, avec la répartition suivante :

Les annexes 1 et 2 définissant la criticité des secteurs d’activités des entreprises par le gouvernement sont disponibles entre les pages 64 et 70 de Directive européenne NIS 2).

Les seuls cas particuliers seront les secteurs critiques de l’administration publique et des infrastructures numériques. Les entités de ces secteurs (ou d’autres par choix arbitraire des pays) y seront considérées comme essentielles, peu importe leur taille.

La subtilité de NIS 2 se manifeste par l’obligation de tous les fournisseurs directs (et donc critiques) d’une entreprise concernée par la directive de respecter ces exigences sur la cybersécurité.

Finalement, les entités essentielles sont soumises à environ 160 points de contrôle contre moitié moins pour celles importantes, basés sur 4 piliers :

• Renforcement de la gouvernance et de la gestion des risques
• Mesures de sécurités obligatoires
• Notification des incidents et partage avec les instances européennes
• Sécurisation de la supply chain

Respect de NIS 2 par Business Central

Dans ce contexte, Business Central et son écosystème permettent de répondre aux exigences européennes.

L’utilisation cloud de Business Central va notamment reporter la responsabilité de résilience face à la sécurité de certaines infrastructures vers un partage entre l’éditeur, l’intégrateur et tout de même une partie revenant au client final (environnement de travail). Ce modèle de responsabilité partagé est proposé par Microsoft :

Le  Trust Center de Microsoft (Portail d’approbation de service) répertorie les certifications, quelles soient régionales, nationales ou encore spécifiques aux secteurs d’activités, auxquelles se conforment toutes les applications Cloud de Microsoft et notamment Dynamics Business Central (RGPD, HDS, ISO 27001, ISO 27017, ISO 27018, SOC 1 (SSAE18) Type 2, SOC 2 Type 2, HIPAA BAA, EU-US Privacy Shield, EU Model Clauses, FERPA, …)

BC online est naturellement conforme à NIS 2. Pour des déploiements on-premise, d’autres actions spécifiques seront nécessaires. Toutefois, comme illustré dans le modèle imagé ci-dessus, des procédures restent toujours à la charge du partenaire ou du client pour satisfaire exhaustivement les exigences de la norme. Elles se partagent entre les domaines d’identification, d’accessibilité ou de gestion des données parmi 4 piliers :

I Gestion des risques sécurités

Au vu du nombre d’utilisateurs, leurs multiples utilisations de l’ERP, ainsi que les interactions avec de systèmes ou ressources techniques externes (Stockage, IA, etc.) la prévention de risques liés à Business Central demande une attention spéciale.

Fonctions natives (à la charge de Microsoft) :

• Les connexions via les navigateurs Web sont chiffrées (utilisant un algorithme RSA de 2048 Bit), à l’aide d’un certificat SSL, fourni par Microsoft.
• L’échange d’informations entre les composants logiciels middleware, base des données ou serveurs web suivent le protocole TLS1.2 minimum.
• L’architecture Web Business Central, load balancer ou serveurs permettent d’éviter les attaques de type DDOS ou nécessitant une persistance des connexions.

 Actions sous responsabilité du client :

• La gestion des accès est déléguée à Microsoft ENTRA ID par défaut. La solution propose des mécanismes modernes et sécurisés, notamment le multi facteur (MFA) et l’accès conditionnel à Business Central. Ces fonctionnalités doivent tout de même être paramétrées pour chaque organisation.
• Administrer les interactions de Business Central avec d’autres systèmes, API, via des applications d’entreprises avec le principe de moindre privilège et le protocole Oauht2.0. Les secrets ou éléments confidentiels doivent être gérés via une entité Azure Keyvault.
• Elaboration des procédures pour régir le cycle de vie des utilisateurs : arrivée, mutation, promotion, départ.
• Cartographier la surface de risques cyber autour de l’ERP. Les localisations géographiques des utilisateurs et interfaces sont répertoriés, avec des solutions ou ressources IT tierces (add-ins, add-ons), en leur octroyant un niveau de risque et les mesures de prévention associées.
• Etablir des règles de développement intégrant la prévention de risques de cybersécurité. Un processus d’analyse de risque doit aussi être prévu lors de l’installation d’extension(s) d’un ISV. Il s’agit donc de veiller aux développements internes mais aussi à ceux véhiculés par des acteurs externes.

II Mesures de protection et prévention contre les cyberattaques

L’objectif principal des attaques contre un environnement ERP est d’atteindre les données de l’organisation, souvent sensibles.

Fonctions natives (à la charge de Microsoft) :

• En mode SaaS, les données de Business Central sont stockées dans une base de données isolée. Ces données ne sont jamais partagées entre des instances différentes et sont également chiffrées, avec l’algorithme TDE (Transparent Data Encryption).

Actions sous responsabilité du client :

• Cartographier les données de l’ERP et de manière générale, son écosystème, ses systèmes connectés ou sa  gestion de fichiers associés. Il faut alors définir le niveau de sécurité et criticité pour chaque source.
• Mettre en place les permissions  des utilisateurs, avec des permission Sets en fonction de leur rôle, géré via des groupes de sécurité depuis ENTRA ID  (évoqué dans un article précédent, gestion des permissions sur Business Central).
• Classer les données dans l’ERP. Au moment des développements (création des tables et champs) ou à l’aide de la feuille de classification de données, il est possible de classer les données afin de respecter la législation en vigueur (RGPD). Cela définit aussi la façon dont le système peut gérer l’accès à ces données. Les  niveaux de sensibilité sont les suivants : sensible, personnel, confidentiel ou normal (Classification des données)
• Souvent les fichiers binaires associés aux transactions de l’ERP sont stockés sur des espaces de stockage externe. La connexion à ce service doit être sécurisée.
• Utiliser l’isolation de données pour les développements spécifiques pour les informations confidentielles comme secrets, codes de licences, etc… avec un niveau d’isolation pertinent : utilisateur, société ou environnement.
• Définir un suivi  de données sensibles, par log changes avec notifications.
• Via l’interface Data Administration, définir les règles de rétention, compression et suppression pour chaque type des données.

III Détection de incidents

La détection des incidents est stratégique pour la continuité des services (exigence explicite de NIS 2). Elle permet d’adopter des mesures palliatives rapidement et surtout de faire évoluer les systèmes afin de ne plus rencontrer les mêmes incidents.

Fonctions natives (à la charge de Microsoft) :

• L’admin center Business Central propose par default deux interfaces listant les incidents ainsi que quelques rapports télémétriques de l’instance BC (tous les environnements). Ces outils restent insuffisants pour suivre efficacement la solution et notamment détecter ou identifier la totalité des incidents.

Actions sous responsabilité du client :

• Associer chaque environnement a une instance Azure Application Insights et prévoir l’intégration de signaux télémétriques dans le(s) développement(s) spécifique(s). Les métriques d’Application Insights peuvent être exploitées via PowerBI, Azure Data explorer ou même Datadog,

• Utiliser Microsoft Pureview pour suivre les évènements liés aux connexions utilisateurs ou la modification de données. L’outil est beaucoup plus exhaustif que l’usage des change log entries et ne gonfle pas inutilement la taille de la base de données.

IV Minimiser l’impact des éventuelles attaques

Même si de nombreuses mesures sont prises pour prévenir ces risques, certaines cyberattaques parviennent à leur fin. Il faut donc des outils pour en limiter l’essor ou revenir à l’état initial.

Fonctions natives (à la charge de Microsoft) :

• Microsoft promet une continuité de se services. Pour se faire, des points de restauration automatiques quotidiens (des environnements de production ET de sandbox) sont réalisés et conservés pendant 28 jours.
• Le principe de moindre privilège empêche une surévaluation des droits pour une ressource touchée.

Actions sous responsabilité du client :

• Le lieux d’hébergement du data center découle de la localisation choisie par le client dont les règles de sécurités peuvent varier d’une région à une autre.  Il faut donc choisir judicieusement le lieu pour avoir la politique qui cadre bien nos besoins sur l’expansion de failles cyber. Cela va aussi impacter la réactivité de votre système en termes de performances.

• Adopter un plan de récupération. Un administrateur Business Central doit, à travers l’Admin Center s’occuper de la restauration des environnements parmi les sauvegardes effectuées et encore disponibles. Si l’environnement a été corrompu, l’administrateur dispose donc de 28 jours pour l’écraser par une sauvegarde. En revanche si l’environnement a été  supprimé il n’en possède que 7.
• Effectuer des test de pénétration (plutôt dans le cadre du partenaire BC) sur les services hébergés dans le cloud Microsoft par le client. En cas de vulnérabilité rencontrée, NIS 2 impose de le communiquer au Centre de Réponse Sécurité (MSRC).

Axians BMS propose ses services pour conformer votre Dynamic Business Central Online à la nouvelle directive NIS 2. Nous vous invitons à nous contacter à contact.bms@axians.com .

Contexte d’application de NIS 2 en France

La directive NIS 2 devait être transposée au plus tard au sein de ses états membres, 2 ans après son instauration. C’est le cas pour les acteurs du numériques, tel Microsoft, dont l’acte d’exécution est déjà paru en France. Les décrets d’application y restent cependant en cours de validation pour les autres acteurs.

La France est tout de même un des précurseurs avec l’Allemagne avec une des rares agences gouvernementales, l’ASCII, qui disposent de moyens importants pour étudier le risque cyber et adopter les mesures nécessaires pour y faire face.

Microsoft a finalement commandé une étude pour identifier l’état actuel et l’impact de NIS2 dans l’environnement français. Celle-ci souligne que le pays est soumis à une méconnaissance du sujet mais avec une réelle volonté d’améliorer leur sécurité pour se plier à nouvelle norme :