- N'implémentez jamais votre propre cryptographie.
- Utilisez toujours TLS.
- La sécurité par l'obscurité est mauvaise.
Etc. La plupart d'entre eux sont généralement corrects. Cependant, il me semble que les gens suivent aveuglément ces axiomes comme un culte de la cargaison. Et beaucoup ne pensent pas vraiment aux exceptions à la règle. Dans cet article, je soulèverai mes objections à l'idée que la sécurité par l'obscurité est mauvaise.
Risque, défense étagée et fromage suisse
L'une des principales tâches de la sécurité de l'information est de réduire les risques. Selon la méthodologie OWASP, le risque de problème est calculé à l'aide de la formule:
Risque = Probabilité * Impact
Par cette formule, le problème de l'exécution de code à distance (RCE) pose un plus grand risque que le problème des scripts intersites, car le RCE a un plus grand impact. Tout est simple ici. Mais qu'en est-il de la métrique de probabilité? Selon OWASP, la probabilité est définie comme suit:
Au plus haut niveau, il s'agit d'une estimation approximative des chances qu'une vulnérabilité particulière soit révélée et exploitée par un attaquant.
Ainsi, si nous réduisons la probabilité, nous réduisons le risque global. C'est bon. En fait, cela ressemble beaucoup au concept bien connu de «défense en profondeur». Il est également appelé le «modèle du fromage suisse».
Selon ce modèle, vous devez créer des mécanismes de défense dans un modèle en couches de manière à ce que même si un attaquant passe le premier niveau, il soit arrêté à d'autres.
La sécurité par l'obscurité
Parlons donc de la sécurité par l'obscurité. C'est une mauvaise idée de l'utiliser comme seule couche de protection. Si l'attaquant réussit, rien d'autre ne vous protégera. Mais en fait, ce n'est pas mal comme niveau "supplémentaire". Parce qu'il a un faible coût de mise en œuvre et fonctionne généralement bien.
Considérons plusieurs scénarios:
- Sur mon serveur, SSH fonctionne sur le port par défaut 22 et les informations d'identification
root:123456. Quelle est la probabilité de compromis?
La probabilité est de presque 100%, car les pirates informatiques partout sur Internet sont des services de force brute avec des informations d'identification standard.
- SSH s'exécute sur le port 22 et les informations d'identification
utku:123456. Quelle est la probabilité de compromis?
Eh bien, nous avons éliminé le danger de la force brute avec des informations d'identification standard. La probabilité et le risque sont réduits. Cependant, nous sommes toujours confrontés à une tonne d'attaques ciblées. Quelqu'un pourrait deviner le nom d'utilisateur utku puisque c'est mon vrai nom.
- SSH fonctionne sur le port 64323 et les informations d'identification
utku:123456. Quelle est la probabilité de compromis?
Nous avons changé le numéro de port par défaut. Cela aidera-t-il? Premièrement, nous avons à nouveau éliminé le danger de la force brute standard, car elle ne scanne que les ports communs. Qu'en est-il du reste? J'ai lancé un petit sondage sur mon twitter pour découvrir le comportement des gens lors de l'analyse des ports.
Comme vous pouvez le voir, beaucoup ont tendance à analyser uniquement les ports standard et les plus populaires. Ainsi, si vous changez le port de 22 à 64323, vous éliminerez certaines des attaques potentielles. Vous réduirez la probabilité et le risque.
Il en va de même pour les vulnérabilités logicielles. Si une vulnérabilité est détectée dans le protocole Microsoft Remote Desktop, tout Internet commencera à analyser le port 3389. Vous pouvez atténuer les risques en modifiant simplement le port par défaut.
Autres applications
Bien entendu, outre la modification des valeurs par défaut, vous pouvez utiliser la même méthodologie dans d'autres domaines. Dans certains cas (pas toujours), les idées suivantes peuvent être appliquées.
- Obscurcissement du code : bien sûr, c'est de notoriété publique. Les hackers sont aussi des personnes. Si vous obscurcissez bien votre code, ils devront passer plus de temps à rechercher les problèmes. Finalement, ils peuvent abandonner.
- Noms de variables aléatoires pour une application Web : vous pouvez utiliser des caractères aléatoires au lieu de noms de variables conviviaux. Cela peut aider de la même manière que l'obfuscation du code.
- :
encryption_algorithm(data, key). , —decryption_algorithm(data, key). , , , . - - , (, SQL-), .
La sécurité par l'obscurité est largement utilisée dans la sécurité physique / réelle. Par exemple, le président conduit du point A au point B avec un cortège de 30 voitures. Mais il ne s'assoit pas dans sa voiture présidentielle, de peur de devenir une cible facile. Il peut se trouver dans n'importe quelle machine du tuple, ce qui réduit le risque d'attaque.
Les animaux exploitent également la sécurité par l'obscurité - c'est le camouflage. La furtivité réduit la probabilité d'être tué. Par conséquent, au cours du processus d'évolution, ils ont acquis cette capacité.
Production
La sécurité par l'obscurité seule ne suffit pas. Les meilleures pratiques doivent toujours être appliquées. Mais si vous pouvez réduire votre risque à un coût nul, vous devriez le faire. L'obscurité est une bonne couche dans le système de sécurité global.