Traduzido e adaptado de “Security baseline (DRAFT) for Windows 10 v1903 and Windows Server v1903“.

Não há dúvidas de que o estado da segurança de senha é problemático e tem sido há muito tempo. Geralmente as pessoas escolhem suas próprias senhas, que muitas vezes são fáceis de adivinhar ou prever.

Durante a criação de suas senhas, elas são designadas ou forçadas a criar senhas que são difíceis de lembrar, muitas vezes elas anotam onde outras pessoas podem ver.

Pessoas são forçadas a mudarem suas senhas, muitas vezes fazendo uma pequena e previsível alteração em suas senhas existentes e /ou esquecem suas novas senhas. Quando as senhas ou seus hashes correspondentes são roubados, pode ser difícil, na melhor das hipóteses, detectar ou restringir seu uso não autorizado.

No último dia 24 de abril, a Microsoft anunciou o lançamento preliminar das configurações da baseline de configuração de segurança para o Windows 10 versão 1903 (também conhecida como “19H1”) e para o Windows Server versão 1903.

Esta nova atualização de recursos do Windows traz poucas novas configurações de diretiva de grupo, que listamos na documentação que acompanha. O esboço da baseline recomenda configurar apenas dois deles. No entanto, várias alterações foram feitas nas configurações existentes e outras ainda estão por vir. Por isso, deve-se revisar as alterações cuidadosamente.

As alterações das baselines do Windows 10 v1809 e Windows Server 2019 incluem:

• Habilitando a nova diretiva “Habilitar opções de atenuação do svchost.exe”, que impõe segurança mais rígida aos serviços do Windows hospedados no svchost.exe, incluindo que todos os binários carregados pelo svchost.exe devem ser assinados pela Microsoft e que o código gerado dinamicamente não é permitido;
• Ao definir a nova configuração de Privacidade do aplicativo, “Permitir que os aplicativos do Windows sejam ativados com voz enquanto o sistema está bloqueado”, para que os usuários não possam interagir com os aplicativos usando a fala enquanto o sistema estiver bloqueado;
• Desabilitando a resolução de nomes de difusão seletiva (LLMNR) para atenuar as ameaças de falsificação de servidor;
• Restringir o NodeType NetBT ao nó P, impedindo o uso de broadcast para registrar ou resolver nomes, também para atenuar as ameaças de falsificação de servidor;
• Corrigindo um descuido na linha de base do Controlador de Domínio adicionando configurações de auditoria recomendadas para o serviço de autenticação Kerberos;
• Eliminar as políticas de expiração de senha que exigem alterações periódicas de senha. Essa alteração é discutida em mais detalhes abaixo;
• Eliminando o método de criptografia de unidade de BitLocker específico e as configurações de força de codificação;
• Descartando o File Explorer “Desativar Prevenção de Execução de Dados para o Explorer” e “Desativar o encerramento da pilha em configurações de corrupção”.

Além disso, embora não tenha sido alterado o rascunho da baseline neste momento, ainda está sendo considerado descartar a imposição do comportamento padrão de desabilitar as contas integradas Administrador e Convidado.

Dropping das políticas de expiração de senha.

Pesquisas científicas recentes questionam o valor de muitas práticas antigas de segurança de senhas, como políticas de expiração de senhas, e apontam alternativas melhores, como a imposição de listas de senhas proibidas e vários fatores de autenticação.

Isso reforça um ponto importante mais importante sobre as baselines : embora sejam uma base sólida e devam fazer parte de sua estratégia de segurança, elas não são uma estratégia de segurança completa. Nesse caso específico, o pequeno conjunto de antigas políticas de senha aplicáveis por meio dos modelos de segurança do Windows não é e não pode ser uma estratégia de segurança completa para o gerenciamento de credenciais do usuário.

Por que estamos removendo as políticas de expiração de senha?

Em primeiro lugar, para tentar evitar mal-entendidos inevitáveis, estamos falando aqui apenas sobre a remoção de políticas de expiração de senha – não estamos propondo a alteração dos requisitos de comprimento, histórico ou complexidade mínimos da senha.

De acordo com a Microsoft, a expiração periódica de senha é uma defesa somente contra a probabilidade de uma senha (ou hash) ser roubada durante seu intervalo de validade e ser usada por uma entidade não autorizada. Se uma senha nunca for roubada, não há necessidade de expirá-la. E se você tiver provas de que uma senha foi roubada, presumivelmente você agiria imediatamente, em vez de esperar pela expiração para corrigir o problema.

Para você, leitor do blog, caso uma senha seja roubada, quantos dias é um período de tempo aceitável para continuar permitindo que o cibercriminoso use sua senha roubada?  O padrão estabelecido no Windows é de 42 dias.  Do seu ponto de vista, isso não parece um tempo muito longo ?

Atualmente, a baseline da Microsoft atual recomenda 60 dias, antigamente, costumava dizer 90 dias. Isso demonstra que forçar a expiração frequente apresenta seus próprios problemas.  Além disso, não existe política de expiração de senha, se seus usuários são do tipo que estão dispostos a responder pesquisas no estacionamento que trocam uma barra de chocolate por suas senhas, nenhuma política de expiração de senha irá ajudá-lo.

As baselines da Microsoft se destinam a ser utilizáveis com modificações mínimas, se houver, pela maioria das empresas bem gerenciadas e preocupadas com a segurança. Eles também se destinam a servir como orientação para os auditores. Os resultados das verificações de conformidade da baseline devem ser utilizados como parâmetros para alterações ou respostas a incidentes.

A empresa global ainda reforça que a expiração periódica de senha é uma mitigação antiga e obsoleta de valor muito baixo, e não acreditamos que valha a pena para nossa linha de base impor qualquer valor específico. Ao removê-la da baseline, em vez de recomendar um valor específico ou nenhuma expiração, as organizações podem escolher o que melhor atende às suas necessidades percebidas, sem contradizer nossa orientação.