Diretiva de conta de administradores de domínio (após auditoria do PCI)

Um de nossos clientes é uma empresa PCI de nível 1 e seus auditores fizeram uma sugestão em relação a nós como administradores do sistema e nossos direitos de acesso.

Administramos sua infraestrutura totalmente baseada em Windows de aproximadamente 700 desktops / 80 servidores / 10 controladores de domínio.

Eles estão sugerindo que passemos para um sistema em que temos três contas separadas:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Onde WS é a conta que faz logon apenas nas estações de trabalho, é um administrador local nas estações de trabalho
• Onde SRV é a conta que faz logon apenas em servidores que não são DC, é Administrador local em servidores
• Onde DC é a conta que faz logon apenas em Controladores de Domínio, efetivamente uma conta de administrador de domínio

As políticas estão em vigor para impedir o logon no tipo errado de sistema da conta errada (que inclui a remoção do logon interativo para contas de administrador de domínio em máquinas que não sejam DC)

Isso evita a situação em que uma estação de trabalho comprometida pode expor um token de logon de Administradores de Domínio e reutilizá-lo no Controlador de Domínio.

Isso parece não apenas ser uma política muito intrusiva para as operações do dia a dia, mas também uma quantidade considerável de trabalho, para abordar o que é um ataque / exploração relativamente improvável (esse é meu entendimento de qualquer maneira, talvez eu entenda mal a viabilidade dessa exploração) .

Estou interessado em ouvir outros pontos de vista de administradores, especialmente aqueles que estiveram envolvidos em uma empresa registrada na PCI e você experimenta recomendações semelhantes. Quais são as suas políticas em relação aos logons de administrador.

Para o registro, atualmente temos uma conta de Usuário de Domínio que usamos normalmente, com uma conta de Administrador de Domínio que também elevamos quando precisamos de direitos adicionais. Com toda a honestidade, somos um pouco preguiçosos e geralmente usamos a conta de Administrador de Domínio para operações do dia a dia, embora isso seja tecnicamente contrário às políticas da empresa (tenho certeza de que você entende!).

Estou em um fornecedor de PCI de nível 1. Temos algo assim, com algumas diferenças.

Os auditores estão realmente tentando descrever um problema muito real, mas estão fazendo um trabalho incrivelmente ruim, explicando as implicações e as análises de necessidades.

Agora é mais eficaz comprometer um sistema usando um hash de uma senha ou um token existente. Em outras palavras, o invasor não precisa mais do seu nome de usuário e senha. Agora existem maneiras mais fáceis de atacar um sistema. Sob nenhuma circunstância você deve assumir ou concluir que esse tipo de ataque é improvável. Os ataques de hash agora são o vetor de ataque defacto .

Os ataques de hash são realmente piores nas contas de cartões inteligentes, o que é irônico, porque a maioria das pessoas espera que a implementação de cartões inteligentes aumente a segurança de um sistema.

Se uma conta for comprometida devido a um ataque de hash, a resposta usual é alterar a senha da conta. Isso altera o hash usado para autenticar. Além disso, uma expiração / alteração normal da senha pode surgir uma incursão, pois o hash do atacante começaria a falhar. No entanto, com cartões inteligentes, a senha é 'gerenciada pelo sistema' (o usuário nunca digita a senha para autenticação), portanto, o hash nunca muda. Isso significa que, com contas de cartão inteligente, uma incursão pode passar despercebida por muito mais tempo do que com uma conta que usa uma senha.

Aqui estão as atenuações que eu consideraria:

• Para contas habilitadas para cartão inteligente, que muitas empresas grandes usam para contas altamente privilegiadas, altere a senha da conta em intervalos frequentes. Isso muda o hash. Você também pode alterar o hash desmarcando o cartão inteligente, habilitando a conta e, em seguida, remarcando o cartão inteligente. A Microsoft faz isso a cada 24 horas, mas você precisa avaliar o impacto potencial que isso pode causar em seu ambiente e estabelecer um cronograma sensato para não criar problemas adicionais.

• Para estações de trabalho, eu não usaria contas de domínio para fins de administração, se possível. Temos uma conta local que pode ser usada para elevar para operações do tipo UAC. Isso satisfaz 99,9% da maioria dos requisitos de elevação. As estações de trabalho tendem a ser vetores de ataque quentes, devido à falta de controle de alterações planejadas e à existência de Java JRE e Flash.

  Essa abordagem funciona para nós, porque temos um mecanismo formal para gerenciar e aplicar a senha para as contas locais e que a senha é exclusiva em cada sistema e que existe um método seguro para alguém solicitar a senha. Também existem aplicativos comerciais que podem executar esta função.

• Se você não puder fornecer uma solução de conta local para estações de trabalho, sim, uma conta de domínio separada deve ser usada para acesso administrativo às estações de trabalho e essa conta não deve ser usada para acesso administrativo aos servidores. Outra opção pode ser usar ferramentas de gerenciamento de suporte remoto e não interativo que usam o LocalSystem para executar atividades e um mecanismo de autenticação separado do Windows.

• Para as contas com privilégios mais altos (Admin da empresa, Admin do domínio etc.), use apenas um servidor de salto. Este servidor estaria sujeito à segurança, controle de alterações e auditoria mais restritivos. Para todos os outros tipos de funções de tipo administrativo, considere ter uma conta administrativa separada. O servidor de salto deve ser reiniciado diariamente para reiniciar os tokens do processo do processo LSA.

• Não execute tarefas administrativas da sua estação de trabalho. Use um servidor reforçado ou um servidor de salto.

• Considere o uso de redefinir VMs com facilidade como suas caixas de salto, que podem ser redefinidas para limpar a memória após cada sessão.

Leitura adicional:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Relatório de Inteligência de Segurança da Microsoft, 13 de janeiro a junho de 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Leia a seção: "Defesa contra ataques Pass-the-Hash".

Derrote os temidos ataques de passe a hash
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753