Un compte privilégié est un compte qui possède plus de privilèges qu’un utilisateur ordinaire. Par exemple, il peut lire et modifier la sécurité d’un système, exécuter des fonctions qui peuvent affecter de nombreux utilisateurs, etc… Ces comptes sont donc les préférés des attaquants (75 % des organisations ont subi une attaque impliquant un compte privilégié) et nécessitent un niveau de sécurité maximal.

Ce webinaire s’est concentré sur la sécurisation de l’accès aux ressources informatiques telles que les serveurs. Cependant, il est important de comprendre qu’un accès sécurisé est également nécessaire pour de nombreux autres éléments (tels que les applications) et qu’il existe différents types d’accès privilégiés, ce qui fait que la sécurité n’est pas une solution unique et doit être adaptée à chaque situation.

Les approches de sécurité traditionnelles utilisées par les organisations, y compris la solution PASM traditionnelle, ne suffisent pas à protéger les accès privilégiés contre les attaquants car elles ne répondent pas aux cinq questions clés nécessaires pour une sécurité solide, étant :

• Comment déployer l’authentification forte ?
• Comment sécuriser les superadministrateurs intégrés ?
• Comment contrôler les permissions effectives ?
• Comment gérer un grand nombre de serveurs ?
• Comment surveiller de près les opérations ?

Pour résoudre ce problème, les entreprises peuvent améliorer la solution PASM afin de la rendre plus efficace dans la sécurisation des accès privilégiés. Pour ce faire, elles peuvent :

1. Automatiser les autorisations autant que possible : Les serveurs sont nombreux et évoluent constamment, et les utilisateurs aussi. La normalisation et l’automatisation des autorisations leur permettront de suivre ce rythme.
2. Prise en compte d’autres cas d’utilisation au-delà de l’administration interactive : Il s’agit de prendre en compte d’autres besoins pour éviter que les utilisateurs ne contournent le PASM. On peut citer comme exemple les scripts utilisant des identifiants d’administrateur et les DevOps / machine-to-machine.
3. Concevoir votre modèle de compte en suivant le principe du moindre privilège (least privilege) : Par exemple, en concevant un seul compte nominatif centralisé par utilisateur pour simplifier la gestion, bien que cela n’entraîne pas de propagation latérale. Un compte générique local serait plus favorable dans ce cas précis, bien qu’il soit plus difficile à mettre en œuvre pour une organisation et qu’il pose question sur la responsabilité des comptes locaux, rendant la gouvernance plus complexe.

Le PASM présente-t-il des risques ?

Lors de la phase de projet, les administrateurs peuvent rejeter le PASM si la gestion du changement n’a pas été suffisante pour les former à ce dernier. Pour éviter cela, il est essentiel d’intégrer et de former les administrateurs à la solution PASM dès le début. De plus, la difficulté du déploiement et le coût peuvent être un obstacle aux solutions PASM pour les organisations. Ainsi, plus le modèle d’accès est simple, plus la solution sera facile à déployer et moins elle prendra de temps, ce qui permettra de réduire les coûts. Enfin, une solution PASM locale risque d’être très lourde et coûteuse en termes d’architecture, d’où l’intérêt de définir une solution SaaS. Bien qu’il s’agisse d’une solution de sécurité complète, les solutions PASM seules ne sont peut-être pas l’avenir des solutions de sécurité, avec l’émergence des stratégies ZSP…

Zero-standing Privilege(ZSP) est une stratégie de sécurité alternative qui vise à remplacer les comptes et privilèges persistants par un système « juste à temps » et « juste assez » pouvant être appliqué à la fois pour l’utilisateur et pour le serveur.

Pour l’utilisateur :

• Zero Standing Privilege : Les utilisateurs ont droit à un ensemble de privilèges préapprouvés, mais ces privilèges ne sont pas activés par défaut
• Juste assez : Lorsqu’ils doivent effectuer une opération, ils peuvent activer les privilèges minimaux nécessaires à la réalisation de leur tâche…
• Juste à temps : … pendant la période requise, suite à laquelle les privilèges sont automatiquement révoqués.

La ZSP appliquée au niveau de l’utilisateur permet de sensibiliser les utilisateurs, d’améliorer la traçabilité des opérations des organisations et de limiter le risque de « fat-finger ».

Pour le serveur :

• Zero standing privilege : Les comptes ne restent pas sur les serveurs, ou ils n’ont pas d’autorisation.
• Juste assez : Lorsqu’un utilisateur a besoin d’accéder au serveur, un compte est créé à la volée sur le serveur ciblé…
• Juste à temps : …uniquement pour la durée de la session.

La ZSP appliquée au niveau du serveur évite la compromission d’un compte en cas de violation, évite le contournement des outils PAM et évite les écarts entre les solutions théoriques et les solutions effectives.

La ZSP est-elle l’avenir de la gestion des accès privilégiés ?

La ZSP est conçue pour l’avenir des technologies de l’information, où de nombreux utilisateurs ont accès à de nombreuses ressources en constante évolution, et elle permet d’utiliser efficacement les principes du Zéro Trust. Cependant, la ZSP ne répond pas à tous les cas d’utilisation (comme machine-to-machine) et son développement n’est pas abouti, ce qui signifie que l’on manque d’expérience sur le terrain.

Ainsi, le conseil de Wavestone sur la stratégie à adopter est de définir d’abord votre stratégie PAM globale, puis une solution PASM solide pour sécuriser efficacement les accès à vos serveurs, avant d’envisager l’introduction d’un peu de ZSP. Par exemple, au niveau de l’utilisateur pour les privilèges élevés ou pour les utilisateurs ayant des besoins occasionnels et au niveau du serveur pour le cloud.

Webinar accessible à ce lien : https://www.thesasig.com/calendar/event/23-10-11-networks/

Cet article La sécurisation des accès privilégiés – Approches pour relever des défis multiples est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.