"Ne faire confiance à personne" - une expression qui rappelle The X-Files - est désormais un concept familier dans le domaine de la cybersécurité.
Alors que la pression pour protéger les systèmes et les données des entreprises augmente et que les attaques deviennent de plus en plus sophistiquées, les équipes informatiques et de sécurité d'aujourd'hui ne peuvent tout simplement pas se permettre de faire automatiquement confiance à quoi que ce soit (ou à qui que ce soit) à l'intérieur ou à l'extérieur de leur réseau. Pas même les administrateurs système.
À l'époque où j'étais une jeune webmistress(oui, c'était un titre), les choses étaient bien différentes...
J'étais en train d'apprendre les tenants et les aboutissants de la maintenance de notre nouveau site web lorsque quelqu'un a mentionné l'ajout d'une fonctionnalité de commerce électronique. Soudain, la sécurité de l'information est devenue un sujet auquel je devais penser.
Bien sûr, nous n'avions pas de politique de sécurité à l'époque, alors je me suis simplement rendu sur un site web, j'ai acheté un certificat SSL et je l'ai installé sur le serveur web. Si j'en avais eu le temps, j'aurais envoyé le certificat et le mot de passe par courriel à mon responsable, en guise de sauvegarde, juste au cas où nous en aurions besoin.
Au fil du temps, j'ai appris à demander des certificats de confiance internes pour des utilisations aléatoires telles que la sécurisation des transferts de fichiers (FTP) et des communications internes (S/MIME). Il me suffisait de me connecter à Active Directory Certificate Services (ADCS) et de demander un certificat avec les données qui me semblaient appropriées.
Là encore, aucune politique n'a été mise en place.
Les temps ont certainement changé. Aujourd'hui, la plupart des organisations appliquent des politiques et des pratiques de sécurité informatique standard à toutes les fonctions et à tous les secteurs d'activité. Mais la capacité d'un administrateur à demander indépendamment un certificat directement à une autorité de certification (AC) interne ou externe n'a pas changé.
Administrateurs malhonnêtes ou méchants ?
Les administrateurs informatiques et systèmes disposent d'un accès privilégié et exercent un pouvoir immense sur les données, les appareils et les applications. Vous ne pouvez pas survivre sans eux, mais peu d'incidents peuvent paralyser une organisation comme le fait un administrateur malhonnête.
Mais il ne faut pas assimiler les administrateurs malhonnêtes à des méchants. Dans de nombreux cas, les agents malhonnêtes ont des intentions honnêtes (pensez à James Bond), mais ils préfèrent travailler en dehors des politiques et des pratiques organisationnelles qu'ils considèrent comme trop restrictives ou trop longues pour leur travail quotidien.
Par définition, voyou signifie "se comporter de manière inattendue ou anormale, souvent de façon à causer des dommages". Voilà le vrai problème.
En réalité, la grande majorité des administrateurs souhaitent suivre les meilleures politiques et pratiques, mais les étapes traditionnellement lentes et manuelles pour créer une demande de signature de certificat (CSR) les amènent à opter pour des alternatives plus rapides et non conformes. Et pour ceux qui suivent les politiques et les procédures, les gens font des erreurs. L'erreur humaine se glissera toujours dans les processus informatiques manuels.
À chaque erreur, le nombre de certificats non conformes finit par dépasser les capacités de votre équipe chargée de l'infrastructure à clé publique (PKI). C'est alors que cela se produit. Un auditeur trouve plusieurs certificats non conformes et exige des mesures correctives immédiates. Les équipes de PKI doivent se démener pour contacter les administrateurs afin de trouver, renouveler et remplacer tous les certificats non conformes à la politique.
Était-ce attendu ? Probablement pas. Mais cela devrait-il vraiment être une surprise ? Pas du tout.
Plus important encore, les dommages causés par ces incidents sont critiques. Dans un récent billet de blog, mon collègue et directeur de la sécurité à Keyfactor, Chris Hickman, a évoqué le rapportKeyfactor-Ponemon sur "L'impact des identités numériques non sécurisées". Chris souligne que les organisations ont subi en moyenne cinq échecs d'audit au cours des 24 derniers mois, ce qui représente une perte économique moyenne de plus de 14 millions de dollars.
Selon lui, "lorsqu'il n'y a pas de contrôle sur la manière dont les administrateurs demandent, renouvellent et installent les certificats, ils sont beaucoup plus susceptibles de violer les politiques informatiques, et il devient rapidement impossible de savoir où se trouve chaque certificat, comment ils sont utilisés et qui en est le propriétaire".
Trouver l'équilibre : Automatisation et contrôle
L'objectif des administrateurs informatiques est de s'assurer que les systèmes et les applications qu'ils gèrent respectent les niveaux de service définis. Dans ce contexte, il est logique qu'ils gèrent également les clés et les certificats.
Dans le même temps, l'équipe PKI devrait en fin de compte avoir le contrôle de chaque clé et de chaque certificat dans l'entreprise, ainsi que de la manière dont ils sont obtenus. Mais en l'absence de garde-fous, il n'y a aucun moyen d'appliquer des politiques permettant d'éviter des scénarios coûteux (et franchement embarrassants) comme ceux décrits dans le rapport.
Il s'agit de trouver un équilibre entre le besoin de contrôle de l'équipe PKI et le besoin de rapidité des administrateurs. La mise en place d'une structure pour l'émission et le cycle de vie de vos certificats est le moyen le plus simple de garantir à votre équipe PKI la visibilité et le contrôle nécessaires pour maintenir le niveau de réclamation. De plus, l'automatisation permet aux administrateurs informatiques et systèmes d'éviter les pannes sans perdre un temps précieux.
La mise en œuvre de la bonne solution et des bons processus pour sécuriser et automatiser les identités numériques aidera votre organisation à instaurer une culture de la confiance et à éviter le risque d'administrateurs malhonnêtes, ou simplement pressés par le temps.
Pour plus d'informations, téléchargez le rapport complet Keyfactor-Ponemon :
