Não há nada mais difícil de se encontrar na web do que um bom artigo que traga as principais práticas de política de auditoria para Windows Server. Sempre que precisei de algo relacionado era uma luta para encontrar um bom artigo e quando encontrava tinha que pegar informações de vários blogs até chegar em uma conclusão. Como o meu intuito sempre foi facilitar a vida dos meus leitores e sempre trazer bons conteúdos em português, criei este artigo para servir como um guia – e, claro, não teria como não compartilhar com a comunidade.

Essas recomendações devem ser apenas um guia de linha de base inicial para os administradores. Cada organização deve tomar as suas próprias decisões sobre as ameaças que enfrentam, suas tolerâncias de risco aceitáveis e quais categorias ou subcategorias de diretiva de auditoria para Windows Server eles devem habilitar.

Políticas de auditoria recomendadas por sistema operacional

Esta seção contém tabelas que listam as recomendações de configuração de auditoria para Windows Server ou não, que se aplicam aos seguintes sistemas operacionais:

• Windows Server 2016
• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2008
• Windows 10
• Windows 8.1
• Windows 7

Essas tabelas contêm a configuração padrão do Windows, as recomendações de linha de base e as recomendações mais fortes para esses sistemas operacionais.

Legenda das tabelas de política de auditoria para Windows Server

Recomendações de configurações de auditoria do Windows 10, do Windows 8 e do Windows 7.

¹ a partir do Windows 10 versão 1809, o logon de auditoria é habilitado por padrão para êxito e falha. Nas versões anteriores do Windows, apenas êxito é habilitado por padrão.

Recomendações de configurações de auditoria para Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 e Windows Server 2008.

Definir política de auditoria em estações de trabalho e servidores

Todos os planos de gerenciamento de log de eventos devem monitorar estações de trabalho e servidores. Um erro comum é monitorar apenas os servidores ou controladores de domínio.

Eventos a Monitorar

Uma ID de evento perfeita para gerar um alerta de segurança deve conter os seguintes atributos:

• Alta probabilidade de que a ocorrência indique atividade não autorizada;
• Número baixo de falsos positivos;
• A ocorrência deve resultar em uma resposta investigativa/forense.

Dois tipos de eventos devem ser monitorados e alertados:

• Esses eventos em que mesmo uma única ocorrência indica atividade não autorizada;
• Um acúmulo de eventos acima de uma linha de base esperada e aceita.

Um exemplo do primeiro evento é:

Se os administradores de domínio (DAs) forem proibidos de fazer logon em computadores que não são controladores de domínio, uma única ocorrência de um membro que faz logon em uma estação de trabalho do usuário final deverá gerar um alerta e ser investigado. Esse tipo de alerta é fácil de gerar usando o evento de logon especial de auditoria 4964 (grupos especiais foram atribuídos a um novo logon). Outros exemplos de alertas de instância única incluem:

• Se o servidor A nunca deve se conectar ao servidor B, alertar quando eles se conectarem entre si;
• Alertar se uma conta de usuário final normal for adicionada inesperadamente a um grupo de segurança confidencial;
• Se os funcionários na localização de fábrica A nunca funcionarem à noite, alerte quando um usuário fizer logon à meia-noite;
• Alertar se um serviço não autorizado estiver instalado em um controlador de domínio;
• Investigue se um usuário final regular tenta fazer logon diretamente em um SQL Server para o qual não há motivo claro para isso;
• Se você não tiver membros em seu grupo de DA, e alguém se adicionar, verifique-o imediatamente.

Um exemplo do segundo evento é:

Um número Aberrant de logons com falha pode indicar um ataque de adivinhação de senha. Para que uma empresa forneça um alerta para um número excepcionalmente alto de logons com falha, eles devem primeiro compreender os níveis normais de logons com falha em seu ambiente antes de um evento de segurança mal-intencionado.

Active Directory objetos e atributos a serem monitorados

A seguir estão as contas, os grupos e os atributos que você deve monitorar para ajudá-lo a detectar tentativas de comprometer sua instalação de Active Directory Domain Services.

• Sistemas para desabilitar ou remover software antivírus e antimalware (reiniciar automaticamente a proteção quando ele é desabilitado manualmente);
• Contas de administrador para alterações não autorizadas;
• Atividades executadas usando contas com privilégios (remover automaticamente a conta quando atividades suspeitas forem concluídas ou o tempo alocado tiver expirado);
• Contas com privilégios de VIP no AD DS. Monitore alterações, especialmente alterações em atributos na guia conta (por exemplo CN, nome, sAMAccountName, userPrincipalName ou userAccountControl). Além de monitorar as contas, restrinja quem pode modificar as contas para o menor conjunto de usuários administrativos possível;
• Agrupe os servidores pela classificação de suas cargas de trabalho, o que permite identificar rapidamente os servidores que devem ser mais bem monitorados e mais rigorosamente configurados;
• Alterações nas propriedades e Associação dos seguintes grupos de AD DS: administradores corporativos (EA), administradores de domínio (DA), administradores (BA) e administradores de esquema (SA);
• Contas com privilégios desabilitadas (como contas de administrador internas no Active Directory e em sistemas Membros) para habilitar as contas;
• Contas de gerenciamento para registrar em log todas as gravações na conta;
• Assistente de configuração de segurança interna para configurar o serviço, o registro, a auditoria e as configurações de firewall para reduzir a superfície de ataque do servidor. Use este assistente se você implementar servidores de salto como parte da sua estratégia de host administrativo.

Lista geral de recomendação de ID de evento de segurança

Todas as recomendações de ID de evento são acompanhadas por uma classificação de criticalidade da seguinte maneira:

Alta: as IDs de evento com uma classificação de criticalidade alta devem ser sempre e imediatamente alertados e investigados.

Médio: uma ID de evento com uma classificação de criticalidade média pode indicar atividades mal-intencionadas, mas deve ser acompanhada por alguma outra anormalidade (por exemplo, um número incomum ocorrendo em um período de tempo específico, ocorrências inesperadas ou ocorrências em um computador que normalmente não seria esperado para registrar o evento). Um evento de criticalidade médio também pode ser coletado como uma métrica e comparado ao longo do tempo.

Baixo: a ID do evento com poucos eventos de criticalidade não devem obter atenção ou causar alertas, a menos que correlacionem-se com eventos de criticalidade médios ou altos.

Essas recomendações de auditoria para Windows Server destinam-se a fornecer um guia de linha de base para o administrador. Todas as recomendações devem ser examinadas minuciosamente antes da implementação em um ambiente de produção.