Gerenciando a ameaça
interna com a segurança
do Active Directory
A anatomia de uma ameaça interna e como proteger o Active Directory
contra ela
por Alvaro Vitta, consultor de segurança, Quest Software
Introdução
"Quer dizer que foi um trabalho interno?"
Desde a primeira história sobre crimes e sobre as pessoas que
tentam resolvê-los, sempre houve um momento em que alguém
encontrasse uma evidência e descobrisse que um indivíduo
de dentro da organização estava envolvido. Os personagens
trocam olhares preocupados e chocados e um deles diz "Quer
dizer que foi um trabalho interno?".
Infelizmente, perguntas e olhares como esses estão se tornando
uma característica padrão de investigações em quase todas as
violações de dados. Após descobrir que alguém acessou dados
de maneira ilegítima na rede, os gerentes de TI geralmente
acreditam (ou esperam, na verdade) que a ameaça tenha vindo
de fontes externas. Mas, como mostram as violações de dados
mais recentes e impactantes, um lapso na segurança interna,
acidental ou malicioso, geralmente torna o ataque possível,
mesmo que a empresa conte com uma segurança externa
eficiente.
Este artigo discute o Microsoft Active Directory (AD) como
sendo o principal alvo dos invasores devido à importância
que o software tem na autenticação e autorização de todos
os usuários. Os leitores verão como uma ameaça interna
típica pode acontecer e aprenderão as melhores práticas de
segurança do Active Directory que minimizam o risco desse tipo
de ameaça à disponibilidade, confidencialidade e integridade
do AD.
Ameaças internas e seu impacto nos negócios
Muitas empresas acreditam que as ameaças internas (nas quais
funcionários, ex-funcionários, funcionários terceirizados ou
usuários válidos obtêm acesso não autorizado a uma rede da
organização e aos recursos conectados a ela) podem causar
tanto dano quanto ataques iniciados externamente. A atenção 1
é focada em funcionários atuais e em ex-funcionários, mas
prestadores de serviço e parceiros de negócios desempenham
um papel crescente no que diz respeito a cometer e facilitar
crimes cibernéticos.
O custo financeiro da violação de dados realizada por um
ataque interno, incluindo o tempo e o dinheiro gastos para
restaurar a segurança dos sistemas, é considerável. Cerca
"Crime cibernético nos Estados Unidos: maiores riscos, menor prontidão – As principais
1
descobertas da Pesquisa sobre o estado do crime cibernético nos EUA em 2014” (em inglês)
PwC, Maio de 2014, http://www.pwc.com/en_US/us/increasing-it-effectiveness/publications/assets/
pwc-2014-us-state-of-cybercrime.pdf
 de 1/5 das empresas acreditam que o
custo ultrapassaria US$ 5 milhões, mas
mais da metade das empresas admite
abertamente que não tem ideia de
como estimar suas possíveis perdas
provenientes de um ataque interno.
Os cenários e as histórias acerca dos
ataques internos são os mesmos em
todos os crimes:
• Espionagem econômica internacional
• Conspirações bem-planejadas para
roubar segredos comerciais
• Ex-funcionários descontentes que
contam com privilégios de redes amplos
• Funcionários insatisfeitos que usam
as credenciais que um supervisor
compartilhou em confidência
Cerca de 95 milhões • Nome de usuário e senha do
representante de uma empresa
(ou um quinto) das fornecedora roubados em um ataque de
contas do AD estão phishing
• Usuários autorizados que encontram
sob ataque todos e copiam dados do cartão de crédito e,
depois, vendem no mercado negro
os dias.
O maior custo de uma violação de dados
cometida por agentes internos inclui
a perda de informações confidenciais,
danos à reputação e interrupção de
sistemas importantes. 3
Ameaças internas e Active Directory
Mais de 90% das maiores empresas do
mundo usam o AD, totalizando cerca de
500 milhões de usuários com contas
ativas.
Cerca de 95 milhões (ou um quinto)
dessas contas estão sob ataque todos
os dias. 4
As organizações usam o AD para
fornecer autenticação e autorização
para funcionários, prestadores de
serviços, parceiros e clientes. Por
meio do AD, elas também garantem
acesso a recursos de rede baseados
no Windows como compartilhamentos e
arquivos, bancos de dados, servidores
de e-mail, alguns aplicativos no local
e aplicativos baseados em cloud.
Sem o AD, elas perdem o Exchange,
"Ameaças internas e a necessidade de respostas rápidas e direcionadas,” (em inglês) SANS Institute, Abril de 2015,
2
https://www.sans.org/reading-room/whitepapers/analyst/insider-threats-fast-directed-response-35892
"Administrando ameaças internas," (em inglês) PwC, Fevereiro de 2015, http://www.pwc.com/en_US/us/increasing-it-effectiveness/
3
publications/assets/managing-insider-threats.pdf
John Fontana, "Czar do Active Directory reúne setor para melhor segurança e identidade" ZDNet, 9 de junho de 2015, http://
4
www.zdnet.com/article/active-directory-czar-rallies-industry-for-better-security-identity/
5
"Relatório de investigações de violação de dados de 2015” (em inglês), Verizon, Abril de 2015, https://msisac.cisecurity.org/
resources/reports/documents/rp_data-breach-investigation-report-2015_en_xg.pdf
Compartilhar:
2
colaborações, comunicações em tempo
real, SharePoint, bancos de dados
do SQL Server, servidores da web
e outros recursos indispensáveis ao
funcionamento de grande parte das
2
empresas.
Uma segurança externa robusta não
garante a segurança do AD, pois as
maiores ameaças à segurança do AD
são internas, e mais da metade do uso
indevido de informações confidenciais
envolve abuso de privilégios. Isso se 5
estende ao uso indevido ou acidental
de permissões do AD, contas elevadas
e grupos confidenciais que podem
enfraquecer protocolos de segurança e
permitir o acesso não autorizado a dados
sensíveis baseados no Windows.
O acesso não autorizado ao AD é como
ter um cartão de acesso roubado: uma
vez que os invasores estão dentro do
prédio, eles podem entrar no elevador,
perambular pelas salas, abrir mesas e
vasculhar as gavetas. Com tantas contas
sob ataques incessantes de fontes
internas e externas, as ameaças internas
ao AD são evidentes e muito presentes.
É difícil proteger o Active Directory?
O AD foi feito para ser seguro, mas assim
como na analogia do cartão de acesso,
a segurança é violada quando o acesso
elevado está nas mãos erradas.
Considere três áreas principais com as
quais os administradores de TI precisam
lidar:
Falta de automação
• Controles de acesso devem ser
continuamente avaliados e corrigidos,
mas não há processos automatizados
para isso no AD.
• A implementação e o teste contínuos de
processos de recuperação de desastres
completos protegeriam contra o tempo
de inatividade prolongado e a perda
de dados no AD, mas o AD não fornece
nativamente uma maneira automatizada
de testar e implementar um cenário
completo de recuperação de desastres
do AD em todos os controladores de
domínio (DCs).
 • Quando ações ou acesso não
autorizado ao AD são detectados,
não há como evitá-los ou remediá-
los automaticamente e também não
há como credenciais obsoletas se
autoapagarem.
• Sem controles de troca automatizados
e integrados no AD, as empresas estão
sujeitas ao acesso não autorizado e
acidental, assim como a interrupções
onerosas.
Fatores humanos/organizacionais/
comerciais
• Quando os funcionários são transferidos
entre unidades de negócios, a maior
parte das organizações usa processos
deficientes para integrá-los. Em vez disso,
os administradores deixam os usuários
com uma autoridade elevada, acumulada
de requisitos de trabalhos anteriores, que
eles não precisam mais.
• Os administradores do AD não podem
ser proibidos de acessar recursos
sensíveis do Windows.
• A fidelidade de dados e os padrões de
nomenclatura da empresa no AD são
difíceis de aplicar, o que faz com que
seja difícil categorizar o acesso, analisar
os direitos e fazer a auditoria de ativos.
• Por uma questão de confiança e
conveniência nos negócios, é comum
que os funcionários, prestadores
de serviço e parceiros de negócios
saibam e compartilhem entre si as suas
credenciais privilegiadas do AD.
Limitações do AD
• Falta de contexto de segurança atrasa a
detecção de violações de dados.
• O AD não permite que as organizações
implementem uma conta de usuário
com privilégio mínimo (least-privileged
user account ou LUA), o que faz com
que os usuários possuam mais privilégios
e mais acesso do que precisam para
realizar seu trabalho. Por exemplo, se
um administrador deseja atribuir ao
funcionário do Help Desk, JSmith, a
capacidade de mover os objetos de
usuário da Unidade Organizacional
(OU) de planejamento para a OU de
engenharia, o administrador teria que
conceder a JSmith o direito de excluir
qualquer objeto do usuário da OU
de planejamento e o direito de fazer
gravações à OU de planejamento.
Isso inclui consideravelmente mais
permissões do que JSmith precisa (e
que o administrador realmente gostaria
de conceder) para executar a ação e
aumenta significativamente a exposição
da organização ao risco.
3
Ferramentas tradicionais de
gerenciamento de eventos e
informações de segurança (SIEM) estão
sujeitas às limitações da auditoria
de registros nativos. Por exemplo, o
registro de auditoria nativo indica que
um Objeto da diretiva de grupo (GPO)
foi modificado, mas não registra quais
configurações foram alteradas ou os
seus valores antes e depois da alteração.
Por isso, proteger o AD é um ato de
equilíbrio constante entre conceder aos
usuários os direitos de que eles precisam
para fazer o seu trabalho e mantê-los,
inclusive os administradores de domínio,
fora de grupos de segurança que podem
acessar bancos de dados, pastas e
arquivos sensíveis que contêm registros
de saúde, informações de cartão de Proteger o AD é um
crédito ou recursos humanos.
ato de equilíbrio
Anatomia de uma ameaça interna
contra o Active Directory constante entre
Considere esta história fictícia que conceder aos usuários
descreve como uma ameaça interna
causada por controles de segurança os direitos de que eles
fracos podem afetar o AD. precisam para fazer o
À medida que o fim do suporte para
o Windows Server 2003 se aproxima, seu trabalho e mantê-
uma distribuidora de produtos médicos los fora de grupos de
chamada Acme faz um contrato de
quatro semanas com JSmith para que ele segurança que podem
ajude a atualizar o ambiente da empresa
para o Windows Server 2012. PBrown, o
acessar recursos
administrador do AD na Acme, adiciona sensíveis.
JSmith ao grupo de administradores de
domínio.
Na sexta-feira da segunda semana de
JSmith na empresa, a Acme encerra
o contrato, mas ninguém pede que
PBrown remova JSmith do grupo de
administradores. Na próxima segunda-
feira, PBrown descobre que JSmith não
está mais trabalhando para a Acme e o
remove do grupo de administradores.
As etapas a seguir descrevem o que
aconteceu no fim de semana.
1. Criação de uma conta falsa
Insatisfeito que a Acme encerrou o
seu contrato antecipadamente, JSmith
procura maneiras, incluindo ilícitas, de
compensar o dinheiro que ele estava
contando em receber. Por um amigo,
ele fica sabendo de um site do mercado
negro que ele pode ganhar dinheiro
rápido vendendo dados de cartão de
crédito.
Compartilhar:
 Em casa, JSmith entra na rede da
Acme usando as suas credenciais
administrativas e cria uma nova conta
de administrador. Para que a criação da
nova conta não chame atenção, ele a
nomeia como corpsvcbk1, seguindo a
convenção de nomenclatura da Acme
usada para as contas de serviço de
backup. Ele considera a possibilidade
de usar a conta corpsvcbk1 caso a Acme
remova ou redefina a senha da sua conta
de administrador original.
2. Obtenção de privilégios de
administrador de domínio
JSmith nota um grupo chamado
CorpOperations, que é membro do
Grupo de administradores de domínio.
Ele cria uma nova conta no grupo e a
Para que a criação nomeia como corpsvcbk1. Em seguida,
da nova conta não ele remove seus rastros adicionando-a
ao grupo aninhado CorpOperations,
chame atenção, ele que dá a ele privilégios indiretos de
Administrador de domínio sem levantar
segue a convenção suspeitas. (O sistema de monitoramento
de nomenclatura da genérico da Acme é configurado para
monitorar apenas alterações diretas ao
Acme usada para grupo de Administradores de domínio.)
contas de serviço 3. Acesso aos servidores de arquivos
de backup. JSmith localiza os SQL Servers e
servidores de arquivos em que a Acme
armazena os dados do cartão de crédito
e as informações de identificação
pessoal (PII).
Ele modifica o GPO que impede que
os administradores façam registro
em determinados bancos de dados e
servidores de arquivo e, em seguida,
faz o seu registro localmente no SQL1
e FSRV1. Ele adiciona a sua conta
corpsvcbk1 ao grupo de administradores
locais no SQL1 e atribui a ela a função
de administrador de sistemas no SQL
Server.
Vasculhando a rede, ele encontra um
banco de dados de cartão de crédito
descriptografado e exporta todos os
registros para o seu notebook usando
a conexão remota.
No FSRV1, ele localiza os arquivos que
contêm PII. Novamente, eliminando os
seus rastros, ele adiciona a sua conta
de administrador a um grupo aninhado
chamado FinanceOps, um membro do
grupo de administradores integrado
localizado no FSRV1. Na pasta Contas a
receber, ele encontra o arquivo Cliente_
PII.xlsx. Para acessar o arquivo, ele
Compartilhar:
4
adiciona a sua conta de administrador
ao grupo de Contas a receber; ele evita
que a sua conta seja exibida na lista de
controles de acesso, mas obtém todos
os direitos ao arquivo. Ele abre o arquivo,
verifica se é o que está procurando
e o copia para uma unidade de rede
mapeada em seu notebook.
4. Configuração de escuta não
autorizada
Em seguida, JSmith modifica uma
chave de registro que reduz o
LmCompatibilityLevel e a segurança da
sessão o bastante para que ele instale
um malware que secretamente furta
dados enquanto o SQL1 e FSRV1 fazem
a autenticação das credenciais. Isso
permite que, no futuro, ele decifre outras
credenciais quando os administradores
fizerem a autenticação para que,
mesmo que a Acme exclua a sua conta
falsa corpsvcbk1, ele possa continuar
roubando mais dados de cartões de
crédito.
5. Limpeza
JSmith remove a sua conta corpsvcbk1
dos grupos de administradores, limpa os
registros (para apagar as evidências do
seu ataque) e decide manter o malware
na rede para explorações futuras.
As políticas de segurança e os controles
de segurança da Acme são insuficientes
para evitar que esse ataque interno
contra o Active Directory ocorra. As
táticas de JSmith garantem que a Acme
levará bastante tempo para detectar
a violação de dados e, quando isso
acontecer, JSmith provavelmente já terá
recuperado a sua renda perdida e a
Acme estará nas vias de se recuperar da
violação de dados.
Melhores práticas de segurança do
Active Directory
Não existe uma abordagem que garanta
a segurança do Active Directory, mas
as organizações podem se proteger
contra ameaças internas ao AD ao seguir
várias diretrizes:
1. Definir datas de validade para contas e
grupos para casos de acesso temporário
a grupos sensíveis.
a. Em vez de fornecer uma associação
permanente a grupos sensíveis, usar
associações de grupo temporárias
com data/hora de início e data/hora
de término automáticas.
b. Configurar datas de validade de contas
ao criar contas para funcionários
temporários, como prestadores de
serviços, estagiários e visitantes.
2. Evitar a criação não autorizada de
contas ao definir uma lista branca
de credenciais autorizadas que têm
permissão para realizar a tarefa. Se
alguém que não estiver na lista de
aprovados criar uma conta de usuário, o
evento acionará um alerta de e-mail. Ele
também pode acionar uma correção que
desativa a conta do criador e/ou a conta
criada.
3. Monitorar em tempo real não apenas
as alterações diretas (por exemplo, que
podem ser rastreadas em registros
de segurança nativos) em grupos
empresariais privilegiados no AD, mas
também adições de membros aninhados
(por exemplo, associação indireta
a grupos do AD elevados), que os
servidores do Windows não registram.
4. Monitorar as alterações de associação
aninhada e direta dos seguintes grupos
empresariais:
Administradores, operadores de
impressão, operadores de configuração
de rede, administradores de DHCP,
operadores de backup, criadores
de confiança de floresta de entrada,
operadores de conta, editores de
certificados, proprietários criadores
de diretiva de grupo, administradores
de domínio, controladores de domínio,
administradores empresariais,
operadores de servidor, servidores RAS
e IAS, administradores de esquema.
5. Monitorar em tempo real as alterações
feitas às configurações de GPO no AD.
Os valores de antes e depois dessas
configurações não podem ser rastreados
nos registros nativos, apresentando uma
ameaça de backdoor ao AD.
6. Proibir que alterações não autorizadas
aconteçam a grupos empresariais
importantes e a configurações do GPO
usando uma lista branca de usuários
autorizados, independentemente
das permissões do usuário. Com a
lista branca, mesmo se os invasores
ganharem direitos de administradores
de credenciais comprometidas, as
alterações feitas às associações
em grupos privilegiados, como
Administradores de domínio e
Administradores empresariais, serão
5
negadas. A lista branca também
se aplica às alterações feitas às
configurações sensíveis do GPO,
como desativar ou negar acesso a
servidores importantes e enfraquecer
a autenticação NTLM.
7. Monitorar em tempo real atividades
suspeitas, como acesso a servidores
sensíveis após horário comercial normal
e alterações feitas a chaves de registro
sensíveis, como o LmCompatibilityLevel.
O último recurso é uma tática de backdoor
para diminuir os valores usados pelo
protocolo de autenticação NTLM.
8. Fazer a auditoria das alterações de
permissão e das atividades realizadas
em bancos de dados e servidores
de arquivos (incluindo arquivos,
compartilhamentos e pastas) que contêm
dados sensíveis.
9. Analisar continuamente os privilégios
e direitos de acesso dos usuários a
grupos e a servidores sensíveis. Analisar
as permissões do banco de dados
SQL Server e permissões NTFS em
servidores de arquivos SQL e AD.
10. Garantir a separação das
responsabilidades para evitar, por
exemplo, que prestadores de serviço
se tornem membros dos grupos de
Administradores de domínio. Usar
um modelo de acesso com menos
privilégios para o AD e Windows.
11. Implementar um processo automatizado
para desprovisionar usuários que
inclua desativar/excluir contas, remover
contas de todos os grupos e listas de
distribuição, remover acesso remoto VPN
e notificar o o RH e o Gerenciamento
de instalações e segurança
automaticamente.
A segurança do AD como parte da
estratégia geral de GRC
A segurança do Active Directory também
tem um papel importante na Governança,
Gerenciamento de risco e Conformidade
(do inglês Governance, Risk management
and Compliance, ou GRC).
A segurança do AD abrange a
capacidade da organização de provar
que ela possui os devidos controles do
AD e de todo ambiente do Windows,
incluindo SharePoint, Exchange e
SQL Server. Fornecer conformidade
Compartilhar:
significa conseguir fazer relatórios
de maneira eficiente em detalhes do
nível do AD, como informações sobre
usuários privilegiados atuais e antigos;
contas de ex-funcionários e prestadores
de serviços antigos; configurações,
atualização e status do patch de
servidores. A segurança eficiente do
AD é uma parte essencial do GRC e de
uma preparação cuidadosa para uma
auditoria.
Conclusão
A ameaça interna ao AD é real, comum
e onerosa. A predominância do AD em
empresas ao redor do mundo faz dele um
alvo atrativo aos adversários, que podem
explorar limitações técnicas e fatores
humanos para lançar violações de dados
de dentro para fora.
Monitorar os registros de eventos do
AD é um começo, mas muitas ameaças
internas se aproveitam dos eventos do
AD que não estão registrados. Além
disso, a lista de itens para verificar em
uma suspeita de ataque é longa e,
portanto, não há maneira automática de
se proteger.
Não importa se são acidentais ou
maliciosas, as ameaças internas
são sempre nocivas. Organizações
continuarão equilibrando a necessidade
de permitir que seus administradores
de sistema realizem tarefas com
certa autonomia com a necessidade
de conceder apenas os privilégios
necessários para essas tarefas.
Enquanto isso, as melhores práticas de
segurança do Active Directory são parte
fundamental da estratégia geral de GRC.
Sobre o autor
Alvaro Vitta é um consultor de segurança
especializado nas soluções de
segurança da Quest Software. Alvaro
avalia, projeta, testa e implanta soluções
de segurança para grandes empresas
do setor público e privado desde os
anos 2000 nas áreas de IAM, Segurança
de Active Directory e Controle, Risco
e Conformidade (GRC). Alvaro possui
certificações do setor que incluem CISSP,
CISSO, MCSE e ITIL.
SOBRE A QUEST
A Quest ajuda os clientes a reduzir as tarefas administrativas enfadonhas para que eles possam se dedicar à inovação necessária
para ampliar os negócios. As soluções Quest® são escaláveis, acessíveis e simples de usar, proporcionando eficiência e produtividade
sem comparação. Juntamente com o convite da Quest à comunidade global para fazer parte de sua inovação, assim como nosso firme
compromisso em garantir a satisfação dos clientes, a Quest continuará a acelerar o fornecimento das soluções mais abrangentes para
gerenciamento de cloud do Azure, SaaS, segurança, mobilidade da força de trabalho e insights conduzidos por dados.

© 2017 Quest Software Inc. TODOS OS DIREITOS RESERVADOS.

Este guia contém informações confidenciais protegidas por direitos autorais. O software descrito nesse guia é oferecido sob
uma licença de software ou um contrato de confidencialidade. Ele pode ser usado ou copiado apenas de acordo com os termos
do acordo aplicável. Nenhuma parte deste guia pode ser reproduzida ou transmitida em qualquer forma ou por qualquer meio,
eletrônico ou mecânico, inclusive fotocópia e gravação para qualquer propósito, sem a permissão por escrito da Quest Software Inc.

As informações deste documento são fornecidas em relação aos produtos da Quest Software. Este documento, isoladamente ou em
conjunto com a venda de produtos da Quest Software, não concede nenhuma licença, expressa ou implícita, por preclusão ou de
qualquer outra forma, a qualquer direito de propriedade intelectual. SALVO CONFORME DEFINIDO NOS TERMOS E CONDIÇÕES
DA QUEST SOFTWARE ESPECIFICADOS NOS CONTRATOS DE LICENÇA PARA ESTE PRODUTO, A QUEST SOFTWARE NÃO
ASSUME QUALQUER RESPONSABILIDADE E RENUNCIA A QUALQUER GARANTIA, EXPRESSA, IMPLÍCITA OU ESTATUTÁRIA,
RELACIONADA A SEUS PRODUTOS, INCLUINDO, ENTRE OUTROS, A GARANTIA IMPLÍCITA DE COMERCIALIZAÇÃO, ADEQUAÇÃO
A DETERMINADO PROPÓSITO OU NÃO VIOLAÇÃO. EM HIPÓTESE ALGUMA, A QUEST SOFTWARE SERÁ RESPONSÁVEL POR
QUALQUER DANO DIRETO, INDIRETO, CONSEQUENCIAL, PUNITIVO, ESPECIAL OU INCIDENTAL (INCLUINDO, SEM LIMITAÇÕES,
DANOS POR LUCROS CESSANTES, INTERRUPÇÃO DOS NEGÓCIOS OU PERDA DE INFORMAÇÕES) DECORRENTES DO USO
OU DA INCAPACIDADE DE USO DESTE DOCUMENTO, MESMO QUE A QUEST SOFTWARE TENHA SIDO ALERTADA SOBRE A
POSSIBILIDADE DE TAIS DANOS. A Quest Software não se responsabiliza por qualquer garantia ou declaração referente à exatidão
ou à integridade deste documento e reserva-se o direito de fazer alterações em especificações e descrições de produtos a qualquer
momento, sem aviso prévio. A Quest Software não se compromete em atualizar as informações contidas neste documento.

Patentes

A Quest Software tem orgulho de nossa tecnologia avançada. Este produto pode ter a aplicação de patentes e de patentes pendentes. Para
ver as informações mais recentes sobre as patentes aplicáveis a esse produto, visite nosso site em www.quest.com/legal.

Marcas comerciais

Quest e o logotipo Quest são marcas comerciais e marcas registradas da Quest Software Inc. Para conferir a lista completa de
marcas da Quest, acesse www.quest.com/legal/trademark-information.aspx. Todas as outras marcas comerciais pertencem a seus
respectivos proprietários.

Se você tiver dúvidas sobre o possível uso deste material, entre

em contato:
Quest Software Inc.
A/C: LEGAL Dept
4 Polaris Way
Aliso Viejo, CA 92656
Acesse nosso site (www.quest.com) para obter informações sobre
escritórios regionais ou internacionais.

Compartilhar:
6

Whitepaper-ManagingInsiderThreat-US-GM-pt_BR-WL-26698