Você está na página 1de 16

NOVE MELHORES PRÁTICAS PARA A SEGURANÇA DO ACTIVE DIRECTORY

A anatomia de uma ameaça interna e as melhores estratégias de defesa

PRÁTICAS PARA A SEGURANÇA DO ACTIVE DIRECTORY A anatomia de uma ameaça interna e as melhores
PRÁTICAS PARA A SEGURANÇA DO ACTIVE DIRECTORY A anatomia de uma ameaça interna e as melhores
PRÁTICAS PARA A SEGURANÇA DO ACTIVE DIRECTORY A anatomia de uma ameaça interna e as melhores

2

Introdução

"Quer dizer que este foi um trabalho interno?"

É um momento clássico na história do crime

clássico: alguém descobre uma pista de que um funcionário interno estava envolvido, e os personagens trocam olhares surpresos e desconfiados quando um deles diz "Quer dizer que este foi um trabalho interno?".

Infelizmente, olhares e perguntas como esses são cada vez mais comuns nas

investigações de violações de dados. Depois de descobrir que alguém acessou dados de maneira ilegítima na rede, os gerentes de

TI inicialmente acreditam (ou esperam, na

verdade) que a ameaça tenha vindo de fontes externas. Mas, como demonstram violações de dados recentes e sensacionalistas, é geralmente uma falha na segurança interna, seja acidental ou mal-intencionada, que

permite que o ataque seja bem-sucedido, mesmo com uma sólida segurança externa.

O Microsoft Active Directory (AD) é o principal

alvo dos invasores devido à sua importância na autenticação e autorização de todos os usuários. Este eBook explora como uma típica ameaça interna é revelada e detalha nove melhores práticas essenciais de segurança que reduzem o risco de ameaça

interna à disponibilidade, confidencialidade

e integridade do AD.

essenciais de segurança que reduzem o risco de ameaça interna à disponibilidade, confidencialidade e integridade do

Os ataques internos e seus impactos

OS PRINCIPAIS ENVOLVIDOS NOS ATAQUES INTERNOS

Muitas organizações acreditam que ações inadequadas de funcionários internos, tanto acidentais quanto mal-intencionadas, podem causar tantos danos quanto os ataques iniciados externamente.

A atenção é voltada aos funcionários antigos e atuais descontentes ou que não receberam

treinamento adequado, mas os prestadores de serviços e parceiros de negócios desempenham um crescente papel na prática e na facilitação dos crimes cibernéticos. Além disso, o roubo de credenciais de todos esses tipos de funcionários internos está cada vez mais comum.

O custo médio total de uma violação de dados nos EUA é de US$ 7,35 milhões.

Os ataques internos assumem vários dos mesmos formatos que outros crimes, inclusive:

• Espionagem econômica internacional

• Conspirações bem-planejadas para roubar segredos comerciais

• Usuários autorizados que copiam dados de cartão de crédito e os vendem no mercado negro

O CUSTO DE ATAQUES INTERNOS

Independentemente do motivo por trás de um ataque interno, os custos para os negócios podem ser muito altos. Além do tempo e do dinheiro necessários para restaurar a segurança nos sistemas

e notificar as vítimas, o custo total envolve coisas como: a perda de informações confidenciais, as consequências em falhar no atendimento das regulamentações de conformidade, como GDPR, dano à reputação da organização que pode resultar na perda de clientes, além da interrupção de sistemas críticos, como o Active Directory.

A quanto isso chega? De acordo com o Ponemon Institute, o custo médio total de uma violação de

dados nos EUA é de US$ 7,35 milhões, enquanto que a média global é de US$ 3,62 milhões. Mas mais da metade das empresas admitem francamente que não fazem ideia de como estimar suas possíveis perdas devido a um ataque interno.

3

das empresas admitem francamente que não fazem ideia de como estimar suas possíveis perdas devido a

4

Active Directory:

as joias da coroa

POR QUE O AD É UM ALVO PRINCIPAL

Como o Active Directory é o principal diretório de autenticação e autorização para mais de 90% das empresas em todo o mundo e cerca de 500 milhões de contas ativas de usuários, ele se torna um alvo comum para os ataques cibernéticos. Na verdade, mais de 95 milhões de contas do AD sofrem ataques cibernéticos diariamente, de acordo com a Microsoft.

Aumentar a segurança externa não garante a segurança do AD, pois os maiores ataques à segurança dele são internos e mais da

metade dos casos de uso indevido por funcionários internos envolve

o abuso de privilégios. Isso se estende ao uso indevido acidental

ou mal-intencionado das permissões do AD, contas elevadas e grupos confidenciais que podem enfraquecer os protocolos de segurança e levar ao acesso não autorizado aos dados confidenciais baseados no Windows.

COMO A CRESCENTE POPULARIDADE DO OFFICE 365 TORNA ESSA AMEAÇA INTERNA AINDA MAIS ALARMANTE

À medida que a adoção do Microsoft Office 365 continua a crescer,

aumenta também a complexidade da segurança do AD. Há mais de 10 bilhões de autenticações do AAD anualmente, e 10 milhões delas são tentativas de ataques cibernéticos. Debaixo do Office 365 está o Azure AD (AAD). Usado por todos os aplicativos do Office 365 para autenticar usuários, o Azure AD funciona como o sistema nervoso central que possibilita o uso do Office 365. Mas todas as instâncias do Office 365

requerem um locatário AAD separado, no entanto, outra TI de ambiente deve realizar o gerenciamento e a proteção.

365 requerem um locatário AAD separado, no entanto, outra TI de ambiente deve realizar o gerenciamento

Para resolver esse problema, acima de 75% dos clientes com mais

de 500 funcionários que utilizam o Office 365 sincronizam o AD local com o Azure AD para permitir uma única autenticação, criando assim um ambiente de AD híbrido. Especificamente, com o uso do Azure AD Connect, as organizações integram os dois diretórios, o que mantém ambos os ambientes sincronizados e oferece aos usuários

a possibilidade de fazer login sem interrupções no Office 365 com o

uso de suas credenciais locais. Como se trata de uma sincronização unidirecional com o AAD, é importante lembrar que o seu ambiente AD local determina o conteúdo do AAD. Portanto, o seu AD local se

torna o ponto principal para administrar os controles de acesso, criar controles de compensações de segurança e determinar como o acesso

é concedido no AAD e nos aplicativos associados.

Em suma, qualquer acesso concedido por meio do AD local pode causar repercussões não somente no AAD:eles também podem alcançar qualquer aplicativo baseado na Web que utilize o AAD. Dessa forma, você precisa implantar controles de segurança dentro do seu AD local queserão refletidos na sua instância do AAD, o que mantém todo o seu AD híbrido seguro.

O QUE UMA VIOLAÇÃO DO AD SIGNIFICA PARA OS NEGÓCIOS

Tenha uma organização umambiente híbrido ou local, sem o Active Directory, ela perdemúltiplos recursos críticos aos negócios: Exchange, colaboração, comunicações em tempo real, SharePoint, bancos de dados do SQL Server, servidores da Web, entre outros.

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, a ameaça interna aos ambientes AD híbridos e locais está evidente e presente.

5

O Active Directory é o principal alvo dos invasores devido à sua importância na autenticação e autorização de todos os usuários.

é o principal alvo dos invasores devido à sua importância na autenticação e autorização de todos

6

Os desafios da segurança do AD

O

AD foi criado para ser seguro, mas a segurança é violada quando

o

acesso elevado está nas mãos erradas. Mesmo em ambientes AD

híbridos, em que a Microsoft garante um contrato de nível de serviço de 99,9% com garantia financeira para o Office 365, o controle de alterações, a governança de acesso e a segurança geral de dados ainda são responsabilidades do cliente.

Considere quatro desafios principais com que os administradores de TI precisam lidar:

LIMITAÇÕES DA AUDITORIA NATIVA

Somente com a auditoria do AD nativa, pode ser difícil detectar ameaças internas e evitar violações. As limitações incluem:

• Os detalhes de eventos contêm contexto limitado e algumas ações que os funcionários internos exploram (como mudanças nas configurações de GPO e associações a grupos aninhados) não são capturadas.

• Não há uma visualização abrangente de todas as alterações de todas as fontes de registros nativos. Por exemplo, os DCs e servidores possuem múltiplos registros nativos. Entretanto, pesquisar um evento específico é uma tarefa demorada e propensa a erros.

• Não há alertas proativos em eventos suspeitos.

• Não há um recurso de relatórios que atenda aos requisitos de conformidade externos ou de grupos de segurança internos.

• Não há uma forma de evitar alterações indesejadas aos objetos mais vulneráveis.

de grupos de segurança internos. • Não há uma forma de evitar alterações indesejadas aos objetos

A auditoria do Azure AD nativo possui seus próprios desafios, que incluem:

• Não há uma forma de monitorar as políticas de auditoria para saber se elas foram alteradas ou desativadas por outros administradores.

• Os dados de auditoria são muito básicos, não possuem nomes de exibição propícios e o formato muda constantemente. Na verdade, não há um formato 5W normalizado (quem, o quê, quando, onde, workstation/origem) entre os eventos.

• Os dados de auditoria são mantidos por um tempo limitado antes de serem perdidos permanentemente.

Monitorar os registros de eventos do AD e do Azure AD é um começo, mas muitas ameaças internas se aproveitam dos eventos que não estão registrados.

As ferramentas tradicionais de gerenciamento de eventos e informações de segurança (SIEM) estão sujeitas a essas limitações da auditoria de registros nativos. Por exemplo, o registro de

auditoria nativa 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, de forma que

a solução SIEM não consegue relatar esses detalhes críticos.

LIMITAÇÕES DO GERENCIAMENTO DE PERMISSÕES

Proteger o AD e o AD híbrido é um ato de equilíbrio constante entre conceder aos usuários os direitos necessários para a realização de seus trabalhos, e mantê-los, inclusive os administradores de domínio, fora de grupos de segurança que podem acessar bancos de dados, pastas e arquivos que contêm dados confidenciais, como registros de Recursos humanos, informações de cartão de crédito ou registros de saúde.

Mas o AD e o Azure AD não permitem que as organizações apliquem um modelo real de privilégio mínimo. Dessa forma, os usuários geralmente possuem privilégios superiores e mais acesso do que o necessário para a realização de seus trabalhos. Por exemplo, se um administrador deseja atribuir a capacidade de AD ao funcionário do Help Desk, JSmith, para mover os objetos de usuário da unidade organizacional (OU) de Planejamento para a OU de Engenharia, o administrador teria de conceder a JSmith o direito de excluir qualquer objeto do usuário da OU de Planejamento e o direito de fazer gravações na OU de Planejamento. Isso inclui consideravelmente mais permissões do que JSmith precisaria (e que o administrador realmente gostaria de conceder) para executar a ação e aumenta significativamente a exposição da organização ao risco.

Além disso, é difícil aplicar a fidelidade de dados e os padrões de nomenclatura da empresa no AD,

o

que aumenta os desafios de fazer auditoria em ativos e analisar direitos.

7

de nomenclatura da empresa no AD, o que aumenta os desafios de fazer auditoria em ativos

FALTA DE RECURSOS DE AUTOMAÇÃO NATIVA

A segurança exige que os controles de acesso sejam continuamente avaliados e corrigidos, mas o AD e o AAD não fornecem nenhuma maneira de automatizar esses processos. Eles oferecem somente visibilidade limitada sobre quem tem acesso ao quê, como essas pessoas receberam o acesso, quem possui permissões elevadas e quais objetos e sistemas estão vulneráveis às ameaças.

Da mesma forma, a prevenção de tempo de inatividade prolongado e perda de dados no AD requer testes e análises contínuos dos processos completos de recuperação de desastres, mas o AD não fornece nativamente uma forma automatizada de testar e implementar um cenário completo de recuperação de desastres do AD em todos os controladores de domínio (DCs). E quando ações ou acesso não autorizado ao AD ou ao Azure AD são detectados, não há como evitá-los ou corrigi-los automaticamente e também não há como as credenciais obsoletas sejam autoapagadas.

A segurança exige que os controles de acesso sejam

continuamente avaliados e corrigidos, mas nem o AD e nem

o Azure AD fornecem nenhuma maneira de automatizar esses processos.

Sem controles de alteração automatizados e integrados no AD e no Azure AD, as empresas estão sujeitas ao acesso não autorizado e acidental, assim como a interrupções onerosas.

FATORES HUMANOS E DE NEGÓCIOS

Quando os funcionários são transferidos entre unidades de negócios, a maioria das organizações não atualiza suas permissões da forma adequada, o que faz com que os usuários mantenham todas as permissões acumuladas das funções anteriores, até mesmo os direitos que não são mais necessários para a realização de seus trabalhos.

Além disso, 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, o que aumenta o risco de uso indevido por funcionários internos, seja acidental ou mal-intencionado.

8

do AD, o que aumenta o risco de uso indevido por funcionários internos, seja acidental ou

Observe um ataque ser revelado

Considere esta história fictícia que descreve como uma ameaça interna causada por controles de segurança fracos pode afetar o AD.

Um varejista de produtos médicos, chamado Acme, acabou de adquirir um de seus concorrentes e agora o departamento de TI da Acme precisa integrar os sistemas centrais das duas empresas. A Acme contrata o prestador de serviço JSmith pelo período de quatro semanas para ajudar a consolidar o Active Directory. O administrador do AD na Acme adiciona 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 para que a equipe de TI remova JSmith do grupo de administradores até a segunda-feira seguinte. Essa falha no processo de segurança faz com que JSmith tenha todo um fim de semana para usar de forma indevida seus prolongados privilégios elevados, e ele aproveita essa chance. Veja a seguir as etapas detalhadas:

ETAPA 1. CRIAÇÃO DE UMA CONTA FALSA

Insatisfeito porque a Acme encerrou o seu contrato antecipadamente, JSmith procura maneiras de compensar o dinheiro que ele contava receber. Por um amigo, ele fica sabendo de um site do mercado negro em que ele pode ganhar dinheiro rápido com a venda de dados de cartão de crédito, coisa que a Acme possui em abundância.

JSmith faz login na rede da Acme de sua casa com suas credenciais de administrador ainda ativas e cria uma nova conta de administrador, caso a Acme remova sua conta original de administrador ou redefina sua senha. Para evitar chamar atenção, ele chama a nova conta de corpsvcbk1, que segue a convenção de nomenclatura da Acme para as contas de serviço de backup.

9

chama a nova conta de corpsvcbk1, que segue a convenção de nomenclatura da Acme para as
ETAPA 2. OBTENÇÃO DE PRIVILÉGIOS DE ADMINISTRADOR DE DOMÍNIO JSmith sabe que o sistema de

ETAPA 2. OBTENÇÃO DE PRIVILÉGIOS DE ADMINISTRADOR DE DOMÍNIO

JSmith sabe que o sistema de monitoramento genérico da Acme está configurado para monitorar alterações diretas no grupo de

administradores de domínio, então, ele não pode adicionar corpsvcbk1

a esse grupo para obter os privilégios necessários para roubar dados

confidenciais. Em vez disso, ele adiciona corpsvcbk1 a um grupo que

é membro dos administradores de domínio, o que fornece a ele os mesmos privilégios sem gerar nenhum alerta.

ETAPA 3. ROUBO DOS DADOS

Com a sua nova conta de administrador, JSmith localiza o SQL Server (SQL1) em que a Acme armazena os dados de cartão de crédito. Ele modifica o GPO que impede que os administradores se conectem a determinados bancos de dados e servidores de arquivo e, em seguida, conecta-se localmente ao SQL1. 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. Ao vasculhar a rede, ele encontra o banco de dados de cartão de crédito descriptografado

e exporta todos os registros para o seu notebook por meio de conexão remota.

As políticas de segurança e os controles de segurança comuns são insuficientes para evitar diversos ataques internos contra o Active Directory.

10

Então, ele encontra o servidor de arquivos (FSRV1) em que a Acme armazena informações de identificação pessoal (PII) e conecta-se localmente a ele. Novamente, eliminando seus rastros, ele adiciona sua conta de administrador a um grupo aninhado que é membro do grupo de administradores integrado no FSRV1. Na pasta Contas a receber, ele encontra o arquivo com as PII. Para acessá-lo, ele adiciona a sua conta de administrador ao grupo de Contas a receber; isso evita que a sua conta seja exibida na lista de controles de acesso, mas ainda obtém todos os direitos ao arquivo. Ele abre o arquivo, verifica se é o que está procurando e o copia para um drive de rede mapeada em seu notebook.

ETAPA 4. CONFIGURAÇÃO DE INTERCEPTAÇÃO 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 intercepte 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. Dessa forma, mesmo que a Acme exclua a sua conta falsa

corpsvcbk1, ele ainda poderá roubar mais dados de cartões de crédito.

ETAPA 5. LIMPEZA

JSmith remove a sua conta corpsvcbk1 dos grupos de administradores, limpa os registros para apagar as evidências do seu ataque e deixa o malware na rede para exploits futuros.

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 dos 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 dos dados.

provavelmente já terá recuperado a sua renda perdida e a Acme estará nas vias de se

Melhores práticas para a segurança do AD

Não há uma abordagem que garanta completamente a segurança do Active Directory, mas as organizações podem se proteger contra ameaças internas ao AD com essas importantes melhores práticas:

1. REDUZA A ÁREA DE ATAQUE

A primeira etapa na redução dos riscos é a

limpeza. Comece com o próprio ambiente de TI: Reduza o número de forests e domínios. Identifique e remova registros

duplicados e outros grupos desnecessários. Remova softwares desnecessários instalados nos controladores de domínio

e servidores confidenciais.

Depois, reduza as maneiras em que o ambiente pode ser usado indevidamente ou explorado. Limite as permissões de todos os usuários, principalmente os usuários privilegiados, completamente

de acordo com o princípio de privilégio mínimo. Certifique-se de configurar datas de validade de contas ao criar contas para funcionários temporários, como prestadores de serviços, estagiários e visitantes. Reduza a delegação nas unidades organizacionais

e evite que controladores de domínio acessem a Internet.

11

Não há uma abordagem que garanta completamente a segurança do Active Directory, mas as organizações podem se proteger contra ameaças internas ao AD seguindo importantes melhores práticas.

Directory, mas as organizações podem se proteger contra ameaças internas ao AD seguindo importantes melhores práticas.

2.

FORTALEÇA O CONTROLE DE ACESSO A CREDENCIAIS

12

E SISTEMAS CONFIDENCIAIS

Para minimizar ainda mais o risco de comprometimento dos seus dados

mais valiosos, exija a autenticação multifator em sistemas confidenciais

e certifique-se de que os administradores usem jumpboxes durante

a conexão com o uso de contas privilegiadas e que eles façam login somente em workstations protegidas.

Gerencie suas contas privilegiadas com o uso de uma solução de cofre de senhas protegidas. Em vez de conceder o acesso de administrador permanente a servidores confidenciais para qualquer pessoa, use uma associação de grupo temporária com data e hora de início e de término automáticas.

3. FIQUE DE OLHO NA ASSOCIAÇÃO DE GRUPO

PRIVILEGIADO

Quando tudo estiver em ordem, você precisará monitorar as ações das pessoas. Observar o atendimento de segundo nível de privilégio deve estar no topo da sua lista. Monitore em tempo real não apenas as alterações diretas em grupos privilegiados (que podem ser rastreadas em registros de segurança nativos), mas também quaisquer adições de membros a grupos aninhados (que os servidores do Windows não registram). Os grupos privilegiados a serem monitorados incluem: administradores, operadores de impressão, operadores de configuração de rede, administradores de DHCP, operadores de backup, criadores de confiança de forest 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.

Ainda melhor, implemente uma solução que impeça qualquer pessoa de fazer alterações em seus grupos de segurança mais importantes.

implemente uma solução que impeça qualquer pessoa de fazer alterações em seus grupos de segurança mais

4. ALERTE SOBRE ATIVIDADE SUSPEITA

Além do atendimento de segundo nível de privilégio, você também deve procurar por outros sinais de invasores ativos em seu ambiente. Certifique-se de gerar alertas sobre os seguintes sinais de acesso anormal ou de invasor:

• Logins suspeitos em servidores confidenciais após o horário comercial normal

• Alterações de senhas feitas em contas confidenciais e VIP por terceiros

• Logins bem-sucedidos após diversas tentativas que falharam

• Atribuição direta de direitos administrativos a qualquer usuário

• Consultas a protocolos LDAP em excesso ou atípicas, que podem ser um sinal de reconhecimento e coleta de informações

• Alterações nas 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 backdoor ao AD)

• Alterações na configuração de registro HKLM\SYSTEM\ CurrentControlSet\Control\Lsa (essa é uma tática de backdoor para reduzir os valores utilizados pelo protocolo de autenticação NTLM)

5. ANALISE CONTINUAMENTE OS CONTROLES DE

ACESSO, AS AMEAÇAS E AS VULNERABILIDADES NO AD E NOS SISTEMAS WINDOWS

Lembre-se de que a segurança não é um evento único de configuração, e sim um processo contínuo. Você precisa entender suas permissões do AD conforme elas mudam com o tempo. Em especial, certifique-se de analisar periodicamente a associação de grupos privilegiados no AD e em sistemas confidenciais locais; contas baseadas no AD em execução como serviços; e permissões de bancos de dados do SQL Server e permissões NTFS no AD e nos servidores de arquivos SQL. Além disso,

13

faça relatórios regulares sobre contas inativas e desativadas e limpe-as antes que elas possam ser exploradas.

Por último, mas não menos importante, faça relatórios frequentes sobre sistemas que não possuem os patches de segurança mais importantes e recentes da Microsoft e corrija essa vulnerabilidade.

6. AUTOMATIZE, APLIQUE E CORRIJA SUAS POLÍTICAS DE SEGURANÇA

Quando se trata de segurança, a automação é a sua melhor amiga. Complemente as ferramentas nativas com soluções que podem detectar e impedir de forma automática intrusões não autorizadas a contas e grupos privilegiados e VIP, além de impedir que os controles sejam ignorados ao aplicar o acesso baseado em regras a recursos confidenciais.

Quando se trata de segurança, a automação é a sua melhor amiga.

Além disso, automatize a correção de problemas. Em especial, implemente políticas de autocorreção que corrigem automaticamente falhas de conformidade e crie regras que automatizam a reversão de alterações não autorizadas em grupos ou usuários confidenciais.

Evite 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 alguma pessoa que não estiver na lista aprovada criar uma conta de usuário, o evento deve ativar um alerta e possivelmente até mesmo desativar a conta do criador, a conta criada ou ambas.

usuário, o evento deve ativar um alerta e possivelmente até mesmo desativar a conta do criador,

Impeça também alterações não autorizadas em grupos empresariais importantes e a configurações do GPO com o uso de uma lista branca de usuários autorizados. Com a lista branca, mesmo que funcionários internos ganhem direitos de administrador de credenciais comprometidas, as tentativas de alteração feitas às associações em grupos privilegiados, como Administradores de domínio e Administradores empresariais, serão negadas. A lista branca também é aplicada às alterações feitas nas configurações confidenciais do GPO, como desativar ou negar o login em servidores importantes e enfraquecer a autenticação NTLM.

7. CENTRALIZE INFORMAÇÕES DE INCIDENTES DE SEGURANÇA DE

MÚLTIPLAS FONTES DE DADOS

Aprimore a sua capacidade de detectar ataques rapidamente e realize análises forenses minuciosas ao coletar não apenas registros nativos, mas também outras informações importantes de auditoria que não estão registradas no mesmo local, além de consolidá-la para fornecer informações contextuais sobre usuários, recursos, tempo decorrido e informações de direitos necessárias para avaliar todos os estágios de um evento, do login ao logoff. De preferência, você deseja uma visualização em 360° de todas as atividades relacionadas de usuários e recursos.

8. PLANEJE, TESTE E IMPLEMENTE SEU PROCESSO DE CONTINUIDADE DOS NEGÓCIOS DO AD

Faça backup frequente dos seus controladores de domínio, bancos de dados e outros sistemas e armazene esses backups de forma segura.

Teste continuamente o seu plano de continuidade dos negócios, inclusive todos os estágios do seu plano de recuperação de desastres. Certifique-se de incorporar a recuperação em seu processo de resposta a incidentes de segurança e confirme que o seu processo de recuperação de desastres atende aos seus Recovery Time Objectives após um desastre ou uma violação.

9. AUTOMATIZE A LIMPEZA DE OBJETOS DO AD

Crie regras que detectem automaticamente objetos que violem a política no AD e limpe-os. Por exemplo, detecte automaticamente contas de usuários e computadores que não fizeram login há 90 dias, desative as contas, coloque-as em um contêiner desativado e exclua-as em três dias caso elas não tenham sido solicitadas.

Implemente um processo automatizado para desprovisionar usuários que inclua desativar ou excluir contas, remover contas de todos os grupos e listas de distribuição, remover acesso remoto VPN e notificar a gerência de instalações, segurança e HR automaticamente.

14

de distribuição, remover acesso remoto VPN e notificar a gerência de instalações, segurança e HR automaticamente.

Conclusão

A ameaça interna ao AD é real, comum e onerosa. Um funcionário

insatisfeito ou ambicioso, principalmente um que tenha uma conta administrativa, ou um invasor que comprometatal conta, pode explorar vulnerabilidades técnicas e fatores humanos para lançar violações de dados de dentro para fora.

Monitorar os registros de eventos do AD e do Azure AD é um começo, mas muitas ameaças internas se aproveitam dos eventos que não estão registrados. Além disso, a lista de coisas a serem analisadas para detectar ações suspeitas é longa e não há uma maneira nativa de automatizar a detecção nem a correção.

A verdade é que os usuários precisam de acesso a recursos para a

realização de seus trabalhos e, às vezes, precisam de permissões de

acesso privilegiado. O essencial para a segurança do AD é equilibrar

a necessidade de simplificar o acesso do usuário para aumentar a

produtividade com a necessidade de proteger sistemas e dados confidenciais contra o abuso de privilégio acidental ou deliberado. Ao seguir as melhores práticas aqui descritas do Active Directory, você poderá aprimorar a segurança e minimizar as ameaças internas.

Proteger o AD requer equilibrar a necessidade de simplificar o acesso do usuário para aumentar a produtividade com a necessidade de proteger sistemas e dados contra o abuso de privilégio acidental ou deliberado.

15

a produtividade com a necessidade de proteger sistemas e dados contra o abuso de privilégio acidental

SOBRE A QUEST

Na Quest, nosso propósito é resolver problemas complexos com soluções simples. Fazemos isso com uma filosofia focada em ótimos produtos, ótimo serviço e uma meta geral de simplicidade para fazer negócios. Nossa visão é oferecer uma tecnologia que elimine a necessidade de escolher entre eficiência e eficácia, o que significa que você e sua organização podem gastar menos tempo com a administração da TI e mais tempo com a inovação dos negócios.

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

Quest Software Inc. Attn: LEGAL Dept 4 Polaris Way Aliso Viejo, CA 92656

Acesse nosso site (https://www.quest.com/br-pt/) para obter informações sobre escritórios regionais e internacionais.

Ebook-InsiderThreats-US-GM-pt_BR-WL-30924

16

© 2017 Quest Software Inc. TODOS OS DIREITOS RESERVADOS.

Este guia contém informações confidenciais protegidas por direitos autorais. O software descrito neste guia é fornecido com uma licença de software ou um contrato de confidencialidade. Este software deve ser usado ou copiado somente de acordo com os termos do contrato 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 exceto o uso pessoal pelo comprador, sem

a permissão por escrito da Quest Software Inc.

As informações fornecidas neste documento referem-se 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 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 QUAISQUER DANOS DIRETOS, INDIRETOS, CONSEQUENCIAIS, PUNITIVOS, ESPECIAIS OU INCIDENTAIS (INCLUINDO, SEM LIMITAÇÃO, DANOS POR PERDA DE LUCROS, INTERRUPÇÃO DE NEGÓCIOS OU PERDA DE INFORMAÇÕES) DECORRENTES DO USO OU IMPOSSIBILIDADE DE UTILIZAR ESTE DOCUMENTO, MESMO QUE A QUEST SOFTWARE TENHA SIDO AVISADA DA 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 a atualizar as informações contidas neste documento.

Patentes

A Quest Software tem orgulho da sua tecnologia avançada. Este produto pode possuir

patentes e patentes pendentes. Para obter informações atualizadas sobre as patentes aplicáveis a este produto, acesse 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 aos seus respectivos proprietários.

trademark-information.aspx . Todas as outras marcas comerciais pertencem aos seus respectivos proprietários.