| accueil | articles | projets | contact | plan |
"How tempting it is to raise high walls and keep out change. Rot here in our own self-satisfied comfort.”
― Frank Herbert, Chapterhouse: Dune
dernière mise à jour 09/09/07/2020
Cet article récapitule une liste de conseils pour RSSI tweeté en juillet 2020. Le cahier des charges que je m'étais donné pour cette série était le suivant :
Vous pouvez retrouver ci-dessous la liste des recommandations, quelques points d'attention dans leur mise en oeuvre et leur justification. Je serai heureux d'accueuillir vos commentaires sur mon compte Twitter @FuraxFox.
seDebugPrivilegeFaites monitorer les instances d'antivirus sur votre parc. Quand ils plantent/s’arrêtent/sont désinstallés sur plusieurs machines en temps restreint, sonnez l'alarme.
Dans la plupart des attaques par rançongiciel observées en 2020, les attaquants neutralisent les antivirus avant déploiement du logiciel chiffrant. Parfoit ce n'est que quelques secondes avant lancement du chiffrement, mais souvent les désactivations commencent plusieurs jours avant. Il y a donc une opportunité de modérer radicalement l'impact d'une telle attaque en supervisant de près les anti-virus.
Il faut que cette supervision remonte dans une console supervisée fréquemment. Or, la plupart des anti-virus sont supervisés par des consoles propriétaires peu regardées.
Il est possible d'y pallier de quatre façons :
Migrez vos administrateurs Windows dans le groupe Protected Users de l'Active Directory (sauf un compte bris de glace).
Par défaut, la politique de gestion des identifiants appliquée dans les environnements Windows vise à simplifier la vie des utilisateurs. Un nombre important de scénarios de compatibilité historique sont supportés (authentification NTLMv2 par exemple), et les mots de passe sont gardés en cache en mémoire et sur disque (pour l'authentification hors ligne entre autre).
En inscrivant les comptes administrateurs dans le groupe Protected Users vous indiquez à Windows que ces comptes doivent exclusivement utiliser l'authentification par Kerberos et que la politique de gestion des identifiants doit privilégier la sécurité sur la simplicité d'utilisation.
Pour l'attaquant, les identifiants des membres de ce groupe deviennent bien plus difficile à capturer pour élévation de privilège ou latéralisation.
Vos comptes administrateurs ne devraient pas être ceux utilisés pour se connecter sur des ordinateurs portables en itinérance. Si c'était le cas, le compte en Protected Users ne pourrait plus se connecter que depuis le réseau local (faute de cache d'authent.hors ligne).
Enfin, un autre effet de bord est l'interaction avec les outils qui n'utilisent pas l'implémentation Microsoft des protocoles d'authentification. C'est parfois le cas sur les outils de gestion d'identité ou certains bastions qui ne supportent pas bien Kerberos et requièrent NTLM. On peut aussi trouver des équipements utilisant de veille version de SAMBA ou utilisant SAMBA sans support Kerberos. Ces configurations ne devraient plus être présentes danns un réseau moderne, mais peuvent bloquer les logins des membres de Protected Users. L'impact est généralement modéré si on applique bien une séparation entre comptes de login et compte d'administration. Et de façon générales les identifiants sensibles du réseau ne devraient pas être utilisés sur des logiciels et équipements obsolètes donc vulnérables.
Il est aussi recommandé de conserver un compte "brise-glace", jamais utilisé. Ce compte dédié aux usages d'urgence (comme une reconstruction d'AD sur incident), doit être protégé par un mot de passe fort et conservé hors ligne. Il doit être exclus des politiques de restriction d'usage afin de s'assurer qu'il ne soit bloqué par erreur dans une situation d'urgence.
Faites scanner vos adresses IP exposées sur Internet régulièrement, et investiguez les changements de services avant que les attaquants ne le fassent.
Un service exposé sur Internet peut être exploité par un attaquant soit comme relais vers l'intérieur du système d'information, soit pour en extraire des informations réutilisées ensuite (des identifiants par exemple), soit comme point d'eau.
La surface exposée n'est pas statique : de nouveaux services sont déployés, des machines sont changées de réseau ou des configuration de pare-feu et d'application changent.
Vérifier cette surface fréquemment, la comprendre et la sécuriser est prendre un pas d'avance sur l'attaquant.
Il n'y a que peu de risque à scanner son infrastructure exposée sur Internet, elle l'est de toute façon en permanence. En revanche, il convient de s'assurer que l'on ne scanne que des adresses qui nous appartiennent. Déborder est une erreur fréquente.
Un autre point d'attention, est que la plupart des organisations ont aujourd'hui beaucoup de machines déployées dans divers cloud. Les énumérer et les scanner peut être plus compliqué que pour des sous-réseaux IP explicitement assignés.
Si vous achetez des services d'infrastructure nuagicielle (IaaS), vous avez probablement des machines virtuelles connectées à vos services internes exposées. Les paramétrages de filtrage réseau des différents clouds peuvent être complexes et sujets à erreur. On peu vite se retrouver a exposer une machine à l'ensemble des clients du fournisseur, ou à l'Internet tout entier.
Enfin, un scan de port, lancé avec des options de performance raisonnables (pas de nmap en mode insane) est aujourd'hui relativement bien toléré. En revanche, les outils de scan de vulnérabilités peuvent aller beaucoup plus loin et causer des dysfonctionnements applicatifs.
Listez les principales applications de votre organisation et prenez un verre/repas/café informel avec chacun de leur propriétaire plusieurs fois par an pour connaitre leurs préoccupations et projets. Bonus si vous récupérez leur GSM pour les appeler le jour ou.
Ne pas connaitre les applications, les enjeux et les propriétaires crée deux grand risques : le premier est celui de choisir des mesures de sécurités inapplicables ou qui vont confronter les choix techniques au niveau applicatif les rendant peu applicables; le second est de ne pas être capable d'évaluer les impacts de décisions prises dans la crise.
Pour un attaquant qui cherche des points d'entrées et des endroits ou récupérer des identifiants toutes les applications sont égales. Pire, ce sont souvent les petites applications oubliées qui sont les plus facile à exploiter.
Mais pour le RSSI, il y'a une hiérarchie de priorités à établir. On constate souvent une divergence entre les visions niveau direction (ou souvent l'importance est jugée au coût) et la réalité dans les métiers. Ce ne sera qu'en parlant aux propriétaires des applications, aux métiers qui les exploitent qu'on pourra efficacement de revoir cette hiérarchie.
Activez le multi-facteur d'Office 365/GSuite pour les comptes d'utilisateurs importants: services financiers, administrateurs techniques, VIP. N'attendez pas d'avoir un facteur matériel idéal: un MFA soft (même SMS) est mieux que pas.
Les attaques à base de dictionnaires de mots de passe sont devenues très courantes (Credential stuffing, ou Password spraying). Le fishing est endémique.
Ces attaques sont particulièrement efficaces sur des services web hébergés dans le cloud.
Activer un second facteur permet de drastiquement réduire les possibilités pour un attaquant de faire des tentatives de connexion : pour chacune une information complémentaire unique sera demandée.
Les seconds facteurs ne sont pas égaux.
L'utilisation d'un générateur de mots de passe à usage unique (One Time Password ou OTP) ou d'un SMS est vulnérable au fishing (l'interface fictive permettant de récupérer le jeton, par exemple). Ce sera le cas pour toute valeur que l'utisateur devra copier manuellement d'un appareil à un autre.
Les logiciels de générations d'OTP sont aussi piratables si l'équipement, ordinateur, tablette ou téléphone est compromis.
Les SMS peuvent aussi être détournés de plusieurs façon. Soit en se faisant réémettre une carte SIM par le service de support, ou en détournant les flux de SMS sur le réseau téléphonique par manipulation SS7.
Même les cartes à puce sont vulnérables à des attaques de Man in the middle comme l'a expérimenté la défense américaine avec le malware Skykipot en 2012.
Toutes ces attaques ont été utilisées en pratique par tous types d'acteurs offensifs. Mais elles obligent à un changement radical de posture : l'attaquant doit cibler individuellement ses victimes plutot qu'énumérer tous les membres d'une organisation.
Forcer ce changement chez l'adversaire entraine une forte réduction des risques pour toute l'entreprise
seDebugPrivilege [...]
Faites supprimer le privilege seDebugPrivilege des utilisateurs du domaine Windows.
Ce privilège permet de lire la mémoire de n'importe quel processus, et de manipuler processus et taches indépendemment de leur propriétaire.
Par défaut, il est donné à "Local Admin" et les seuls qui en aient besoin sont les développeurs système.
Ce privilège est exploité par des outils comme Mimikatz afin d'accèder aux identifiants en mémoire et de permettre élévation de privilège et latéralisation.
Si un attaquant parvient à exécuter du code dans votre système d'information (par l'attaque d'un poste utilisateur par exemple), désactiver ce privilège va diminuer sa capacité à étendre son emprise.
Il existe des usagers légitimes de ce privilège. Ce seront les développeurs de logiciels de bas niveau (outils système, drivers, outils de forensique...), les administrateurs impliqués dans le tuning système fin, ou des investigateurs.
Certains comptes de service, comme ceux d'outils exécutant des EDR ou des antivirus peuvent requérir ce privilège. Ces outils ont souvent de toute façon déja tout controle sur la machine sur laquelle ils s'exécutent.
Dans tous les cas, ces besoins peuvent être adressés au travers d'un groupe spécifique dont les membres peuvent être très peu nombreux.
La plupart des outils de développement ne requièrent pas ce privilège pour faire du déverminage. Si vous avez un doute, le mieux est encore de faire un test avec vos équipes.
Si l'attaquant réussi a exécuter ses outils en tant que SYSTEM sur une machine, il n'a pas besoin de ce privilège pour lire toute la mémoire de n'importe quel processus.
Faites une liste des prestataires potentiels de réponse à incident et de gestion de crise. Contactez chacun pour connaître ses conditions contractuelles, tarifaires, point de contact et délais de réponse en cas d'urgence.
Bonus si vous revoyez la liste tous les ans
Les crises surviennent toujours au mauvais moment. Des attaquants par rançongiciel attendent même les jours fériés pour déclencher leur attaque.
Dans ces moments, trouver un prestataire peut être compliqué : qui appeller, comment obtenir un devis et la signature d'une commande dans l'urgence, et qui sera disponible au moment critique ?
Contacter les prestataires potentiels, échanger avec eux sur les contacts d'urgence et les modes d'achats permet facilement de réduire ce risque.
La loi de Murphy régissant les activités humaines, il est possible que malgré votre prévenance, tous vos contacts soient indisponibles lorsque l'incident survient. Peut être vos contacts seront-ils à même de vous conseiller d'autres prestataires. Sinon, les assureurs ont souvent des listes de contacts.
Un bon complément de ce quick-win est donc de se rapprocher de son assureur pour connaitre son fonctionnement en temps de crise. Parler de ces circonstances avec votre service achat, avec la direction financière est aussi conseillé.
Faites déployer(si ce n'est déjà en place) un outil de gestion de mot de passe sur tout le parc bureautique (comme Keepass).
Et préparez une campagne de "nudging" sur l'usage des mots de passe générés uniques et le stockage sécurisé.
La gestion de mots de passe modernes sans outillage est impossible. Un mot de passe long, imprédictible et unique est déjà complexe à créer et mémoriser, mais les dizaines couramment requis dans un usage régulier des outils informatique sont hors de portée de la plupart des êtres humains.
Le gestionnaire de mot de passe vise donc à réduire le nombre de mots de passe à mémoriser et à rendre plus facile leur changement.
Proprement utilisé, tous les mots de passes en ligne deviennent des valeurs aléatoires qui n'ont plus à être mémorisés. La surface d'attaque pour un attaquant qui voudrait retrouver des identifiants est réduite. Et même si un compte est compromis (et il vous pouvez faire l'hypothèse que tout service en ligne sera tôt ou tard piraté), l'impacte reste minime et le changement de mot de passe peu couteux.
Contrairement à ce qui peut être dit, utiliser un gestionnaire de mot de passe ne fait pas disparaitre totalement ceux-ci. Il faut au minimum pouvoir ouvrir une session sur un équipement, pouvoir le démarrer, et déchiffrer le stockage des mots de passe.
L'objectif est donc juste de réduire le nombre de mots de passe à mémoriser à une minorité de passphrases fortes et qui ne soient pas(de préférence) saisies au travers d'un réseau. Il va de soit que ces mots de passes Maitres, doivent être très robustes
Il reste un risque résiduel incompressible : la compromission d'un équipement contenant le stockage des mots de passe doit faire présumer que la totalité des mots de passe qui y sont contenus sont compromis. L'usage d'un tel outil crée donc un risque induit : l'attaquant peut récupérer tous vos identifiants instantanément en piratant un poste plutôt que devoir les intercepter au fil de l'eau sur la durée.
Inscrire ses domaines DNS sur HaveIBeenPowned pour découvrir les mots de passe leakés avant que les attaquants ne le fassent.
Les dictionnaires de logins/mots de passe utilisés par les attaquants sont basés sur les identifiants fuités en ligne.
La plupart des être humains vont réutiliser leurs mots de passe entre divers service, ou utiliser une règle de génération de passphrase relativement statique.
L'expérience montre que les mots de passe sont réutilisables souvent des mois, ou des années après leur fuite.
Être notifié de fuites de mots de passe d'utilisateurs de votre organisation permet de les changer préventivement et de réduire la fenêtre d'utilisation pour les attaquants.
Cette mesure, quoique utile ne couvre qu'une partie des risques.
Vos utilisateurs ont une vie en dehors de votre organisation. Leurs identifiés volés sur des services tiers sont probablement réutilisable sur des comptes professionnels.
Un attaquant cible cherchera des pivots au travers d'information en source ouverte afin d'essayer de les énumérer et trouvera sans doute des identifiants échappant à votre vigilance.
Néanmoins, bien que limité, le ratio effort/réduction du risque d'une veille sur HaveIBeenPowned reste très rentable.
Faites bloquer sur le pare-feu devant les services internes exposés sur Internet (webmail, portail VPN, portail RH...) les adresses IPs de sorties TOR et (si possible) des principaux VPN publics.
Seuls les plus mauvais des Script Kiddies se connectent encore à leurs cibles directement depuis leur point de connexion à Internet.
Il existe des techniques très sophistiquées d'anonymisation, allant du simple rebond à un site piraté à l'opération d'un réseau dédié de coupes-circuits. Mais en fait, mettre en place et maintenir de tels moyens est très lourd et la plupart des attaquants vont utiliser des solutions plus simples: les VPN publics et le routage au travers de TOR.
Toutes les organisations ont des services ouverts sur Internet qui ne sont pas destinés au grand public : point de connexion VPN, portails employés divers, webmail. Il n'y a que très rarement de bonnes raisons d'employer les moyens sus-cités pour s'y connecter (on imagine mal que monter un VPN depuis une sortie VPN soit très légitime).
En bloquant les adresses de sortie TOR et de VPN (quand possible) sur les services destinés aux employés on réduit la possibilité pour des pirates d'y tester identifiants et failles depuis des connexion anonymes. Dans les faits, ces mesures réduisent drastiquement le bruit de fond de scans anonymes et permanents sur Internet.
Cette mesure ne concerne ni l'accès depuis TOR et VPN sur des services destinés au public qui peuvent avoir des usages légitimes. Elle ne parle pas non plus de l'éventuel filtrage de TOR sur les flux sortant du réseau d'une organisation qui est de l'ordre des PSSI et Chartes d'utilisation
Par ailleurs, même les meilleurs listes ont des trous. Des noeuds de sortie TOR ou de VPN apparaissent et disparaissent régulièrement plus vite que les listes ne s'adaptent.
Il sera donc toujours possible à un attaquant sélectionnant un nœud de sortie non référencé ou un VPN exotique d'accéder à vos services. Mais vous aurez réduit ce nombre à une poignée.