Política de conta de administradores de domínio (após auditoria de PCI)

Question

Um dos nossos clientes é uma empresa PCI de nível 1 e os seus auditores fizeram uma sugestão relativamente a nós como administradores do sistema e aos 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  

• Em que WS é a conta que faz logon somente em WorkStations, é um Administrador local em WorkStations
• Onde SRV é a conta que faz logon somente em servidores nã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

Há políticas para impedir o logon do tipo errado de sistema da conta errada (isso inclui a remoção do logon interativo para contas de administrador de domínio em computadores que não sejam da DC)

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

Isto parece não ser apenas uma política muito intrusiva para as nossas 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 (este é o meu entendimento, talvez eu entenda mal a viabilidade de esta façanha).

Estou interessado em ouvir as opiniões de outros administradores, especialmente aqueles aqui que estiveram envolvidos em uma empresa registrada no PCI e você tem experiências com recomendações semelhantes. Quais são suas políticas relacionadas a 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 elevamos também quando precisamos dos direitos adicionais. Com toda honestidade, somos todos um pouco preguiçosos e muitas vezes apenas usamos a conta do Administrador do Domínio para operações do dia a dia, embora isso seja tecnicamente contra as políticas da nossa empresa (tenho certeza que você entende!).

    

Answer 1

Estou em um fornecedor de PCI da Camada 1. Temos algo assim, com algumas diferenças.

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

Agora, é mais eficaz comprometer um sistema usando um hash de uma senha ou um token existente. Simplificando, seu 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 são agora o vetor de ataque de facto .

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

Se uma conta for comprometida devido a um ataque pass-the-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 de senha pode surgir em uma incursão, pois o hash do invasor começaria a falhar. No entanto, com cartões inteligentes, a senha é 'gerenciada pelo sistema' (o usuário nunca insere a senha para autenticar), portanto, o hash nunca é alterado. 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 ativadas por cartão inteligente, que muitas empresas de grande porte usam para contas altamente privilegiadas, altere a senha da conta em um intervalo frequente. Isso muda o hash. Você também pode alterar o hash por un-smartcard habilitando a conta, em seguida, re-smartcard permitindo isto. A Microsoft faz isso a cada 24 horas, mas você precisa avaliar o o impacto potencial que isso pode causar em seu ambiente e estabelecer programação sã para que você não crie problemas adicionais.

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

  Essa abordagem funciona para nós devido temos um mecanismo formal para gerenciar e impor a senha para as contas locais e que a senha é única em cada sistema, e que existe um método seguro para alguém solicitar o senha. Existem também 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, então sim, um conta de domínio separada deve ser usada para acesso administrativo a estações de trabalho, e essa conta não deve ser usada para fins administrativos. acesso a servidores. Outra opção pode ser usar suporte remoto não interativo ferramentas de gerenciamento que usam o LocalSystem para executar atividades e mecanismo de autenticação separado do Windows.

• Para as contas com privilégios mais altos (Enterprise Admin, Domain Admin, etc), use apenas um servidor de salto. Este servidor seria sujeitos à segurança mais restritiva, controle de alterações e auditoria. Para todos os outros tipos de funções administrativas, considere ter uma conta administrativa separada. O servidor de salto deve ser reinicializado diariamente para limpar os tokens de processo do processo LSA.

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

• Considere a possibilidade de redefinir facilmente as VMs como suas caixas de salto, que podem ser redefinir para limpar a memória após cada sessão.

Leitura adicional:

link

Relatório de Inteligência de Segurança da Microsoft, Volume 13, janeiro a junho de 2012 link

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

Derrote os temidos ataques "pass-the-hash"
link