Faut-il vraiment bannir l'obscurité?

Utilisation de protocoles “maison”, fonctions non documentées, menus cachés : nombreux sont les exemples de conceptions ayant pour objectif de décourager les attaquants, et qui font bondir notre profession. Et ériger en principe fondamental que la sécurité par l’obscurité n’est pas de la sécurité.

Mais à l’heure où on marque un intérêt croissant pour les leurres et la tromperie (“deception” en bon français), et où la menace est pour la majorité des cibles rarement personnalisée (les acteurs visant en priorité des technologies standards et configurations par défaut), on pourrait être tenté de mettre un grain de sel personnel dans son SI, en complément de mesures de réduction de risques plus classiques :

• pour ne pas être le plus exposé face à des menaces trop génériques (on scanne rarement tous les ports d’Internet pour toutes les vulnérabilités récentes),
• pour ralentir et décourager l’attaquant, qui va devoir comprendre pourquoi ses outils ne donnent pas les résultats attendus ou devoir passer plus de temps dans sa phase de découverte,
• pour détecter plus facilement, puisque des comportements standards deviendront des exceptions.

Quelques idées d’obscurcissements déja observés, pour inspiration :

• le classique port non standard, aucune raison que ssh ne soit pas sur TCP/4422,
• la nomenclature inversée pour les comptes ou noms de machine (les admins du domaine qui s’appellent DEVquelquechose),
• le changement de nom des comptes par défaut (recommandation qu’on retrouve souvent dans les guides de durcissement),
• l’installation sur un autre volume que C: (il faut être très joueur car ce n’est plus vraiment supporté),
• les faux numéros de version dans des bannières ou pages d’erreur,
• la page captive sur le proxy web qui demande juste un OK à l’utilisateur d’un domaine jamais vu mais va bloquer tous les premier stages de malware (risque de bloquer aussi des iframes ou imports légitimes au passage).

Évidemment, le principal inconvenient à anticiper sera une maintenance plus complexe, puisque tous les intervenants informatiques devront connaitre ces écarts aux habitudes, et que même certains outils au service de la sécurité (scanners de vulnérabilités par exemple) seront à adapter. A manier avec précautions ou sur des périmètres déja bien maîtrisés.