Pourquoi les attaquants adorent les ICP mal gérées

Parfois, j'ai l'impression que décrire PKI comme un aspect de la "cybersécurité" est quelque peu abusif. Un manque de visibilité et de centralisation, l'utilisation de certificats auto-signés, de services et d'appareils non inventoriés et d'autres exemples de mauvaise hygiène sur PKI créent des piles technologiques compliquées et fragiles et entraînent des coûts inutiles (y compris des pertes de revenus liées à des services interrompus).

À cet égard, la cyber stabilité ou cyber résilience peuvent être plus justes pour décrire l'importance d'un PKI moderne et performant.

Cependant, un site PKI mal géré se prête à de véritables cyberattaques. Les mauvaises pratiques permettent aux acteurs malveillants de s'emparer plus facilement des clés des systèmes et des actifs, tandis que les "angles morts" créés par ces pratiques facilitent l'accès à l'information. les angles morts créés par ces pratiques leur permettent de se déplacer et de s'installer dans les systèmes organisationnels. leur permettent de se déplacer et de s'installer dans les systèmes de l'organisation.

Les clés privées sont utilisées pour décrypter les informations, et chaque utilisateur et chaque machine les utilisent. Les clés publiques, en revanche, permettent de vérifier que l'expéditeur d'une communication cryptée est bien celui qu'il prétend être. Si ces clés sont compromisesles attaquants peuvent mener des attaques de type "man-in-the-middle", qui consistent à intercepter et à décrypter les communications pendant le transport. Par ailleurs, en fonction du type de certificat, un acteur malveillant peut également signer des software malveillants ou émettre des certificats frauduleux qui permettent d'autres formes d'attaques.

Une fois en possession des bonnes clés, un attaquant peut ouvrir une myriade de portes. Les attaques contre PKI comprennent l'ingénierie sociale, les vulnérabilités de software , les attaques de la chaîne d'approvisionnement et les attaques par canal latéral (entre autres).

Pour les protéger, les clés privées doivent être stockées sur hardware security modules (HSM) et faire l'objet d'une rotation régulière. Bien entendu, elles doivent être limitées aux seuls utilisateurs et services qui ont besoin d'y accéder, conformément au principe du moindre privilège. Une fois ces mesures prises, vous pouvez surveiller et enregistrer les tentatives d'accès afin de détecter tout comportement suspect, tout en surveillant et en inventoriant en permanence votre site PKI. La centralisation de la gestion de PKI et des certificats, l'activation de la découverte proactive et la définition de politiques empêchant l'utilisation de PKI permettront aux organisations de mieux faire face à l'évolution des attaques contre PKI.

Algorithmes cryptographiques, outils, meilleures pratiques, et même les fournisseurs tombent en disgrâce lorsqu'ils ne sont plus sûrs contre les nouvelles menaces. Après tout, les attaquants ne cessent d'améliorer leurs propres capacités et outils, tout comme nous. Si un site PKI utilise des clés faibles ou des protocoles obsolètes, il devient plus facile pour les attaquants de l'exploiter.

Un mot sur les clés :

• Les clés sont comme des mots de passe, et nous mesurons la longueur d'une clé en "bits". Plus il y a de bits, plus la sécurité est grande. Imaginez une serrure à combinaison avec seulement un 1 et un 0, mais avec 2 048 cadrans.
• Les longueurs de bits recommandées pour la sécurité varient selon les types de clés. Ces recommandations sont en constante évolution.
• L'inconvénient des clés plus longues est qu'elles nécessitent une plus grande puissance de calcul, ce qui peut avoir une incidence sur le coût et la rapidité de vos processus PKI . 
• Les nouveaux algorithmes visent à combiner l'efficacité et la taille tout en tenant compte de l'informatique post-quantique.

Les attaquants peuvent plus facilement forcer les clés faibles, déterminer les collisions pour le hachage cryptographique de la clé, ou faire de l'ingénierie inverse de la clé d'origine. Ils peuvent exploiter des vulnérabilités connues dans des protocoles et algorithmes obsolètes, et ce à différents niveaux et points d'intrusion. 

Vérifiez que votre site PKI ne contient pas de protocoles obsolètes ou de clés faibles. et mettez à jour ce qui doit l'être. Vous devez utiliser TLS 1.2 ou une version plus récente, et vous ne devez pas utiliser WEP, DES, RC4 ou MD5. Mettez ensuite en place des contrôles afin d'effectuer une rotation fréquente des clés et de limiter le nombre de tentatives autorisées pour les entrées de clés incorrectes.

Les certificats numériques sont émis par des sources fiables appelées autorités de certification (AC). Les AC existent dans une hiérarchie de confiance. Au sommet se trouve l'AC racine, également connue sous le nom d'ancre de confiance. Les AC intermédiaires constituent la couche suivante, et les AC émettrices se trouvent au bas de l'échelle. Les organisations utilisent un mélange d'AC publiques et privées. Selon l'étude Keyfactor , l'organisation moyenne en utilise neuf.l'organisation moyenne en utilise neuf.

Comme les certificats numériques, les autorités de certification possèdent leurs propres clés privées. Les attaquants peuvent voler ces clés privées et les utiliser pour émettre des certificats frauduleux. Cela leur permet de mener des attaques de type "man-in-the-middle". Ils peuvent également utiliser des logiciels malveillants ou d'autres techniques d'infiltration pour faire signer un certificat frauduleux par une autorité de certification sans avoir besoin de sa clé privée. 

L'autorité de certification racine doit être protégée à tout prix. Si quelqu'un parvient à la compromettrel'ensemble du site PKI doit être reconstruit à partir de zéro. La meilleure façon de la protéger est de la stocker hors ligne dans un HSM.

En outre, les organisations feraient bien de développer la crypto-agilité et de mettre en place des processus permettant de révoquer en bloc les certificats, les autorités de certification et les clés compromises.

Clés et certificats de signature de code valident que le code et le site software n'ont pas été altérés ou corrompus. Ces clés et certificats sont le plus souvent utilisés par les développeurs et les équipes DevOps. En volant les clés de signature de code, les attaquants peuvent signer des logiciels malveillants et de faux pilotes qui leur donnent accès à des actifs sensibles.

Dans les organisations qui n'ont pas de processus PKI normalisé ou de supervision, les équipes de développement se procurent souvent leurs propres ressources PKI et signent leurs propres certificats. Cet exemple illustre parfaitement la façon dont les tensions entre la sécurité, l'ambiguïté des politiques et la productivité créent des risques inutiles pour les entreprises de toutes sortes.

Non seulement les pratiques en matière de certificats auto-signés sont moins sûres, mais elles sont aussi souvent exacerbées par une mauvaise hygiène sur le site PKI , comme un stockage laxiste des clés. En tant que telles, elles deviennent des fruits faciles à attraper pour les attaquants.

Récemment, CABForum et Microsoft ont travaillé à l'amélioration des exigences de base des certificats de signature de code afin d'y inclure des exigences relatives à l'approbation de l'organisation et à la vérification du HSM. Nous sommes ravis de collaborer avec ces groupes afin de garantir que les produits Keyfactorrépondent à ces exigences en constante évolution et permettent aux clients de développer, de gérer et de faire évoluer leur site PKI.

Une liste de révocation de certificats (LCR) est un inventaire des certificats retirés ou invalidés. Les certificats sont inscrits sur cette liste lorsqu'ils expirent, sont révoqués ou remplacés à la suite d'une compromission.

La CRL est tenue à jour par l'autorité de certification. Les navigateurs et les applications vérifient la LCR pour s'assurer que les certificats qu'ils rencontrent n'ont pas été invalidés. Les pirates peuvent manipuler la LCR pour camoufler l'état révoqué d'un certificat.

Pour accéder à la CRL, les attaquants peuvent voler la clé privée de signature de la CRL par hameçonnage ou en exploitant les vulnérabilités du site software . Cela permet à l'attaque de créer une fausse CRL signée qui réactive un certificat potentiellement compromis. Une autre méthode consiste à usurper DNS pour fournir une CRL périmée.

De nombreuses organisations s'orientent vers le le protocole OSCPqui vérifie l'état de révocation de chaque certificat individuel au lieu de télécharger la CRL complète. Ce changement peut s'avérer judicieux pour votre organisation.

Dans tous les cas, vous pouvez protéger la LCR en stockant les clés en toute sécurité, en maintenant des privilèges de contrôle d'accès stricts et en effectuant des audits de sécurité réguliers.  

PKI n'est pas difficile à défendre contre les attaquants. Des gains considérables en matière de sécurité seront de la modernisation de votre système d'information. PKI pour qu'elle fonctionne de manière plus fluide et plus efficace.

Prenez soin de vos clés. Stockez-les sur un HSM ou un coffre-fort software - ou au moins sur un système de fichiers local qui peut à la fois générer et générer et stocker la clé privée sans faire appel à un serveur. Renforcez la solidité de vos clés et faites-en la rotation régulièrement. Restreignez l'accès et mettez régulièrement à jour les listes de contrôle d'accès.

Créez des politiques à l'adresse PKI . Lorsqu'il y a des règles, le comportement aberrant d'un attaquant est plus facile à détecter. Permettre la découverte proactive de tous les certificats et crypto-actifs afin de savoir ce qu'il faut protéger. Consolidez-les dans une plateforme de gestion universelle. À partir de cette centralisation, mettez en place des politiques et des procédures sécurisées.

Procéder à un entretien de routine. Vérifier les mauvaises configurations et les vulnérabilités, mettre à jour les autorisations d'accès, rechercher les comportements suspects et atténuer la prolifération de PKI - c'est ainsi que les organisations construisent véritablement un site PKI qui est à la fois sûr et flexible. Il s'agit d'une pratique constante, et non pas d'un grand coup de pouce une fois par an.

Les équipes chargées de la sécurité, de l'infrastructure et autres qui gèrent PKI ont beaucoup à faire. Cependant, réagir à une compromission sur PKI est beaucoup plus coûteux et intensif que de l'empêcher dès le départ.