Convergência de ITDR, PAM e IGA. Qual dos três está presente quando o ataque chega?

Mas como o trabalho é dividido? Gestão de Acesso Privilegiado e Governança de Identidade e Administração lidam com a prevenção: elas decidem quem detém privilégio e quando é permitido usá-lo. O trabalho de Detecção e Resposta de Ameaça de Identidade é diferente. Ela observa e diz quando algo já deu errado. Combine os três em um console e abaixo dele, você ainda tem três trabalhos separados.

Descobrimos onde essa divisão se quebra pagando estranhos para nos atacarem.

O que os atacantes reais conseguiram

Executamos um programa de recompensa por bug gerenciado através do Bugcrowd contra um Active Directory moderadamente endurecido. Os ataques foram apresentados por pessoas pagas por resultados, em vez de completar uma lista de verificação. DCSync, despejo de processo LSASS e bypass de acesso NTDS.dit estavam entre eles. Descobrimos que 100% dos ataques realizados por usuários padrão e contas de administrador de TI foram detectados e prevenidos.

Mas nos casos em que um hacker começou com credenciais válidas de admin de domínio, os ataques tiveram sucesso, porque as solicitações provenientes dessa conta eram as solicitações que um admin de domínio faz. Esse caso pertence a PAM. Descobrir quais contas detêm poder oculto em primeiro lugar pertence a IGA.

A aposta de retrocesso nem sempre compensa

Paramos tudo naquela lista enquanto ainda estava sendo tentado, não depois do fato. Essa distinção importa mais do que parece. Um ataque interrompido no meio da tentativa nunca se torna um incidente que alguém precisa investigar; nunca faz com que o nome da sua empresa apareça em manchetes de violação.

Parte disso pode ser desfeita: restaurar uma associação de grupo, redefinir uma senha, remover uma delegação e você está mais ou menos de volta ao ponto de partida.

Mas com alguns ataques para de funcionar. Considere Certificate Services por exemplo. Um modelo que permite ao solicitante fornecer seu próprio nome alternativo do assunto emitirá um certificado nomeando o solicitante como alguém mais. Inscreva-se, nomeie uma conta privilegiada e saia com uma credencial que se autentica como tal.

Nenhuma das correções habituais toca nisso. Redefina a senha e o certificado continua funcionando. Corrija o modelo e você apenas parou o próximo atacante, não aquele que já está segurando uma credencial válida. Reverta o diretório e você ainda não tocou nela, porque o privilégio nunca esteve no diretório. Está sentado em um repositório de certificados, válido até expirar ou até que alguém revogue esse certificado específico manualmente.

Nesse ponto, um alerta apenas diz onde começar a procurar. Bloquear o registro é a única coisa que o encerra de forma confiável.

Onde cada peça deve fazer seu trabalho

PAM, IGA e ITDR importam apenas em um momento específico em um ataque. Se ninguém nunca sinalizou uma conta como privilegiada, é responsabilidade de IGA. Se uma credencial permanente já existia para essa conta, PAM era a única coisa que poderia ter parado o que veio a seguir. Se o comprometimento passou por ambos e começou a agir como um atacante, ITDR foi a última chance de pegá-lo antes de se mover mais adiante.

Como Netwrix ajuda

Netwrix PingCastle e 1Secure avaliam a posição de segurança de identidade, mapeiam descobertas para MITRE ATT&CK e as classificam por risco, então a remediação começa com o que realmente prejudicaria. No nível do protocolo, a prevenção de ameaça patenteada bloqueia leituras NTDS.dit, despejos LSASS e solicitações de replicação não autorizadas diretamente no controlador de domínio, antes que tenham sucesso. Netwrix Threat Manager detecta e responde a ameaças que não podem ser bloqueadas. E quando algo consegue passar, a recuperação automática de floresta AD e reversão granular em AD, Entra ID e Okta trazem as coisas de volta, até o objeto específico que foi alterado.

Se você deseja vê-lo contra seu próprio diretório, podemos arranjar. Entre em contato conosco para uma demonstração.