Dans la sécurité de l'information et des TI, il existe une tendance désagréable à ce que les "meilleures pratiques" spécifiques deviennent des règles d'or inviolables, ce qui conduit les gens à recommander leur application, qu'elles soient appropriées à une situation donnée (semblable à Cargo Programmation culte )
Un bon exemple de ceci est l'approche commune aux politiques de mot de passe qui applique une exigence de taille unique de 8 caractères combinée à des exigences de complexité élevée, 12 mots de passe précédents stockés dans un historique pour arrêter la réutilisation, 3 tentatives de verrouillage incorrectes et 30 rotation de jour.
La rotation de 30 jours est destinée à réduire la fenêtre d'opportunité pour un attaquant d'utiliser un mot de passe volé, mais il est probable que les utilisateurs utilisent des mots de passe de séquence, ce qui signifie que si un attaquant peut pirater une instance, il peut facilement en résoudre d'autres, inversant en fait l'avantage de sécurité prévu.
Les exigences de longueur et de complexité élevées sont destinées à arrêter les attaques par force brute. Les attaques par force brute en ligne sont mieux atténuées avec une combinaison de politiques de verrouillage sensées et de détection d'intrusion, la force brute hors ligne se produit généralement lorsqu'un attaquant a compromis la base de données contenant les mots de passe et est mieux atténuée en utilisant un bon mécanisme de stockage (par exemple bcyprt, PBKDF2 ), un effet secondaire non voulu est également que les utilisateurs trouvent un modèle qui fonctionne et augmente également le risque que les utilisateurs écrivent le mot de passe.
La 3 politique de verrouillage incorrecte est destinée à arrêter les attaques par force brute en ligne, mais le définir trop bas augmente le verrouillage des comptes et surcharge les helpdesks et pose également un risque de déni de service (de nombreux systèmes en ligne ont facilement deviné les structures de nom d'utilisateur comme firstname.lastname, donc il est facile de verrouiller les utilisateurs)
Quels sont les autres exemples de sécurité Cargo-Cult qui sont généralement appliqués de manière inappropriée?
La source fermée est plus sécurisée que l'open-source car les attaquants peuvent afficher le code source et trouver et exploiter les vulnérabilités. Bien que je ne prétende pas que c'est toujours faux , avec un logiciel open source, il est au moins possible pour des experts externes d'examiner le logiciel à la recherche de vulnérabilités/backdoors béantes, puis de les corriger publiquement. Avec un logiciel à source fermée, ce n'est tout simplement pas possible sans démonter soigneusement le binaire. Et bien que vous et la plupart des attaquants n'ayez pas accès au code source, il existe probablement de puissants attaquants (par exemple, le gouvernement américain) qui peuvent être en mesure d'obtenir le code source ou d'y injecter des vulnérabilités secrètes.
L'envoi de données sur un réseau est secret si vous cryptez les données . Le chiffrement doit être authentifié pour empêcher un attaquant de modifier vos données. Vous devez vérifier l'identité de l'autre partie à laquelle vous envoyez des informations, sinon un homme du milieu peut intercepter et modifier votre trafic. Même avec l'authentification et l'identification, le cryptage laisse souvent fuir des informations. Vous parlez à un serveur via HTTPS? Les écoutes clandestines du réseau (n'importe qui chez votre FAI) savent exactement combien de trafic vous avez envoyé, à quelle adresse IP et quelle est la taille de chacune des réponses (par exemple, vous pouvez prendre les empreintes digitales de diverses pages Web en fonction de la taille de toutes les ressources transférées). De plus, en particulier avec les sites Web AJAX, les informations que vous saisissez entraînent souvent une réponse du serveur qui est identifiable par ses modèles de trafic. Voir Fuites de canal latéral dans les applications Web .
Questions de réinitialisation de mot de passe faible - Comment le courrier électronique de Sarah Palin a été piraté ? Une personne a suivi la procédure de réinitialisation du mot de passe et a pu répondre correctement à chaque question à partir d'informations accessibles au public. Quelles questions de réinitialisation de mot de passe une connaissance de Facebook pourrait-elle comprendre?
Le système X est incassable - il utilise un cryptage AES 256 bits et mettrait probablement un milliard d'ordinateurs ordinaires un million de milliards de milliards de milliards de milliards d'années à se fissurer. Oui, il ne peut pas être forcé brutalement car cela nécessiterait ~ 2256 opérations. Mais le mot de passe pourrait être réutilisé ou dans un dictionnaire de mots de passe courants. Ou vous avez bloqué un enregistreur de frappe sur l'ordinateur. Ou vous menacé quelqu'un avec une clé de 5 $ et ils vous ont dit le mot de passe . Il existe des attaques par canal latéral. Peut-être que le générateur de nombres aléatoires était défectueux . Des attaques temporelles existent. Il existe des attaques d'ingénierie sociale. Ce sont généralement les maillons les plus faibles.
Cette pratique faible est assez bonne pour nous, nous n'avons pas le temps d'attendre pour faire les choses en toute sécurité . Le gouvernement américain n'a pas à se soucier de cryptage des flux vidéo de leurs drones - qui saura écouter les bonnes fréquences porteuses; en plus des boîtes de cryptage seront lourdes et coûteuses - pourquoi s'embêter?
Les ordinateurs quantiques peuvent résoudre rapidement les problèmes de temps exponentiel et briseront toutes les méthodes de cryptage . Les gens lisent des articles scientifiques populaires sur les ordinateurs quantiques et entendent que ce sont ces entités mystiques super-puissantes qui exploiteront la puissance de calcul d'un nombre presque infini d'univers parallèles pour faire n'importe quoi. Ce n'est que partiellement vrai. Les ordinateurs quantiques permettront la factorisation et les logarithmes discrets en temps polynomial O (n3) via l'algorithme de Shor rendant RSA, DSA et le chiffrement basé sur ces fonctions de trappe facilement cassables. De même, les ordinateurs quantiques peuvent utiliser l'algorithme de Grover pour forcer brutalement un mot de passe qui devrait prendre O (2N) temps en O uniquement (2N/2) temps; réduire efficacement de moitié la sécurité d'une clé symétrique - L'algorithme de Granted Grover est connu pour être asymptotiquement optimal pour les ordinateurs quantiques, alors ne vous attendez pas à de nouvelles améliorations.
Quelques exemples:
De plus grandes touches. RSA 4096 bits, AES 256 bits ... plus de bits sont toujours meilleurs. (Voir les commentaires: il est inutile d'avoir des clés plus grandes que la taille qui garantit le statut "ne peut pas du tout le casser"; mais des clés plus grandes impliquent une surcharge réseau et CPU, parfois en grande quantité.)
Application automatique de "fonctions sûres" comme snprintf()
au lieu de sprintf()
(cela ne fera pas grand-chose à moins que le programmeur ne teste la possible troncature, et cela n'empêchera pas d'utiliser un utilisateur -chaîne fournie comme chaîne de format). Points supplémentaires pour strncpy()
qui ne fait pas ce que la plupart des gens semblent supposer (en particulier, il n'assure pas un '\0'
Final).
"Pureté du Security Manager". En application de la séparation des fonctions et des rôles, toutes les décisions "liées à la sécurité" doivent être prises par un spécialiste de la sécurité, distinct des concepteurs et développeurs de projets. Souvent amené à l'extrême malavisé, où le gars qui décide quels ports réseau doivent être laissés ouverts sur un pare-feu n'a aucune connaissance du projet, et refuse délibérément d'apprendre quoi que ce soit à cet égard, car - décision indépendante est plus important que décision éclairée.
Je vais ajouter mes propres exemples appsec que j'ai vus en consultant:
sanitize()
sur tout ! ". Il n'y a aucun moyen de rendre une variable sûre pour chaque utilisation, vous devez utiliser la routine d'assainissement pour le travail.J'entends toujours celui de nombreux professionnels de la sécurité, une formation à la sécurité et des guides de sécurité actuels.
Utiliser SSL uniquement pour la page de connexion plutôt que pour toutes les zones authentifiées d'un site Web.
Un seul, mais c'est un gros problème: "La sécurité de l'information est un problème technologique, qui peut être résolu avec la technologie."
Afin d'empêcher les gens de savoir si certains utilisateurs existent dans le système - cacher si le mot de passe était incorrect ou si le nom d'utilisateur était invalide lors d'une tentative de connexion échouée, ... tout en offrant un formulaire de réinitialisation du mot de passe qui ne fuite de cette information.
"Notre site Web ne peut pas être piraté car nous utilisons SSL". Monsieur, cela le rend plus facile à exploiter s'il est vulnérable, car même votre IDS/IPS est rendu inutile par le flux SSL.