Notre auditeur de sécurité est un idiot. Comment puis-je lui fournir les informations dont il a besoin?
Un auditeur de sécurité pour nos serveurs a exigé ce qui suit en deux semaines:
- Une liste des noms d'utilisateur actuels et des mots de passe en texte brut pour tous les comptes d'utilisateurs sur tous les serveurs
- Une liste de tous les changements de mot de passe pour les six derniers mois, toujours en texte brut
- Une liste de "chaque fichier ajouté au serveur à partir d'appareils distants" au cours des six derniers mois
- Les clés publiques et privées de toutes les clés SSH
- Un e-mail qui lui est envoyé chaque fois qu'un utilisateur change de mot de passe, contenant le mot de passe en texte brut
Nous utilisons des boîtiers Red Hat Linux 5/6 et CentOS 5 avec authentification LDAP.
Pour autant que je sache, tout sur cette liste est impossible ou incroyablement difficile à obtenir, mais si je ne fournis pas ces informations, nous risquons de perdre l'accès à notre plateforme de paiement et de perdre des revenus pendant une période de transition alors que nous passons à un nouveau service. Des suggestions sur la façon dont je peux résoudre ou truquer ces informations?
La seule façon dont je peux penser pour obtenir tous les mots de passe en texte brut, est d'amener tout le monde à réinitialiser son mot de passe et à noter ce qu'il a défini. Cela ne résout pas le problème des six derniers mois de changements de mot de passe, car je ne peux pas enregistrer rétroactivement ce genre de choses, il en va de même pour la journalisation de tous les fichiers distants.
Obtenir toutes les clés SSH publiques et privées est possible (bien que gênant), car nous avons seulement quelques utilisateurs et ordinateurs. À moins que j'aie manqué un moyen plus facile de le faire?
Je lui ai expliqué à plusieurs reprises que les choses qu'il demandait étaient impossibles. En réponse à mes préoccupations, il a répondu par le courriel suivant:
J'ai plus de 10 ans d'expérience dans l'audit de sécurité et une compréhension complète des méthodes de sécurité redhat, je vous suggère donc de vérifier vos faits sur ce qui est et n'est pas possible. Vous dites qu'aucune entreprise ne pourrait possiblement avoir ces informations, mais j'ai effectué des centaines d'audits où ces informations étaient facilement disponibles. Tous les clients [fournisseur de traitement de cartes de crédit génériques] doivent se conformer à nos nouvelles politiques de sécurité et cet audit vise à s'assurer que ces politiques ont été mises en œuvre * correctement.
* Les "nouvelles politiques de sécurité" ont été introduites deux semaines avant notre audit, et la journalisation historique de six mois n'était pas requise avant les changements de politique.
Bref, j'ai besoin;
- Un moyen de "faux" six mois de modifications de mot de passe et de le rendre valide
- Un moyen de "faux" six mois de transferts de fichiers entrants
- Un moyen simple de collecter toutes les clés publiques et privées SSH utilisées
Si nous échouons à l'audit de sécurité, nous perdons l'accès à notre plate-forme de traitement des cartes (une partie critique de notre système) et il nous faudrait deux bonnes semaines pour déménager ailleurs. Comment suis-je foutu?
Mise à jour 1 (samedi 23)
Merci pour toutes vos réponses, cela me soulage beaucoup de savoir que ce n'est pas une pratique courante.
Je prépare actuellement ma réponse par e-mail lui expliquant la situation. Comme beaucoup d'entre vous l'ont souligné, nous devons nous conformer à la norme PCI qui stipule explicitement que nous ne devrions avoir aucun moyen d'accéder aux mots de passe en texte brut. Je posterai l'e-mail lorsque j'aurai fini de l'écrire. Malheureusement, je ne pense pas qu'il nous teste simplement; ces choses sont maintenant dans la politique de sécurité officielle de l'entreprise. J'ai cependant mis les roues en mouvement pour m'éloigner d'elles et sur Paypal pour le moment.
Mise à jour 2 (samedi 23)
Ceci est l'e-mail que j'ai rédigé, des suggestions de choses à ajouter/supprimer/modifier?
Bonjour [nom],
Malheureusement, il nous est impossible de vous fournir certaines des informations demandées, principalement les mots de passe en texte brut, l'historique des mots de passe, les clés SSH et les journaux de fichiers distants. Non seulement ces choses sont techniquement impossibles, mais également être en mesure de fournir ces informations serait à la fois contraire aux normes PCI et une violation de la loi sur la protection des données.
Pour citer les exigences PCI,8.4 Rendre tous les mots de passe illisibles pendant la transmission et le stockage sur tous les composants du système en utilisant une cryptographie robuste.
Je peux vous fournir une liste des noms d'utilisateur et des mots de passe hachés utilisés sur notre système, des copies des clés publiques SSH et du fichier des hôtes autorisés (cela vous donnera suffisamment d'informations pour déterminer le nombre d'utilisateurs uniques pouvant se connecter à nos serveurs et le chiffrement méthodes utilisées), des informations sur nos exigences de sécurité par mot de passe et notre serveur LDAP, mais ces informations ne peuvent pas être retirées du site. Je vous suggère fortement de revoir vos exigences d'audit car il n'y a actuellement aucun moyen pour nous de passer cet audit tout en restant en conformité avec PCI et la loi sur la protection des données.
Cordialement,
[moi]
Je serai CC'ing dans le CTO de l'entreprise et notre gestionnaire de compte, et j'espère que le CTO peut confirmer que cette information n'est pas disponible. Je vais également contacter le PCI Security Standards Council pour lui expliquer ce qu'il attend de nous.
Mise à jour 3 (26e)
Voici quelques courriels que nous avons échangés;
RE: mon premier e-mail;
Comme expliqué, ces informations devraient être facilement accessibles sur tout système bien entretenu à tout administrateur compétent. Votre incapacité à fournir ces informations me porte à croire que vous êtes au courant des failles de sécurité de votre système et que vous n'êtes pas prêt à les révéler. Nos demandes sont conformes aux directives PCI et les deux peuvent être satisfaites. Une cryptographie forte signifie uniquement que les mots de passe doivent être chiffrés pendant que l'utilisateur les saisit, mais ils doivent ensuite être déplacés vers un format récupérable pour une utilisation ultérieure.
Je ne vois aucun problème de protection des données pour ces demandes, la protection des données ne s'applique qu'aux consommateurs et non aux entreprises, il ne devrait donc pas y avoir de problème avec ces informations.
Mais quoi, je ne peux même pas ...
"Une cryptographie forte signifie uniquement que les mots de passe doivent être chiffrés pendant que l'utilisateur les saisit, mais ils doivent ensuite être déplacés vers un format récupérable pour une utilisation ultérieure."
Je vais encadrer cela et le mettre sur mon mur.
J'en ai eu marre d'être diplomate et je l'ai dirigé vers ce fil pour lui montrer la réponse que j'ai reçue:
La fourniture de ces informations contredit DIRECTEMENT plusieurs exigences des directives PCI. La section que j'ai citée dit même
storage(ce qui implique où nous stockons les données sur le disque). J'ai commencé une discussion sur ServerFault.com (une communauté en ligne pour les professionnels de l'administration système) qui a créé une énorme réponse, suggérant tous que cette information ne peut pas être fournie. N'hésitez pas à lire à travers vous-mêmehttps://serverfault.com/questions/293217/
Nous avons fini de déplacer notre système vers une nouvelle plate-forme et nous annulerons notre compte avec vous dans les prochains jours, mais je veux que vous vous rendiez compte à quel point ces demandes sont ridicules, et aucune entreprise mettant correctement en œuvre les directives PCI ne va, ou ne devrait, être en mesure de fournir ces informations. Je vous suggère fortement de repenser vos exigences de sécurité car aucun de vos clients ne devrait être en mesure de s'y conformer.
(J'avais en fait oublié que je l'avais traité d'idiot dans le titre, mais comme mentionné, nous nous étions déjà éloignés de leur plate-forme, donc aucune perte réelle.)
Et dans sa réponse, il déclare qu'apparemment aucun de vous ne sait de quoi vous parlez:
J'ai lu en détail ces réponses et votre message d'origine, les répondants ont tous besoin de bien comprendre leurs faits. Je travaille dans cette industrie depuis plus longtemps que quiconque sur ce site, obtenir une liste de mots de passe de compte d'utilisateur est incroyablement basique, cela devrait être l'une des premières choses que vous faites lorsque vous apprenez à sécuriser votre système et est essentiel au fonctionnement de tout système sécurisé. serveur. Si vous n'avez vraiment pas les compétences nécessaires pour faire quelque chose d'aussi simple, je vais supposer que vous n'avez pas installé PCI sur vos serveurs car pouvoir récupérer ces informations est une exigence de base du logiciel. Lorsque vous traitez de quelque chose comme la sécurité, vous ne devriez pas poser ces questions sur un forum public si vous n'avez aucune connaissance de base de son fonctionnement.
Je voudrais également suggérer que toute tentative de me révéler, ou [nom de l'entreprise] sera considérée comme une diffamation et qu'une action judiciaire appropriée sera engagée
Points clés idiots si vous les avez manqués:
- Il est auditeur de sécurité depuis plus longtemps que quiconque ici (il vous devine ou vous traque)
- La possibilité d'obtenir une liste de mots de passe sur un système UNIX est "basique"
- PCI est maintenant un logiciel
- Les gens ne devraient pas utiliser les forums lorsqu'ils ne sont pas sûrs de la sécurité
- La publication d'informations factuelles (auxquelles j'ai une preuve par e-mail) en ligne est diffamatoire
Excellent.
PCI SSC a répondu et enquête sur lui et l'entreprise. Notre logiciel est maintenant passé sur Paypal, nous savons donc qu'il est sûr. Je vais attendre que PCI me revienne en premier, mais je m'inquiète un peu qu'ils aient pu utiliser ces pratiques de sécurité en interne. Si c'est le cas, je pense que c'est une préoccupation majeure pour nous car tout notre traitement des cartes les a traversés. S'ils le faisaient en interne, je pense que la seule chose responsable à faire serait d'informer nos clients.
J'espère que lorsque PCI réalisera à quel point il est mauvais, ils enquêteront sur l'ensemble de l'entreprise et du système, mais je ne suis pas sûr.
Alors maintenant, nous nous sommes éloignés de leur plate-forme, et en supposant qu'il faudra au moins quelques jours avant que PCI me revienne, des suggestions inventives sur la façon de le troller un peu? =)
Une fois que j'aurai obtenu l'autorisation de mon avocat (je doute fortement que tout cela soit en fait de la diffamation, mais je voulais vérifier), je publierai le nom de l'entreprise, son nom et son e-mail, et si vous le souhaitez, vous pouvez le contacter et lui expliquer pourquoi vous ne comprenez pas les bases de la sécurité Linux, comme comment obtenir une liste de tous les mots de passe des utilisateurs LDAP.
Petite mise à jour:
Mon "gars légal" a suggéré que révéler que la société causerait probablement plus de problèmes que nécessaire. Je peux dire cependant que ce n'est pas un fournisseur majeur, ils ont moins de 100 clients utilisant ce service. Nous avons commencé à les utiliser lorsque le site était petit et fonctionnait sur un petit VPS, et nous ne voulions pas passer par tous les efforts pour obtenir PCI (nous avions l'habitude de rediriger vers leur frontend, comme Paypal Standard). Mais lorsque nous sommes passés au traitement direct des cartes (y compris le PCI et le bon sens), les développeurs ont décidé de continuer à utiliser la même société avec une API différente. La société est basée à Birmingham, au Royaume-Uni, donc je doute fortement que quiconque ici soit touché.
D'abord, ne capitulez pas. Il est non seulement un idiot mais DANGEREUSEMENT faux. En fait, la divulgation de ces informations serait violer la norme PCI (ce à quoi je suppose que l'audit est destiné car c'est un processeur de paiement) ainsi que toutes les autres normes et tout simplement du bon sens. Cela exposerait également votre entreprise à toutes sortes de responsabilités.
La prochaine chose que je ferais est d'envoyer un e-mail à votre patron lui disant qu'il doit impliquer un conseiller juridique pour déterminer le risque juridique auquel l'entreprise serait confrontée en poursuivant cette action.
Ce dernier point dépend de vous, mais I contacterait VISA avec ces informations et obtiendrait son statut d'auditeur PCI.
En tant que personne qui a suivi la procédure d'audit avec Price Waterhouse Coopers pour un contrat gouvernemental classifié, je peux vous assurer que c'est totalement hors de question et que ce type est fou.
Lorsque PwC a voulu vérifier la solidité de nos mots de passe, ils:
- Demandé de voir nos algorithmes de force de mot de passe
- Exécuter des unités de test par rapport à nos algorithmes pour vérifier qu'ils refuseraient les mauvais mots de passe
- On nous a demandé de voir nos algorithmes de chiffrement pour s'assurer qu'ils ne pouvaient pas être inversés ou non chiffrés (même par les tables Rainbow), même par quelqu'un qui avait un accès complet à tous les aspects du système
- Vérifié pour voir que les mots de passe précédents ont été mis en cache pour garantir qu'ils ne pouvaient pas être réutilisés
- Nous a demandé la permission (que nous avons accordée) pour qu'ils tentent de pénétrer dans le réseau et les systèmes connexes en utilisant des techniques d'ingénierie non sociales (des choses comme xss et des exploits non-0 jours)
Si j'avais même laissé entendre que je pouvais leur montrer quels étaient les mots de passe des utilisateurs au cours des 6 derniers mois, ils nous auraient immédiatement exclus du contrat.
S'il était possible de fournir ces exigences, vous échoueriez instantanément chaque audit unique qui mérite d’être effectué.
Mise à jour: votre e-mail de réponse semble bon. Beaucoup plus professionnel que tout ce que j'aurais écrit.
Honnêtement, il semble que ce type (l'auditeur) vous prépare. Si vous lui donnez les informations qu'il demande, vous venez de lui prouver que vous pouvez être conçu socialement pour abandonner des informations internes critiques. Échouer.
Je viens de repérer que vous êtes au Royaume-Uni, ce qui signifie que ce qu'il vous demande de faire est d'enfreindre la loi (le Data Protection Act en fait). Je suis également au Royaume-Uni, je travaille pour une grande entreprise fortement auditée et je connais le droit et les pratiques courantes dans ce domaine. Je suis aussi un travail très méchant qui sera ravi de tamponner ce gars pour vous si vous le souhaitez juste pour le plaisir, faites-moi savoir si vous souhaitez aider ok.
Vous êtes conçu socialement. Soit pour vous "tester", soit pour un pirate se faisant passer pour un auditeur pour obtenir des données très utiles.
Je suis sérieusement préoccupé par le manque de compétences de résolution des problèmes éthiques des PO et la communauté des fautes de serveur ignorant cette violation flagrante de la conduite éthique.
Bref, j'ai besoin;
- Un moyen de "faux" six mois de modifications de mot de passe et de le rendre valide
- Une façon de "faux" six mois de transferts de fichiers entrants
Permettez-moi d'être clair sur deux points:
- Il n'est jamais approprié de falsifier des données au cours d'une activité normale.
- Vous ne devez jamais divulguer ce type d'informations à qui que ce soit. Jamais.
Ce n'est pas à vous de falsifier des enregistrements. Il est de votre devoir de vous assurer que tous les enregistrements nécessaires sont disponibles, précis et sécurisés.
La communauté ici à Server Fault must traite ces types de questions comme le site stackoverflow traite les questions de "devoirs". Vous ne pouvez pas résoudre ces problèmes avec seulement une réponse technique ou ignorer la violation de la responsabilité éthique.
Voir autant d'utilisateurs de haut niveau répond ici dans ce fil et aucune mention des implications éthiques de la question ne m'attriste.
J'encourage tout le monde à lire le Code d'éthique des administrateurs système SAGE .
BTW, votre auditeur de sécurité est un idiot, mais cela ne signifie pas que vous devez ressentir une pression pour être contraire à l'éthique dans votre travail.
Edit: Vos mises à jour sont inestimables. Gardez la tête baissée, votre poudre sèche et ne prenez pas (ni ne donnez) de nickels en bois.
Vous ne pouvez pas lui donner ce que vous voulez, et les tentatives de "faux" sont susceptibles de revenir pour vous mordre le cul (éventuellement de manière légale). Vous devez soit faire appel à la chaîne de commandement (il est possible que cet auditeur soit devenu un voyou, bien que les audits de sécurité soient notoirement idiots - demandez-moi à propos de l'auditeur qui voulait être en mesure d'accéder à un AS/400 via SMB), ou obtenez l'enfer hors de dessous ces exigences onorous.
Ils ne sont même pas une bonne sécurité - une liste de tous les mots de passe en clair est une chose incroyablement dangereuse à jamais produire, quelles que soient les méthodes utilisées pour les protéger, et je ' Je parie que ce type voudra qu'ils soient envoyés par e-mail en clair. (Je suis sûr que vous le savez déjà, je dois juste évacuer un peu).
Pour les merdes et les rires, demandez-lui directement comment exécuter ses exigences - admettez que vous ne savez pas comment, et que vous souhaitez tirer parti de son expérience. Une fois que vous êtes sorti et parti, une réponse à son "J'ai plus de 10 ans d'expérience en audit de sécurité" serait "non, vous avez 5 minutes d'expérience répétées des centaines de fois".
Aucun vérificateur ne devrait vous échouer s'il trouve un problème historique que vous avez résolu. En fait, c'est la preuve d'un bon comportement. Dans cet esprit, je suggère deux choses:
a) Ne mentez pas et n'inventez rien. b) Lisez vos politiques.
La déclaration clé pour moi est celle-ci:
Tous les clients [fournisseur de traitement de cartes de crédit génériques] doivent se conformer à nos nouvelles politiques de sécurité
Je parie qu'il y a une déclaration dans ces politiques disant que les mots de passe ne peuvent pas être écrits et ne peuvent être transmis à personne d'autre que l'utilisateur. Si tel est le cas, appliquez ces politiques à ses demandes. Je suggère de le manipuler comme ceci:
- Une liste des noms d'utilisateur actuels et des mots de passe en texte brut pour tous les comptes d'utilisateurs sur tous les serveurs
Montrez-lui une liste de noms d'utilisateurs, mais ne permettez pas qu'ils soient supprimés. Expliquez que donner des mots de passe en texte brut est a) impossible car c'est unidirectionnel, et b) contre la politique, contre laquelle il vous audite, donc vous n'obéirez pas.
- Une liste de tous les changements de mot de passe pour les six derniers mois, toujours en texte brut
Expliquez que ce n'était pas disponible historiquement. Donnez-lui une liste des derniers changements de mot de passe pour montrer que cela est en cours. Expliquez, comme ci-dessus, que les mots de passe ne seront pas fournis.
- Une liste de "chaque fichier ajouté au serveur à partir d'appareils distants" au cours des six derniers mois
Expliquez ce qui est et ce qui n'est pas enregistré. Donnez ce que vous pouvez. Ne fournissez rien de confidentiel et expliquez pourquoi par politique. Demandez si votre journalisation doit être améliorée.
- Les clés publiques et privées de toutes les clés SSH
Regardez votre politique de gestion des clés. Il doit indiquer que les clés privées ne sont pas autorisées à sortir de leur conteneur et ont des conditions d'accès strictes. Appliquez cette stratégie et n'autorisez pas l'accès. Les clés publiques sont heureusement publiques et peuvent être partagées.
- Un e-mail qui lui est envoyé chaque fois qu'un utilisateur change de mot de passe, contenant le mot de passe en texte brut
Dis juste non. Si vous disposez d'un serveur de journaux local sécurisé, laissez-le voir qu'il est enregistré sur place.
Fondamentalement, et je suis désolé de le dire, mais vous devez jouer au hardball avec ce gars. Suivez votre politique exactement, ne déviez pas. Ne mens pas. Et s'il vous échoue pour tout ce qui n'est pas dans la politique, se plaindre à ses aînés de l'entreprise qui l'a envoyé. Recueillez une trace papier de tout cela pour prouver que vous avez été raisonnable. Si vous ne respectez pas votre politique, vous êtes à sa merci. Si vous les suivez à la lettre, il finira par être limogé.
Oui, l'auditeur est un idiot. Cependant, comme vous le savez, des idiots sont parfois placés en position de pouvoir. C'est l'un de ces cas.
Les informations qu'il a demandées ont zéro portant sur la sécurité actuelle du système. Expliquez à l'auditeur que vous utilisez LDAP pour l'authentification et que les mots de passe sont stockés à l'aide d'un hachage unidirectionnel. À moins de faire un script de force brute contre les hachages de mot de passe (ce qui pourrait prendre des semaines (ou des années), vous ne pourrez pas fournir les mots de passe.
De même, les fichiers distants - j'aimerais entendre, peut-être, comment il pense que vous devriez pouvoir faire la différence entre les fichiers créés directement sur le serveur et un fichier qui est SCPé sur le serveur.
Comme l'a dit @womble, ne simulez rien. Cela ne servira à rien. Soit abandonner cet audit et infliger une amende à un autre courtier, soit trouver un moyen de convaincre ce "professionnel" que son fromage a glissé de son cracker.
Demandez à votre "auditeur de sécurité" de pointer vers n'importe quel texte de l'un quelconque de ces documents qui a ses exigences et observez-le alors qu'il s'efforce de trouver une excuse et finit par s'excuser de ne plus jamais être entendu.
WTF! Désolé mais c'est ma seule réaction à cela. Je n'ai jamais entendu parler d'exigences d'audit nécessitant un mot de passe en clair, sans parler de leur fournir les mots de passe à mesure qu'ils changent.
Tout d'abord, demandez-lui de vous montrer l'exigence que vous fournissez cela.
Ensuite, si c'est pour PCI (que nous supposons tous car c'est une question de système de paiement), allez ici: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php et obtenez un nouvel auditeur.
3ème, suivez ce qu'ils ont dit ci-dessus, contactez votre direction et demandez-lui de contacter la société QSA avec laquelle il travaille. Obtenez immédiatement un autre auditeur.
Les auditeurs auditent les états, les normes, les processus, etc. du système. Ils n'ont pas besoin de disposer d'informations leur permettant d'accéder aux systèmes.
Si vous souhaitez des auditeurs recommandés ou des colo alternatifs qui travaillent en étroite collaboration avec les auditeurs, contactez-moi et je serais heureux de fournir des références.
Bonne chance! Faites confiance à votre instinct, si quelque chose semble mal, il l'est probablement.
Il n'y a aucune raison légitime pour lui de connaître le mot de passe et d'avoir accès aux clés privées. Ce qu'il a demandé lui donnerait la possibilité de se faire passer pour n'importe lequel de vos clients à tout moment et de siphonner autant d'argent qu'il le souhaite, sans aucun moyen de le détecter comme une transaction frauduleuse possible. Ce sera exactement le type de menaces de sécurité pour lesquelles il est censé vous auditer.
Avertissez la direction que l'auditeur a demandé que vous violiez vos politiques de sécurité et que la demande est illégale. Suggérez-leur de vider le cabinet d'audit actuel et d'en trouver un légitime. Appelez la police et rendez l'auditeur pour demander des informations illégales (au Royaume-Uni). Appelez ensuite le PCI et rendez l'auditeur pour sa demande.
La demande revient à vous demander d'aller tuer quelqu'un au hasard et de lui remettre le corps. Le feriez-vous? ou appeleriez-vous les flics et les remettez?
Répondez avec un procès. Si un auditeur demande des mots de passe en texte brut (allez maintenant, ce n'est pas si difficile de forcer brutalement ou de casser des hachages de mot de passe faibles), il vous a probablement menti au sujet de leurs informations d'identification.
Juste un conseil sur la façon dont vous rédigez votre réponse:
Malheureusement, il nous est impossible de vous fournir certaines des informations demandées, principalement les mots de passe en texte brut, l'historique des mots de passe, les clés SSH et les journaux de fichiers distants. Non seulement ces choses sont techniquement impossibles ...
Je reformulerais ceci pour éviter d'entrer dans une discussion sur la faisabilité technique. En lisant le terrible e-mail initial envoyé par l'auditeur, on dirait que c'est quelqu'un qui peut choisir des détails qui ne sont pas liés au problème principal, et il pourrait affirmer que vous pourriez enregistrer les mots de passe, les connexions, etc. Donc, dites soit:
... En raison de nos politiques de sécurité strictes, nous n'avons jamais enregistré les mots de passe en texte brut. Il sera donc techniquement impossible de fournir ces données.
Ou
... Non seulement nous réduirions considérablement notre niveau de sécurité interne en nous conformant à votre demande, ...
Bonne chance et tenez-nous au courant de comment cela se termine!
Au risque de continuer la ruée des utilisateurs de haut niveau sur cette question, voici mes réflexions.
Je peux en quelque sorte voir vaguement pourquoi il veut les mots de passe en clair, et c'est pour juger de la qualité des mots de passe utilisés. C'est une façon merdique de s'y prendre, la plupart des auditeurs que je connais accepteront les hachages cryptés et exécuteront un cracker pour voir quel type de fruits à faible pendaison ils peuvent retirer. Tous examineront la politique de complexité des mots de passe et examineront les garanties en place pour les appliquer.
Mais vous devez fournir certains mots de passe. Je suggère (même si je pense que vous l'avez déjà fait) de lui demander quel est l'objectif de la livraison du mot de passe en clair. Il a dit que c'était pour valider votre politique de conformité par rapport à la politique de sécurité, alors demandez-lui de vous donner cette politique. Demandez-lui s'il acceptera que votre régime de complexité des mots de passe soit suffisamment robuste pour empêcher les utilisateurs de définir leur mot de passe sur P@55w0rd et sont en place depuis six mois.
S'il le pousse, vous devrez peut-être admettre que vous ne pouvez pas fournir de mots de passe en clair car vous n'êtes pas configuré pour les enregistrer (ce qui constitue un défaut de sécurité majeur), mais vous pouvez vous efforcer de le faire à l'avenir s'il le requiert vérification directe du bon fonctionnement de vos politiques de mot de passe. Et s'il veut le prouver, vous serez heureux de lui fournir la base de données de mots de passe cryptée (ou vous! Montrez-le! Cela aide!) Pour exécuter une passe de cracking.
Les "fichiers distants" peuvent probablement être extraits des journaux SSH pour les sessions SFTP, ce dont je soupçonne qu'il parle. Si vous n'avez pas 6 mois de syslogging, ce sera difficile à produire. L'utilisation de wget pour extraire un fichier d'un serveur distant pendant la connexion via SSH est-elle considérée comme un "transfert de fichiers à distance"? Les HTTP sont-ils PUT? Fichiers créés à partir du texte du presse-papiers dans la fenêtre du terminal de l'utilisateur distant? Si quoi que ce soit, vous pouvez le harceler avec ces étuis Edge pour mieux comprendre ses préoccupations dans ce domaine et peut-être inculquer le sentiment "J'en sais plus que vous", ainsi que les technologies spécifiques auxquelles il pense. Ensuite, extrayez ce que vous pouvez des journaux et des journaux archivés sur les sauvegardes.
Je n'ai rien sur les clés SSH. La seule chose à laquelle je peux penser est qu'il vérifie les clés sans mot de passe pour une raison quelconque, et peut-être la force de la crypto. Sinon, je n'ai rien.
En ce qui concerne l'obtention de ces clés, la récolte au moins des clés publiques est assez facile; il suffit de parcourir les dossiers .ssh à leur recherche. Obtenir les clés privées impliquera de mettre votre chapeau BOFH et de harceler vos utilisateurs au son de: "Envoyez-moi vos paires de clés SSH publiques et privées. Tout ce que je ne recevrai pas sera purgé des serveurs dans 13 jours", et si quelqu'un crie (je voudrais) les pointer vers l'audit de sécurité. Le script est votre ami ici. Au minimum, un groupe de paires de clés sans mot de passe obtiendra des mots de passe.
S'il insiste toujours sur les "mots de passe en texte brut dans les e-mails", soumettez au moins ces e-mails au cryptage GPG/PGP avec sa propre clé. Tout vérificateur de sécurité digne de ce nom devrait être capable de gérer quelque chose comme ça. De cette façon, si les mots de passe fuient, ce sera parce qu'il les a laissés sortir, pas vous. Encore un autre test décisif pour la compétence.
Je dois être d'accord avec Zypher et Womble sur celui-ci. Idiot dangereux aux conséquences dangereuses.
Il vous teste probablement pour voir si vous représentez un risque pour la sécurité. Si vous lui fournissez ces informations, vous serez probablement immédiatement renvoyé. Apportez ceci à votre patron immédiat et passez la balle. Faites savoir à votre patron que vous impliquerez les autorités compétentes si ce cul se rapproche de vous.
C'est pour cela que les patrons sont payés.
J'ai une vision d'un morceau de papier laissé à l'arrière d'un taxi qui contient une liste de mots de passe, de clés SSH et de noms d'utilisateurs! Hhhmmm! Peut voir les titres des journaux en ce moment!
Mise à jour
En réponse aux 2 commentaires ci-dessous, je suppose que vous avez tous les deux de bons arguments à faire valoir. Il n'y a aucun moyen de vraiment découvrir la vérité et le fait que la question ait été postée montre un peu de naïveté de la part de l'affiche ainsi que du courage pour faire face à une situation défavorable avec des conséquences potentielles sur la carrière où d'autres s'enfonceraient la tête dans le poncez et fuyez.
Ma conclusion pour ce qu'il vaut est qu'il s'agit d'un débat très intéressant qui a probablement amené la plupart des lecteurs à se demander ce qu'ils feraient dans cette situation, que l'auditeur ou les politiques des auditeurs soient compétents ou non. La plupart des gens seront confrontés à ce genre de dilemme sous une forme ou une autre dans leur vie professionnelle et ce n'est vraiment pas le genre de responsabilité qui devrait être imposée aux épaules d'une seule personne. C'est une décision commerciale plutôt qu'une décision individuelle quant à la façon de gérer cela.
De toute évidence, il y a beaucoup de bonnes informations ici, mais permettez-moi d'ajouter mon 2c, en tant que personne qui écrit des logiciels vendus dans le monde entier par mon employeur à de grandes entreprises principalement pour aider les gens à se conformer aux politiques de sécurité de la gestion des comptes et à passer des audits; pour ce que ça vaut.
Tout d'abord, cela semble très suspect, comme vous (et d'autres) l'avez remarqué. Soit l'auditeur suit simplement une procédure qu'il ne comprend pas (possible), soit vous teste pour la vulnérabilité donc l'ingénierie sociale (peu probable après les échanges de suivi), ou une fraude sociale vous (également possible), ou juste un idiot générique (probablement probablement). En ce qui concerne les conseils, je vous propose de parler à votre direction et/ou de trouver une nouvelle société d'audit, et/ou de signaler celle-ci à l'agence de surveillance appropriée.
En ce qui concerne les notes, quelques choses:
- Il est possible (dans des conditions spécifiques) de fournir les informations demandées, si votre système est configuré pour le permettre. Cependant, il ne s'agit en aucun cas d'une "meilleure pratique" pour la sécurité, et ce ne serait pas du tout courant.
- En règle générale, les audits visent à valider les pratiques et non à examiner les informations réellement sécurisées. Je me méfierais fortement de quiconque demanderait des mots de passe ou des certificats en texte brut, plutôt que les méthodes utilisées pour s'assurer qu'ils sont "bons" et sécurisés correctement.
J'espère que cela vous aidera, même si c'est surtout en réitérant ce que d'autres personnes ont conseillé. Comme vous, je ne vais pas nommer mon entreprise, dans mon cas parce que je ne parle pas pour eux (compte personnel/opinions et tout); excuses si cela nuit à la crédibilité, mais qu'il en soit ainsi. Bonne chance.
Cela pourrait et devrait être publié sur le IT Security - Stack Exchange .
Je ne suis pas un expert en audit de sécurité, mais la première chose que j'ai apprise sur la politique de sécurité est "NEVER GIVE PASSWORDS AWAY". Ce mec est peut-être dans cette entreprise depuis 10 ans, mais comme Womble l'a dit "no, you have 5 minutes of experience repeated hundreds of times"
Je travaille avec les informaticiens bancaires depuis un certain temps, et quand je vous ai vu poster, je leur ai montré ... Ils riaient si fort. Ils m'ont dit que ce mec ressemble à une arnaque. Ils traitaient ce genre de choses pour la sécurité du client de la banque.
Demander un mot de passe clair, des clés SSH, des journaux de mots de passe est clairement une faute professionnelle grave. Ce mec est dangereux.
J'espère que tout va bien maintenant, et que vous n'avez aucun problème avec le fait qu'ils peuvent avoir gardé un journal de votre transaction précédente avec eux.
Si vous pouvez fournir l'une des informations (à l'exception peut-être des clés publiques) demandées aux points 1, 2, 4 et 5, vous devez vous attendre à l'échec de l'audit.
Répondez formellement aux points 1, 2 et 5 en disant que vous ne pouvez pas vous conformer car votre politique de sécurité exige que vous ne conserviez pas les mots de passe en texte brut et que les mots de passe soient cryptés à l'aide d'un algorithme non réversible. Au point 4, encore une fois, vous ne pouvez pas fournir les clés privées car cela violerait votre politique de sécurité.
Quant au point 3. Si vous avez les données, fournissez-les. Si vous ne le faites pas parce que vous n'aviez pas à le collecter, dites-le et montrez comment vous travaillez (vers) à répondre à la nouvelle exigence.
Un auditeur de sécurité pour nos serveurs a exigé ce qui suit dans un délai de deux semaines:
...
Si nous échouons à l'audit de sécurité, nous perdons l'accès à notre plate-forme de traitement des cartes (une partie critique de notre système) et cela prendrait deux bonnes semaines pour se déplacer ailleurs . Comment je suis foutu?
Il semble que vous ayez répondu à votre propre question. (Voir le texte en gras pour des conseils.)
Une seule solution vient à l'esprit: demander à chacun d'écrire son dernier et actuel mot de passe, puis de le changer immédiatement en un nouveau. S'il veut tester la qualité du mot de passe (et la qualité des transitions du mot de passe au mot de passe, par exemple pour s'assurer que personne n'utilise rfvujn125 puis rfvujn126 comme prochain mot de passe,) cette liste d'anciens mots de passe devrait être suffisante.
Si cela n'est pas jugé acceptable, je soupçonne que le gars est membre d'Anonymous/LulzSec ... à quel moment vous devriez lui demander quelle est sa poignée et lui dire d'arrêter d'être un tel gommage!
Comme l'a dit oli: la personne en question essaie de vous faire enfreindre la loi (protection des données/directives de confidentialité de l'UE)/les règlements internes/les normes PCI. Non seulement vous devriez informer la direction (comme vous l'avez déjà fait, je pense), mais vous pouvez appeler la police comme suggéré.
Si la personne en question détient une sorte d'accréditation/certification, par ex. CISA (Certified Information Systems Auditor), ou l'équivalent britannique de US CPA (un titre d'expert-comptable), vous pouvez également informer les organismes d'accréditation de l'enquêter. Non seulement cette personne essaie de vous faire enfreindre la loi, mais c'est également un "audit" extrêmement incompétent et probablement contraire à toutes les normes d'audit éthique selon lesquelles les auditeurs accrédités doivent se conformer sous peine de perdre leur accréditation.
De plus, si la personne en question est membre d'une plus grande entreprise, les organisations d'audit susmentionnées ont souvent besoin d'une sorte de service d'assurance qualité qui supervise la qualité des audits et des dossiers d'audit et enquête sur les plaintes. Vous pouvez donc également vous plaindre auprès de la société d'audit en question.
J'étudie toujours et la première chose que j'ai apprise lors de la configuration des serveurs, c'est que si vous permettez d'enregistrer des mots de passe en clair, vous vous mettez déjà en danger pour une brèche géante. Aucun mot de passe ne doit être connu, sauf pour l'utilisateur qui l'utilise.
Si ce type est un auditeur sérieux, il ne devrait pas vous demander ces choses. Pour moi, il ressemble à un malfaiteur . Je vérifierais avec l'organe régulateur parce que ce gars sonne comme un idiot complet.
Mise à jour
Attendez, il pense que vous devez utiliser un cryptage symétrique juste pour transmettre le mot de passe, mais ensuite les stocker en clair dans votre base de données, ou fournir un moyen de les décrypter. Donc, fondamentalement, après toutes les attaques anonymes contre des bases de données, où ils montraient des mots de passe d'utilisateurs en texte brut, il pense TOUJOURS que c'est un bon moyen de "sécuriser" un environnement.
C'est un dinosaure coincé dans les années 1960 ...
- Une liste des noms d'utilisateur et mots de passe en texte brut actuels pour tous les comptes d'utilisateur sur tous les serveurs
- Les noms d'utilisateur actuels PEUVENT être dans la portée de "nous pouvons publier cela" et devraient être dans la portée de "nous pouvons vous le montrer, mais vous ne pouvez pas le retirer hors site".
- Les mots de passe en texte brut ne devraient pas exister plus longtemps qu'il ne le faut pour les hacher unidirectionnels et ils ne devraient certainement jamais laisser de mémoire (pas même pour traverser les fils), donc leur existence dans le stockage permanent est un non-non.
- Une liste de tous les changements de mot de passe pour les six derniers mois, toujours en texte brut
- Voir "le stockage permanent est un non-non".
- Une liste de "chaque fichier ajouté au serveur à partir d'appareils distants" au cours des six derniers mois
- Cela peut être pour vous assurer que vous enregistrez les transferts de fichiers vers/depuis le (s) serveur (s) de traitement des paiements, si vous avez les journaux, vous devriez pouvoir les transmettre. Si vous n'avez pas de journaux, vérifiez ce que les politiques de sécurité pertinentes disent à propos de la journalisation de ces informations.
- Les clés publiques et privées de toutes les clés SSH
- Peut-être qu'une tentative pour vérifier que "les clés SSH doivent avoir une phrase de passe" est dans la politique et suivie. Vous voulez des phrases secrètes sur toutes les clés privées.
- Un e-mail qui lui est envoyé chaque fois qu'un utilisateur change de mot de passe, contenant le mot de passe en texte brut
- C'est très certainement un non-non.
Je répondrais avec quelque chose dans le sens de mes réponses, soutenu par des documents de conformité PCI, de conformité SOX et de politique de sécurité interne selon les besoins.
Je lui dirais qu'il faut du temps, des efforts et de l'argent pour construire l'infrastructure de craquage pour les mots de passe, mais parce que vous utilisez un hachage fort comme SHA256 ou autre, il pourrait ne pas être possible de fournir les mots de passe dans les 2 semaines. En plus de cela, je dirais que j'ai contacté le service juridique pour confirmer s'il est légal de partager ces données avec quelqu'un. PCI DSS aussi une bonne idée de mentionner comme vous l'avez fait. :)
Mes collègues sont choqués en lisant ce post.
Ces gars demandent des relents au paradis, et je conviens que toute correspondance à partir d'ici devrait passer par le CTO. Soit il essaie de faire de vous le gars de l'automne pour ne pas avoir pu répondre à cette demande, pour avoir divulgué des informations confidentielles, soit il est extrêmement incompétent. J'espère que votre CTO/manager fera une double prise en compte de cette demande de gars et qu'une action positive sera faite, et s'ils sont derrière les actions de ce gars .... eh bien, les bons administrateurs système sont toujours en demande sur les petites annonces, comme il semble qu'il soit temps de commencer à chercher un endroit si cela se produit.
Je serais fortement tenté de lui donner une liste de nom d'utilisateur/mots de passe/clés privées pour les comptes de pot de miel, puis s'il teste les connexions pour ces comptes, faites-lui un accès non autorisé à un système informatique. Cependant, malheureusement, cela vous expose probablement à au moins une sorte de délit civil pour avoir fait une représentation frauduleuse.
Refusez simplement de révéler les informations, déclarant que vous ne pouvez pas transmettre les mots de passe car vous n'y avez pas accès. Étant moi-même auditeur, il doit représenter une institution. Ces institutions publient généralement des lignes directrices pour un tel audit. Vérifiez si une telle demande est conforme à ces directives. Vous pouvez même vous plaindre auprès de telles associations. Indiquez également clairement à l'auditeur qu'en cas d'actes répréhensibles, le blâme peut lui revenir (l'auditeur) car il a tous les mots de passe.
Je dirais qu'il n'y a aucun moyen pour vous de lui fournir les informations demandées.
- Les noms d'utilisateur lui donnent un aperçu des comptes qui ont accès à vos systèmes, un risque pour la sécurité
- L'historique des mots de passe fournirait un aperçu des modèles de mots de passe utilisés, ce qui lui donnerait une possibilité d'attaque en devinant le prochain mot de passe de la chaîne
- Les fichiers transférés sur le système peuvent contenir des informations confidentielles qui pourraient être utilisées dans une attaque contre vos systèmes, ainsi que leur donner un aperçu de la structure de votre système de fichiers
- Clés publiques et privées, à quoi bon les avoir si vous les donniez à quelqu'un d'autre que l'utilisateur prévu?
- Un e-mail envoyé chaque fois qu'un utilisateur modifie un mot de passe lui donnerait des mots de passe à jour pour chaque compte d'utilisateur.
Ce mec tire votre compagnon plonker! Vous devez entrer en contact avec son manager ou un autre auditeur de l'entreprise pour confirmer ses demandes scandaleuses. Et éloignez-vous dès que possible.
Problème résolu maintenant, mais pour le bénéfice des futurs lecteurs ...
Étant donné que:
Vous semblez y avoir consacré plus d'une heure.
Vous avez dû consulter le conseiller juridique de l'entreprise.
Ils demandent beaucoup de travail après avoir modifié votre accord.
Vous perdrez de l'argent et plus de temps à passer.
Vous devez expliquer que vous aurez besoin de beaucoup d'argent à l'avance et qu'il y a un minimum de quatre heures.
Ces dernières fois, j'ai dit à quelqu'un qu'ils n'étaient soudain pas si nécessiteux.
Vous pouvez toujours les facturer pour toute perte subie lors du basculement et pour le temps nécessaire, car ils ont changé votre accord. Je ne dis pas qu'ils paieront dans les deux semaines, tout comme ils pensaient que vous vous conformeriez dans ce délai - ils seront unilatéraux, je n'en doute pas.
Il les secouera si le bureau de votre avocat envoie l'avis de recouvrement. Il devrait attirer l'attention du propriétaire de la société d'audit.
Je déconseille toute autre négociation avec eux, le simple fait de discuter de la question entraînera un dépôt pour le travail requis. Ensuite, vous pouvez être payé pour les dénoncer.
Il est étrange que vous ayez un accord en vigueur et que quelqu'un à l'autre bout se détache du Rails - si ce n'est pas un test de sécurité ou de renseignement, c'est certainement un test de votre patience.