Un auditeur de sécurité pour nos serveurs a demandé ce qui suit dans les 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 des six derniers mois, toujours en texte clair
• Une liste de "tous les fichiers ajoutés 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 email lui est envoyé chaque fois qu'un utilisateur change son mot de passe, contenant le mot de passe en texte brut

Nous utilisons les boîtes Red Hat Linux 5/6 et CentOS 5 avec authentification LDAP.

Autant que je sache, tout ce qui est sur cette liste est soit impossible, soit 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 au cours d'une période de transition. nouveau service. Des suggestions sur la façon dont je peux résoudre ou simuler cette information?

La seule façon pour moi d’obtenir tous les mots de passe en texte brut est d’amener tout le monde à réinitialiser son mot de passe et à noter sa configuration. Cela ne résout pas le problème des six derniers mois de changement de mot de passe, car je ne peux pas enregistrer ce type de données de manière rétroactive, 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 ne disposons que de quelques utilisateurs et ordinateurs. À moins que j'ai raté un moyen plus facile de faire cela?

Je lui ai expliqué à maintes reprises que les choses qu'il demande sont impossibles. En réponse à mes préoccupations, il a répondu avec le courrier électronique suivant:

J'ai plus de 10 ans d'expérience dans l'audit de sécurité et une parfaite compréhension des méthodes de sécurité redhat. Je vous suggère donc de vérifier vos informations sur ce qui est ou non possible. Vous dites qu'aucune entreprise ne pourrait avoir cette information, mais j'ai effectué des centaines d'audits lorsque cette information était facilement disponible. Tous les clients [fournisseurs génériques de traitement de cartes de crédit] sont tenus de se conformer à nos nouvelles politiques de sécurité et cet audit a pour but de s’assurer que ces politiques ont été mises en œuvre * correctement.

* Les "nouvelles stratégies de sécurité" ont été introduites deux semaines avant notre audit et l'enregistrement historique de six mois n'était pas nécessaire avant les modifications de stratégie.

En bref, j'ai besoin de;

• Un moyen de "simuler" six mois de modification du mot de passe et de lui donner un aspect valide
• Une façon de "simuler" six mois de transferts de fichiers entrants
• Un moyen facile 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 de cartes (une partie essentielle de notre système) et il nous faudrait deux bonnes semaines pour nous déplacer ailleurs. Comment je suis foutu?

Mise à jour 1 (samedi 23)

Merci pour toutes vos réponses. Cela me soulage de savoir que ce n’est pas une pratique courante.

Je suis en train de préparer ma réponse par courrier électronique à lui expliquer 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'email quand j'aurai fini de l'écrire. Malheureusement, je ne pense pas qu'il nous teste seulement; ces choses sont dans la politique de sécurité officielle de l'entreprise. Cependant, j'ai mis les roues en mouvement pour m'éloigner d'eux et rejoindre PayPal pour le moment.

Mise à jour 2 (samedi 23)

Ceci est le courriel que j'ai rédigé, des suggestions pour des choses à ajouter / supprimer / changer?

Bonjour [nom],

Malheureusement, il n’ya aucun moyen pour nous de vous fournir certaines des informations demandées, principalement des 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 le fait de pouvoir fournir ces informations irait à la fois contre les normes PCI et contre la loi sur la protection des données.
Pour citer les exigences PCI,

8.4 Rend tous les mots de passe illisibles pendant la transmission et le stockage sur tous les composants du système en utilisant une cryptographie puissante.

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 d'hôtes autorisés (ceci vous donnera suffisamment d'informations pour déterminer le nombre d'utilisateurs uniques pouvant se connecter à nos serveurs, ainsi que le chiffrement. méthodes utilisées), des informations sur nos exigences en matière de sécurité des mots de passe et notre serveur LDAP, mais ces informations ne peuvent pas être extraites du site. Je vous suggère fortement de revoir vos exigences en matière d’audit car il n’existe actuellement aucun moyen de réussir cet audit tout en respectant les normes PCI et la loi sur la protection des données.

Cordialement,
[moi]

Je ferai du CC dans la CTO de la société et notre responsable des comptes, et j'espère que le CTO pourra confirmer que ces informations ne sont pas disponibles. Je contacterai également le Conseil des normes de sécurité PCI pour expliquer ce qu'il nous demande.

Mise à jour 3 (26ème)

Voici quelques courriels que nous avons échangés.

RE: mon premier email;

Comme expliqué, ces informations doivent être facilement disponibles sur tout système bien entretenu pour tout administrateur compétent. Votre incapacité à fournir ces informations me porte à croire que vous êtes conscient 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. La cryptographie renforcée signifie uniquement que les mots de passe doivent être cryptés pendant la saisie par l'utilisateur, mais ils doivent ensuite être déplacés vers un format récupérable pour une utilisation ultérieure.

Je ne vois pas de problèmes de protection des données pour ces demandes, la protection des données ne concerne que les consommateurs et non les entreprises, il ne devrait donc y avoir aucun problème avec ces informations.

Juste, quoi, je ne peux même pas ...

"Une cryptographie renforcée signifie uniquement que les mots de passe doivent être cryptés pendant la saisie par l'utilisateur, mais qu'ils doivent ensuite être déplacés vers un format récupérable pour une utilisation ultérieure."

Je vais l'encadrer et le mettre sur mon mur.

J'en avais marre d'être diplomate et l'ai dirigé vers ce fil pour lui montrer la réponse que j'ai obtenue:

Fournir ces informations contredit directement plusieurs exigences des directives PCI. La section que j'ai citée dit même storage (impliquant de stocker les données sur le disque). J'ai lancé une discussion sur ServerFault.com (une communauté en ligne pour les professionnels de sys-admin) qui a suscité une énorme réaction, suggérant que ces informations ne pouvaient pas être fournies. N'hésitez pas à lire par vous-même

https://serverfault.com/questions/293217/

Nous avons fini de passer de notre système à une nouvelle plate-forme et nous allons annuler notre compte avec vous dans un jour ou deux, mais je veux que vous réalisiez à quel point ces demandes sont ridicules et aucune entreprise mettant correctement en œuvre les directives PCI ne pourra ou ne devrait, être en mesure de fournir cette information. Je vous suggère fortement de repenser vos exigences en matière 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 nous l'avions mentionné, nous nous étions déjà éloignés de leur plateforme, donc aucune perte réelle.)

Et dans sa réponse, il déclare qu’apparemment, aucun d’entre vous ne sait de quoi vous parlez:

J'ai lu en détail dans ces réponses et dans votre message original, les répondants doivent tous bien comprendre les faits. Je connais ce secteur depuis plus longtemps que quiconque sur ce site. Obtenir une liste des mots de passe des comptes d'utilisateurs est extrêmement élémentaire. Ce doit être l'une des premières choses que vous devez faire pour apprendre à sécuriser votre système. Il est essentiel au fonctionnement de tout système sécurisé serveur. Si vous manquez réellement des compétences pour effectuer une tâche aussi simple, je suppose que le PCI n’est pas installé sur vos serveurs, car la récupération de ces informations est une exigence de base du logiciel. Lorsque vous traitez avec 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 la façon dont cela fonctionne.

Je voudrais également suggérer que toute tentative de me révéler, ou [nom de la société] sera considéré comme une diffamation et une action judiciaire appropriée sera prise

Points clés idiots si vous les avez manqués:

• Il est auditeur de sécurité depuis plus longtemps que tout le monde ici (il devine ou vous traque)
• Pouvoir 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 quand ils ne sont pas sûrs de la sécurité
• Poser des informations factuelles (pour lesquelles j'ai une preuve électronique) en ligne est une diffamation

Excellent.

PCI SSC a répondu et enquête sur lui et sur la société. Notre logiciel a maintenant été transféré sur PayPal, nous savons donc qu'il est sécurisé. J'attendrai que PCI me contacte d'abord, mais je crains un peu qu'ils utilisent peut-être ces pratiques de sécurité en interne. Si c'est le cas, je pense que c'est une préoccupation majeure pour nous, car tous les processus de traitement de nos cartes les ont traité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 difficile d'enquêter sur l'ensemble de l'entreprise et du système, je ne suis pas sûr.

Alors maintenant, nous nous sommes éloignés de leur plate-forme, et en supposant que ce soit au moins quelques jours avant que PCI ne me revienne, des suggestions inventives sur la façon de le suivre un peu? =)

Une fois que mon avocat aura obtenu l'autorisation (je doute fort que tout ceci soit réellement de la diffamation mais je voulais vérifier) ​​je publie le nom de la société, son nom et son adresse email, et si vous le souhaitez, vous pouvez le contacter pour lui expliquer pourquoi vous ne comprenez pas les bases de la sécurité Linux, comme obtenir une liste de tous les mots de passe des utilisateurs LDAP.

Petite mise à jour:

Mon "type juridique" a suggéré de révéler que la société causerait probablement plus de problèmes que nécessaire. Je peux cependant dire 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 très petit et fonctionnait sous un petit VPS, et nous ne voulions pas passer par tous les efforts nécessaires pour obtenir le PCI (nous avions l'habitude de rediriger vers leur interface, comme PayPal Standard). Mais lorsque nous sommes passés aux cartes de traitement direct (y compris le PCI et le bon sens), les développeurs ont décidé de continuer à utiliser la même société, juste une API différente. La société est basée à Birmingham, au Royaume-Uni, alors je doute fort que quiconque ici sera touché.

Tout d'abord, ne capitule pas. Il est non seulement un idiot, mais DANGEREUSEMENT faux. En fait, la divulgation de ces informations constituerait une violation de la norme PCI (ce à quoi je suppose que la vérification s’applique étant donné qu’il s’agit d’un processeur de paiement), de même que de toutes les autres normes existantes et du simple bon sens. Cela exposerait également votre entreprise à toutes sortes de responsabilités.

La prochaine chose que je ferais serait d’envoyer un courrier électronique à votre patron pour lui dire qu’il devait faire appel à un conseil d’entreprise pour déterminer les risques juridiques auxquels la société serait exposée en procédant de la sorte.

Ce dernier bit appartient à vous, mais je contacterais VISA avec ces informations pour obtenir son statut d’auditeur PCI.

En tant que personne qui a suivi la procédure de vérification avec Price Waterhouse Coopers pour un contrat classifié avec le gouvernement, je peux vous assurer que cela est tout à fait hors de question et que ce type est fou.

Lorsque PwC a voulu vérifier la force de notre mot de passe, ils ont:

• Demandé de voir nos algorithmes de force de mot de passe
• Testé des unités de test contre nos algorithmes pour vérifier qu'ils refuseraient les mauvais mots de passe
• Nous avons demandé à voir nos algorithmes de cryptage pour nous assurer qu'ils ne pourraient pas être inversés ou non cryptés (même par des tables arc-en-ciel), même par une personne ayant un accès complet à tous les aspects du système
• Vérifié que les mots de passe précédents ont été mis en cache pour s'assurer qu'ils ne pourront pas être réutilisés
• Nous leur avons demandé la permission (que nous leur avons accordée) de tenter de pénétrer dans le réseau et les systèmes associés 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 les mots de passe des utilisateurs au cours des 6 derniers mois, ils nous auraient immédiatement mis fin au contrat.

S'il était possible de répondre à ces exigences, vous échoueriez instantanément dans chaque audit intéressant.

Mise à jour: Votre email de réponse a l'air bien. Bien plus professionnel que tout ce que j'aurais écrit.

Honnêtement, on dirait que ce type (le vérificateur) vous prépare. Si vous lui donnez les informations qu'il demande, vous venez de lui prouver que vous pouvez être socialement conçu pour renoncer à des informations internes critiques. Échouer.

Je viens de m'apercevoir que vous êtes au Royaume-Uni, ce qui signifie qu'il vous demande d'enfreindre la loi (la loi sur la protection des données en fait). Je suis aussi au Royaume-Uni, je travaille pour une grande entreprise fortement auditée et je connais la loi et les pratiques courantes dans ce domaine. Je suis aussi un travail très méchant qui va heureusement freiner ce garçon pour vous si vous aimez juste pour le plaisir, laissez-moi savoir si vous voulez de l'aide, d'accord.

Vous êtes socialement conçu. Soit pour vous «tester», soit pour un pirate informatique se faisant passer pour un auditeur afin d’obtenir des données très utiles.

Je suis sérieusement préoccupé par le manque de compétences en résolution de problèmes éthiques chez les PO et par la communauté des serveurs défaillants qui ignore cette violation flagrante de la conduite éthique.

En bref, j'ai besoin de;

• Un moyen de «simuler» six mois de modification du mot de passe et de lui donner un aspect valide
• Un moyen de «simuler» six mois de transferts de fichiers entrants

Laissez-moi être clair sur deux points:

1. Il n'est jamais approprié de falsifier des données au cours d'une activité normale.
2. Vous ne devriez jamais divulguer ce genre d'informations à qui que ce soit. Déjà.

Ce n'est pas à vous de falsifier des disques. Il est de votre devoir de vous assurer que tous les enregistrements nécessaires sont disponibles, exacts et sécurisés.

La communauté ici chez Server Fault doit traiter ce genre de questions comme le site stackoverflow traite de "devoirs". Vous ne pouvez pas aborder ces problèmes avec une simple 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 de déontologie des administrateurs de système SAGE .

BTW, votre auditeur de sécurité est un idiot, mais cela ne signifie pas que vous devez ressentir de la pression pour ne pas être éthique dans votre travail.

Edit: Vos mises à jour sont inestimables. Gardez la tête basse, la poudre sèche, et ne prenez pas (et ne donnez pas) de nickels en bois.

Vous ne pouvez pas lui donner ce que vous voulez, et les tentatives de "falsification" risquent de revenir vous mordre à la gorge (éventuellement de manière légale). Vous devez soit faire appel dans la chaîne de commandement (il est possible que cet auditeur soit devenu un voyou, même si les audits de sécurité sont notoirement idiots - demandez-moi si l'auditeur souhaitait pouvoir accéder à un AS / 400 via SMB) ou obtenir l'enfer sortir de dessous ces exigences onoriques.

Ils ne sont pas même une bonne sécurité - une liste de tous les mots de passe est une plaintext incroyablement chose dangereuse à jamais produire, quelles que soient les méthodes utilisées pour les protéger, et je parierai ce mec voudra les envoyé par courrier électronique en texte clair . (Je suis sûr que vous le savez déjà, je dois juste me défouler un peu).

Pour des merdes et des 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 parti, sa réponse "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ée des centaines de fois".

Aucun auditeur ne devrait vous laisser tomber 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 ment pas et ne maquille pas. b) Lisez vos politiques.

La déclaration clé pour moi est celle-ci:

Tous les clients [fournisseurs génériques de traitement de cartes de crédit] doivent se conformer à nos nouvelles politiques de sécurité.

Je parie que ces politiques contiennent une déclaration selon laquelle les mots de passe ne peuvent pas être écrits ni transmis à une personne autre que l'utilisateur. Si tel est le cas, appliquez ces stratégies à 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 les laissez pas être enlevés. Expliquez que donner des mots de passe en clair est a) impossible car il est à sens unique, 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 des six derniers mois, toujours en texte clair

Expliquez que ceci n'était pas disponible historiquement. Donnez-lui une liste des derniers changements de mot de passe pour montrer que cela est en train de se faire. Expliquez, comme ci-dessus, que les mots de passe ne seront pas fournis.

• Une liste de "tous les fichiers ajoutés au serveur à partir d'appareils distants" au cours des six derniers mois

Expliquez ce qui est et n'est pas enregistré. Fournissez ce que vous pouvez. Ne fournissez rien de confidentiel et expliquez par politique pourquoi pas. 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 convient d'indiquer que les clés privées ne sont pas autorisées à sortir de leur conteneur et que leurs conditions d'accès sont 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 email lui est envoyé chaque fois qu'un utilisateur change son mot de passe, contenant le mot de passe en texte brut

Dis juste non. Si vous avez un serveur de journalisation sécurisé local, laissez-lui savoir qu'il est consigné in situ.

En gros, et je suis désolé de le dire, mais vous devez jouer dur avec ce gars. Suivez votre politique exactement, ne déviez pas. Ne mens pas. Et s'il vous omet pour quoi que ce soit qui ne soit pas dans la politique, se plaindre à ses aînés à la compagnie qui l'a envoyé. Recueillez une trace écrite de tout cela pour prouver que vous avez été raisonnable. Si vous enfreignez votre politique, vous êtes à sa merci. Si vous les suivez à la lettre, il finira par être renvoyé.

Oui, l'auditeur est un idiot. Cependant, comme vous le savez, il arrive que des idiots soient placés au pouvoir. C'est l'un de ces cas.

Les informations demandées n’ont aucune incidence 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 brutal-force contre les hachages de mots 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 peut-être savoir comment il pense que vous devriez pouvoir différencier les fichiers créés directement sur le serveur des fichiers SCP sur le serveur.

Comme @womble l'a dit, ne simulez rien. Cela ne fera aucun bien. 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 biscuit.

Demandez à votre "auditeur de sécurité" de pointer n'importe quel texte de l'un de ces documents contenant ses exigences et de regarder comment il s'efforce de trouver une excuse et finit par s'excuser pour ne plus jamais être entendu.

WTF! Désolé mais c'est ma seule réaction à cela. Je n'ai jamais entendu parler de besoin d'audit nécessitant un mot de passe en texte clair, sans parler de leur fournir les mots de passe à mesure qu'ils changent.

Tout d'abord, demandez-lui de vous montrer l'obligation de fournir cela.

Deuxièmement, si cela concerne PCI (nous supposons tous qu’il s’agit d’une question liée au système de paiement), cliquez ici: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php et procurez-vous un nouvel auditeur.

Troisièmement, suivez ce qu'ils ont dit ci-dessus, contactez votre direction et demandez-lui de contacter la société QSA avec laquelle il travaille. Ensuite, obtenez immédiatement un autre auditeur.

Les auditeurs auditent les états, normes, processus, etc. du système. Ils n'ont pas besoin d'informations qui leur donnent accès aux systèmes.

Si vous souhaitez que des auditeurs recommandés ou des collaborateurs alternatifs travaillant en étroite collaboration avec les auditeurs, contactez-moi et je me ferai un plaisir de vous fournir des références.

Bonne chance! Faites confiance à votre instinct, si quelque chose semble mal, c'est probablement.

Il n’ya 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 lui demandait 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 voudrait, 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.

Informez la direction que l'auditeur a demandé que vous enfreignez vos politiques de sécurité et que la demande est illégale. Suggérez-leur de vouloir vider le cabinet d’audit actuel et d’en trouver un légitime. Appelez la police et demandez à l'auditeur de demander des informations illégales (au Royaume-Uni). Ensuite, appelez le PCI et rendez l’auditeur pour connaître sa demande.

La demande revient à vous demander d’assassiner quelqu'un au hasard et de remettre le corps. Feriez-vous cela? ou appellerais-tu les flics et les rendrais-tu?

Répondre avec un procès . Si un auditeur demande des mots de passe en texte clair (ne vous inquiétez pas, ce n'est pas si difficile de faire une force brutale ou de déchiffrer des mots de passe faibles), il vous a probablement menti au sujet de ses informations d'identification.

Juste un conseil quant à la façon dont vous formulez votre réponse:

Malheureusement, il n’ya aucun moyen pour nous de vous fournir certaines des informations demandées, principalement des 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 cette question pour éviter d’entamer une discussion sur la faisabilité technique. La lecture du premier e-mail envoyé par le terrible auditeur, il semble que ce soit quelqu'un qui peut prendre sur les détails qui ne sont pas liés au problème principal, et il pourrait faire valoir que vous pouvez enregistrer les mots de passe, connectez - vous les connexions, etc. Donc , soit dire :

... 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 abaissions considérablement notre niveau de sécurité interne en nous conformant à votre demande, ...

Bonne chance et continuez comme ça!

Au risque de continuer à nous presser d’utilisateurs très expérimentés, voici ce que je pense.

Je peux vaguement comprendre pourquoi il veut les mots de passe en texte clair, et c'est pour juger de la qualité des mots de passe utilisés. C'est une mauvaise façon de s'y prendre, la plupart des auditeurs que je connais accepteront les codes de hachage cryptés et lanceront un cracker pour voir quel type de solution à portée de main ils peuvent retirer. Tous examineront la politique relative à la complexité du mot de passe et examineront les mesures de protection mises en place pour le faire respecter.

Mais vous devez fournir des mots de passe. Je suggère (bien que je pense que vous l'ayez déjà fait) de lui demander quel est l'objectif de la transmission du mot de passe en texte clair. Il a dit que c'était pour valider votre politique de conformité par rapport à votre politique de sécurité, alors demandez-lui de vous donner cette politique. Demandez-lui s'il accepte que le régime de complexité de votre mot de passe soit suffisamment robuste pour empêcher les utilisateurs de définir leur mot de passe P@55w0rdet qu'il a été mis en place de manière prouvée pendant les six mois en question.

S'il le pousse, vous devrez peut-être admettre que vous ne pouvez pas fournir de mot de passe en clair, car vous n'êtes pas prêt à les enregistrer (ce qui constitue un problème de sécurité majeur), mais vous pouvez le faire à l'avenir s'il le souhaite. vérification directe du fonctionnement de vos stratégies de mot de passe. Et s'il veut le prouver, vous serez heureux de fournir la base de données de mots de passe cryptée pour lui (ou vous-même, prêt à montrer! Ça aide!) À exécuter une passe.

Les "fichiers distants" peuvent probablement être extraits des journaux SSH pour les sessions SFTP, ce dont je suppose qu'il parle. Si vous ne disposez pas de syslogging sur une période de 6 mois, cela sera difficile à produire. L'utilisation de wget pour extraire un fichier d'un serveur distant alors que vous êtes connecté via SSH est-elle considérée comme un «transfert de fichier distant»? Sont les PUT HTTP? Fichiers créés à partir du texte du presse-papiers dans la fenêtre du terminal de l'utilisateur distant? Au contraire, vous pouvez le harceler avec ces cas extrêmes pour mieux comprendre ses préoccupations dans ce domaine et peut-être inculquer le sentiment de "j'en sais plus que vous", ainsi que les technologies spécifiques auxquelles il pense. Extrayez ensuite ce que vous pouvez extraire des journaux et des journaux archivés des sauvegardes.

Je n'ai rien sur les clés SSH. La seule chose à laquelle je peux penser, c'est qu'il cherche des clés sans mot de passe pour une raison quelconque, et peut - être une force de cryptographie. 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 pour les rechercher. Obtenir les clés privées impliquera d'enfiler votre chapeau BOFH et de harasser vos utilisateurs sur le message «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 s'acharne (je le ferais) vers l'audit de sécurité. Le script est votre ami ici. Au minimum, il faudra un tas de paires de clés sans mot de passe pour obtenir 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 auditeur de sécurité digne de ce nom devrait pouvoir gérer quelque chose comme ça. De cette façon, si les mots de passe fuient, ce sera parce qu'il les aura laissés sortir, pas vous. Encore un autre test décisif pour la compétence.

Je suis d'accord avec Zypher et Womble sur celui-ci. Dangereux idiot avec des conséquences dangereuses.

Il vous teste probablement pour voir si vous présentez un risque de sécurité. Si vous lui fournissez ces informations, vous serez probablement renvoyé immédiatement. Apportez ceci à votre supérieur immédiat et passez la balle. Dites à votre patron que vous impliquerez les autorités compétentes si cet âne revient à vous.

C'est pour ça que les patrons sont payés.

J'ai la vision d'un morceau de papier laissé à l'arrière d'un taxi qui contient une liste de mots de passe, clés SSH et noms d'utilisateur! Hhhmmm! Peut voir les titres du journal en ce moment!

Mise à jour

En réponse aux 2 commentaires ci-dessous, je suppose que vous avez tous deux de bons arguments à faire valoir. Il n’ya aucun moyen de vraiment savoir la vérité et le fait que la question ait été posée montre un peu de naïveté de la part de l’affiche ainsi que le courage de faire face à une situation difficile pouvant avoir des conséquences sur sa carrière, où d’autres se fourreraient la tête. sable et fuir.

Ma conclusion à ce que cela vaille la peine, c’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 leur auditeur ou ses politiques soient compétents ou non. La plupart des gens vont être confrontés à ce genre de dilemme dans leur vie professionnelle et ce n’est vraiment pas le genre de responsabilité qui devrait être assumée par une seule personne. Il s’agit d’une décision d’affaires plutôt que d’une décision individuelle en ce qui concerne la manière de traiter cette question.

Il est clair qu’il ya beaucoup de bonnes informations ici, mais permettez-moi d’ajouter mon 2c, en tant que concepteur de logiciels vendus dans le monde entier par mon employeur aux grandes entreprises, principalement pour aider les personnes à se conformer aux politiques de sécurité de la gestion des comptes et à passer des audits; pour ce que cela vaut.

Tout d’abord, cela semble très suspect, comme vous (et d’autres) l’avez remarqué. Soit l’auditeur ne fait que suivre une procédure qu’il ne comprend pas (possible), ou il vous teste la vulnérabilité (ingénierie sociale) (peu probable après des échanges de suivi), ou une fraude d’ingénierie sociale (également possible), ou tout simplement un idiot générique (probablement probablement). En ce qui concerne les conseils, je vous proposerais 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 (sous certaines conditions) de fournir les informations qu'il a demandées, si votre système est configuré pour le permettre. Cependant, il ne s'agit en aucun cas d'une "meilleure pratique" en matière de sécurité et ne le serait pas du tout.
• En règle générale, les audits s’intéressent à la validation des pratiques et non à l’examen des informations sécurisées. Je me méfierais grandement 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 correctement sécurisés.

J'espère que cela vous aidera, même si cela répète en grande partie ce que les autres ont conseillé. Comme vous, je ne vais pas nommer mon entreprise, dans mon cas parce que je ne parle pas pour elles (compte / avis personnels et autres); excuses si cela porte atteinte à la crédibilité, mais ainsi soit-il. Bonne chance.

Cela pourrait et devrait être posté sur IT Security - Stack Exchange .

Je ne suis pas un expert en audit de sécurité, mais la première chose que j'ai apprise au sujet de la politique de sécurité est "NEVER GIVE PASSWORDS AWAY". Ce gars a peut-être été dans cette affaire depuis 10 ans, mais comme Womble l'a dit"no, you have 5 minutes of experience repeated hundreds of times"

Je travaille avec des informaticiens du secteur bancaire depuis un certain temps et, quand je t'ai vue poster, je le leur ai montré ... Ils riaient si fort. Ils m'ont dit que ce gars ressemble à une arnaque. Ils avaient l'habitude de traiter ce genre de chose pour la sécurité du client de la banque.

Demander des mots de passe clairs, des clés SSH et 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 demandées aux points 1, 2, 4 et 5 (à l'exception peut-être des clés publiques), vous devez vous attendre à un échec de l'audit.

Répondez officiellement aux points 1, 2 et 5 en indiquant 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é.

Au point 3. Si vous avez les données, fournissez-les. Si vous ne le collectez pas parce que vous n'avez pas à le collecter, dites-le-moi et montrez comment vous (travaillez actuellement) à respecter la nouvelle exigence.

Un auditeur de sécurité pour nos serveurs a demandé ce qui suit dans les deux semaines :

...

Si nous échouons à l'audit de sécurité, nous perdons l'accès à notre plate-forme de traitement de cartes (une partie essentielle de notre système) et il nous faudrait deux bonnes semaines pour nous 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 me vient à l’esprit: demandez à chacun d’écrire son dernier et son mot de passe actuel, puis changez-le immédiatement en un nouveau. S'il veut tester la qualité du mot de passe (et la qualité des transitions de mot de passe en mot de passe, par exemple pour s'assurer que personne n'utilise rfvujn125 puis rfvujn126 comme mot de passe suivant,) cette liste d'anciens mots de passe devrait suffire.

Si cela n’est pas jugé acceptable, alors je soupçonne qu’il est membre d’Anonymous / LulzSec ... à quel moment vous devriez lui demander quelle est sa poignée et lui dire de cesser d’être un tel gommage!

Comme le disait oli: la personne en question essaie de vous amener à enfreindre la loi (directives concernant la protection des données / La confidentialité de l'UE) / la réglementation interne / les normes PCI. Non seulement devriez-vous informer la direction (comme vous l'avez déjà fait je pense), mais vous pouvez également appeler la police comme suggéré.

Si la personne en question est titulaire d’une accréditation ou d’une certification, par exemple CISA (vérificateur agréé de systèmes d’information), ou son équivalent au Royaume-Uni de US CPA (désignation d’expert-comptable), vous pouvez également demander aux organismes d’accréditation d’enquêter à son sujet. Non seulement cette personne essaie-t-elle de vous forcer à enfreindre la loi, mais elle est également "un audit" extrêmement incompétent et probablement en violation de toutes les normes d'audit éthique imposées aux auditeurs accrédités sous peine de perdre leur accréditation.

De plus, si la personne en question est membre d’une grande entreprise, les organisations d’audit susmentionnées ont souvent besoin d’un service d’assurance de la qualité qui supervise la qualité des audits et du classement des audits 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 de serveurs, c'est que si vous permettez de vous connecter des mots de passe en clair, vous vous mettez déjà en danger pour une faille géante. Aucun mot de passe ne doit être connu, sauf pour l'utilisateur qui l'utilise.

Si ce gars est un auditeur sérieux, il ne devrait pas vous demander ces choses-là. Pour moi, il sonne un peu comme un malfaiteur . Je vérifierais avec l'organe de réglementation parce que ce gars a l'air d'un idiot complet.

Mise à jour

Attendez, il pense que vous devez utiliser un cryptage symétrique uniquement pour transmettre le mot de passe, puis stockez-les en texte brut dans votre base de données ou fournissez un moyen de les décrypter. Donc, en gros, après toutes les attaques anonymes sur les bases de données, où elles ont montré des mots de passe utilisateur en clair, il croit 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 actuels et des mots de passe en texte brut pour tous les comptes d'utilisateurs sur tous les serveurs
  • Les noms d'utilisateur actuels PEUVENT être dans la portée de "nous pouvons libérer ceci" et devraient être dans la portée de "nous pouvons vous montrer ceci, mais vous ne pouvez pas le prendre hors site".
  • Les mots de passe en texte brut ne doivent pas exister plus longtemps qu'il ne faut pour les hacher dans un sens et ils ne doivent certainement jamais laisser de mémoire (même pour ne pas passer entre des câbles), leur existence dans la mémoire permanente est donc un non-non.
• Une liste de tous les changements de mot de passe des six derniers mois, toujours en texte clair
  • Voir "le stockage permanent est un non-non".
• Une liste de "tous les fichiers ajoutés au serveur à partir d'appareils distants" au cours des six derniers mois
  • Cela permet peut-être de 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 pouvez les transmettre. Si vous n'avez pas les journaux, vérifiez ce que disent les stratégies de sécurité pertinentes sur la journalisation de ces informations.
• Les clés publiques et privées de toutes les clés SSH
  • Peut-être qu'une tentative visant à vérifier que «les clés SSH doivent avoir une phrase secrète» se trouve dans la politique et est suivie. Vous voulez des phrases de passe sur toutes les clés privées.
• Un email lui est envoyé chaque fois qu'un utilisateur change son 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, étayé par des documents de politique de conformité PCI, SOX_compliance et de sécurité interne selon les besoins.

Ce gars demande des poireaux au paradis, et je conviens que toute correspondance d'ici devrait passer par la CTO. Soit il essaie de faire de vous l’automne parce qu’il n’est pas en mesure de répondre à cette demande, de divulguer des informations confidentielles, ou il est manifestement incompétent. Espérons que votre CTO / manager fera une double prise en compte de cette requête et que des actions positives seront entreprises, et s’ils sont gung ho derrière les actions de ce gars ... eh bien, les bons administrateurs système sont toujours en demande sur les petites annonces, comme Cela semble être le moment de commencer à chercher un endroit si cela se produit.

Je lui dirais qu'il faut du temps, des efforts et de l'argent pour créer l'infrastructure de craquage des mots de passe, mais étant donné que vous utilisez un hachage puissant 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 qui que ce soit. PCI DSS est également une bonne idée de mentionner comme vous l'avez fait. :)

Mes collègues sont choqués en lisant ce post.

Je serais fortement tenté de lui donner une liste de noms d’utilisateur / mots de passe / clés privées pour les comptes honeypot, puis s’il teste les identifiants de connexion pour ces comptes, faites-le pour un accès non autorisé à un système informatique. Malheureusement, cela vous expose probablement au moins à une sorte de responsabilité civile pour avoir fait une déclaration frauduleuse.

Déclinez simplement de révéler les informations, en déclarant que vous ne pouvez pas transmettre les mots de passe car vous n'y avez pas accès. En ma qualité d'auditeur, il doit représenter une institution. Ces institutions publient généralement des lignes directrices pour un tel audit. Voir si une telle demande est conforme à ces directives. Vous pouvez même vous plaindre auprès de telles associations. Indiquez également clairement au vérificateur qu'en cas d'actes répréhensibles, le blâme peut lui revenir (le vérificateur) car il dispose de tous les mots de passe.

Je dirais qu'il est impossible pour vous de lui fournir AUCUNE des informations demandées.

• Les noms d'utilisateur lui fournissent un aperçu des comptes qui ont accès à vos systèmes, un risque de 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 voie d’attaque possible 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 pouvant être utilisées dans le cadre d'une attaque contre vos systèmes, tout en leur donnant un aperçu de la structure de votre système de fichiers.
• Clés publiques et privées, à quoi servirait-il si vous les donniez à quelqu'un d'autre que l'utilisateur prévu?
• Un courriel 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 contacter son directeur ou un autre auditeur de la société pour confirmer ses demandes scandaleuses. Et éloignez-vous dès que possible.

Problème résolu à présent, mais pour le bénéfice des futurs lecteurs ...

Étant donné que:

• Vous semblez avoir passé plus d'une heure à ce sujet.

• Vous avez dû consulter le conseiller juridique de la société.

• Ils demandent beaucoup de travail après avoir modifié votre contrat.

• Vous aurez plus d'argent et plus de temps pour basculer.

Vous devriez 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 à une personne qu’elle n’était soudainement plus dans le besoin.

Vous pouvez toujours les facturer pour toute perte subie lors du basculement et pour le temps écoulé, car ils ont modifié votre contrat. Je ne dis pas qu'ils paieront dans les deux semaines, comme ils pensaient que vous vous y conformeriez - ils ne seraient que unilatéraux, je n'en doute pas.

Cela les agitera si le bureau de votre avocat envoie la notification de recouvrement. Cela devrait attirer l'attention du propriétaire de la société de l'auditeur.

Je déconseillerais toute autre transaction avec eux, le simple fait de discuter plus avant entraînerait 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 dérape - si ce n'est pas un test de sécurité ou de renseignement, c'est certainement un test de votre patience.