Comment j'ai perdu le contrôle de mon PKI

Sur le chemin du bureau, je remarque les bouleaux qui bourgeonnent et je me demande quand mes allergies commenceront à se manifester, dans deux semaines environ. En arrivant à mon bureau, je reçois quelques hochements de tête de mes collègues. J'engage la conversation avec un collègue qui envisage d'acheter une nouvelle voiture. Un autre qui se réjouit de partir en week-end avec son futur fiancé. Toutes les activités de la matinée se déroulent selon le statu quo. Remplissage du café. Démarrage du système. Entrée dans BitLocker. Entrée du code PIN protégé par certificat pour démarrer tous mes postes de travail. Comme une cadence rythmique. Je commence à cocher ma liste quotidienne de tâches de surveillance.

1. Vérifier les prochaines expirations de certificats
2. Vérifier les journaux de l'autorité de certification
3. Vérifier l'état des LCR connues
4. Examiner et attribuer les tickets d'assistance

Contrôle, contrôle, contrôle, contrôle

Quelques tickets d'assistance mineurs continuent à circuler dans le système. L'un d'entre eux indique que quelque chose ne va pas avec notre système téléphonique secondaire - c'est étrange, mais pas trop alarmant. Le système a toujours été défaillant, tout comme nos processus de contrôle manuel, SHA-1 PKI, et le nombre exorbitant de certificats. Terry, notre ancien "PKI guy" (considéré comme le maître de PKI parmi ses nombreuses autres responsabilités) était dans l'entreprise depuis 22 ans et a pris sa retraite il y a tout juste six semaines, me laissant avec :

• un manuel de trois pages
• des copies de notre CP/CPS de 2006
• quelques notes sur l'architecture de l'écorce de poulet
• et quelques heures de "transfert de connaissances" en partant

C'est ainsi que je suis devenu le "nouveau gars de PKI ".

Le premier jour après le départ de Terry, ma première suggestion a été de prendre en main nos certificats, nos LCR et nos AC, ainsi que la gestion globale de leur cycle de vie. Réunir l'inventaire des certificats émis en interne et des certificats de confiance externes que nous avions achetés, puis trouver un meilleur moyen de les inscrire, de les renouveler et de les révoquer - mais cela n'a pas été bien perçu par la direction générale.

"Pourquoi réparer quelque chose qui n'est pas cassé ? Tenez vos feuilles de calcul et vos notes à jour"... "Terry a fait cela pendant des années sans problème - je ne vois pas pourquoi vous ne pourriez pas faire de même". Au cours de mes quatre années passées dans cette entreprise, j'avais appris à garder la tête baissée et à ne pas être trop ambitieux lorsqu'il s'agissait de suggérer de nouvelles plates-formes ou méthodologies d'automatisation, et ce pour les raisons suivantes :

• pas de budget
• trop de départements concernés
• douleur du changement par rapport au "système" actuel

Ne faites pas de vagues.

En respirant profondément, je reviens à la réalité et réalise que je ne peux pas faire bouillir l'océan. Un sentiment de paix m'envahit. J'ai peut-être le temps de passer en revue les principales prédictions/menaces de cette année en matière de sécurité (oui, je sais, nous sommes en juin). Je sais que je devrais être plus prévoyant, mais je ne peux pas m'empêcher de me sentir submergé par notre bombe à retardement, c'est-à-dire notre sitePKI obsolète et mal géré, et par les tâches manuelles qui m'accaparent quotidiennement. Je me demande (juste pour un instant) combien de temps elle a fait tic-tac avant que j'en hérite. Peut-être que l'ignorance est vraiment une bénédiction.

Quelques heures s'écoulent. Je commence à penser au déjeuner, encore une livraison de Jimmy John's ? Bien sûr, pourquoi pas. Je scanne encore une fois les courriels. Je me rends compte que la chaîne de remédiation pour les tickets d'assistance que j'ai émis ce matin est revenue comme un échec. Mon courriel à la personne responsable de notre système de demande de congés est revenu sans erreur d'utilisateur ni problème de serveur. Idem pour le contact téléphonique secondaire. C'est étrange. Je m'apprête à envoyer un ping à Justin pour poursuivre l'escalade, lorsque je remarque que mon accès à Internet est coupé. Juste le Wi-Fi ? Non, tout le réseau. Je lève les yeux vers mon téléphone de bureau et je vois le message d'erreur qui s'y affiche également. Lentement d'abord, puis d'un seul coup, ils commencent à me frapper comme une tonne de briques. Alertes de refus d'accès. Personne ne peut accéder au réseau. Une catastrophe imminente.

Mon téléphone portable sonne, non pas une fois, mais deux fois, puis une troisième fois en succession rapide. Des courriels commencent à arriver de notre système d'alerte externe qui surveille l'accès au domaine. Mon cœur s'emballe. Je commence à espérer que j'ai manqué une note de service concernant une panne planifiée par notre fournisseur d'accès à Internet - mais la situation ressemblait trop à "l'orage parfait" pour que ce soit le cas.

Je commence à dresser une liste des refus d'accès (qui ne cesse malheureusement de s'allonger) :

• réseau à l'échelle de l'entreprise
• Wi-Fi à l'échelle de l'entreprise
• système téléphonique principal
• système téléphonique secondaire
• portail client
• serveur de fichiers interne
• système de demande de congés

Il s'agissait d'un exercice d'évacuation éprouvé. J'alerte frénétiquement notre équipe dirigeante et commence à creuser. Je fais défiler les journaux et je refais mes "vérifications" - ai-je manqué quelque chose plus tôt ?

Une ampoule s'allume alors que je me remémore un livre blanc de Gartner que j'ai lu il y a plusieurs mois. Qu'en est-il d'un certificat expiré ? Ha, lequel ? Nous en avons des milliers. Je me concentre. Je commence à vérifier les dates d'expiration des certificats utilisés par les systèmes concernés. Des dates valides - peut-être une liste de révocation de certificats (CRL) indisponible ou périmée ? Je n'ai aucune idée de l'endroit où ces listes sont conservées. Cela ne s'est jamais produit lorsque Terry était là. Pourquoi moi ?

La raison pour laquelle cela ne s'était jamais produit auparavant était simple, ce qui rendait la situation d'autant plus frustrante. Terry hébergeait la CRL de nombreuses applications sur un serveur qui avait été mis hors service. Il s'avère que l'équipe d'exploitation informatique a constaté qu'un serveur disparate, appartenant à Terry (parti), n'était manifestement plus nécessaire et a pris la décision de le débrancher. Un serveur web qui hébergeait la CRL vers laquelle tout était dirigé s'est éteint sans combattre - sans avertissement. Quel plaisir - tous ces ravages causés par une CRL aléatoire. Ce qui soulève une question existentielle : si une CRL n'est pas accessible ou si un certificat expire et que personne n'est là pour le voir, cela pose-t-il un problème ? Absolument.

J'héberge la CRL ailleurs et je me mets en mode de reprise après sinistre. Je m'assure que l'accès est rétabli partout. Contrôler les dégâts avec les équipes internes. Je m'assure personnellement que l'accès de notre PDG est rétabli. Je m'occupe de la perte de productivité à l'échelle de l'entreprise, etc. mais le retour de bâton ne fait que commencer. Nos équipes chargées de la réussite des clients et des ventes sont entrées en colère dans mon bureau : "Comment expliquer cela à nos clients ? Comment faire en sorte que cela ne se reproduise plus ?" Je me recroqueville, donnant une réponse générique mais pleine d'excuses, me demandant dans ma tête comment j'allais *vraiment* faire en sorte que cela ne se reproduise plus. Cette fois, il s'agissait d'un problème de CRL, mais je n'avais aucune idée de l'endroit où étaient hébergées les autres CRL, ni de l'endroit où se trouvaient les milliers de certificats que nous avions émis, ni même de leur utilité. Un mal de tête lancinant est venu s'ajouter à mon estomac tordu.

Ce soir-là, j'ai commencé à évaluer à quel point mon site PKI était incontrôlable depuis le début et à quel point la situation s'était aggravée au cours des six dernières semaines. J'ai créé une troisième autorité de certification pour prendre en charge l'authentification Wi-Fi sécurisée. Nous émettions un nombre considérable de certificats pour chaque appareil se connectant au Wi-Fi, ce qui rendait mon ancienne méthode de suivi manuel des certificats et des données CRL dans une feuille de calcul totalement invalide. De plus, nous avions des personnes disparates issues de départements complètement séparés, dans des bâtiments complètement différents, qui émettaient des certificats à mon insu. J'étais consterné par mon irresponsabilité. Comment avais-je pu laisser un attribut d'authentification aussi puissant sans aucune gestion ? En un clin d'œil, j'avais perdu le contrôle total de mon site PKI . Alors que je supportais avec bonheur de nouveaux cas d'utilisation fantastiques, que je rendais notre CISO heureux avec des couches de sécurité supplémentaires grâce aux certificats que nous avions émis en interne à partir de notre propre site PKI, j'avais orchestré sans le savoir un tir directement sur mon propre pied en laissant ces certificats et ces CRL devenir peu maniables.

Ce jour restera infâme pour moi et mon ancienne entreprise. Tirez les leçons de mes erreurs - envisagez et mettez en œuvre une plateforme de gestion du cycle de vie des certificats et de PKI avant qu'il ne soit trop tard - je regrette de ne pas l'avoir fait.