Sécurité

Le grand débat : la sécurité par l'obscurité

Jesper M. Johansson and Roger Grimes

Vue d'ensemble:

• Définition de la sécurité par l'obscurité
• Évaluation de la sécurité par des mesures d'obscurité
• Comprendre l'intérêt du changement de nom du compte Administrateur
• Prendre des décisions informées de gestion des risques

Le terme « sécurité par l'obscurité » est souvent pris à la dérision par les professionnels de la sécurité, notamment ceux qui se considèrent comme experts. Quasi considérée comme un juron dans certains milieux, la sécurité

par l'obscurité, selon Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), représente l'un des aspects véritablement controversés de la sécurité. Vous verrez souvent des références moqueuses à des personnes dont les efforts sont relégués comme étant « seulement de la sécurité par l'obscurité ».

La sécurité par l'obscurité est, pour rester simple, une violation du principe de Kerckhoffs, qui décrit un système comme étant sécurisé de par sa conception et non parce que sa conception est inconnue de l'adversaire. Le principe fondamental de Kerckhoffs est que les secrets ne restent pas secrets très longtemps.

Le protocole d'authentification Windows NT® LAN Manager (NTLM), qui était considéré au début comme un secret de conception, constitue un excellent exemple. Pour implémenter l'interopérabilité de produit Samba pour les systèmes d'exploitation basés sur UNIX, l'équipe Samba a dû effectuer une rétroconception du protocole. Le résultat a été la documentation la plus complète disponible sur NTLM (monyo.com/technical/samba/translation/ntlm.en.html) ainsi que la découverte de plusieurs bogues. Comme une très grande partie de la sécurité a évolué à partir de la cryptographie, et que tant de conceptions secrètes ont été révélées, de nombreux professionnels de la sécurité estiment que toute sécurité des informations doit suivre le principe de Kerckhoffs.

Mais la sécurité par l'obscurité est-elle toujours mauvaise ? Dans cet article, nous décrirons ce qu'est la sécurité par l'obscurité, tenterons d'expliquer pourquoi beaucoup la considèrent comme une perte de temps (et d'autres non) et vous montrerons pourquoi la réponse, comme d'habitude, est beaucoup plus compliquée qu'elle ne semble l'être au premier abord.

Présentation de la sécurité par l'obscurité

Ne modifiez pas les valeurs par défaut, par Steve Riley

Je suis partisan de l'opinion « ne changez rien » sur la question du changement de nom. Il ne s'agit même pas d'une question de sécurité. C'est un problème d'administration des systèmes. Comme je passe plus de temps à réfléchir sur le domaine de l'administration de systèmes (car l'administration et la sécurité sont en train de fusionner), je deviens de plus en plus partisan du « ne rien faire » qui peut accroître la vulnérabilité d'un système. Ne plus utiliser les éléments par défaut est une méthode garantie pour accroître la vulnérabilité. Il existe deux (d'accord, trois) raisons pour lesquelles les gens modifient les paramètres par défaut :

• La modification permet de répondre à une exigence connue de la fonctionnalité.
• Il est supposé que la modification améliorera la sécurité.
• (Attention : préparez-vous à entendre des sottises) Quelqu'un l'a lu dans un article de magazine.

Si vous devez changer pour ne plus utiliser un nom par défaut pour la raison numéro 1, allez-y. Ces types de modifications ont rarement pour résultat l'instabilité du système, souvent parce qu'ils ont été testés au préalable.

Si vous modifiez une valeur par défaut pour la raison numéro 2, arrêtez-vous et prenez un moment pour réfléchir. Ces types de modifications ne sont presque jamais testés par le fabricant du logiciel et celui-ci ne peut donc pas prédire comment le système se comportera après que vous ayez effectué la modification. De plus, il existe généralement de bien meilleures alternatives qui vous offriront une véritable sécurité.

Si une personne mal intentionnée arrive à connaître le nom d'un compte, est-ce si important ? C'est le mot de passe et la force de ce mot de passe qui gardent cette personne à l'écart de votre système. L'envie de modifier les noms de compte par défaut comme Administrateur et Invité pour les remplacer par quelque chose de moins facile à deviner est en fait souvent un indicateur du désir d'éviter les mots de passe forts. Résolvez le véritable problème (les secrets douteux) et vous pourrez alors éviter la vulnérabilité (la modification des noms par défaut).

La sécurité par l'obscurité n'inclut pas de mesures qui ne font absolument rien pour atténuer un problème. Par exemple, une organisation qui bloque le protocole NNTP (Network News Transfer Protocol) aux routeurs de périmètre pour empêcher les employés de lire les groupes de discussion mais autorise le Shell sécurisé (SSH) sortant n'applique pas la sécurité par l'obscurité. Puisque SSH peut acheminer tous les protocoles, le problème n'est pas obscurci. L'atténuation absurde qui a été implémentée ne fait rien d'autre qu'empêcher les utilisateurs légitimes d'accomplir des tâches légitimes sans enfreindre des stratégies de sécurité. De telles mesures ne correspondent pas à la sécurité par l'obscurité. Elles sont absurdes et dénuées de sens.

Comme l'indique le mot « sécurité » dans le terme « sécurité par l'obscurité », vous obtenez vraiment une certaine protection grâce à celle-ci. Cependant, ce que ce terme implique également (et c'est là tout le problème) est que vous ne faites rien pour arrêter une attaque d'un ou plusieurs vecteurs (un vecteur d'attaque est en gros un moyen par lequel un attaquant peut accéder à un système).

Supposez que vous ayez par exemple un serveur Web vulnérable, pouvant être attaqué via le port TCP 80 par du code malveillant. Pour fermer ce vecteur particulier, vous pouvez appliquer un correctif au serveur Web ou l'éteindre. Chacune de ces actions arrêterait complètement ce vecteur. Vous pourriez arrêter partiellement le vecteur d'attaque en utilisant un pare-feu ou IPSec pour fermer le port 80 à tout sauf à quelques ordinateurs particuliers. Ceci ne bloquerait pas complètement le vecteur d'attaque, mais atténuerait de manière significative le problème.

La sécurité par l'obscurité, d'un autre côté, implique la prise de certaines mesures n'arrêtant pas le vecteur d'attaque mais le dissimulant simplement. Par exemple, vous pouvez décider de transférer le serveur Web sur le port 81 au lieu du port 80 afin que seuls ceux qui savent où trouver votre serveur Web puissent le faire. C'est ainsi que cela se justifie. En réalité, le transfert de votre serveur Web sur le port 81 arrête seulement certaines attaques et dérange principalement l'utilisateur final. Un intrus compétent exécuterait simplement un scanneur de port et une capture de bannière Web avec plusieurs ports pour découvrir des serveurs Web sur les ports non standard. Dès qu'il en aura trouvé, il pourra exécuter le code malveillant contre votre serveur car vous n'avez en fait pas éliminé le vecteur d'attaque, mais l'avez simplement (temporairement) obscurci.

Cela signifie-t-il que vous ne devriez même pas essayer ? La réponse est : ça dépend. Comme avec tout ce qui a trait au domaine de la sécurité des informations, cela se réduit à la gestion des risques. Pour comprendre les facteurs clés à prendre en considération, nous examinerons rapidement quelques mesures de sécurité par l'obscurité supplémentaires et commenterons l'une de celles-ci (renommer le compte administrateur) plus en détail.

Évaluer les mesures de sécurité

Les exemples de sécurité par l'obscurité sont nombreux. Il peut s'agir d'actions prises par les administrateurs système et réseau ou initiées par les développeurs de logiciels. Ce qu'elles ont toutes en commun, cependant, est qu'elles ont pour objectif d'atténuer une vulnérabilité en la masquant des attaquants potentiels.

Certaines de ces procédures ne pourraient-elles pas au moins avoir un effet avantageux ? Est-il vraiment juste de dire que toute sécurité par l'obscurité est mauvaise ? Vous trouverez certainement des partisans d'au moins certaines de ces mesures. Par exemple, dans Windows®, il est possible de masquer les lettres de lecteur dans l'Explorateur Windows. Dans de nombreux environnements, plus particulièrement dans les salles d'informatique des établissements scolaires, vous utiliserez cette technique pour empêcher les utilisateurs d'enregistrer des données sur le disque dur. Bien entendu, la plupart des applications peuvent toujours enregistrer des données sur le disque dur et elle n'a qu'une valeur limitée en tant que mesure de sécurité. Cependant, les établissements qui l'ont implémentée déclarent souvent qu'elle réduit la quantité de données sur le disque dur.

Une autre pratique de sécurité par l'obscurité souvent mise en œuvre sur Windows consiste à désactiver les partages réseau administratifs (tels que C$, Admin$, etc.). Ceci a pour but d'empêcher un attaquant de se connecter à l'ordinateur à distance. En réalité, ceci est non seulement faux, mais en plus, un attaquant possédant un compte qui peut utiliser les partages administratifs peut réactiver à distance ces mêmes partages. Pourtant, de nombreuses entreprises déclarent solennellement que la désactivation de ces partages réduit la quantité de logiciels malveillants sur leurs réseaux.

L'un des nos exemples préférés d'efforts mal gérés est le paramètre « autoriser le retrait sans ouverture de session préalable » de Windows. Si ceci est désactivé, le bouton « Retirer l’ordinateur » est masqué de l'écran d'ouverture de session. Le principe sous-jacent est que de cette manière un attaquant ne peut pas retirer normalement l'ordinateur. Bien sûr, tout intrus peut simplement mettre l'ordinateur et la station d'accueil dans un sac et s'en aller avec, que ce bouton soit visible ou non. Cette possibilité n'est pas même de manière lointaine de la sécurité par l'obscurité.

Le paramètre « permettre aux opérateurs du serveur de planifier des tâches » est un autre exemple évident. Comme il l'indique, il permet aux utilisateurs membres du groupe Opérateurs de serveur de planifier des tâches. Il s'agit d'un problème sensible car de telles tâches peuvent s'exécuter comme Système local, et seuls les administrateurs doivent pouvoir planifier des tâches s'exécutant comme Système local. Bien entendu, les opérateurs de serveur peuvent potentiellement se rendre administrateurs grâce à différents vecteurs et les empêcher de planifier des tâches de cette manière a en fait un intérêt minimal.

Pourtant, de nombreuses entreprises apprécient ce paramètre car il permet aux ingénieurs d'être opérateurs de serveurs au lieu des administrateurs, ce qui signifie qu'ils risquent probablement moins de détruire accidentellement le serveur. Ceci, en soi, peut apporter un certain avantage.

Par conséquent, quel est le verdict ? Il est évident que certains de ces problèmes peuvent être très complexes. Nous avons passé des heures à débattre agréablement de ces types de mesures. Roger est fermement dans le camp qui trouve que de telles pratiques ont une valeur. Jesper, d'un autre côté, pensent qu'elles sont, dans le meilleur des cas, une perte de temps. Examinons un cas fréquemment abordé (et débattu) pour la sécurité par l'obscurité : renommer le compte administrateur. Roger sera en faveur de cette mesure, Jesper contre celle-ci. Les barons de la sécurité Aaron Margosis et Steve Riley donnent également respectivement leur avis dans les encadrés « Renommer le compte administrateur » et « Ne modifiez pas les valeurs par défaut ».

Masquer le compte Administrateur

Renommer le compte Administrateur, d'identificateur relatif (RID) 500, est relativement peu connu du grand public, souvent recommandé par les professionnels de la sécurité et est inclus dans plusieurs guides de renforcement de Microsoft. La Stratégie de groupe inclut même un paramètre pour renommer le compte Administrateur, comme indiqué à la figure 1. Le principe est que si le compte administrateur est renommé, un attaquant aura plus de difficultés à se connecter en tant que véritable administrateur. Bien entendu, le problème évident avec l'utilisation de la Stratégie de groupe pour cette opération est que le compte Administrateur renommé aura le même nom sur chaque ordinateur auquel cet objet de Stratégie de groupe aura été appliqué. Cela diminue la valeur d'obscurité de cette mesure de sécurité particulière.

Figure 1** Renommer le compte administrateur **(Cliquez sur l'image pour l'agrandir)

Il est également important dans ce contexte de se rendre compte que tout utilisateur avec un compte légitime peut récupérer le nom du compte Administrateur, qu'il ait été renommé ou non. Le compte Administrateur possède le RID 500. En demandant simplement le nom du compte de RID 500, tout utilisateur doté d'un compte peut voir quel est son véritable nom, comme indiqué à la figure 2.

Figure 2** Recherche des comptes Administrateur renommés **(Cliquez sur l'image pour l'agrandir)

L'avis de Roger

L'argument principal que j'entends contre le changement de nom du compte Administrateur est qu'il est si facile de convertir n'importe quel nom de compte d'entité de sécurité en son identificateur de sécurité (SID) et de découvrir son RID. Le véritable compte Administrateur possède toujours le RID 500. Par conséquent, si un attaquant peut facilement convertir des noms de comptes d'utilisateur en combinaisons SID/RID pour trouver le RID 500, pourquoi s'embêter ?

Ce n'est pas si simple. Pour accomplir la traduction du nom du compte d'utilisateur en SID/RID, vous devez avoir accès aux ports NetBIOS ou LDAP. La plupart des pare-feu de périmètre n'autorisent pas ce type d'accès sur Internet et jusqu'à ce que l'attaquant contourne complètement le pare-feu, il ne pourra rien traduire. De plus, les traductions anonymes de SID ne fonctionnent pas sur Windows XP et versions ultérieures de Windows, sauf sur les contrôleurs de domaine (DC). Face aux ordinateurs les plus exposés à l'extérieur (qui courent le plus grand risque), l'attaquant nécessiterait des informations d'identification authentifiées pour effectuer la traduction nom vers SID.

Il existe donc un bon nombre de véritables barrières devant être contournées pour commencer une attaque de traduction. Même si l'attaquant parvenait aussi loin, il finirait au même endroit que si le nom de compte n'avait pas été renommé. Renommer le compte Administrateur peut seulement améliorer la sécurité. Il ne peut certainement pas l'endommager.

C'est un autre secret Si un attaquant ne connaît pas le nom du compte Administrateur, celui-ci devient une autre étiquette « secrète », similaire à un mot de passe, qu'un attaquant doit connaître. Je vous l'accorde, les noms de compte d'utilisateur sont probablement loin d'être aussi complexes qu'un mot de passe administratif, mais il s'agit toujours d'une entrave supplémentaire qui complique l'opération visant à deviner/décoder le mot de passe. Si vous avez fait des tests de pénétration de mot de passe, vous savez déjà à quel point deviner le nom d'utilisateur ainsi que le mot de passe représente davantage de travail. Ce travail complique une tâche déjà difficile.

Déjoue les logiciels malveillants automatisés et les scripteurs amateurs Je pratique la défense de sécurité Windows depuis maintenant 22 ans maintenant, et j'ai utilisé huit « pots de miel » Windows, exposés à Internet, au cours des 5 dernières années. Pendant tout ce temps, je n'ai jamais vu de logiciel malveillant automatisé (ce qui inclut la vaste majorité de toutes les attaques) utiliser un compte utilisateur quelconque, mis à part Administrateur (ou root, pour les systèmes *NIX). Si vous renommez votre compte Administrateur, vous arrêtez tout de suite tout logiciel malveillant reposant sur le nom d'administrateur. Cela se traduit par un risque réduit pour la sécurité.

Ceci est également vrai pour les scripteurs amateurs. Chaque manuel de piratage Windows branché que je connais mentionne les techniques de traduction de SID mais, pour une raison ou une autre, je n'ai pas vu un seul cas correspondant sur mes pots de miel, lorsque ceux-ci possédaient un « faux » compte administrateur pour les égarer. Les bons pirates informatiques devraient toujours vérifier que le compte administrateur qu'ils ont trouvé est le véritable Administrateur (RID 500), mais ils ne font pas. Je ne sais pas pourquoi. Pour moi, la culpabilité en revient à la paresse des pirates informatiques et au comportement humain habituel.

Ca arrête également la plupart des professionnels Ca étonne la plupart des gens. Lorsque vous avez utilisé des pots de miel pendant quelques années, vous reconnaissez rapidement la différence entre les attaques automatisées, les scripteurs amateurs et les professionnels. Au cours des cinq dernières années, avec des millions d'attaques enregistrées pour mes pots de miel, je n'ai jamais vu de professionnels faire la traduction de SID lorsqu'un faux compte Administrateur était présent.

Je suis sûr que certains criminels utilisent la traduction de SID, mais je suis prêt à parier qu'il s'agit d'une petite minorité, que je n'ai jamais rencontrée. Pourquoi les professionnels ne le feraient-ils pas ? J'imagine qu'ils ne voient pas l'intérêt de faire quelque chose lorsque la plupart des gens ne le font pas.

Simplifie les alertes Maintenant, l'autre camp pourrait objecter que si renommer le compte Administrateur devenait courant, cette opération perdrait de sa valeur en tant que technique d'obscurité. La justification est que les logiciels malveillants, les scripteurs amateurs et les professionnels modifieraient leurs tactiques par défaut pour rechercher des noms différents d'Administrateur. Il s'agit d'une inquiétude fondée. Heureusement, elle ne change rien à la condition essentielle. Premièrement, si le compte Windows aux superprivilèges n'est pas nommé Administrateur, le pirate informatique malveillant doit travailler plus dur. Ce n'est qu'un fait. Si le pirate informatique malveillant doit travailler plus dur, il est un peu moins probable qu'il essaiera ce vecteur d'attaque, permettant ainsi peut-être à une autre des techniques de blocage approfondies de détecter plus rapidement l'activité malveillante.

Ceci me mène à mon dernier point en faveur du changement de nom. Si votre compte administrateur n'est jamais appelé Administrateur et que vous créez un autre compte avec ce nom, comme indiqué à la figure 3, vous disposez d'un bon mécanisme d'alerte. Si votre interception d'événements détecte une ouverture de session tentée utilisant le nom par défaut, il s'agit d'un événement à explorer immédiatement.

Figure 3** Les tentatives d'ouverture de connexion avec un compte d'appât nommé Administrateur peuvent servir d'avertissement en amont **(Cliquez sur l'image pour l'agrandir)

Nos journaux des événements sont remplis de « mauvaises » ouvertures de session qui n'ont pas de signification. Généralement, il s'agit simplement d'un utilisateur (ou de Windows) qui essaie d'ouvrir une session en utilisant un mauvais mot de passe ou quelque chose de ce genre. Si votre compte administrateur est appelé Administrateur, cependant, comment pouvez-vous séparer facilement les bonnes tentatives d'ouverture de session de celles qui sont malveillantes ? Si vous n'avez jamais eu de compte d'ouverture de session appelé Administrateur et que vous détectez une tentative d'ouverture de session utilisant ce nom de compte, vous savez que son but est probablement malveillant. Un avertissement en amont avec peu d'écho a une grande valeur pour les défenses d'aujourd'hui.

Le point de vue de Jesper

Renommer le compte Administrateur par Aaron Margosis

Jesper, dans un monde idéal, vous auriez absolument raison. Les mots de passe devraient toujours être assez forts pour rendre impossible leur déduction par force brute et les comptes Administrateur locaux -500 ne seraient jamais utilisés pour la récupération d'urgence. Dans le monde réel, cependant, rien de ceci n'est vrai.

Malgré l'excellente promotion de la sécurité que vous avez effectuée, et en particulier la série d'articles sur les mots de passe que vous avez écrits, (« Les grands débats : Codes contre mots de passe », parties 1, 2 et 3, aux adresses go.microsoft.com/fwlink/?LinkId=113157 ; go.microsoft.com/fwlink/?LinkId=113159 et go.microsoft.com/fwlink/?LinkId=113160), de nombreux administrateurs système n'ont pas une compréhension à jour de ce que constitue un mot de passe fort.

Il n'y a pas si longtemps que les mots de passe composés de huit caractères aléatoires tirés de jeux de caractères multiples étaient forts. La loi de Moore a rendu ceci obsolète. La formation des utilisateurs (et des administrateurs système) est un maillon faible et le demeurera probablement, tout du moins jusqu'à ce que le débat des mots de passe devienne un sujet si important que les journaux télévisés commencent à en parler.

Par conséquent, étant donné que la déduction d'un mot de passe du monde réel ne nécessite pas aujourd'hui 600 milliards d'années mais peut souvent s'effectuer dans le temps nécessaire à un repas, ajoutez-y un facteur multiplicateur égal à 1 000 et vous obtiendrez la véritable valeur. Contre les nombreuses attaques automatisées qui essaient de marteler le compte nommé Administrateur, renommer le compte le rend invulnérable.

Le temps et l'effort qu'implique généralement le fait de renommer le compte administratif sont habituellement peu importants. De manière générale, comme vous l'avez remarqué, ils se réduisent à définir un simple paramètre de GPO. La recommandation de configuration d'ordinateur du bureau gouvernemental des États-Unis (csrc.nist.gov/fdcc), exige en fait de renommer le compte -500. Renommer ce compte n'est qu'un des nombreux paramètres requis et je ne l'ai jamais vu nécessiter une quantité démesurée de temps ou d'attention. Je n'ai jamais non plus vu qui que ce soit conforté dans une fausse impression de sécurité quant à sa valeur. Je n'ai encore jamais entendu qui que ce soit déclarer « Nous n'avons pas besoin de gestion des correctifs car nous avons renommé nos comptes Administrateur ».

Le changement de nom offre-t-il une valeur ajoutée quelconque lorsque le compte est renommé de manière équivalente dans toute l'entreprise ? Ce n'est pas une valeur ajoutée énorme, mais elle est toujours positive : premièrement, il bloque les attaques automatisées qui s'attendent à Administrateur, et deuxièmement, l'ensemble d'attaquants potentiels n'est pas nécessairement un sous-ensemble du « tout le monde » qui connaît le nouveau nom (le plus grand risque est celui lié au partage dans toute une entreprise du mot de passe par les comptes Administrateur local. L'administration de ceux-ci demeure le problème le plus conséquent et le plus important. Désactiver le compte -500 est une méthode permettant d'y répondre, mais ceci bloque une voie de récupération importante lorsque les comptes de domaine ne peuvent pas être utilisés). Je ferai également remarquer que nos guides sur la sécurité ont depuis longtemps recommandé de renommer les comptes par défaut et cette pratique a par conséquent été bien testée et est entièrement prise en charge.

Je pense que nous savons tous à présent que ces mesures d'obscurité (en soi) ne constituent pas une défense suffisante. Mais elles peuvent améliorer d'autres mesures de sécurité et les données de Roger le montrent tout à fait clairement. Du moment que les coûts de mise en œuvre sont bas, les entreprises ne devraient pas les négliger.

Comme pour les arguments en leur faveur, il existe des arguments valides à l'encontre du changement de nom du compte Administrateur. Avant d'y venir, cependant, je dois admettre que le dernier point soulevé par Roger est tout à fait valable. Cependant, dans un environnement extrêmement géré, n'importe quelle ouverture de session avec le compte Administrateur devrait être examinée car ce compte ne devrait jamais être utilisé sauf dans les situations de récupération d'urgence.

C'est superflu Le risque principal qu'est supposé atténuer le changement de nom du compte administrateur est le risque que quelqu'un devine son mot de passe à distance. Mais seul un utilisateur ne possédant pas d'autre compte autorisé sur l'ordinateur serait contrecarré par le changement de nom du compte Administrateur. Un tel attaquant essaierait généralement une série de mots de passe aléatoires pour ouvrir une session avec le compte Administrateur. Cependant, un tel attaquant recevrait le même message d'erreur, que le nom de compte qu'il essaie de deviner soit incorrect ou que le mot de passe soit incorrect.

Cela suggère qu'un des arguments principaux en faveur du changement de nom du compte administrateur (tenir à l'écart les scripteurs amateurs) ne tient pas debout. Ceux-ci ne sont pas plus tenus à l'écart lorsque le compte Administrateur est renommé que lorsqu'il a son nom d'origine car ils sont incapables de faire la différence ! Ils devineront le même ensemble de mots de passe aléatoires quoi qu'il en soit et passeront à leur victime potentielle suivante.

Ceci signifie que tant que le mot de passe du compte Administrateur est assez robuste pour repousser des attaques, renommer le compte n'offre aucun avantage supplémentaire. Imaginons que nous avons un mot de passe de 15 caractères pour notre compte Administrateur, composé de lettres majuscules et minuscules, de chiffres et de symboles choisis depuis l'ensemble du clavier. Deviner ce mot de passe sur le réseau prendra environ 591 310 404 907 années. Pour vous donner une idée, c'est approximativement 43 fois plus longtemps que l'existence de l'univers.

Imaginons maintenant que nous renommons le compte Administrateur et lui donnons une valeur parmi 1 000 valeurs possibles. Nous étendrions le temps nécessaire pour deviner le mot de passe à 591 310 404 906 787 années ou 43 161 fois plus longtemps que l'existence de l'univers. Sommes-nous plus sécurisés ? Bien entendu, nous le sommes, d'un ordre de grandeur trois fois supérieur. Avons-nous fait en sorte qu'il soit moins probable que l'utilisateur devine notre mot de passe ? Eh bien, cette probabilité est infiniment réduite dans les deux cas. En d'autres termes, en termes réalistes, nous sommes absolument dans la même situation qu'avec le nom de compte Administrateur d'origine. Renommer simplement le compte arrête les logiciels malveillants qui tentent de l'utiliser et ne signifie pas que ces logiciels malveillants auraient réussi si vous n'aviez pas renommé le compte. En fait, si vous utilisez un mot de passe fort, comme vous devriez le faire, vous pouvez pratiquement garantir qu'ils ne réussissent pas, quel que soit le nom du compte.

Il est évident que de nombreuses recommandations de sécurité exigent de renommer le compte Administrateur, mais cela n'en fait pas une mesure de sécurité de valeur et encore moins valide. Elles suppriment simplement votre capacité à prendre une décision de gestion des risques appropriée le concernant. Les guides sur la sécurité ont souvent exigé l'utilisation de paramètres n'offrant aucune différence et dans beaucoup de cas, de paramètres qui n'existent même pas. En fin de compte, pour progresser dans le domaine de la sécurité, nous devons aller au-delà des exigences, analyser véritablement les problèmes et évaluer si les atténuations ont un sens ou non. Il est important de se souvenir ici d'un point essentiel : le fait qu'un attaquant cible une fonctionnalité n'est, en soi, pas une raison suffisante pour modifier cette fonctionnalité. Vous devriez uniquement modifier une fonctionnalité si vous avez des raisons valables de croire qu'une attaque réussira à moins que vous ne modifiiez la fonctionnalité.

Si nous utilisons un mot de passe fort, la probabilité de succès est en pratique nulle, que le compte soit renommé ou non. Par conséquent, tant que vous disposez d'un mot de passe fort, vous n'avez pas de raison de sécurité particulière de renommer le compte. De plus, si, comme moi, vous partez du principe qu'un ordinateur sera probablement plus stable si vous lui apportez peu de réglages et de modifications (un fait bien confirmé, par ailleurs), il est d'autant plus justifié de ne pas renommer le compte Administrateur.

L'attention est déplacée sur des atténuations de faible valeur Un problème avec la sécurité à faible valeur ajoutée offerte par les atténuations d'obscurité est qu'elle risque de déplacer l'attention de l'organisation des atténuations de grande valeur ajoutée. Par exemple, le temps et les efforts mis en œuvre pour renommer le compte Administrateur ne peuvent pas être utilisés pour quelque chose d'autre. Si ce quelque chose d'autre offre une valeur ajoutée plus élevée que le changement de nom des comptes Administrateur, l'entreprise a perdu une opportunité. Ceci peut ne pas sembler un coût important, mais imaginez renommer 50 000 comptes administrateur et vous commencerez à avoir une idée.

Ce qui est pire est qu'il est très vraisemblable que la direction de l'organisation sera satisfaite une fois l'atténuation de basse valeur mise en place. L'administration de l'entreprise peut ne pas toujours comprendre la valeur minimale fournie par la sécurité par atténuations d'obscurité et ne pas mettre en œuvre des étapes supplémentaires. Ceci peut en fait poser un risque significatif pour l'organisation, bien que le risque soit tout à fait évitable si l'administration consacre simplement du temps et des efforts à la compréhension de la valeur des atténuations en cours de mise en œuvre.

Coûteuse à gérer Enfin, en fonction de la qualité de la mise en œuvre de l'atténuation, elle peut devenir coûteuse à gérer. Si vous définissez simplement un objet de Stratégie de groupe (GPO) pour renommer le compte Administrateur, le coût est très faible. Tout le monde connaîtra le nom et le coût de déploiement est presque nul. Cependant, la valeur fournie est également tout à fait minimale car, comme je l'ai dit, toute personne possédant un compte connaîtra le nom. Par conséquent, pour véritablement tirer une valeur importante de cette atténuation, vous devez utiliser des noms différents sur les différents hôtes et cela devient un système assez coûteux à gérer.

Il serait vraiment préférable d'utiliser un outil tel que passgen (protectyourwindowsnetwork.com/tools.htm) pour définir un mot de passe complètement aléatoire de 100 caractères sur tous les comptes Administrateur du réseau et utiliser à la place des comptes différents pour la gestion de tous les jours. En prenant en compte le fait que le compte Administrateur a vraiment pour objectif la récupération après incident (sauf sur Windows Small Business Server 2003), ceci ne doit pas avoir du tout d'impact sur votre système de gestion de réseau. Qui plus est, l'attaquant aurait une plus grande chance de trouver une aiguille dans une botte de foin que de deviner le mot de passe sur n'importe lequel de vos comptes Administrateur. En vous concentrant à la place sur des mots de passe forts et uniques, les scripteurs amateurs peuvent simplement continuer à essayer de deviner ce qu'ils veulent.

Tout est une affaire de gestion des risques

Pratiquement toute sécurité par mesure d'obscurité peut être analysée de la façon dont nous l'avons fait ici. Chaque approche a des avantages et des inconvénients et la bonne approche pour une organisation n'est pas nécessairement adaptée à une organisation différente. En fin de compte, ceci devient un problème de gestion des risques. Les risques sont-ils plus importants que les coûts d'implémentation de la solution ? Chaque décision que vous prenez pour la protection de vos informations doit être une décision de gestion des risques informée et est rarement un choix noir ou blanc.

Il est vrai que certaines décisions ont déjà été prises pour vous. Par exemple, même si vous pouvez très certainement choisir de ne pas chiffrer les informations de carte de crédit ou d'enregistrer les codes de vérification de carte de crédit, chacune de ces actions aura probablement pour résultat une perte de votre capacité à accepter des cartes de crédit comme forme de paiement. L'impact négatif probable de cette décision pour votre entreprise est tel que vous n'avez pas vraiment de choix. En d'autres termes, bien que ceci soit certainement une décision de gestion des risques, c'est une décision qui n'est pas facile à prendre.

De même, il est également vrai que personne de sensé ne connecterait un réseau sans fil ouvert à l'arrière du réseau local d'un magasin physique. Cependant, cela ne signifie pas que la décision ne soit pas une décision de gestion des risques. C'en est une. Il est possible de choisir de le faire et, si ce choix est effectué, les conséquences doivent en être assumées (ce qui ne semble jamais se produire, malheureusement).

La mesure essentielle à prendre ici est de clairement définir le problème auquel vous devez répondre, les solutions proposées pour ce problème et les avantages et inconvénients de chacune. Une fois que vous avez cela, vous avez les informations dont vous avez besoin pour prendre une décision informée de gestion des risques. Sans ces informations, vous prenez des décisions fondées sur un pressentiment et ce sont rarement de bonnes décisions.

Jesper M. Johansson est architecte de logiciels chargé des logiciels de sécurité et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, MCSE sécurité), consultant senior en sécurité pour l'équipe ACE de Microsoft, a écrit ou contribué à huit livres sur la sécurité informatique et à plus de 200 articles de magazines. Il intervient régulièrement lors de conférences sur la sécurité et est chroniqueur de sécurité d'InfoWorld.

© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..