Um auditor de segurança para nossos servidores exigiu o seguinte em duas semanas:

• Uma lista de nomes de usuário atuais e senhas em texto sem formatação para todas as contas de usuário em todos os servidores
• Uma lista de todas as alterações de senha dos últimos seis meses, novamente em texto sem formatação
• Uma lista de "todos os arquivos adicionados ao servidor a partir de dispositivos remotos" nos últimos seis meses
• As chaves públicas e privadas de qualquer chave SSH
• Um e-mail enviado a ele sempre que um usuário altera sua senha, contendo a senha em texto sem formatação

Estamos executando as caixas Red Hat Linux 5/6 e CentOS 5 com autenticação LDAP.

Tanto quanto sei, tudo nessa lista é impossível ou incrivelmente difícil de obter, mas se eu não fornecer essas informações, enfrentaremos a perda de acesso à nossa plataforma de pagamentos e a perda de receita durante um período de transição, à medida que avançamos para um novo serviço. Alguma sugestão de como resolver ou falsificar essas informações?

A única maneira de pensar em obter todas as senhas de texto sem formatação é fazer com que todos redefinam sua senha e tomem nota do que a definiram. Isso não resolve o problema dos últimos seis meses de alterações de senha, porque não consigo registrar retroativamente esse tipo de coisa, o mesmo vale para registrar todos os arquivos remotos.

É possível obter todas as chaves SSH públicas e privadas (embora irritante), pois temos apenas alguns usuários e computadores. A menos que eu tenha perdido uma maneira mais fácil de fazer isso?

Já expliquei muitas vezes que as coisas que ele pede são impossíveis. Em resposta às minhas preocupações, ele respondeu com o seguinte email:

Tenho mais de 10 anos de experiência em auditoria de segurança e um entendimento completo dos métodos de segurança redhat, por isso sugiro que você verifique seus fatos sobre o que é e o que não é possível. Você diz que nenhuma empresa poderia ter essas informações, mas realizei centenas de auditorias onde essas informações estavam prontamente disponíveis. Todos os clientes do [fornecedor de processamento genérico de cartão de crédito] devem estar em conformidade com nossas novas políticas de segurança e esta auditoria visa garantir que essas políticas foram implementadas * corretamente.

* As "novas políticas de segurança" foram introduzidas duas semanas antes da nossa auditoria e o registro histórico de seis meses não era necessário antes da alteração da política.

Em suma, eu preciso;

• Uma maneira de "falsificar" seis meses de alterações de senha e torná-la válida
• Uma maneira de "falsificar" seis meses de transferências de arquivos de entrada
• Uma maneira fácil de coletar todas as chaves públicas e privadas SSH que estão sendo usadas

Se falharmos na auditoria de segurança, perderemos o acesso à nossa plataforma de processamento de cartões (uma parte crítica do nosso sistema) e levaria duas semanas para mudar para outro lugar. Estou ferrado?

Atualização 1 (sáb 23rd)

Obrigado por todas as suas respostas, é um grande alívio saber que essa não é uma prática padrão.

Atualmente, estou planejando minha resposta por e-mail para ele, explicando a situação. Como muitos de vocês apontaram, precisamos cumprir o PCI, que afirma explicitamente que não devemos ter nenhuma maneira de acessar senhas em texto sem formatação. Vou postar o email quando terminar de escrevê-lo. Infelizmente, não acho que ele esteja apenas nos testando; essas coisas estão na política de segurança oficial da empresa agora. No entanto, coloquei as rodas em movimento para afastá-las e entrar no PayPal por enquanto.

Atualização 2 (sábado, 23)

Este é o e-mail que rascunhei, alguma sugestão para adicionar / remover / alterar?

Olá [nome],

Infelizmente, não há como fornecer algumas das informações solicitadas, principalmente senhas em texto sem formatação, histórico de senhas, chaves SSH e logs de arquivos remotos. Essas coisas não são apenas tecnicamente impossíveis, mas também a possibilidade de fornecer essas informações seria uma violação aos padrões da PCI e uma violação do ato de proteção de dados.
Para citar os requisitos do PCI,

8.4 Tornar todas as senhas ilegíveis durante a transmissão e o armazenamento em todos os componentes do sistema usando criptografia forte.

Posso fornecer uma lista de nomes de usuário e senhas com hash usados ​​em nosso sistema, cópias das chaves públicas SSH e arquivo de hosts autorizados (Isso fornecerá informações suficientes para determinar o número de usuários únicos que podem se conectar aos nossos servidores e a criptografia métodos usados), informações sobre nossos requisitos de segurança de senha e nosso servidor LDAP, mas essas informações não podem ser retiradas do site. Eu sugiro fortemente que você revise seus requisitos de auditoria, pois atualmente não há como passarmos nessa auditoria enquanto permanecemos em conformidade com o PCI e a Lei de proteção de dados.

Atenciosamente,
[eu]

Estarei no CCO da empresa e em nosso gerente de contas, e espero que o CTO possa confirmar que essas informações não estão disponíveis. Também entrarei em contato com o PCI Security Standards Council para explicar o que ele está exigindo de nós.

Atualização 3 (26º)

Aqui estão alguns e-mails que trocamos;

RE: meu primeiro email;

Conforme explicado, essas informações devem estar facilmente disponíveis em qualquer sistema bem mantido para qualquer administrador competente. Sua falha em poder fornecer essas informações me leva a acreditar que você está ciente das falhas de segurança em seu sistema e não está preparado para revelá-las. Nossos pedidos estão alinhados com as diretrizes do PCI e ambos podem ser atendidos. Criptografia forte significa apenas que as senhas devem ser criptografadas enquanto o usuário as insere, mas devem ser movidas para um formato recuperável para uso posterior.

Não vejo problemas de proteção de dados para essas solicitações; a proteção de dados se aplica apenas a consumidores e não a empresas, portanto, não deve haver problemas com essas informações.

Apenas o que eu não posso nem ...

"Criptografia forte significa apenas que as senhas devem ser criptografadas enquanto o usuário as insere, mas devem ser movidas para um formato recuperável para uso posterior".

Vou enquadrar isso e colocá-lo na minha parede.

Eu me cansei de ser diplomático e o direcionei a esse tópico para mostrar a resposta que recebi:

O fornecimento dessas informações contradiz DIRETAMENTE vários requisitos das diretrizes da PCI. A seção que citei até diz storage (implicando onde armazenamos os dados no disco). Comecei uma discussão no ServerFault.com (uma comunidade on-line para profissionais de administração de sistemas) que criou uma resposta enorme, tudo sugerindo que essas informações não podem ser fornecidas. Sinta-se livre para ler você mesmo

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

Concluímos a mudança do sistema para uma nova plataforma e cancelaremos nossa conta com você dentro de um dia ou mais, mas quero que você perceba o quão ridículas são essas solicitações, e nenhuma empresa que implemente corretamente as diretrizes da PCI irá, ou deve, poder fornecer essas informações. Eu sugiro fortemente que você repense seus requisitos de segurança, pois nenhum de seus clientes deve estar em conformidade com isso.

(Na verdade, eu tinha esquecido que o chamei de idiota no título, mas, como mencionado, já tínhamos nos afastado da plataforma deles, sem perda real.)

E em sua resposta, ele afirma que aparentemente nenhum de vocês sabe do que está falando:

Li em detalhes essas respostas e sua postagem original. Todos os respondentes precisam entender seus fatos. Estou neste setor há mais tempo do que qualquer pessoa nesse site. Obter uma lista de senhas de contas de usuário é incrivelmente básica. Essa deve ser uma das primeiras coisas que você faz ao aprender a proteger seu sistema e é essencial para a operação de qualquer segurança. servidor. Se você realmente não possui as habilidades necessárias para fazer algo tão simples, vou assumir que você não possui PCI instalado em seus servidores, pois a capacidade de recuperar essas informações é um requisito básico do software. Ao lidar com algo como segurança, você não deve fazer essas perguntas em um fórum público se não tiver conhecimento básico de como funciona.

Eu também gostaria de sugerir que qualquer tentativa de me revelar, ou [nome da empresa] será considerada difamatória e medidas legais apropriadas serão tomadas

Principais pontos idiotas se você os perdeu:

• Ele é um auditor de segurança há mais tempo do que qualquer pessoa aqui (ele está adivinhando ou perseguindo você)
• Conseguir obter uma lista de senhas em um sistema UNIX é 'básico'
• PCI agora é software
• As pessoas não devem usar fóruns quando não têm certeza da segurança
• Colocar online informações factuais (para as quais tenho prova de e-mail) é difamatório

Excelente.

O PCI SSC respondeu e está investigando ele e a empresa. Nosso software agora mudou para o PayPal, então sabemos que é seguro. Vou esperar que o PCI volte primeiro, mas estou um pouco preocupado que eles possam estar usando essas práticas de segurança internamente. Nesse caso, acho que é uma grande preocupação para nós, pois todo o processamento do nosso cartão passou por eles. Se eles estivessem fazendo isso internamente, acho que a única coisa responsável a fazer seria informar nossos clientes.

Espero que, quando o PCI perceber o quão ruim é, eles investigarão toda a empresa e o sistema, mas não tenho certeza.

Então, agora que nos afastamos da plataforma deles, e assumindo que levará pelo menos alguns dias para o PCI voltar para mim, alguma sugestão inventiva de como trollá-lo um pouco? =)

Depois de obter autorização do meu legal (duvido muito que isso seja realmente difamatório, mas eu queria checar novamente) publicarei o nome da empresa, o nome e o e-mail dele, e se desejar, você pode entrar em contato com ele e explicar por que você não entende os conceitos básicos de segurança do Linux, como obter uma lista de todas as senhas de usuários LDAP.

Pequena atualização:

Meu "sujeito legal" sugeriu que revelar a empresa provavelmente causaria mais problemas do que o necessário. Posso dizer, porém, que este não é um provedor importante, eles têm menos de 100 clientes usando este serviço. Originalmente, começamos a usá-los quando o site era pequeno e rodava com um pouco de VPS e não queríamos fazer todo o esforço para obter PCI (costumávamos redirecionar para o front-end, como o PayPal Standard). Mas quando passamos para o processamento direto de placas (incluindo a obtenção de PCI e bom senso), os desenvolvedores decidiram continuar usando a mesma empresa apenas com uma API diferente. A empresa está sediada na área de Birmingham, Reino Unido, por isso duvido que alguém aqui seja afetado.

Primeiro, NÃO capitule. Ele não é apenas um idiota, mas perigosamente errado. De fato, liberar essas informações violaria o padrão PCI (que é o que eu suponho que seja a auditoria, pois é um processador de pagamento), juntamente com todos os outros padrões existentes no mercado e apenas o senso comum. Também exporia sua empresa a todos os tipos de responsabilidades.

A próxima coisa a fazer é enviar um e-mail ao seu chefe, dizendo que ele precisa envolver um advogado corporativo para determinar a exposição legal que a empresa enfrentaria se prosseguir com essa ação.

A decisão é sua, mas eu entraria em contato com a VISA com essas informações e obteria o status de auditor do PCI.

Como alguém que passou pelo procedimento de auditoria da Price Waterhouse Coopers para um contrato secreto com o governo, posso garantir que isso está totalmente fora de questão e esse cara é louco.

Quando a PwC quis verificar a força da senha, eles:

• Solicitado a ver nossos algoritmos de força de senha
• Executou unidades de teste em nossos algoritmos para verificar se negariam senhas ruins
• Pediu para ver nossos algoritmos de criptografia para garantir que eles não pudessem ser revertidos ou descriptografados (mesmo pelas tabelas arco-íris), mesmo por alguém que tivesse acesso total a todos os aspectos do sistema
• Verificado para ver se as senhas anteriores foram armazenadas em cache para garantir que não pudessem ser reutilizadas
• Nos pediu permissão (que concedemos) para que tentassem invadir a rede e os sistemas relacionados usando técnicas de engenharia não-social (coisas como xss e explorações de dia não zero)

Se eu tivesse sugerido que poderia mostrar a eles quais eram as senhas dos usuários nos últimos 6 meses, elas teriam nos excluído do contrato imediatamente.

Se fosse possível fornecer esses requisitos, você falharia instantaneamente em cada auditoria que vale a pena ter.

Atualização: seu email de resposta parece ser bom. Muito mais profissional do que qualquer coisa que eu teria escrito.

Honestamente, parece que esse cara (o auditor) está configurando você. Se você der a ele as informações que ele está pedindo, você acabou de provar a ele que pode ser socialmente projetado para fornecer informações internas críticas. Falhou.

Acabei de descobrir que você está no Reino Unido, o que significa que o que ele está pedindo para você é violar a lei (na verdade, a Lei de Proteção de Dados). Também estou no Reino Unido, trabalho para uma grande empresa fortemente auditada e conheço as leis e práticas comuns nessa área. Eu também sou um trabalho muito desagradável que alegremente reprimirá esse cara por você, se você gosta apenas por diversão, deixe-me saber se você gostaria de ajudar, ok.

Você está sendo projetado socialmente. Ou é para 'testar você' ou é um hacker que se apresenta como auditor para obter alguns dados muito úteis.

Estou seriamente preocupado com a falta de habilidades de resolução de problemas éticos dos OPs e a comunidade de falhas do servidor ignorando essa violação flagrante da conduta ética.

Em suma, eu preciso;

• Uma maneira de 'falsificar' seis meses de alterações de senha e torná-la válida
• Uma maneira de 'falsificar' seis meses de transferências de arquivos de entrada

Deixe-me esclarecer dois pontos:

1. Nunca é apropriado falsificar dados durante o curso normal dos negócios.
2. Você nunca deve divulgar esse tipo de informação a ninguém. Sempre.

Não é seu trabalho falsificar registros. É seu trabalho garantir que todos os registros necessários estejam disponíveis, precisos e seguros.

A comunidade aqui na Server Fault deve tratar esses tipos de perguntas, pois o site stackoverflow trata as questões de "trabalhos de casa". Você não pode resolver esses problemas apenas com uma resposta técnica ou ignorar a violação da responsabilidade ética.

Ver tantos usuários de alta reputação responde aqui neste tópico e nenhuma menção às implicações éticas da pergunta me entristece.

Gostaria de incentivar todos a ler o Código de Ética dos Administradores do Sistema SAGE .

BTW, seu auditor de segurança é um idiota, mas isso não significa que você precise sentir pressão para ser antiético em seu trabalho.

Editar: suas atualizações não têm preço. Mantenha a cabeça baixa, o pó seco e não tome (ou dê) níquel de madeira.

Você não pode dar a ele o que deseja, e as tentativas de "fingir" provavelmente voltarão para morder sua bunda (possivelmente de maneiras legais). Você precisa apelar para a cadeia de comando (é possível que esse auditor tenha se tornado nocivo, embora as auditorias de segurança sejam notoriamente idiotas - pergunte-me sobre o auditor que desejava poder acessar um AS / 400 via SMB) ou vá direto ao assunto. sob esses requisitos onorosos.

Eles nem são uma boa segurança - uma lista de todas as senhas de texto sem formatação é uma coisa incrivelmente perigosa a ser produzida, independentemente dos métodos usados ​​para protegê-las, e aposto que esse cara vai querer que sejam enviadas por e-mail em texto sem formatação . (Tenho certeza que você já sabe disso, só preciso desabafar um pouco).

Para merdas e risadinhas, pergunte a ele diretamente como executar seus requisitos - admita que você não sabe como e gostaria de aproveitar sua experiência. Quando você estiver fora, a resposta "Eu tenho mais de 10 anos de experiência em auditoria de segurança" seria "não, você tem 5 minutos de experiência repetidos centenas de vezes".

Nenhum auditor deve falhar se encontrar um problema histórico que você já corrigiu. De fato, isso é evidência de bom comportamento. Com isso em mente, sugiro duas coisas:

a) Não minta ou invente coisas. b) Leia suas políticas.

A declaração chave para mim é esta:

Todos os clientes do [provedor genérico de processamento de cartão de crédito] devem estar em conformidade com nossas novas políticas de segurança

Aposto que há uma declaração nessas políticas dizendo que as senhas não podem ser anotadas e não podem ser passadas a ninguém que não seja o usuário. Se houver, aplique essas políticas aos pedidos dele. Eu sugiro lidar com isso assim:

• Uma lista de nomes de usuário atuais e senhas em texto sem formatação para todas as contas de usuário em todos os servidores

Mostre a ele uma lista de nomes de usuários, mas não permita que eles sejam removidos. Explique que fornecer senhas em texto sem formatação é a) impossível, só de ida; eb) contra a política, contra a qual ele está auditando você; portanto, você não obedecerá.

• Uma lista de todas as alterações de senha dos últimos seis meses, novamente em texto sem formatação

Explique que isso não estava disponível historicamente. Dê a ele uma lista dos horários recentes de alteração de senha para mostrar que isso está sendo feito agora. Explique, como acima, que senhas não serão fornecidas.

• Uma lista de "todos os arquivos adicionados ao servidor a partir de dispositivos remotos" nos últimos seis meses

Explique o que está e não está sendo registrado. Forneça o que puder. Não forneça nada confidencial e explique pela política por que não. Pergunte se seu registro precisa ser aprimorado.

• As chaves públicas e privadas de qualquer chave SSH

Veja sua política de gerenciamento de chaves. Ele deve indicar que as chaves privadas não são permitidas em seu contêiner e têm condições estritas de acesso. Aplique essa política e não permita o acesso. As chaves públicas são públicas e podem ser compartilhadas.

• Um e-mail enviado a ele sempre que um usuário altera sua senha, contendo a senha em texto sem formatação

Apenas diga não. Se você tiver um servidor de log seguro local, permita que ele veja que isso está sendo registrado in situ.

Basicamente, lamento dizer isso, mas você precisa jogar duro com esse cara. Siga sua política exatamente, não se desvie. Não minta. E se ele falhar com você por qualquer coisa que não esteja na política, reclame com os idosos da empresa que o enviou. Colete uma trilha de papel de tudo isso para provar que você tem sido razoável. Se você violar sua política, estará à mercê dele. Se você os seguir à risca, ele acabará sendo demitido.

Sim, o auditor é um idiota. No entanto, como você sabe, às vezes os idiotas são colocados em posições de poder. Este é um daqueles casos.

As informações que ele solicitou têm influência nula na segurança atual do sistema. Explique ao auditor que você está usando LDAP para autenticação e que as senhas são armazenadas usando um hash unidirecional. Antes de executar um script de força bruta contra os hashes de senha (que podem levar semanas (ou anos)), você não poderá fornecer as senhas.

Da mesma forma que os arquivos remotos - eu gostaria de ouvir, por acaso, como ele acha que você deve diferenciar entre os arquivos criados diretamente no servidor e um arquivo com SCP para o servidor.

Como o @womble disse, não finja nada. Isso não fará bem. Abandone essa auditoria e multe outro corretor, ou encontre uma maneira de convencer esse "profissional" de que seu queijo escorregou do biscoito.

Peça ao seu "auditor de segurança" que aponte para qualquer texto de qualquer um desses documentos que tenha os requisitos dele e observe como ele se esforça para encontrar uma desculpa e, eventualmente, se desculpa para nunca mais ser ouvido.

WTF! Desculpe, mas essa é minha única reação a isso. Não há requisitos de auditoria que eu já tenha ouvido falar que exijam uma senha em texto sem formatação, muito menos alimentando as senhas à medida que elas mudam.

Primeiro, peça a ele que lhe mostre o requisito que você fornece.

Segundo, se for para o PCI (que todos assumimos por se tratar de uma questão do sistema de pagamento), acesse aqui: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php e obtenha um novo auditor.

Terceiro, siga o que eles disseram acima, entre em contato com sua gerência e solicite que eles entrem em contato com a empresa de QSA com a qual ele está trabalhando. Em seguida, chame imediatamente outro auditor.

Os auditores auditam estados, padrões, processos etc. do sistema. Eles não precisam ter nenhuma informação que lhes forneça acesso aos sistemas.

Se você quiser auditores recomendados ou colos alternativos que trabalhem em estreita colaboração com os auditores, entre em contato comigo e teremos prazer em fornecer referências.

Boa sorte! Confie no seu intestino, se algo parece errado, provavelmente é.

Não há motivo legítimo para ele saber a senha e ter acesso às chaves privadas. O que ele solicitou daria a ele a capacidade de se passar por qualquer um de seus clientes a qualquer momento e desviar o dinheiro que ele quisesse, sem nenhuma maneira de detectá-lo como uma possível transação fraudulenta. Será exatamente o tipo de ameaça à segurança pela qual ele deveria auditar você.

Notifique o gerenciamento que o Auditor solicitou que você elabore suas políticas de segurança e que a solicitação é ilegal. Sugira que eles possam despejar a empresa de auditoria atual e encontrar uma legítima. Ligue para a polícia e entregue o auditor para solicitar informações ilegais (no Reino Unido). Em seguida, ligue para o PCI e entregue o Auditor para sua solicitação.

O pedido é semelhante a pedir para você matar alguém aleatoriamente e entregar o corpo. Você faria isso? ou você chamaria a polícia e os entregaria?

Responder com uma ação judicial . Se um auditor está solicitando senhas em texto sem formatação (vamos agora, não é tão difícil forçar ou quebrar hashes de senhas fracos), eles provavelmente mentiram para você sobre suas credenciais.

Apenas uma dica sobre como você expressa sua resposta:

Infelizmente, não há como fornecer algumas das informações solicitadas, principalmente senhas em texto sem formatação, histórico de senhas, chaves SSH e logs de arquivos remotos. Essas coisas não são apenas tecnicamente impossíveis ...

Eu reformularia isso para evitar entrar em uma discussão sobre viabilidade técnica. Lendo o terrível e-mail inicial enviado pelo auditor, parece que alguém pode escolher detalhes que não estão relacionados ao problema principal e ele pode argumentar que você pode salvar senhas, logins etc. Então, diga :

... Devido às nossas rígidas políticas de segurança, nunca registramos senhas em texto simples. Portanto, será tecnicamente impossível fornecer esses dados.

Ou

... Não apenas reduziríamos significativamente nosso nível de segurança interna, atendendo a sua solicitação, ...

Boa sorte e mantenha-nos informados sobre como isso acaba!

Correndo o risco de continuar a corrida de usuários de alta reputação que pulam nessa questão, aqui estão meus pensamentos.

Eu posso ver vagamente por que ele quer as senhas em texto simples, e isso é para julgar a qualidade das senhas em uso. É uma maneira péssima de fazer isso, a maioria dos auditores que conheço aceitará os hashes criptografados e executará um cracker para ver que tipo de fruta mais baixa eles podem retirar. Todos eles revisarão a política de complexidade de senhas e revisarão quais são as salvaguardas para impor isso.

Mas você precisa entregar algumas senhas. Eu sugiro (embora eu ache que você já tenha feito isso) perguntar a ele qual é o objetivo da entrega de senha em texto sem formatação. Ele disse que é para validar sua conformidade versus a política de segurança, então peça a ele que lhe dê essa política. Pergunte a ele se ele aceitará que o seu regime de complexidade de senha é robusto o suficiente para impedir que os usuários definam sua senha P@55w0rde estejam comprovadamente em vigor há 6 meses em questão.

Se ele insistir, talvez seja necessário admitir que não é possível entregar senhas em texto sem formatação, pois você não está configurado para gravá-las (o que faz com que haja uma grande falha de segurança), mas pode se esforçar para fazê-lo no futuro, se ele exigir verificação direta de que suas políticas de senha estão funcionando. E se ele quiser provar, você terá todo o prazer em fornecer o banco de dados de senhas criptografadas para ele (ou você! Mostre-se disposto! Ajuda!) Para executar uma passagem de cracking.

Os "arquivos remotos" provavelmente podem ser retirados dos logs SSH para sessões SFTP, e é sobre isso que suspeito que ele esteja falando. Se você não tiver 6 meses de syslogging, isso será difícil de produzir. O uso do wget para extrair um arquivo de um servidor remoto enquanto estiver conectado via SSH é considerado uma 'transferência remota de arquivo'? HTTP PUTs são? Arquivos criados a partir do texto da área de transferência na janela do terminal do usuário remoto? De qualquer forma, você pode incomodá-lo com esses casos extremos para ter uma idéia melhor de suas preocupações nessa área e talvez instilar o sentimento "eu sei mais sobre isso do que você", bem como quais tecnologias específicas ele está pensando. Em seguida, extraia o que puder dos logs e logs arquivados nos backups.

Não tenho nada nas chaves SSH. A única coisa em que consigo pensar é que ele está procurando chaves sem senha por algum motivo, e talvez com força de criptografia. Caso contrário, eu não tenho nada.

Quanto à obtenção dessas chaves, é fácil coletar pelo menos as chaves públicas; basta vasculhar as pastas .ssh procurando por elas. A obtenção das chaves privadas envolverá vestir seu chapéu BOFH e atacar seus usuários com a seguinte sintonia: "Envie-me seus pares de chaves SSH públicos e privados. Qualquer coisa que eu não conseguir será removida dos servidores em 13 dias" e se alguém grasnar (eu o apontaria) na auditoria de segurança. O script é seu amigo aqui. No mínimo, fará com que vários pares de chaves sem senha obtenham senhas.

Se ele ainda insistir em "senhas de texto sem formatação no email", pelo menos submeta esses emails à criptografia GPG / PGP com sua própria chave. Qualquer auditor de segurança que se preze deve ser capaz de lidar com algo assim. Dessa forma, se as senhas vazarem, será porque ele as soltou, não você. Mais um teste decisivo para a competência.

Eu tenho que concordar com Zypher e Womble neste. Idiota perigoso com consequências perigosas.

Ele provavelmente está testando você para ver se você é um risco de segurança. Se você fornecer esses detalhes a ele, provavelmente será imediatamente demitido. Leve isso para o seu chefe imediato e passe o dinheiro. Informe o seu chefe que você envolverá as autoridades relevantes se essa bunda chegar perto de você novamente.

É por isso que os chefes são pagos.

Tenho uma visão de um pedaço de papel deixado na parte de trás de um táxi que contém uma lista de senhas, chaves SSH e nomes de usuário! Hhhmmm! Pode ver as manchetes dos jornais agora mesmo!

Atualizar

Em resposta aos 2 comentários abaixo, acho que vocês dois têm bons pontos a fazer. Não há como realmente descobrir a verdade, e o fato de a pergunta ter sido postada mostra um pouco de ingenuidade por parte do pôster, além de coragem para enfrentar uma situação adversa com possíveis conseqüências na carreira, onde outros colocariam a cabeça na cabeça. areia e fugir.

Minha conclusão sobre o que vale é que este é um debate completamente interessante que provavelmente levou a maioria dos leitores a se perguntar o que fariam nessa situação, independentemente de as políticas do auditor ou dos auditores serem ou não competentes. A maioria das pessoas enfrentará esse tipo de dilema de alguma forma em sua vida profissional e esse realmente não é o tipo de responsabilidade que deve ser colocada nos ombros de uma única pessoa. É uma decisão comercial, e não individual, sobre como lidar com isso.

Claramente, há muitas informações boas aqui, mas permita-me adicionar o meu 2c, como alguém que escreve software vendido mundialmente pelo meu empregador em grandes empresas, principalmente para ajudar as pessoas a cumprir as políticas de segurança de gerenciamento de contas e passar nas auditorias; por quanto isso vale.

Primeiro, isso parece muito suspeito, como você (e outros) notaram. O auditor está apenas seguindo um procedimento que ele não entende (possível) ou testando sua vulnerabilidade para engenharia social (improvável após trocas de acompanhamento) ou uma fraude para engenharia social (também possível) ou apenas um idiota genérico (provavelmente provavelmente). No que diz respeito aos conselhos, sugiro que você fale com sua gerência e / ou encontre uma nova empresa de auditoria, e / ou informe essa empresa à agência de supervisão apropriada.

Quanto às notas, algumas coisas:

• É possível (sob condições específicas) fornecer as informações solicitadas, se o seu sistema estiver configurado para permitir isso. No entanto, não é, em nenhum sentido, uma "melhor prática" para segurança, nem seria de todo comum.
• Geralmente, as auditorias estão preocupadas com a validação de práticas, sem examinar as informações seguras reais. Eu suspeitaria de alguém que solicitasse senhas ou certificados de texto simples, em vez dos métodos usados ​​para garantir que eles sejam "bons" e protegidos adequadamente.

Espero que ajude, mesmo se estiver reiterando o que outras pessoas aconselharam. Como você, não vou nomear minha empresa, no meu caso, porque não estou falando por eles (conta pessoal / opiniões e tudo); desculpas se isso prejudica a credibilidade, mas que seja. Boa sorte.

Isso pode e deve ser postado no IT Security - Stack Exchange .

Não sou especialista em auditoria de segurança, mas a primeira coisa que aprendi sobre política de segurança é "NEVER GIVE PASSWORDS AWAY". Esse cara talvez esteja nesse ramo há 10 anos, mas como Womble disse"no, you have 5 minutes of experience repeated hundreds of times"

Eu trabalho com pessoas de TI do setor bancário há algum tempo e, quando eu vi você postar, mostrei a elas ... Eles estavam rindo muito. Eles me disseram que esse cara parece uma farsa. Eles costumavam lidar com esse tipo de coisa pela segurança do cliente do banco.

Pedir uma senha clara, chaves SSH, registros de senhas é claramente uma falta profissional grave. Esse cara é perigoso.

Espero que esteja tudo bem agora e que você não tenha nenhum problema com o fato de que eles possam manter o registro da transação anterior com eles.

Se você pode fornecer qualquer uma das informações (com a possível exceção das chaves públicas) solicitadas nos pontos 1, 2, 4 e 5, você deve esperar falhar na auditoria.

Responda formalmente aos pontos 1,2 e 5 dizendo que você não pode cumprir, pois sua política de segurança exige que você não mantenha senhas de texto sem formatação e que as senhas sejam criptografadas usando um algoritmo não reversível. Para apontar 4, novamente, você não pode fornecer as chaves privadas, pois isso violaria sua política de segurança.

Quanto ao ponto 3. Se você tiver os dados, forneça-os. Caso contrário, porque não foi necessário coletá-lo, diga-o e demonstre como você está agora (trabalhando para) atender ao novo requisito.

Um auditor de segurança para nossos servidores exigiu o seguinte em duas semanas :

...

Se falharmos na auditoria de segurança, perderemos o acesso à nossa plataforma de processamento de cartões (uma parte crítica do nosso sistema) e levaria duas semanas para mudar para outro lugar . Como eu estou ferrado?

Parece que você respondeu sua própria pergunta. (Veja o texto em negrito para obter dicas.)

Apenas uma solução vem à mente: peça a todos que anotem sua senha atual e a última e depois alterem-na imediatamente para uma nova. Se ele deseja testar a qualidade da senha (e a qualidade das transições de senha para senha, por exemplo, para garantir que ninguém use rfvujn125 e rfvujn126 como sua próxima senha), essa lista de senhas antigas deve ser suficiente.

Se isso não for considerado aceitável, eu suspeitaria que o cara é membro do Anonymous / LulzSec ... nesse momento, você deve perguntar qual é o seu identificador e pedir que ele pare de ser tão desleixado!

Como disse oli: a pessoa em questão está tentando fazer com que você viole a lei (proteção de dados / diretivas de confidencialidade da UE) / regulamentos internos / padrões do PCI. Não apenas você deve notificar a gerência (como você já pensava), mas também pode chamar a polícia, conforme sugerido.

Se a pessoa em questão possuir algum tipo de credenciamento / certificação, por exemplo, CISA (Certified Information Systems Auditor) ou o equivalente britânico do US CPA (designação de contador público), você também poderá informar as organizações credenciadoras para investigá-la. Essa pessoa não apenas está tentando convencê-lo a violar a lei, mas também é uma "auditoria" extremamente incompetente e provavelmente contraria todos os padrões éticos de auditoria pelos quais os auditores credenciados devem respeitar a dor da perda do credenciamento.

Além disso, se a pessoa em questão é membro de uma empresa maior, as organizações de auditoria mencionadas frequentemente exigem algum tipo de departamento de controle de qualidade que supervisiona a qualidade das auditorias e dos registros de auditoria e investiga as reclamações. Portanto, você também pode reclamar com a empresa de auditoria em questão.

Ainda estou estudando e a primeira coisa que aprendi ao configurar servidores é que, se você possibilitar o registro de senhas em texto sem formatação, você já estará ameaçado por uma violação gigantesca. Nenhuma senha deve ser conhecida, exceto para o usuário que a emprega.

Se esse cara é um auditor sério, ele não deveria estar lhe perguntando essas coisas. Para mim, ele meio que parece um desastre . Eu verificaria com o órgão regulador porque esse cara parece um completo idiota.

Atualizar

Espere, ele acredita que você deve usar uma criptografia simétrica apenas para transmitir a senha, mas depois armazená-las em texto sem formatação no banco de dados ou fornecer uma maneira de descriptografá-las. Então, basicamente, depois de todos os ataques anônimos aos bancos de dados, onde eles mostravam senhas de usuário em texto sem formatação, ele AINDA acredita que essa é uma boa maneira de "proteger" um ambiente.

Ele é um dinossauro preso na década de 1960 ...

• Uma lista de nomes de usuário atuais e senhas em texto sem formatação para todas as contas de usuário em todos os servidores
  • Os nomes de usuário atuais PODEM estar dentro do escopo de "podemos liberar isso" e devem estar dentro do escopo de "podemos mostrar isso a você, mas você não pode retirá-lo do local".
  • As senhas em texto sem formatação não devem existir por mais tempo do que o hash unidirecional e certamente nunca devem deixar memória (nem mesmo para passar por fios); portanto, sua existência no armazenamento permanente é um não-não.
• Uma lista de todas as alterações de senha dos últimos seis meses, novamente em texto sem formatação
  • Consulte "armazenamento permanente é um não-não".
• Uma lista de "todos os arquivos adicionados ao servidor a partir de dispositivos remotos" nos últimos seis meses
  • Isso pode ser para garantir que você registre as transferências de arquivos de / para o (s) servidor (es) de processamento de pagamentos, se você tiver os logs, deve ser bom passar adiante. Se você não possui os logs, verifique o que dizem as políticas de segurança relevantes sobre o registro dessas informações.
• As chaves públicas e privadas de qualquer chave SSH
  • Talvez uma tentativa de verificar se 'Chaves SSH devem ter uma frase secreta' esteja na política e seja seguida. Você deseja senhas em todas as chaves privadas.
• Um e-mail enviado a ele sempre que um usuário altera sua senha, contendo a senha em texto sem formatação
  • Definitivamente, este é um não-não.

Eu responderia com algo como minhas respostas, com o suporte de conformidade com PCI, SOX_compliance e documentos de política de segurança interna, conforme necessário.

Esses caras pedem fedorentos, e eu concordo que qualquer correspondência daqui em diante deve passar pelo CTO. Ou ele está tentando fazer de você o cara da queda por não conseguir atender a essa solicitação, liberar informações confidenciais ou ser totalmente incompetente. Esperamos que o seu CTO / gerente faça uma análise dupla dessa solicitação de pessoal e que sejam tomadas ações positivas, e se eles estão entusiasmados por trás das ações desse indivíduo ... bem, bons administradores de sistema sempre estão em demanda nos classificados, como Parece que é hora de começar a procurar algum lugar, se isso acontecer.

Eu diria a ele que é preciso tempo, esforço e dinheiro para criar a infraestrutura de cracking para as senhas, mas como você usa um hash forte como o SHA256 ou qualquer outra coisa, talvez não seja possível fornecer as senhas dentro de duas semanas. Além disso, eu diria que entrei em contato com o departamento jurídico para confirmar se é legal compartilhar esses dados com alguém. O PCI DSS também é uma boa idéia para mencionar como você fez. :)

Meus colegas estão chocados ao ler este post.

Eu ficaria fortemente tentado a fornecer a ele uma lista de nomes de usuário / senhas / chaves privadas para contas de honeypot, se ele testar os logins dessas contas, faça-o para obter acesso não autorizado a um sistema de computador. Porém, infelizmente isso provavelmente expõe você a, no mínimo, algum tipo de delito civil por fazer uma representação fraudulenta.

Simplesmente recuse a revelação das informações, afirmando que você não pode passar as senhas porque não tem acesso a elas. Sendo um auditor, ele deve estar representando alguma instituição. Tais instituições geralmente publicam diretrizes para essa auditoria. Veja se esse pedido está em conformidade com essas diretrizes. Você pode até reclamar com essas associações. Também deixe claro ao auditor que, em caso de erros, a culpa pode voltar para ele (o auditor), pois ele possui todas as senhas.

Eu diria que não há como você fornecer QUALQUER das informações solicitadas.

• Os nomes de usuário fornecem uma visão geral das contas que têm acesso aos seus sistemas, um risco à segurança
• O histórico de senhas forneceria uma visão dos padrões de senhas usados, dando a ele uma possível via de ataque, adivinhando a próxima senha na cadeia
• Os arquivos transferidos para o sistema podem conter informações confidenciais que podem ser usadas em um ataque contra seus sistemas, além de fornecer informações sobre a estrutura do sistema de arquivos
• Chaves públicas e privadas, qual seria o sentido de tê-las se você as desse a alguém que não seja o usuário pretendido?
• Um email enviado toda vez que um usuário altera uma senha fornece a ele senhas atualizadas para cada conta de usuário.

Esse cara está puxando seu companheiro! Você precisa entrar em contato com o gerente dele ou com outro auditor da empresa para confirmar suas demandas ultrajantes. E afaste-se o mais rápido possível.

Problema resolvido até agora, mas para o benefício de futuros leitores ...

Considerando que:

• Você parece ter passado mais de uma hora nisso.

• Você teve que consultar o advogado da empresa.

• Eles estão pedindo muito trabalho depois de alterar seu acordo.

• Você estará sem dinheiro e mais tempo mudando.

Você deve explicar que precisará de muito dinheiro com antecedência e há um mínimo de quatro horas.

Nas últimas vezes eu disse a alguém que de repente não era tão carente.

Você ainda pode cobrá-los por qualquer perda incorrida durante a transição e pelo tempo gasto, pois eles mudaram seu contrato. Não estou dizendo que eles pagarão dentro de duas semanas, por mais que eles pensassem que você cumpriria nesse período - eles serão unilaterais, não tenho dúvida.

Irá agitar-los se o escritório do seu advogado enviar o aviso de cobrança. Deve atrair a atenção do proprietário da empresa do auditor.

Eu desaconselharia quaisquer outras negociações com eles, apenas para discutir melhor o assunto implicará um depósito pelo trabalho necessário. Então você pode ser pago por denunciá-los.

É estranho que você tenha um acordo em vigor e alguém do outro lado saia do caminho - se não é um teste de segurança ou inteligência, é certamente um teste de sua paciência.