Quand le moindre privilège est la chose la plus importante

Cela ne veut pas dire qu’il s’agit uniquement d’un problème lié au développement d’applications mobiles. Les éditeurs de logiciels placent trop souvent leurs bénéfices et le fait d’être les premiers sur le marché avant la sécurité. Les développeurs sont contraints de fournir du code, souvent avant qu’il n’ait été testé de manière adéquate pour détecter les vulnérabilités de sécurité, la modélisation des menaces, etc. L’écriture de code sécurisé qui répond aux PoLP n’est souvent pas une priorité.

L’Internet des objets n’est pas exempté du moindre privilège

Un autre cauchemar est celui de l’Internet des objets (IoT). Nous autorisons les appareils partout, des maisons privées et des entreprises aux hôpitaux, bâtiments publics et bien plus encore. Beaucoup de ces appareils IoT n’ont aucune sécurité interne à proprement parler, et pourtant nous leur donnons accès à nos réseaux et souvent à Internet.

Il s’agit d’un désastre potentiel alimenté par le fait d’ignorer les moindres privilèges, et à l’heure actuelle, la seule façon de le combattre est de surveiller le trafic réseau et de limiter leur accès aux seuls appareils avec lesquels ils ont besoin de communiquer – et rien d’autre. Mais il n’y a aucune pression sur les fournisseurs d’IoT pour qu’ils mettent en place des contrôles appropriés sur leurs appareils au niveau du système d’exploitation – des contrôles qui pourraient limiter les dégâts causés à la fois par les bogues dans le code et par la subversion des appareils par d’autres.

À mesure que nous nous dirigeons vers le cloud, de nouveaux cauchemars potentiels apparaissent. Les fournisseurs de cloud comme Microsoft Azure et Amazon Web Services veulent s’assurer que leurs cloud sont interopérables avec des fournisseurs tiers. Vous pouvez donc choisir parmi une multitude de compléments, mais les fournisseurs demandent souvent des autorisations excessives et les clients n’ont que peu d’autorisations. recours mais de les autoriser car le fournisseur ne prendra pas en charge ses produits s’ils ne sont pas mis en œuvre conformément à leurs exigences.

Certaines entreprises souhaitent des solutions de sauvegarde tierces pour leurs services cloud. Ces fournisseurs nécessitent un accès complet aux données : la sauvegarde nécessite la lecture de toutes les données de partout, et la restauration nécessite la possibilité d’écrire des données n’importe où, ce qui revient essentiellement à donner les clés du royaume au fournisseur, à moins que vous n’ajoutiez des contrôles supplémentaires.

Des sauvegardes sont effectuées régulièrement, mais la restauration des données est généralement une tâche rare. Alors pourquoi ne pas diviser les fonctions et donner à la fonction de sauvegarde des droits en lecture seule tandis que la fonction de restauration, rarement utilisée, qui ne serait utilisée qu’en cas d’urgence, aurait les seuls droits en écriture ? Pourtant, lorsqu’on a posé cette question à un échantillon de fournisseurs de sauvegarde dans le cloud, ils n’y avaient même pas pensé. Cela signifie que si un ver cloud jusqu’alors inconnu compromettait la fonction de sauvegarde, il pourrait écraser les données de l’entreprise, très probablement sans que personne ne s’en aperçoive.

Si un ransomware sophistiqué avait accès au logiciel, dans ce scénario, il pourrait garantir que les sauvegardes elles-mêmes deviendraient la source de logiciels malveillants. Et il existe d’innombrables autres possibilités où le PoLP non appliqué pourrait être utilisé de manière malveillante.

De même, un outil de conformité qui se connecte aux systèmes de messagerie cloud de l’entreprise exige un accès en lecture et en écriture à toutes les boîtes aux lettres des utilisateurs. L’accès en lecture est logique ; l’accès en écriture ne le fait pas. Il s’agit d’une décision de conception du fournisseur, mais cette décision elle-même viole PoLP et la solution doit être repensée.

Il s’agit d’un échec de la part des fournisseurs de cloud, ne serait-ce que de prendre en compte le principe de sécurité fondamental du moindre privilège. Cependant, les propriétaires des écosystèmes cloud ne sont pas en mesure de déterminer si le fournisseur exige des droits excessifs. Nous faisons confiance aux fournisseurs eux-mêmes pour dire qu’il s’agit d’exigences et, comme nous l’avons vu, les fournisseurs choisissent souvent d’exiger plus d’autorisations que de perdre du temps. pour commencer, créer une architecture sécurisée pour leur code.

Il n’est pas exagéré d’imaginer un ver cloud qui profiterait de ces autorisations excessives, et les dommages potentiels seraient bien pires que n’importe quel événement de sécurité précédent.

L’avenir n’est pas plus brillant

De nos jours, tout le monde parle d’intelligence artificielle (IA). Et l’IA, comme toute nouvelle technologie, apporte son propre ensemble de défis uniques au concept de moindre privilège.

Les fournisseurs de cloud sont désormais assez à l’aise avec la séparation des bases de données pour différents clients, et on s’inquiète beaucoup moins des erreurs commises lorsqu’un client pourrait (accidentellement ou délibérément) lire ou écrire les données d’un concurrent dans le cloud du même fournisseur. Mais qui parle de protéger les données d’entreprise dans un cloud IA ?

De par leur nature, de nombreux systèmes d’IA sont acquisifs et vouloir pour obtenir autant de données que possible (pensez aux exaoctets) pour les ajouter à leur modèle d’apprentissage et prendre de meilleures décisions. Quels contrôles existent pour les produits d’IA qui accèdent aux données d’entreprises privées afin de préserver la confidentialité de ces données ? Dans pratiquement tous les cas, l’IA téléchargerait les données de l’entreprise dans la vaste base de données de l’IA pour aider le client à prendre de meilleures décisions, mais d’autres peuvent-ils élaborer une requête pour tromper l’IA et lui faire partager les données de votre entreprise avec eux ?

L’IA prend désormais également en charge les modules complémentaires et les plugins, nous avons donc des systèmes de plus en plus complexes qui ne peuvent pas être facilement (ou jamais) débogués aujourd’hui – et leur complexité augmente de façon exponentielle. Les méthodes de sécurité traditionnelles qui reposent sur des contrôles au niveau du centre de données et des bases de données ne fonctionneront pas dans ce nouveau monde.

Allons-nous compter sur l’IA pour sécuriser ses propres données – et pouvons-nous être sûrs qu’elle peut le faire ? Il s’agit aujourd’hui d’échecs de moindre privilège, et seule une minorité de fournisseurs de solutions d’IA s’attaque à ces problèmes.

Dix recommandations pour résoudre l’énigme du moindre privilège

Nous avons exposé un grand nombre de problèmes. Alors qu’est ce qui peut être fait? Dans la Harvard Business Review, Sabina Nawaz écrit qu’il est temps d’abandonner le dicton « Ne m’apportez pas de problèmes, apportez-moi des solutions ». Mais par respect pour Mme Nawaz, nous avons exposé le problème et voici quelques solutions tactiques et stratégiques.

1. Les clients doivent insister pour que leurs fournisseurs et ceux qui écrivent le code système sous-jacent prennent ces problèmes au sérieux avant qu’une catastrophe ne se produise. Les fournisseurs qui construisent aujourd’hui des systèmes sécurisés seront dans une bien meilleure position en cas de catastrophe. Les vendeurs doivent être clairement informés pendant la phase de recherche qu’ils perdront la vente s’ils ne disposent pas de PoLP de base et d’autres contrôles de sécurité.
2. De même, si vous utilisez déjà des applications tierces qui violent le moindre privilège, adressez des demandes de fonctionnalités aux fournisseurs en leur demandant d’adhérer à PoLP.
3. Mettre en œuvre des contrôles compensatoires. Ne filtrez pas seulement le trafic de pare-feu entrant, mais limitez également le trafic sortant des systèmes critiques aux seules cibles essentielles avec lesquelles ils doivent communiquer, généralement le site du fournisseur lui-même, pour les mises à jour logicielles.
4. Bien que le moindre privilège soit pris en compte au niveau du système, il s’applique également aux données. Et vous devez vous assurer que vous disposez d’une découverte et d’une classification complètes de toutes vos données confidentielles. Connaître précisément de quelles données confidentielles vous disposez et leur localisation est loin d’être une tâche anodine. Comprendre où se trouvent vos données facilite grandement le processus visant à garantir le moindre privilège.
5. Un autre contrôle essentiel, bien qu’imparfait, consiste à augmenter la journalisation sur toutes les couches de la pile technologique que vous pouvez. Les outils de détection d’anomalies peuvent permettre de gagner du temps ou de détecter des modèles inhabituels. Surveillez particulièrement vos outils qui ont accès à tous vos réseaux internes.
6. Il est essentiel de créer des versions standard et sécurisées pour vos systèmes d’exploitation qui éliminent les bloatwares, plug-ins et protocoles inutiles. Cela réduit votre surface d’attaque de plusieurs ordres de grandeur.
7. C’est tellement évident et tellement élémentaire que nous en avons débattu. Mais vous devez supprimer les comptes d’utilisateurs inactifs. Vous ne pouvez pas bénéficier du moindre privilège si vous disposez de comptes d’utilisateur pour des utilisateurs qui ne font plus partie de l’organisation. Les attaquants ciblent les comptes inactifs car cela leur donne accès sous couvert d’être un utilisateur légitime.
8. Le contrôle d’accès basé sur les rôles (RBAC) est primordial pour garantir que les privilèges ne sont pas augmentés. Et RBAC est pris en charge par tous les principaux fournisseurs de cloud et par tous les systèmes d’exploitation.
9. Passez en revue les politiques et procédures de développement de logiciels de votre entreprise et assurez-vous que le code que vous développez respecte le principe du moindre privilège.
10. Enfin, la surveillance des utilisateurs, notamment des comptes privilégiés, est primordiale. Vous devez comprendre ce que font ces utilisateurs et à quels systèmes et données ils accèdent.

L’histoire nous apprend que les problèmes de moindre privilège ne sont pas sérieusement attaqués jusqu’à ce que des incidents importants poussent les fournisseurs à faire ce qu’ils auraient dû faire au départ. La plupart d’entre nous n’ont pas le luxe d’attendre que les vendeurs se réveillent. Supposons et planifions le pire.

L’histoire de la sécurité de l’information montre également clairement que les violations de données et les catastrophes ne sont pas une question de savoir si, mais quand. Et le meilleur moment pour se préparer à cette inévitable situation est maintenant.