monitor amen to
TRANSCRIPT
1
Monitoramento de segurança e detecção de ataques
Introdução Bem-vindo a este documento da coleção Orientações de segurança para empresas de médio
porte. A Microsoft espera que as informações a seguir ajudem a criar um ambiente de
computação mais seguro e produtivo.
Sinopse
O elevado número de incidentes e ameaças de software mal-intencionado que dominaram as
reportagens da mídia por anos serviu para aumentar a conscientização e estimular a maioria das
empresas a investir tempo e recursos na defesa contra este sério problema de segurança.
Entretanto, a maior ameaça à infra-estrutura das empresas pode não estar sob a forma de um
ataque externo, como vírus, mas pode se encontrar dentro da própria rede interna.
Os ataques lançados de dentro da rede da empresa têm um alto poder de destruição,
especialmente se efetuados por pessoas em cargos de confiança e que têm acesso a todos os
recursos da rede dentro da empresa. Quando os riscos apresentados por ameaças tanto
externas quanto internas são analisados, muitas empresas decidem pesquisar sistemas que
podem monitorar redes e detectar ataques de qualquer lugar de onde partam.
As práticas de monitoramento de segurança não estão abertas a considerações para as
empresas que são governadas por restrições normativas; são uma exigência. Essas mesmas
normas podem até controlar por quanto tempo e como os registros de monitoramento de
segurança devem ser mantidos e arquivados. O ambiente de regulamentação sempre em
alteração e as sempre crescentes necessidades que as empresas regulamentadas têm para
proteger suas redes, acompanhar a identificação de pessoas que acessam recursos e proteger
informações privadas exercem pressões maiores sobre as empresas em todo o mundo para que
elas instituam soluções efetivas para o monitoramento de segurança.
Há várias razões por que o monitoramento de segurança e a detecção de ataques devem ser
uma questão importante para empresas de médio porte que não precisam obedecer a
requisitos de regulamentação. Elas incluem as conseqüências que qualquer empresa poderia
enfrentar se um ataque à sua infra-estrutura tivesse êxito. Não apenas as operações da empresa
poderiam ser afetadas, resultando em perda de produtividade e, até, monetária. Ela poderia,
inclusive, sofrer a perda de sua reputação, o que, em geral, leva muito mais tempo para
recuperar do que qualquer das perdas impostas por um ataque.
Os recursos de log de segurança do Microsoft® Windows® podem ser o ponto de partida para
uma solução de monitoramento de segurança. Porém, os logs de segurança sozinhos não
fornecem informações suficientes para o planejamento de respostas a incidentes. Esses logs de
segurança podem ser combinados com outras tecnologias que coletam e consultam
informações para compor uma parte central de uma solução abrangente para monitoramento
de segurança e detecção de ataques.
O primeiro objetivo de um sistema de monitoramento de segurança e detecção de ataques é
ajudar a identificar eventos suspeitos em uma rede que podem indicar atividade mal-
intencionada ou erros de procedimentos. Este artigo descreve como desenvolver um plano para
ajudar a atender à necessidade de um sistema como esse em redes baseadas no Windows. Ele
também fornece instruções sobre como implementar, gerenciar e validar esse sistema.
Visão geral
Este documento consiste em quatro seções principais que enfocam conceitos e questões
essenciais para o projeto e a implementação de uma solução eficiente para monitoramento de
segurança e detecção de ataques. A primeira seção é a "Introdução" que você está lendo agora.
As demais seções são:
2
Definição Esta seção fornece informações que são úteis para a compreensão de processos envolvidos com
a geração e a aplicação da solução apresentada neste artigo.
O desafio das empresas de médio porte Esta seção descreve muitos dos desafios comuns enfrentados pelas empresas de médio porte
em relação a um sistema de monitoramento de segurança e detecção de ataques.
Soluções Esta seção fornece informações detalhadas sobre como desenvolver, implementar, gerenciar e
validar a solução apresentada neste artigo. Ela está dividida em duas subseções.
"Desenvolvendo a solução" discute as atividades que são pré-requisito e cria as etapas do
planejamento. "Implantando e gerenciando a solução" fornece informações que ajudarão nos
esforços para implantar, gerenciar e validar um sistema de monitoramento de segurança e
detecção de ataques.
Quem deve ler este documento
Este documento aborda problemas de privacidade e segurança de empresas de médio porte,
especialmente aquelas que exigem proteção de identidade e controle do acesso a dados por
força de restrições reguladoras. Por conseguinte, o público-alvo deste documento varia de
gerentes técnicos e responsáveis pelas decisões até profissionais de TI e implementadores de
tecnologia que são responsáveis pelo planejamento, pela implantação, pela operação ou,
especialmente, pela segurança da rede da empresa.
Embora partes deste documento devam ser úteis à maioria dos responsáveis pelas decisões, os
leitores devem estar familiarizados com problemas de segurança e risco em seus próprios
ambientes de rede e ter conhecimento dos conceitos de serviços de log de eventos para aplicar
todo o conteúdo aqui apresentado.
Início da página
Definição Este artigo usa o modelo de processo MOF (Microsoft Operations Framework), além da
Administração de Segurança MOF e das funções de gerenciamento de serviços (SMFs) do
Gerenciamento de Incidentes.
Em especial, a solução apresentada neste artigo recomenda o uso de um método de processo
contínuo, no lugar de um método de implantação linear para monitoramento de segurança e
detecção de ataques. Especificamente, esta solução deve envolver as etapas mostradas na figura
a seguir:
3
Figura 1. Aplicando MOF
Uma solução de monitoramento de segurança é, na verdade, um processo contínuo de
planejamento, implementação, gerenciamento e teste porque essa é a própria natureza do
monitoramento de segurança. Como as ameaças às redes corporativas estão sempre mudando,
o sistema que monitora a segurança de uma rede corporativa também tem que mudar.
A aplicação desse processo ao monitoramento de segurança é adequada à SMF do
Gerenciamento de Segurança, que busca realizar o seguinte:
Avaliar a exposição da empresa e identificar quais ativos proteger.
Identificar meios de reduzir o risco a níveis aceitáveis.
Projetar um plano para atenuar riscos de segurança.
Monitorar a eficiência dos mecanismos de segurança.
Reavaliar a eficiência e os requisitos de segurança regularmente.
Para saber mais sobre o MOF, consulte o site Microsoft Operations Framework (em inglês) em
www.microsoft.com/mof. Mais informações sobre a SMF do Gerenciamento de segurança estão
disponíveis em www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx.
Gerenciamento de risco é o processo de se determinar o nível aceitável de risco de uma
organização, avaliar os riscos atuais, encontrar meios para atingir o nível aceitável de riscos e
gerenciar os riscos. Embora este documento trate de alguns conceitos de gerenciamento de
riscos e de algumas etapas que auxiliarão na avaliação deles, uma discussão em maior
profundidade sobre o gerenciamento de riscos é um assunto independente que merece um
foco dedicado. Para obter mais informações sobre análise e avaliação de riscos, consulte Guia de
Gerenciamento de Riscos de Segurança em http://go.microsoft.com/fwlink/?linkid=30794.
Início da página
O desafio das empresas de médio porte As empresas de médio porte enfrentam vários desafios quando tentam construir um sistema
eficiente de monitoramento de segurança e instituir diretivas que sirvam de apoio a tal esforço.
Esses desafios incluem:
Compreender a necessidade e os benefícios de proteger todo o ambiente de rede
contra ameaças internas e externas.
Projetar um sistema eficiente de monitoramento de segurança e detecção de ataques
que inclua métodos para detectar e impedir ações para burlar as diretivas estabelecidas.
Implementar diretivas de monitoramento abrangentes e eficazes que não somente
detectem ataques mas que também forneçam um cenário global do nível de segurança
do ambiente para efeitos de correção.
Manter diretivas e processos que correlacionem com eficiência os relatórios de
segurança e as diretivas estabelecidas para facilitar as ações administrativas na detecção
de atividades suspeitas.
Implementar e impor práticas e diretivas corporativas eficientes que forneçam apoio às
ações de monitoramento de segurança ao mesmo tempo que equilibram as
necessidades corporativas.
Determinar limites de risco aceitáveis para equilibrar usabilidade e atenuação de risco.
Início da página
Soluções Como discutido antes, um processo de monitoramento de segurança não apenas ajuda na
necessidade de realização de análise forense mas também pode ser uma medida de segurança
proativa, capaz de fornecer informações antes, durante e depois de um ataque. Com um
repositório centralizado para relatórios de segurança, um ataque pode ser detectado durante a
4
fase de sondagem, no momento de sua ocorrência ou imediatamente depois para fornecer aos
responsáveis pela reação as informações necessárias para reagirem ao ataque efetivamente, o
que pode reduzir o impacto de tentativas de invasão.
Compreender a gama de benefícios que podem ser obtidos pela implementação do
monitoramento de segurança é importante durante a fase conceitual de desenvolvimento, para
que o projeto e as diretivas possam aproveitar todas essas vantagens. Algumas das vantagens
fornecidas pelo monitoramento de segurança incluem:
Identificar e corrigir sistemas que não sejam compatíveis com diretivas de segurança ou
atualização para reduzir o perfil de vulnerabilidade de uma empresa de médio porte.
Produzir informações que possam alertar a equipe sobre tentativas de invasão antes de
um ataque real por meio de identificação de atividade incomum.
Criar informações de auditoria de segurança e protegê-las para melhorar a análise
forense, o que não apenas atende aos requisitos reguladores mas também reduz o
impacto de qualquer ataque.
Auxiliar nos esforços de análise do nível de segurança para melhorar a segurança geral.
Detectar atividades que ocorrem fora dos processos corporativos estabelecidos, sejam
elas intencionais ou acidentais.
Auxiliar na identificação de sistemas não gerenciados em uma rede ou na correção de
dispositivos vulneráveis.
Desenvolvendo a solução
A segurança é uma questão importante para muitas empresas. Embora a maioria das empresas
destine um grau razoável de recursos à segurança física com métodos que variam de bloqueio
de porta comum até aqueles elaborados, como controles de acesso baseados em cartão, muitas
ainda não destinam o suficiente à segurança dos dados dos quais tornaram-se cada vez mais
dependentes.
Quando questões de monitoramento e segurança de dados são levadas em consideração, as
empresas em geral concentram os esforças destinados à segurança de dados em firewalls do
perímetro. Entretanto, confiar neste método deixa outras origens de ataque bastante
vulneráveis. De acordo com o documento 2004 E-Crime Watch Survey, publicado pelo serviço
secreto dos EUA e pelo Centro de Coordenação CERT em
www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf (em inglês), 29 por cento dos ataques
identificados vieram, na verdade, de fontes internas, incluindo funcionários atuais, prestadores
de serviços e ex-funcionários. Considerando-se essa informação, torna-se evidente que um
método de segurança com várias camadas deve ser criado para proteção contra ameaças
internas, além das externas.
Um método que é usado para lidar com ameaças internas e externas a partir de uma postura de
segurança reativa é implementar um processo de log de auditoria de segurança. Todas as
versões do Microsoft Windows, desde o Microsoft Windows NT® 3.1 até as versões mais
recentes, usam um arquivo de log de eventos de segurança incorporado para registrar eventos
de segurança. Entretanto, mesmo que essa funcionalidade incorporada possa ser útil na
realização de uma investigação forense em resposta a uma invasão já ocorrida, seria difícil usá-
la sozinha de forma proativa para identificar uma atividade de ataque ou alertar os responsáveis
quanto a tentativas de invasão no momento em que ocorrem.
Como foi dito, os logs de segurança são, em geral, usados de forma reativa durante a análise
forense de um incidente de segurança após ele ter ocorrido. Entretanto, no documento 2005
Insider Threat Study, publicado pelo serviço secreto dos EUA e pelo CERT (em inglês) em
www.cert.org/archive/pdf/insidercross051105.pdf, uma análise das principais descobertas
indicou que o monitoramento e os logs de segurança podem ser usados para a detecção
proativa, mais que apenas para investigação forense reativa. Além disso, a maioria dos hackers,
internos e externos, tentará encobrir suas pistas alterando logs; portanto, devem ser tomadas
providências para proteger os logs do sistema. Por isso, podemos dizer que os logs de
5
segurança e outros métodos usados para monitorar e detectar ataques podem ser ferramentas
vitais no arsenal de segurança da rede se utilizados e protegidos corretamente.
Embora os logs de segurança do sistema sejam o foco deste documento, eles apenas formam o
núcleo da metodologia de monitoramento de segurança e detecção de ataques. Outras
questões que devem ser consideradas incluem como identificar e corrigir os sistemas que não
sejam compatíveis com diretivas de segurança estabelecidas ou que não tenham os patches de
vulnerabilidade atualmente recomendados. A infra-estrutura de rede interna também deve ser
monitorada, incluindo a emissão de relatórios de segurança de portas do switch (para impedir
que sistemas não gerenciados obtenham acesso à rede) e o monitoramento de segurança sem
fio (para impedir conexões não autorizadas ou rastreamento de pacotes). Muitos desses tópicos
de monitoramento estão além do escopo deste documento, mas eles merecem atenção em
uma solução de monitoramento de segurança desenvolvida com abrangência e equilíbrio.
Implementando o monitoramento de segurança As subseções a seguir fornecem informações sobre várias considerações de implementação com
relação a um sistema de monitoramento de segurança.
Logs de eventos de segurança do Windows
Todas as versões do Microsoft Windows, desde o Microsoft Windows NT versão 3.1 e posterior
até as mais recentes, são capazes de registrar eventos de segurança com a funcionalidade de
arquivo de log incorporada. Em um ambiente baseado no Microsoft Windows, essa
funcionalidade fornece a base para o monitoramento de segurança. Entretanto, sem utilitários
ou ferramentas adicionais para correlacionar essas informações, torna-se difícil usá-las
proativamente porque estão dispersas.
Figura 2. Log de segurança de Visualizar eventos
O log de eventos de segurança (mostrado na figura anterior) usa um formato de arquivo
personalizado para registrar dados de monitoramento de segurança. Embora seja possível ler
partes desses registros com um editor de texto, é necessário um programa apropriado, como
Visualizar eventos, para ver todas as informações registradas nesses logs. O arquivo de log de
eventos de segurança (SecEvent.evt) fica no diretório %systemroot%\System32\config. O acesso
a logs de evento é sempre orientado pelo serviço do Log de eventos, que impõe controles de
acesso para cada log. As permissões padrão no log de segurança são muito restritas se
comparadas com outros logs no sistema; por padrão, somente administradores têm acesso ao
log de segurança.
Existem dois tipos de evento que são registrados no log de eventos de segurança: auditorias
com êxito e auditorias sem êxito. Eventos de auditoria com êxito indicam que uma operação
executada por um usuário, serviço ou programa foi concluída com êxito. Eventos de auditoria
sem êxito detalham operações que não foram concluídas com êxito. Por exemplo, falhas em
tentativas de logon do usuário seriam exemplos de eventos de auditoria com falha e registrados
no log de eventos de segurança se as auditorias de logon estivessem ativadas.
6
As configurações de Diretiva de Grupo de Diretiva de Auditoria, localizadas em Configuração do
computador\Configuração do Windows\Diretivas locais, controlam quais eventos criam entradas
nos logs de segurança. As configurações de Diretiva de Auditoria podem ser definidas por meio
do console de Configurações locais de segurança ou no nível de site, domínio ou unidade
organizacional (UO) por meio de Diretiva de Grupo com Active Directory.
Interpretando eventos de auditoria
Os eventos de auditoria são discutidos em mais detalhes em todo este documento, por isso é
importante ter um conhecimento básico da estrutura de eventos de auditoria e das informações
contidas neles.
Figura 3. Janela Propriedades do Evento
Os eventos são compostos de três partes básicas: o cabeçalho do evento, a descrição do evento
e uma seção de dados binários.
Os cabeçalhos de evento consistem nos campos a seguir:
7
Tabela 1. O cabeçalho do evento
Campo Definição
Data A data em que o evento ocorreu
Hora A hora local em que o evento ocorreu
Tipo Uma classificação da gravidade ou do tipo do evento. Para os eventos de
auditoria de segurança, essas classificações são auditoria com êxito ou
auditoria sem êxito.
Origem O aplicativo que registrou o evento. Ele pode ser um programa real, como
o SQL Server, um nome de driver ou um componente do sistema, como
Segurança, por exemplo.
Categoria A classificação da origem do evento. Ela é pertinente em logs de auditoria
de segurança porque corresponde a um tipo de evento que pode ser
configurado em Diretiva de Grupo.
ID do
evento
Esse código identifica o tipo específico de evento. Na figura acima, a ID
do evento é listada como 680. Essa ID indica que um conjunto de
credenciais foi passado para o sistema de autenticação por um processo
local, um processo remoto ou um usuário.
Usuário O nome de usuário em nome de quem o evento ocorreu. Esse nome é a
ID de cliente se o evento foi causado por um processo, ou a identificação
principal se não estiver ocorrendo um representação. Em eventos de
segurança, tanto as informações principais quanto as de representação
serão exibidas se for possível e aplicável.
Computador O nome do computador onde o evento ocorreu.
O campo de descrição do evento realmente contém diversas informações que podem variar de
evento para evento. No evento 680 de exemplo mostrado na figura anterior, o campo Código
de erro: especifica 0xC000006A, o que significa que foi fornecida uma senha incorreta. Cada
tipo de evento exibirá informações específicas nesse campo.
Os eventos do log de eventos de segurança do Windows não usam a seção de dados binários
do registro do evento.
Questões técnicas
Para implementar um sistema de monitoramento de segurança e detecção de ataques baseado
em logs de eventos de segurança do Windows, as seguintes questões devem ser resolvidas:
Gerenciar grandes volumes de eventos de segurança. Para lidar com o grande
volume de eventos de segurança que será gerado, será necessário decidir
cuidadosamente quais eventos de auditoria de segurança devem ser rastreados. Essas
considerações são especialmente importantes quando se lida com auditoria de acesso a
arquivos e objetos, já que ambos podem gerar grandes quantidades de dados.
Armazenar e gerenciar informações de eventos em um repositório central. O
armazenamento de informações de eventos pode envolver terabytes de dados, de
8
acordo com a configuração do sistema de monitoramento. Isso é ainda mais importante
quando se consideram as necessidades para a análise forense, por isso o assunto é
abordado em detalhes na seção relacionada.
Identificar e reagir a assinaturas de ataque. Para identificar padrões de atividade que
possam sinalizar um ataque, um revisor ou uma consulta configurada deve ser capaz de
discernir os eventos associados com tal atividade incorporada nas informações
fornecidas. Depois que uma atividade suspeita é identificada, deve haver um
mecanismo em funcionamento que solicite uma resposta oportuna e apropriada.
Impedir a equipe de burlar controles de auditoria de segurança. As pessoas que têm
altos privilégios em uma rede, especialmente os administradores, devem ter esses
privilégios compartilhados para restringir o acesso a informações de auditoria de modo
que apenas os especialistas da segurança sejam responsáveis pela administração de
sistemas de auditoria.
Planejamento da solução
As atividades a seguir devem ser concluídas antes da implementação de um sistema de
monitoramento de segurança e detecção de ataques:
Examinar as atuais configurações de auditoria de segurança.
Avaliar as funções de administrador e as tarefas normais de usuário.
Examinar diretivas e procedimentos corporativos.
Identificar sistemas vulneráveis.
Listar ativos de alto valor.
Identificar contas confidenciais ou suspeitas.
Listar programas autorizados.
Para obter mais informações em relação aos requisitos de armazenamento, consulte a seção
"Implementar análise forense" mais adiante neste documento.
Examinar as atuais configurações de auditoria de segurança.
As empresas devem examinar as configurações atuais de auditoria de segurança e do arquivo
de log de segurança para fornecer uma linha de base para as alterações recomendadas neste
documento. Tal exame deve ser feito regularmente após a implementação de uma solução e
necessitará da obtenção das seguintes informações:
Configurações de auditoria de segurança atuais e eficazes.
Nível a que essas configurações se aplicam (computador local, site, domínio ou UO).
Configurações atuais do arquivo de log (os limites de tamanho e comportamento
quando esse tamanho é atingido).
Configurações adicionais de auditoria de segurança que podem se aplicar (por exemplo,
auditoria do uso de privilégios de backup e restauração).
As informações do "Apêndice B: Implementando configurações de diretiva de grupo” no final
deste documento podem ser usadas para ajudar na identificação de quais configurações
registrar. Para obter mais informações referentes a configurações de auditoria de segurança,
consulte Introdução à Segurança do Windows 2003 em
http://go.microsoft.com/fwlink/?LinkId=14845.
Avaliar as funções de administrador e as tarefas normais de usuário.
Um elemento-chave para a implementação de uma solução eficiente de monitoramento de
segurança é assegurar que os detentores da conta de administrador sejam conhecidos e que
suas funções e responsabilidades sejam compreendidas. Por exemplo, a maioria das empresas
inclui administradores no grupo Admins. do Domínio para que eles possam criar novas contas
de usuário no domínio. Entretanto, as diretivas corporativas podem especificar que apenas um
sistema de fornecimento instalado é permitido para a criação de novas contas. Em tal situação,
um evento de criação de conta iniciado por uma conta de administrador exigiria uma
investigação imediata.
9
Uma avaliação de tarefas de contas de usuário é, em geral, muito mais simples porque essas
contas normalmente têm muito menos acesso a recursos de rede que as contas de
administrador. Por exemplo, já que os usuários normais em geral não têm necessidade de
acessar o sistema de arquivos nos computadores que residem no perímetro de uma rede, existe
pouca necessidade de monitorar esses servidores quanto à atividade do usuário comum.
Examinar diretivas e procedimentos corporativos.
Um exame dos processos e procedimentos corporativos corresponde praticamente a uma
avaliação de funções e responsabilidades do administrador, sem estar limitado a ela. Os
componentes importantes desse exame incluiriam o estudo do processo de criação de usuário e
o processo de controle de alteração, por exemplo. O exame de mecanismos que fornecem um
processo de aprovação e uma trilha de auditoria para todos os eventos que ocorrem em uma
rede é vital para fornecer uma correlação sobre o que seriam eventos de auditoria autorizados e
o que poderia ser uma tentativa de invasão.
Identificar sistemas vulneráveis.
Sistemas vulneráveis são computadores e dispositivos em uma rede que um hacker externo
mais provavelmente sondaria e contra os quais lançaria tentativas de acesso antes de tentar
outro método. Normalmente, esses computadores ficam no perímetro de uma rede, mas
dispositivos internos também podem ser vulneráveis a ataques e não devem ser completamente
ignorados.
Um exame abrangente de sistemas vulneráveis deve assegurar o seguinte:
Todas as atualizações e todos os service packs foram aplicados.
Serviços e contas de usuário desnecessários foram desativados.
Os serviços estão configurados para execução em contas de Serviço local ou Serviço de
rede sempre que possível.
Os serviços que requerem credenciais de conta de usuário são verificados para
assegurar que eles exigem aquele nível de acesso, especialmente quando tais contas
têm privilégios de administrador.
Os modelos de diretivas de alta segurança foram aplicados.
Observação Esse processo de exame não deve se limitar a computadores vulneráveis que
residem no perímetro. Uma boa prática de segurança deve aplicar essas verificações em todos
os computadores em uma rede.
Para obter mais informações sobre como configurar serviços para que sejam executados com
segurança, consulte Guia de Planejamento dos Serviços e Contas de Serviços (a página pode estar
em inglês) em http://go.microsoft.com/fwlink/?LinkId=41311.
Listar ativos de alto valor.
A maioria das empresas já deve ter identificado os ativos de alto valor que residem em suas
redes, mas talvez não tenham formalizado essas informações como parte de uma diretiva
organizacional por meio de documentação e de detalhamento das proteções no local para cada
ativo. Por exemplo, uma empresa poderia usar ACLs (listas de controle de acesso) e criptografia
para armazenar registros financeiros confidenciais com segurança em partições do sistema de
arquivos NTFS. Porém, uma diretiva organizacional deveria identificar tais registros como
arquivos protegidos que usuários e administradores não autorizados não devem tentar acessar
de tal forma que os usuários e administradores estejam cientes dessa restrição.
Qualquer alteração a uma ACL usada para proteger esses arquivos deve ser investigada,
especialmente quando estão envolvidas alterações de propriedade, porque esses eventos
podem indicar tentativas ilícitas de acesso a arquivos sem a autorização apropriada. Como as
alterações de propriedade dessa natureza devem ser raras, elas devem ser facilmente
detectadas depois que os ativos de alto valor tenham sido identificados e documentados.
Identificar contas confidenciais ou suspeitas.
Todas as contas confidenciais devem ser examinadas para que se possam identificar quais delas
requerem um nível de auditoria mais alto. Essas contas incluirão a conta de administrador
10
padrão, todos os membros dos grupos Empresa, Esquema ou Admins. do domínio e todas as
contas usadas por serviços.
Afora as contas confidenciais, também é importante ajustar os níveis de auditoria de segurança
para contas de indivíduos que foram identificados como de risco ou que podem ser suspeitos
de participação em atividade suspeita. Para obter mais informações sobre como ajustar os níveis
de auditoria para contas de usuário individuais, consulte a seção “Violações e limites de
diretivas” mais adiante neste documento.
Listar programas autorizados.
Para descobrir informações sobre uma rede, um hacker deve executar programas em sistemas
que residam dentro dessa rede. Se a empresa restringir os programas que têm permissão de ser
executados em sua rede, poderá reduzir consideravelmente a ameaça de ataque externo. Para
definir uma lista de programas autorizados, deve ser realizada uma auditoria em todos os
programas atualmente autorizados ou identificados como necessários em um ambiente de rede.
Todos os programas desconhecidos descobertos nessa auditoria devem ser considerados
suspeitos e investigados imediatamente. O Microsoft Systems Management Server 2003 pode
ajudar nas auditorias de software, mas seu uso não é obrigatório.
Observação Para certos computadores, algumas exceções podem ser requeridas, como
estações de trabalho de desenvolvedores onde os executáveis em desenvolvimento possam não
constar de uma lista de programas aprovados. Entretanto, um método mais seguro seria exigir
que as atividades de desenvolvimento e testes somente ocorressem em um ambiente virtual ou
somente em um domínio de rede de desenvolvimento isolado.
Detectar violações e limites de diretivas As violações de diretivas formam a maior categoria de questões de segurança para as quais as
empresas devem fazer planejamentos. Esses tipos de incidentes incluem:
Criação de contas de usuário fora do processo estabelecido.
Utilização imprópria ou não autorizada de privilégios de administrador.
Uso de contas de serviço para logon interativo.
Tentativas de acesso a arquivo por contas de usuário não autorizadas.
Exclusão de arquivos que as contas de usuário tenham permissão de acessar.
Instalação e execução de software não aprovado.
Embora o tipo mais comum de violação de diretiva seja as tentativas de acesso de usuário não
intencionais, como navegação por diretórios restritos, essas violações são, em geral, menos
significativas por causa de limitações de acesso, e diretivas de direitos bem projetadas resolvem
essa questão. As violações de diretivas administrativas, deliberadas ou acidentais, são o mais
significativo tipo de evento, por causa da natureza própria dos direitos administrativos.
Os privilégios de conta administrativa concedem um grau significativo de acesso a sistemas aos
indivíduos que requerem esse tipo de autoridade para executar suas tarefas. No entanto, essa
autoridade não implica a autorização para o uso daqueles direitos de sistema fora do escopo ou
processo autorizado. As contas administrativas têm capacidade para permitir a criação de contas
de usuário, a modificação de contas de usuário, a visualização de dados restritos e a
modificação de direitos de acesso, por isso é necessária uma avaliação cuidadosa das formas
para se diminuírem os riscos associados com essa capacidade poderosa.
Modelagem de ameaças
Como se vê, alguns conjuntos de ameaças podem ser corrigidos com auditoria, outros não e
alguns podem ser corrigidos com auditoria, embora o custo não compense. O ponto principal é
que nem toda vulnerabilidade representa uma ameaça para a rede. Para determinar quais
vulnerabilidades podem ou devem ser corrigidas, podem se aplicar princípios de modelagem de
ameaças.
Modelagem de ameaças é uma técnica de engenharia que pode ser usada para ajudar a
identificar ameaças e vulnerabilidades para que se criem contramedidas eficientes no contexto
de um ambiente específico. Esse processo geralmente envolve três etapas básicas:
11
Compreender a perspectiva do hacker.
Identificar o perfil de segurança do sistema.
Determinar e classificar as ameaças relevantes.
De forma mais específica, examinar o ambiente de rede da perspectiva de um hacker envolve
determinar quais alvos seriam mais tentadores para uma pessoa que está tentando obter acesso
a uma rede e quais condições devem ser cumpridas para que um ataque a tais alvos tenha êxito.
Quando alvos vulneráveis tiverem sido identificados, o ambiente poderá ser examinado para se
determinar como as proteções existentes afetam as condições de ataque. Esse processo indica
as ameaças relevantes que podem ser classificadas de acordo como o nível de risco que
apresentam, que atividades de correção podem fornecer a solução mais valiosa para a ameaça e
quais áreas essa correção pode afetar, de forma benéfica ou prejudicial, aumentando ou
diminuindo assim o seu valor.
Conseqüentemente, na verdade existem algumas etapas específicas para um processo de
modelagem de ameaças bem-sucedido que se baseiam nestes requisitos:
1. Identificar ativos críticos. Uma etapa na determinação do destino de recursos de
segurança é listar os ativos que sejam críticos para as operações corporativas. Esse
processo deve envolver os proprietários de processos corporativos, bem como os
proprietários da tecnologia, porque cada um deles terá perspectivas importantes com
relação a quais ativos, se comprometidos, causariam danos à empresa.
2. Identificar pontos possíveis de ataque. Essa fase de identificação envolve duas
perspectivas diferentes também. Primeiro, é necessário classificar os tipos de limites em
que os dados na rede podem residir. Esses limites residem dentro de territórios críticos,
confidenciais e públicos, com base nos danos que poderiam ocorrer se esse dados
ficassem expostos. Segundo, a perspectiva da tecnologia examina os pontos de ataque
por meio de vetores e quais pontos possíveis de vulnerabilidade poderiam oferecer
exposição a ativos críticos e confidenciais. A combinação dessas informações pode
ajudar a concentrar o foco dos esforços de segurança nas vulnerabilidades de pontos
onde informações críticas podem ser acessadas.
3. Identificar ameaças reais. Com a revelação dos ativos críticos e dos pontos possíveis
de acesso, é possível criar uma lista daquilo que os hackers poderiam fazer para causar
danos. Com essa lista, é possível concentrar os esforços em ameaças reais específicas.
Existem métodos diferentes que podem ser usados para identificar ameaças reais.
STRIDE é um método que examina ameaças com base nos tipos de ataque que podem
ser usados (falsificação, violação, recusa, divulgação não autorizada de informação,
negação de serviço e elevação de privilégio). Também existem outras medidas
repetitivas, como dividir as ameaças por camadas lógicas (por exemplo, rede, host e
aplicativo). A organização deve escolher o método com base naquilo que faz mais
sentido para um determinado ambiente.
4. Categorizar e classificar ameaças. Essa etapa envolve princípios de gerenciamento e
avaliação de riscos comuns ao classificar as ameaças com base na probabilidade de uso
e do impacto em potencial que as elas poderiam ter na empresa. A fórmula padrão é a
seguinte:
Risco = Probabilidade de ataque x Impacto potencial na empresa
Na verdade, existem vários métodos envolvidos nesse processo, assim como várias
ferramentas disponíveis, para ajudar nessas avaliações de riscos que estão bem além do
escopo deste artigo. Para obter mais informações sobre o gerenciamento de riscos e
esses métodos, consulte o Guia de Gerenciamento de Riscos de Segurança em
http://go.microsoft.com/fwlink/?linkid=30794.
5. Corrigir e reavaliar. O produto das etapas anteriores fornece uma lista de ameaças
reais que podem afetar a empresa e que são classificadas na ordem de risco que
representam para essa empresa. Essa lista permite concentrar os esforços de correção
12
que devem também ser avaliados de acordo com a relação econômica que eles
apresentam. Finalmente, pode haver várias formas de atenuar riscos específicos, e
algumas podem resolver outras vulnerabilidades que, assim, tornam tais esforços de
segurança ainda mais eficazes.
Mesmo após um plano de correção ser escolhido, o método de modelagem de ameaças é um
processo repetitivo que deve ser executado regularmente com ações constantes de reavaliação
para assegurar que os esforços de segurança sejam os mais abrangentes possíveis.
Investigações e exames do histórico
A maioria das empresas já realiza algum tipo de verificação de histórico dos funcionários em
potencial como uma condição para sua contratação, mas não realizam novas verificações
depois. As empresas devem considerar a realização de verificações de histórico regularmente
durante o vínculo empregatício, especialmente dos funcionários em cargos críticos com acesso
a informações restritas.
Contratos de diretivas para uso de computador
Os contratos de utilização de computador e rede são importantes não apenas para informar os
funcionários sobre como eles podem usar os ativos da empresa mas também para informá-los
sobre as diretivas para monitoramento da atividade da rede e para o uso do computador, além
das possíveis conseqüências de qualquer tentativa de violação das diretivas.
As declarações das diretivas de utilização também atuam como documentos legais quando
definem essas questões em termos explícitos e requerem a assinatura do funcionário como
indicação de acordo. Sem uma prova de que o funcionário está plenamente ciente das diretivas
internas de monitoramento de segurança e de que se espera dele o uso aceitável dos ativos da
empresa, torna-se cada vez mais difícil processar violadores em caso de transgressão.
Também é importante emitir um aviso de uso e acesso não autorizados em qualquer ponto de
acesso na rede corporativa informando qualquer pessoa que tente acessá-la de que se trata de
uma rede privada e de que o acesso não autorizado a ela é proibido e poderá resultar em
processo judicial. Por exemplo, os sistemas operacionais Windows têm capacidade de exibir um
aviso durante um evento de tentativa de logon que pode ser usado para informar os usuários
de que estão prestes a tentar um acesso a um recurso corporativo protegido e que o acesso não
autorizado é proibido.
Embora esteja fora do escopo deste artigo tratar das questões legais envolvidas no teor e uso
exatos desse tipo de documento, é importante mencionar que os documentos e as diretivas
devem existir. Há na Internet muitos exemplos de declarações sobre uso e acesso, mas elas
devem ser preparadas com o suporte de consultores legais porque existem diversas questões
internacionais e locais exclusivas que exigem uma avaliação criteriosa.
Separação de tarefas
Assim como as diferentes funcionalidades do sistema são segmentadas pela rede para fins de
segurança, desempenho e disponibilidade, também é importante providenciar a duplicação e a
separação de tarefas quando se elaboram os requisitos da equipe para um departamento de
segurança de TI.
Funções importantes que envolvem acesso ou controle de dados e sistemas confidenciais
devem ser redundantes, sempre que possível e razoável, não apenas para proteção contra
problemas relativos a perda de informações, se o único membro da equipe que as detém for
embora, mas também para fornecer uma função de segurança em casos de sabotagem interna.
Por exemplo, seria difícil recuperar senhas de administrador se apenas um membro da equipe as
conhecesse e saísse da empresa sem fornecê-las a mais ninguém.
Além da redundância de funções, também é importante separar funções críticas, especialmente
para monitoramento de segurança. Quem gerencia a rede não deve ser também responsável
pelo exame das informações de auditoria de segurança, e a equipe de segurança não deve ter
direitos administrativos iguais aos dos administradores. Às vezes, também é importante
salvaguardar informações departamentais da equipe administrativa para depois aplicar a
13
separação de tarefas. Por exemplo, algumas empresas têm unidades organizacionais com seus
próprios sistemas ou contas administrativas, como o financeiro e os recursos humanos.
Observação Embora possa não ser possível impedir que detentores de conta de administrador
descubram soluções alternativas para a separação de tarefas, é importante pelo menos
estabelecer diretivas de conjunto para o uso autorizado pela autoridade administrativa que
adota o princípio de separação de tarefas.
Validar a funcionalidade de monitoramento de segurança
Os testes regulares de uma solução de monitoramento de segurança devem ser planejados
cuidadosamente antes da implementação de um tal programa. Embora os testes iniciais sejam
importantes para validar uma solução de monitoramento de segurança, é também importante
ter uma programação de testes que ocorram regularmente devido às constantes mudanças no
ambiente de segurança.
Os testes podem incluir tentativas de invasão e uso de privilégios administrativos para
determinar se a solução é eficaz na localização dessas atividades. Entretanto, também é
importante pesquisar as últimas alterações nas técnicas de segurança e perfis de ataque para
determinar se precisam ser feitas alterações. As ameaças a redes corporativas mudam
constantemente à medida que os hackers se ajustam às implementações de segurança, por isso
as defesas e técnicas de monitoramento devem estar sempre em evolução para que
permaneçam eficazes.
Estabelecer processos
Para separar eventos autorizados de não autorizados, é necessário criar um plano para o
controle de alterações obrigatórias e de processos de gerenciamento de problemas
estabelecidos. Esse plano pode fornecer uma trilha detalhada impressa que pode ter suas
informações cruzadas com as do log de segurança. Embora o acompanhamento de problemas
seja corriqueiro na maioria das empresas, por meio de pedidos do suporte técnico ou de outros
processos de acompanhamento de problemas, o controle de alterações é freqüentemente
negligenciado. O controle de alterações é um mecanismo necessário e pode ser usado não
somente para acompanhar tendências para descobrir sistemas ou aplicativos problemáticos,
mas também como um mecanismo de segurança fundamental.
Os processos de controle de alterações devem ocorrer como um procedimento proativo, e as
alterações reativas devem ser limitadas ao uso de um processo de gerenciamento de
problemas. Um processo de controle de alterações deve exigir envio e aprovação antes de
qualquer alteração e deve incluir os detalhes a seguir:
Nome do aprovador
Nome do implementador
Cronograma da alteração
Razões da alteração
Alterações a serem feitas
Sistemas afetados pela alteração
Impacto na empresa
Resultados reais da alteração
Um outro processo que deve ser estabelecido é o de configuração de usuário via um
procedimento para adicionar/alterar/excluir usuário que também cria uma trilha de auditoria
para a proteção contra alterações de conta não autorizadas. Antes de se estabelecer tal
processo, é importante executar uma auditoria de segurança das contas de usuário existentes
para verificar a validade delas e periodicamente validar a lista, já que ela muda.
O uso de configuração de usuário automática e de soluções de gerenciamento de identidades,
como o Microsoft Identity Integration Server (MIIS) 2003, pode ser útil também, pois automatiza
alterações em conta e os processos que estão por trás dessas atividades. Ao adotar tais
soluções, é importante lembrar-se de que as contas de administrador ainda retêm a capacidade
de criar novas contas mas que não precisam fazer isso, porque as contas seriam criadas pelos
14
processos estabelecidos. Portanto, todos os eventos associados com a criação de contas, como
o evento 624, devem ser correlacionados apenas ao MIIS 2003 ou outra conta de serviço
estabelecida que seja usada para configuração automática.
Embora ameaças externas a redes corporativas sejam constantemente divulgadas pela mídia, a
experiência mostra que redes e dados corporativos são muito mais vulneráveis a perdas ou
comprometimentos decorrentes de configurações incorretas ou de erros em etapas de
procedimentos. É importante se proteger de todas as ameaças externas e internas, e existem
muitos fornecedores que ajudam a proteger sua empresa contra ameaças externas, mas
nenhum deles consegue vender um pacote que impeça erros cometidos pelos responsáveis por
sua rede e sua segurança. A melhor forma de atenuar esses riscos é implementar e impor
processos e procedimentos seguros com relação a alterações executadas na rede.
Definir respostas da segurança
Para limitar os danos que uma violação de segurança pode causar, é importante desenvolver um
plano de resposta adequado predefinido e estabelecer processos para responder a incidentes.
Relatórios de incidentes, a formação de uma equipe de resposta rápida e um protocolo de
resposta de emergência são bons exemplos. A velocidade e a eficácia de respostas a incidentes
aperfeiçoarão o perfil de segurança de uma organização e limitarão os danos reais e percebidos
que uma tentativa de invasão pode causar.
A formação de um processo de resposta de segurança estabelecido não apenas ajuda a limitar
os danos que um incidente real pode causar, como também atua como um impedimento
porque notifica a equipe e outras pessoas de que um incidente provocará uma resposta,
coordenada e imediata, a qualquer violação de segurança.
Recursos humanos
De acordo com estudos feitos pelo CERT e pelo serviço secreto dos EUA, muitos ataques de
fontes internas poderiam ser evitados se as empresas estivessem mais conscientes e adotassem
medidas em resposta a alterações de comportamento ou ameaças de um funcionário.
Provavelmente, os recursos de segurança mais valiosos são os próprios funcionários, porque
eles sabem quando um membro da equipe se torna descontente ou alertam o pessoal
apropriado quando um visitante está agindo de forma suspeita. De fato, uma das primeiras
medidas de um grupo externo de auditoria de segurança será “dar um passeio” numa tentativa
de encontrar informações de senha escritas em papel, descobrir dispositivos inseguros ou tentar
invasões conectando-se diretamente à rede interna.
A equipe da empresa pode servir como uma camada importante de proteção contra ameaças
internas e externas. Encorajar diretivas de porta aberta para discutir comportamentos
preocupantes com os colegas e treinar o pessoal de suporte para emitir relatórios de atividade
incomum dos computadores com a equipe são medidas que podem realmente ajudar a atenuar
tentativas de invasão ou incidentes de malware. O treinamento interno é também importante
como um método de ensinar aos funcionários como descobrir tipos de comportamento de
computador que devem ser relatados. O treinamento também serve como medida preventiva
com respeito a evitar ataques de engenharia social.
Correlacionar violações de diretivas de segurança com eventos de auditoria Correlacionar informações de eventos de segurança envolve a coleta de eventos de segurança
de vários sistemas e a colocação desses dados em um local central seguro. Depois que as
informações de segurança forem correlacionadas, os responsáveis podem analisar o repositório
central para identificar violações ou ataques externos. O repositório é importante não apenas
para análise forense mas também como uma ferramenta para detectar ataques e solucionar
vulnerabilidades. Embora haja várias soluções de terceiros com essa finalidade, os seguintes
produtos e ferramentas da Microsoft podem ajudar a tratar essas necessidades, correlacionando
logs de eventos de segurança e outras informações de monitoramento de segurança em um
repositório central.
15
EventCombMT
EventCombMT (com vários segmentos) é um componente do Guia de Segurança do Windows
Server 2003, que está disponível em
http://www.microsoft.com/brasil/security/guidance/prodtech/win2003/secmod117.mspx. Essa
ferramenta pode analisar e coletar eventos dos respectivos logs em vários computadores. Ele é
executado como um aplicativo com várias camadas que permite ao usuário especificar qualquer
número de parâmetros na busca por logs de eventos, como:
Identificações de evento (individuais ou várias identificações)
Intervalos de identificações de evento
Origens de evento
Texto específico do evento
Duração do evento em minutos, horas ou dias
Figura 4. EventCombMT
Certas categorias de pesquisa específicas estão incorporadas no EventCombMT, como
bloqueios de contas (mostrados na figura anterior), que fornecem a funcionalidade de pesquisa
dos eventos a seguir:
529. Falha de logon (nome ou senha de usuário incorreto(a))
644. Conta de usuário bloqueada automaticamente
675. Falha de pré-autenticação no controlador de domínio (senha incorreta)
676. Falha no pedido de permissão de autenticação
681. Falha de logon
Outro evento relacionado à segurança que não reside no arquivo de log do sistema é o evento
12294, que vem do arquivo de log do sistema. É importante adicionar esse evento a todas as
pesquisas, porque ele pode ser usado para detectar tentativas de ataque contra a conta do
administrador que não tem um limite de bloqueio e é, portanto, um alvo vulnerável e tentador
para qualquer hacker.
16
Observação O evento 12294 aparece como um evento do SAM (Gerenciador de contas de
segurança) no log do sistema, e não no log de segurança.
O EventCombMT pode salvar eventos numa tabela de banco de dados do Microsoft SQL
Server™, o que é útil para armazenamento e análise a longo prazo. Depois de armazenadas em
um banco de dados SQL Server, as informações dos logs de eventos podem ser acessadas por
uma grande variedade de programas, como SQL Query Analyzer, Microsoft Visual Studio® .NET
ou por vários utilitários de terceiros.
Log Parser 2.2
O Log Parser é uma ferramenta gratuita disponível na Microsoft que pode ser usada para
pesquisar dados em um log, carregar logs em um banco de dados SQL ou arquivo CSV e gerar
relatórios a partir de logs de eventos, arquivos CSV ou outros formatos de log (inclusive logs IIS,
para os quais a ferramenta foi originalmente projetada).
Essa ferramenta de script pode ser usada como um recurso para correlacionar informações de
logs de eventos em um local central, analisar os eventos relevantes e, até mesmo, gerar
relatórios. Porém, a interface de linha de comando e script exige um nível de detalhe que está
além do escopo deste artigo. Mais informações sobre o Log Parser, seus usos e seus recursos de
script estão disponíveis na página Log Parser 2.2 (a página pode estar em inglês) em
www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx e no artigo "Como o Log
Parser 2.2 funciona" (a página pode estar em inglês) em
www.microsoft.com/technet/community/columns/profwin/pw0505.mspx.
EventQuery.vbs
EventQuery.vbs é uma ferramenta distribuída com o Windows XP. Ela pode ser usada para listar
eventos e suas propriedades a partir de um ou mais logs de eventos. O host de script baseado
em comando (CScript.exe) deve estar sendo executado para que se possa usar esse script. Se o
Host de scripts do Windows padrão não foi configurado como CScript, você pode fazê-lo
executando o seguinte comando:
Cscript //h:cscript //s //nologo
Esse utilitário de script de linha de comando é muito flexível e pode aceitar muitos parâmetros
diferentes para ajustar os filtros e o formato aplicados à sua saída. Para obter mais informações
sobre a utilização dessa ferramenta, consulte o tópico Gerenciando logs de eventos da linha de
comando na Documentação do produto Windows XP Professional (a página pode estar em
inglês) em www.microsoft.com/resources/documentation/windows/xp/all/proddocs/pt-
BR/event_commandline.mspx?mfr=true.
Log do IIS (Internet Information Services)
A funcionalidade de log adicional, disponível com o IIS (Internet Information Services), fornece a
capacidade de relatar a identidade dos visitantes do site, os objetos das visitas e quando elas
foram feitas. Os logs do IIS registram tentativas de acesso, com ou sem êxito, a sites, pastas
virtuais e arquivos, e podem ser configurados para fazer auditorias seletivamente dessas
informações para diminuir os requisitos de armazenamento e limitar o registro de informações
desnecessárias.
Esses logs podem ser armazenados em formato nativo como um arquivo que pode depois ser
filtrado com uma das ferramentas de análise e agrupamento listadas antes, ou armazenados
diretamente em um local central com o log de banco de dados ODBC, que pode ser usado para
armazenar as informações em um banco de dados SQL ou em qualquer outro banco de dados
compatível com ODBC.
Certas atividades e seqüências de eventos devem ser controlados de perto, incluindo o
seguinte:
Várias falhas de comandos que tentam executar scripts ou arquivos executáveis.
17
Várias falhas de tentativas de logon de um único endereço IP ou de um intervalo de
endereços, o que pode indicar uma tentativa de DoS (ataque de negação de serviço) ou
de elevação de privilégios.
Falhas de tentativas para acessar ou modificar arquivos .bat ou .cmd.
Tentativas não autorizadas de carregar arquivos para uma pasta que contém arquivos
executáveis.
Começando com o Windows Server 2003, novos recursos de auditoria estão incorporados no IIS
e podem ser usados com novos recursos de log do IIS, ou integrados diretamente no Log de
eventos ou, ainda, acessados com páginas ASP para soluções personalizadas. Para obter mais
informações sobre esses recursos e como implementá-los, consulte a documentação do IIS.
Microsoft Internet Security and Acceleration Server
O Microsoft Internet Security and Acceleration (ISA) Server é um firewall de camada de
aplicativo e pacote com informações de estado que também fornece funcionalidade adicional,
inclusive VPN e cache de proxy.
Além do utilitário de defesa ativa que o ISA Server fornece, ele também oferece uma função de
monitoramento de segurança, por funcionar como uma ferramenta de log centralizado que
monitora todas as atividades que passam pelo perímetro de uma rede. As capacidades de log
do ISA Server incluem captar tráfego no firewall, atividade de proxy da Web e logs de filtragem
de mensagens SMTP. Esses logs podem ser filtrados, consultados ou monitorados em tempo
real usando-se a opção Visualizar eventos em tempo real incorporada (mostrada na captura de
tela a seguir) ou o painel de controle de monitoração.
Figura 5. Visualizar eventos em tempo real do Microsoft ISA Server 2004
Além da funcionalidade de log incorporada, o ISA Server tem um recurso que pode emitir
alertas por email e entradas de log de eventos ou mesmo iniciar e parar serviços. A capacidade
18
de registrar atividades suspeitas em entradas do log de eventos é especialmente útil no escopo
deste artigo. Essa capacidade permite o registro e o armazenamento de informações sobre um
possível ataque em um local central, juntamente com outros dados do log de eventos de
auditoria.
Além da funcionalidade de log e alerta, existem também ferramentas de detecção de invasão
que podem ser ativadas no ISA Server. Esses IDSs (serviços de detecção de invasão) são
licenciados no ISS (Internet Security Systems) e incluem diversos filtros de pacote IP, filtros de
aplicativo DNS e um filtro de aplicativo POP. Esses serviços são capazes de detectar muitos
ataques comuns.
A funcionalidade de detecção de invasão no ISA Server é capaz de registrar eventos e gerar
alertas quando são detectados ataques em potencial. Ela também encerra serviços ou conexões
suspeitas. Alguns perfis de ataque que podem ser detectados incluem:
WinNuke (ataques fora da banda do Windows)
Ataques terrestres
Ataques de meia varredura IP
Bombas UDP
Varreduras de portas
Ataques de estouro do comprimento do nome de host DNS
Transferências de zona DNS a partir de portas TCP/IP altas ou privilegiadas
Em qualquer caso, usando o ISA Server ou qualquer outra solução de firewall ou IDS, é
importante considerar a rede de perímetro (conhecida como DMZ, zona desmilitarizada, e sub-
rede filtrada) ao se projetar um sistema de monitoramento de segurança e detecção de ataque.
Microsoft Operations Manager 2005
O MOM (Microsoft Operations Manager) monitora vários servidores em um ambiente
corporativo a partir de um local central. O agente do MOM coleta eventos nos logs de eventos e
os encaminha para o servidor de gerenciamento do MOM que, a seguir, coloca os eventos no
banco de dados do MOM. O MOM 2005 e suas versões mais recentes são capazes de coletar
eventos de computadores que não executam agentes do MOM.
O MOM usa suas regras do pacote de gerenciamento para identificar problemas que afetam a
eficácia operacional dos servidores. Podem ser criadas regras adicionais para monitorar eventos
específicos e, quando esses eventos ocorrerem, enviar notificações de alerta via email,
mensagens pop-up ou diretamente aos dispositivos pager.
Embora o MOM forneça muitos recursos úteis que podem ser usados para monitoramento de
segurança e detecção de ataque, ele não foi projetado para essa funcionalidade. Futuras versões
do MOM fornecerão maior funcionalidade de coleta de logs de segurança.
Microsoft Systems Management Server 2003
O SMS (Microsoft Systems Management Server) 2003 pode monitorar e gerenciar servidores e
estações de trabalho em uma rede a partir de um local central. Embora ele esteja preparado
para tarefas de gerenciamento, também pode ajudar a fornecer funções relativas à segurança
em uma solução de monitoramento de segurança, seja gerenciando a distribuição de
atualizações de segurança, seja relatando todas as instalações de software não autorizadas.
A funcionalidade de inventário do SMS pode ajudar a suprir uma necessidade vital em uma
solução de monitoramento de segurança, pois pode servir como uma solução de
gerenciamento de inventário em tempo real, o que é vital para qualquer processo de auditoria e
monitoramento de segurança.
Implementar análise forense A análise forense é um assunto amplo por si só, e este documento não pode explicar esse
tópico inteiramente. Em especial, este documento não discute os requisitos de tratamento de
provas da análise forense nem descreve dados forenses diferentes das informações fornecidas
pelos logs de eventos de segurança.
19
A determinação do momento, gravidade e resultados de violações de segurança e a
identificação de sistemas afetados por hackers podem ser realizados com análise forense. Para
serem eficazes, as informações reunidas para a análise forense devem conter o seguinte:
Hora do ataque
Duração do ataque
Sistemas afetados pelo ataque
Alterações feitas durante o ataque
Como se disse, por causa do grande número de detalhes envolvidos na compreensão das leis
que governam os procedimentos probatórios, os tipos de dados principais com relação à
investigação forense, as ferramentas requeridas para análise, coleta de provas, preservação de
provas e metodologias forenses, é impossível tratar desse assunto em detalhes neste
documento. Contudo, há alguns recursos excelentes, como First Responders Guide to Computer
Forensics (em inglês) do CERT em www.cert.org/archive/pdf/FRGCF_v1.3.pdf, disponíveis em
sites dedicados aos estudos sobre segurança.
Questões comerciais
Planejar o uso de análise forense é diferente de abordar outras soluções, porque a análise
forense envolve a investigação de incidentes após terem ocorrido, e não em tempo real.
Portanto, um histórico detalhado de eventos de vários sistemas deve ser mantido por um longo
período de tempo. Por causa dessa necessidade adicional, um sistema de análise forense eficaz
deve ser centralizado e ter uma capacidade considerável de armazenamento para guardar
inúmeros registros em uma estrutura de banco de dados apropriada.
Uma das decisões corporativas atenuantes refere-se ao tempo durante o qual esses registros
devem ser mantidos para análise forense e também que tipo de ciclo de retenção deve ser
usado. Esses fatores podem afetar muito os requisitos de armazenamento e equipamento para
o plano de análise forense. A tabela a seguir ilustra os períodos de retenção típicos que são
encontrados nas empresas que estabeleceram planos de análise forense.
Tabela 2. Limites de armazenamento para análise forense
Fatores de
armazenamento
Limites de
armazenamento Comentários
Armazenamento online
(banco de dados)
21 dias Permite acesso rápido a detalhes de
evento
Armazenamento offline
(backup)
180 dias Limite de arquivamento aceitável para
a maioria das organizações
Ambiente
regulamentado
7 anos Requisito de arquivamento para
empresas regulamentadas
Órgãos de inteligência Permanente Requisitos organizacionais de
inteligência e defesa
Observação Algumas práticas de setores regulamentados (como os que lidam com registros
médicos, por exemplo), usam especificações de limite de tempo em termos de “não reter além
de” em vez de um tempo de retenção definido.
20
Um opção a se considerar é o uso de bancos de dados online para reter dados de análise
forense online e depois arquivar eventos mais antigos em um formato compactável, como texto
delimitado por vírgula (conhecido como CSV, valores separados por vírgula) para o
armazenamento offline. Se necessário, os arquivos CSV podem ser importados de volta ao
banco de dados online para análise, se necessário.
Verifique se a solução selecionada, seja ela qual for, atende aos requisitos corporativos para a
rápida investigação de eventos recentes com a capacidade extra de recuperar eventos mais
antigos quando necessário. Um histórico de incidentes de segurança dentro de uma empresa,
juntamente com uma lista de recursos disponíveis, devem orientar o desenvolvimento de um
plano que forneça a melhor combinação de períodos de retenção de dados para
armazenamento online e offline. Se possível, teste o sistema de coleta de eventos em um banco
de dados bem grande, com os relatórios que deseja executar, e verifique se os relatórios são
executados em um tempo aceitável e se fornecem informações para uso jurídico.
A segurança dos dados de análise forense deve também ser considerada, porque o acesso a
eles raramente será necessário. Se o acesso for necessário, ele deverá ser fornecido somente a
algumas pessoas da segurança, selecionadas e confiáveis. O acesso de administrador a essas
informações deve ser regulamentado rigidamente dentro de um processo de controle de
alterações estabelecido que tenha supervisão de segurança adicional. Ninguém mais deve ter a
capacidade de acessar essas informações, interromper sua coleta ou modificá-las.
Questões técnicas
Planejar uma solução de monitoramento de segurança para análise forense exige cuidadosa
configuração para a coleta e o armazenamento seguros e confiáveis de um grande número de
eventos. Os requisitos de monitoramento de segurança são semelhantes àqueles detalhados em
outros cenários de solução, mas requerem muito mais recursos para o armazenamento em
banco de dados e o gerenciamento de dados altamente eficaz.
Alguns desafios técnicos que devem ser considerados incluem:
Armazenamento confiável e seguro para dados online.
Configuração de grandes espaços em disco de alto desempenho para o
armazenamento online.
Sistemas de backup confiáveis para armazenar eventos mais antigos em mídias de
arquivamento.
Processos seguros para gerenciar o armazenamento de arquivamento.
Processos de restauração testados para recuperar informações de armazenamento de
backup.
Esses desafios não devem ser específicos do monitoramento de segurança porque os
administradores de bancos de dados têm preocupações semelhantes com outros aplicativos,
como bancos de dados OLTP (processamento de transações online). Porém, diferentemente dos
aplicativos tradicionais de banco de dados, como o OLTP, um banco de dados de análise
forense deve lidar com um volume muito maior de gravações, e não de leituras.
Requisitos
Para planejar um programa de análise forense eficaz, os seguintes requisitos devem ser
cumpridos:
Configuração apropriada de parâmetros de logs de segurança.
Processos de verificação de entrada em logs de segurança já estabelecidos.
Ponto e processo de coleta, seguros e centralizados, criados para logs de segurança.
Armazenamento confiável para as informações de monitoramento de segurança.
Planos e cronogramas eficazes de armazenamento já desenvolvidos.
Os requisitos, capacidades e restrições de regulamentação de um ambiente corporativo devem
ser considerados em qualquer solução de análise forense, porque esses itens variam em cada
organização.
21
Implementando e gerenciando a solução
A capacidade de identificar, perfilar e responder a um ataque é a meta primordial de qualquer
solução para monitoramento de segurança e detecção de ataques. Por isso, a maior parte dessa
seção será uma discussão detalhada sobre eventos pertinentes que possam indicar ataques em
andamento quando descobertos em um log de eventos. Levando isso em consideração, um
plano de monitoramento de segurança e detecção de ataques deve atender aos seguintes
requisitos:
Detectar violações de diretivas internas
Identificar ataques de fontes externas
Permitir análise forense eficaz e precisa
A solução detalhada neste artigo usa componentes semelhantes para cada um desses três
requisitos. A implementação de recursos para análise forense tem requisitos adicionais que
serão tratados depois.
Monitoramento de segurança e detecção de ataques O conceito da solução para monitoramento de segurança e detecção de ataques exige o
planejamento de níveis apropriados de auditorias de segurança das áreas a seguir:
Gerenciamento de contas
Acesso a arquivo protegido
Alterações de diretivas de segurança
Criação e exclusão de confiança
Utilização de direitos de usuário
Reinícios do sistema e alterações de hora
Modificações de registro
Execução de programa desconhecido
O sistema de monitoramento de segurança e detecção de ataques coleta informações dos logs
de eventos de segurança e as agrupa em um local central. Os auditores de segurança podem
analisar esses dados em busca de atividade suspeita. Além disso, essas informações também
podem ser armazenadas e arquivadas para uma futura análise forense, se necessário.
Um dos principais componentes dessa solução é a capacidade de configurar um recurso do
Microsoft Windows 2003 com Service Pack 1 (SP1) e do Microsoft Windows XP com Service Pack
2 (SP2), chamado de auditoria por usuário. As auditorias por usuário permitem a especificação
de níveis de auditoria de contas específicas de usuário, o que, por sua vez, permite um nível
maior de detalhes de auditoria de contas confidenciais ou suspeitas.
Pré-requisitos da solução
A configuração desta solução para monitoramento de segurança e detecção de ataques tem os
seguintes pré-requisitos:
Os servidores devem executar o Windows Server 2003 SP1 ou posterior e residir em um
domínio do Active Directory.
Os computadores clientes devem executar o Windows XP SP2 ou posterior como
membros de um domínio do Active Directory.
Observação Se os computadores no perímetro de uma empresa não residirem dentro do
domínio, não poderão ser configurados com as configurações da Diretiva de Grupo do Active
Directory. Contudo, diretivas e modelos locais podem ser usados para configurar esses sistemas.
Este documento se concentra na identificação de assinaturas características de ataques e não
recomenda o uso de nenhuma tecnologia específica para o agrupamento de eventos de
segurança, embora liste algumas soluções possíveis. Após a decisão quanto ao mecanismo de
coleta apropriado, os eventos e as seqüências de eventos listados neste artigo podem ser
usados para projetar consultas e alertas para identificar comportamento suspeito.
22
Violações e limites de diretivas Novos recursos disponíveis no Microsoft Windows Server 2003 e no Microsoft Windows XP com
SP2 permitem níveis seletivos de auditoria em contas individuais de usuário. Por exemplo, os
níveis de auditoria podem ser configurados para relatar apenas atividade de logon e logoff de
todos os usuários, enquanto é feita a auditoria de todas as atividades de um usuário específico.
A auditoria seletiva por usuário também pode ser usada para reduzir o volume de eventos no
log de segurança, porque permite que certas contas sejam excluídas da geração de auditoria de
determinadas atividades. Somente contas de usuário podem ser auditadas com essa
funcionalidade; os grupos de segurança e de distribuição não podem ser auditados dessa
forma. As contas que pertencem ao grupo local de administradores não podem ser excluídas da
auditoria com o mecanismo de auditoria seletiva por usuário.
O utilitário de linha de comando usado para configurar a diretiva de auditoria seletiva por
usuário no Windows Server 2003 e no Windows XP SP2 é Auditusr.exe. As categorias de
auditoria seletiva válidas são:
Evento do sistema
Logon/Logoff
Acesso a objeto
Uso de privilégio
Acompanhamento detalhado
Alteração de diretiva
Gerenciamento de contas
Acesso a serviço de diretório
Logon de conta
Quando o Aauditusr.exe é executado a partir da linha de comando sem nenhum parâmetro, ele
exibe as atuais configurações de auditoria seletiva, que inicialmente ficarão em branco. Há duas
formas de preencher os parâmetros de auditoria seletiva: incluir manualmente um parâmetro
por usuário como parâmetros de linha de comando, ou incluir vários parâmetros por meio da
importação de um arquivo de configurações de auditoria por usuário.
A utilização do Audituser.exe ocorre como a seguir:
Audituser.exe /parameter useraccount:”category”
(ou uma lista de categorias delimitadas por vírgulas).
Por exemplo, para ativar a auditoria com falha de Eventos do sistema e de eventos de
Logon/Logoff em uma conta de nome LocalUser, seria utilizada a seguinte linha de comando:
Audituser /if LocalUser:”System Event”,”Logon/Logoff”
Os parâmetros a seguir podem ser usados na linha de comando:
/is – adiciona ou altera uma entrada incluir-êxito
/if – adiciona ou altera uma entrada incluir-falha
/es – adiciona ou altera uma entrada excluir-êxito
/ef – adiciona ou altera uma entrada excluir-falha
/r – remove entradas de auditoria por usuário de uma conta de usuário específica
/r – remove todas as entradas de auditoria por usuário de todas as contas de usuário
/e – exporta configurações para um nome de arquivo especificado
/i – importa configurações de um nome de arquivo especificado
Um arquivo de configurações de auditoria por usuário é um arquivo de texto sem formatação e
usa o formato mostrado na figura a seguir.
23
Figura 6. Exemplo de arquivo de importação Auditusr.exe
Observação O arquivo de importação deve iniciar com a linha “Auditusr 1.0” como mostrado
para a importação com êxito.
Portanto, para importar o arquivo de configurações de auditoria mostrado na figura anterior,
seria usado o seguinte comando:
Audituser /i path\audit.txt
Você pode usar esse utilitário para ajudar a estabelecer limites para informações de log de
auditoria, o que pode reduzir os requisitos de armazenamento e aumentar a probabilidade de
que as tentativas de invasão sejam percebidas.
Violação de diretivas de segurança e correlação de eventos de auditoria Embora esta seção não faça distinção entre violações de diretivas causadas por fontes internas
ou externas, é importante notar que as internas podem ser tão desastrosas para a empresa
quando as externas. Como observado anteriormente neste documento, um percentual
significativo de ataques mal-intencionados é perpetrado por fontes internas, e esse percentual
inclui danos acidentais causados pelo uso indevido de privilégios elevados fora do escopo dos
procedimentos estabelecidos.
Por causa do risco de abuso, acidental ou intencional, de privilégios elevados por fontes
internas, é importante estabelecer diretivas e procedimentos relativos ao uso apropriado desses
privilégios e estabelecer trilhas de auditoria para correlação cruzada. Após se instituir uma
diretiva de processo e documentação de gerenciamento de alterações, pode ser desenvolvida
uma correlação entre informações de auditoria e eventos aprovados e reprovados, facilitando,
assim, a capacidade de detecção de comportamentos incomuns dentro da empresa. Esta seção
ajudará nessa correlação, descrevendo os tipos diferentes de eventos que podem ser rastreados
e como podem se aplicar a diretivas e processos.
Acessando computadores não autorizados
Cada vez mais as equipes administrativa e de suporte usam recursos de gerenciamento remoto,
como Serviços de terminal, para se conectarem aos sistemas remotos e os gerenciarem. Esses
sistemas devem ser monitorados quanto a tentativas de logon interativas, e cada tentativa de
conexão deve ter a validade verificada. Essas verificações devem executar as seguintes ações:
Identificar logons de contas de serviço.
Registrar tentativas de acesso por contas não autorizadas.
Investigar tentativas provenientes de áreas geográficas incomuns.
Listar tentativas provenientes de intervalos de endereços IP externos.
24
É preciso dar atenção especial ao monitoramento de ativos de alto valor. Esses recursos críticos
residem em servidores específicos configurados com parâmetros rígidos de controle de acesso
e de monitoramento de auditoria.
A tabela a seguir lista eventos de auditoria de logon que devem ser comparados com eventos
de contas autorizadas quando vistos em sistemas de ativos de alto valor.
Tabela 3. Eventos de utilização de computadores não autorizados
Tabela 3. Eventos de utilização de computadores não autorizados
Identificação
do evento Ocorrência Comentários
528 Logon com
êxito
Verifique o nome da estação de trabalho e o
nome da conta de usuário. Verifique se o
endereço da rede de origem reside dentro de uma
rede.
529 Falha de logon
– nome de
usuário
desconhecido
ou senha
inválida
Verifique as tentativas onde o Nome da conta de
destino é igual a Administrador ou à conta padrão
do administrador renomeada. Verifique também
várias falhas de logon que estejam abaixo do
limite de bloqueio de conta.
530 Falha de logon
– Restrições de
tempo
Indica uma tentativa de logon fora do intervalo de
tempo permitido. Verifique o nome da conta de
usuário e o nome da estação de trabalho.
531 Falha de logon
– Conta
atualmente
desativada
Verifique o nome da conta de destino e o nome
da estação de trabalho. Esse evento pode indicar
tentativas de invasão por ex-usuários e requer
investigação.
532 Falha de logon
– A conta de
usuário
especificada
expirou
Verifique o nome da conta de destino e o nome
da estação de trabalho. Esse evento pode indicar
tentativas feitas por funcionários contratados ou
temporários e requerem investigação.
533 Falha de logon
– O usuário não
tem permissão
para efetuar
logon no
computador
Indica que o usuário pode estar tentando efetuar
logon em estações de trabalho restritas.
534 Falha de logon
– Tipo de logon
não permitido
Verifique o nome da conta de destino, o nome da
estação de trabalho e o tipo de logon. Esse evento
indica falha na tentativa de logon interativo com
25
credenciais de conta de serviço quando as
configurações da Diretiva de Grupo impedem
logons interativos nessas contas.
535 Falha de logon
– A senha da
conta de
especificada
expirou
Indica que o usuário está tentando fazer logon em
uma conta cuja senha expirou. Pode exigir
investigação caso se repita sem a respectiva
alteração de senha ou chamada de suporte.
536 Falha de logon
– O
componente
NetLogon não
está ativo
Verifique se o serviço NetLogon está em
operação. Do contrário, esse evento pode
requerer investigação.
540 Logon com
êxito
Esse evento equivale ao Evento 528 da rede.
Cavalos de Tróia, rootkits e malware
A identificação do evento 592 é muito útil para detectar ocorrências de cavalos de Tróia, rootkits
e outros tipos de malware, porque ela é criada sempre que um novo processo se inicia.
Qualquer ocorrência desse evento deve requerer investigação imediata sempre que o Nome do
arquivo de imagem não corresponder a um processo listado em uma lista de programas
aprovados.
Embora os cavalos de Tróia e os programas de registro de teclas sejam relativamente fáceis de
identificar, os rootkits têm uma capacidade de camuflagem especial. Eles podem ser detectados
localizando-se programas desconhecidos que iniciam e param em rápida sucessão. Entretanto,
quando um rootkit é iniciado, o sistema operacional não tem como detectá-lo e, assim, não
gera novos eventos.
Outras tentativas de malware podem tomar a forma de anexos de email ou sites infectados, e
podem tentar aumentar privilégios quando a conta de execução não tem os direitos para iniciar
novos programas. Nesses casos, o software não autorizado deve criar um evento de falha a ser
investigado, especialmente quando os seguintes eventos ocorrerem:
Processos gerados como LocalSystem. Os processos que são executados como
LocalSystem devem ser bem definidos em uma lista de programas aprovados e podem
incluir processos como Services.exe.
Processos gerados em horários inesperados. Se o sistema monitorado não usa
processos em lotes programados, certas atividades (como backups, CGI ou scripts)
devem ser investigadas quando ocorrerem. Em outros casos, deve ser feita uma
investigação quando tais eventos ocorrerem fora dos horários de lotes programados
regularmente.
26
Tabela 4. Evento 592
Tabela 4. Evento 592
Identificação
do evento Ocorrência Comentários
592 Criando
um novo
processo
Verifique as entradas Nome do arquivo de imagem e
Nome de usuário em busca de processos não
aprovados, horários de início inesperados ou
programas desconhecidos que iniciam e param em
rápida sucessão.
Acessar recursos alterando permissões de arquivo
É possível usar privilégios administrativos para acessar arquivos cujo acesso seria normalmente
negado alterando-se a propriedade dos dados e, depois, adicionando-se as contas à lista de
permissões de leitura para aqueles dados. Também é possível disfarçar essa atividade no
Windows Server 2003 alterando-se a propriedade e as permissões de volta às configurações
originais.
Nesse sentido, a identificação de dados e ativos de alto valor é importante, porque seria
contraproducente implementar uma auditoria de acesso a objetos para cada arquivo em uma
rede corporativa de empresa de médio porte, em vista do grande volume de eventos de acesso
que ocorre normalmente todos os dias. A auditoria de acesso a objetos deve ser ativada para
arquivos e pastas confidenciais; as entradas de ACL não são suficientes para a defesa apropriada
contra tentativas de acesso não autorizadas.
Para detectar atividades ilícitas de forma eficaz, os seguintes fatores devem ser facilmente
identificáveis para arquivos de alto valor:
Qual objeto foi alvo de uma tentativa de acesso?
Que conta foi usada para solicitar o acesso?
Que conta autorizou o acesso?
Qual foi o tipo de acesso tentado?
O evento teve êxito ou não?
Qual sistema foi usado para iniciar a tentativa?
O recurso de visualização de eventos incorporado não teve configurações de filtro suficientes
para identificar essas informações. Por isso, o EventCombMT ou algum outro mecanismo deve
ser usado para executar a análise.
Os eventos de auditoria de acesso a objetos na tabela a seguir indicam tentativas dessa
natureza.
Tabela 5. Eventos de alteração de permissões de arquivo
Identificação
do evento Ocorrência Comentários
560 Acesso
concedido a
objeto
existente
Indica uma solicitação de acesso a um objeto
concedida com êxito. Verifique ID de logon primário,
Nome de usuário cliente e Nome de usuário principal
para detectar o acesso não autorizado. Verifique o
27
campo Acessos para determinar o tipo de operação.
Esse evento detecta apenas solicitações de acesso; ela
não detecta se o acesso ocorreu.
567 Uma
permissão
associada a
um
identificador
utilizado
Indica a primeira ocorrência de um tipo de acesso a
um objeto e indica que as permissões foram alteradas
se o campo Acesso incluir “WRITE_DAC.” Correlacione
com o evento 560 comparando os campos de
identificação de identificador.
Acessar recursos redefinindo senhas
Alterações de senha somente devem ocorrer dentro de uma estrutura aprovada de
procedimentos estabelecidos. Níveis de auditoria configurados corretamente devem registrar os
eventos de gerenciamento de contas mostrados na tabela a seguir e correlacionar esses eventos
com os procedimentos registrados para identificar atividades que não obedeçam aos
procedimentos.
Tabela 6. Eventos de redefinição de senha
Identificação
do evento Ocorrência Comentários
627 Tentativa de
alteração de
senha
Indica uma solicitação de alteração de senha na qual
o solicitante forneceu a senha original. Compare o
Nome de conta principal com o Nome de conta de
destino para determinar se a conta solicitante é a
conta alterada.
628 Definição ou
redefinição
de senha de
conta de
usuário
Indica uma redefinição de senha proveniente de uma
interface administrativa, e não de um processo de
alteração de senha. O solicitante deve ser uma conta
autorizada, como a do suporte técnico, ou uma
conta que solicite uma redefinição de senha via
auto-atendimento.
698 Alteração de
senha do
modo de
restauração
dos serviços
de diretório
Indica uma tentativa de alteração de senha do modo
de restauração dos serviços de diretório em um
controlador de domínio. Verifique o IP da estação de
trabalho e o nome da conta. Esse evento exige uma
investigação imediata.
Modificação de conta de usuário
Qualquer modificação de conta, seja adicionar, excluir ou alterar, deve corresponder a um
processo estabelecido que envolve um processo de lógica comercial de várias etapas iniciado
por uma solicitação oficial proveniente de um funcionário com nível de gerenciamento. Todos
os eventos na tabela a seguir devem corresponder a uma solicitação de modificação de conta
oficial; do contrário, é exigida uma investigação imediata.
28
Tabela 7. Eventos de alteração de conta de usuário
Identificação
do evento Ocorrência Comentários
624 Criando uma
conta de usuário
Indica uma ocorrência de criação de conta na
rede.
630 Excluindo uma
conta de usuário
Indica uma ocorrência de exclusão de conta da
rede.
642 Alterando uma
conta de usuário
Indica alterações de conta de usuário relativas à
segurança que não estão incluídas nos eventos
627-630.
685 Alterando um
nome de conta
de usuário
Indica uma alteração de nome de conta de
usuário.
Para identificar de forma eficaz problemas de gerenciamento de contas, devem ser configuradas
consultas para se obter o seguinte:
Localizar atividades de conta irregulares ou incomuns.
Identificar contas de nível administrativo que abusem de privilégios para criar ou
modificar contas.
Detectar padrões de atividades de conta que ocorrem fora da diretiva de segurança da
organização.
Também é importante confirmar o intervalo entre a criação de uma conta, o logon inicial e a
alteração de senha. Se uma nova conta não for utilizada dentro de um período de tempo
predefinido (normalmente, um processo de criação de conta registra a data de início prevista
para um novo usuário), a conta deverá ser desativada e uma investigação deverá ser iniciada
para se descobrir o motivo do atraso.
Alterações em associações de grupo
Uma boa prática de segurança envolve o princípio do privilégio mínimo, que significa conceder
às contas o nível mínimo de acesso requerido para que elas possam executar suas funções
adequadamente. Quando essa prática é aplicada, a maioria das contas será membro do grupo
Usuários do domínio padrão com associação adicional a grupos de segurança específicos da
empresa.
Alterações em associações do grupo de segurança somente devem ocorrer de acordo com
diretrizes de diretiva estabelecidas, especialmente quando estiverem envolvidas contas com
privilégios elevados. Essas alterações em associações de grupo apenas devem ser executadas
por contas estabelecidas, utilizadas para gerenciamento de contas, e esses eventos devem ser
correlacionados a um processo estabelecido para essas alterações. Todas as alterações fora
desse processo exigem uma investigação imediata.
Na tabela a seguir, os eventos de auditoria de gerenciamento de contas detalham alterações em
associações de grupo.
Tabela 8. Eventos de alterações em associações de grupo
Tabela 8. Eventos de alterações em associações de grupo
29
Identificação
do evento Ocorrência Comentários
631, 632,
633, 634
Alteração de
grupo global
de
segurança
ativada
Examine o campo Nome da conta de destino para
determinar se o grupo alterado era global ou tinha
amplos privilégios de acesso.
635, 636,
637, 638
Alteração de
grupo local
de
segurança
ativada
Examine o campo Nome da conta de destino para
determinar se o grupo alterado era Administradores,
Operadores de servidor ou Operadores de cópia.
639, 641,
668
Alteração de
grupo de
segurança
ativada
Indica uma alteração em um grupo que não é
exclusão, criação ou alteração de associação. Examine
o Nome da conta de destino para se certificar de que
um grupo com privilégio alto não foi alterado.
659, 660, 661,
662
Alteração de
grupo
universal de
segurança
ativada
Examine o campo Nome da conta de destino para se
certificar de que um grupo com privilégio alto, como
Administradores de empresa, não foi alterado.
Observação A associação em grupos de distribuição não fornece acesso a recursos de rede,
pois os grupos de distribuição não são princípios de segurança. Entretanto, a associação em
certos grupos de distribuição pode criar problemas de segurança, dependendo do grupo. Por
exemplo, a inclusão de contas de usuário em um grupo de distribuição executivo ou de
gerenciamento pode fazer com que os usuários recebam mensagens de emails inapropriadas
para seus cargos.
Tentativas de utilização de contas não autorizadas
A promoção do primeiro controlador de domínio do Active Directory em uma floresta cria uma
conta de administrador que é membro de ambos os grupos: Administradores de domínio e
Administradores de empresa. Essa conta requer proteção especial porque ela é a única que não
é afetada por configurações de bloqueio de conta. Portanto, mesmo quando uma diretiva de
bloqueio de conta está vigorando, essa conta está especialmente vulnerável a ataques de
dicionário.
O monitoramento de segurança eficaz deve ser capaz de identificar todas as tentativas de logon
nessa conta de administrador, mesmo que ela tenha sido renomeada. Para obter mais
informações sobre o aumento de segurança em contas administrativas, consulte o Guia de
Planejamento de Segurança de Contas de Administrador em
http://www.microsoft.com/brasil/security/guidance/topics/sgk/default.mspx.
Além disso, tentativas de logon em contas desativadas ou expiradas podem indicar que um ex-
funcionário, funcionário temporário ou prestador de serviço tentou ter acesso à rede sem as
credenciais atualizadas. Esses eventos exigem investigação imediata.
A tabela a seguir lista eventos que identificam a utilização de conta não autorizada e que
pertencem às categorias de auditoria Logon de conta e Logon.
30
Tabela 9. Eventos de logon não autorizado
Identificação
do evento Ocorrência Comentários
528
540
Logon com
êxito
528 é um evento comum. Porém, o evento 540
deve gerar um exame do Nome da conta de
destino para determinar se ele foi causado pela
conta de administrador padrão.
529 Falha de logon
– nome ou
senha de
usuário
desconhecido(a)
Sempre investigue quando o Nome da conta de
destino for a conta de administrador ou a conta
de administrador padrão renomeada. Investigue
também se as falhas de logon estão logo abaixo
do limite de bloqueio. Além disso, verifique se
houve tentativas em que o Nome da conta de
destino seja administrador ou raiz e quando o
Nome de domínio seja desconhecido.
531 Falha de logon
– Conta
desativada
Examine o Nome da conta de destino e o Nome
da estação de trabalho para determinar a origem.
Esse evento deve exigir uma investigação, pois
pode indicar uma possível tentativa de invasão
por ex-usuários da conta.
532 Falha de logon
– Conta
expirada
Examine o Nome da conta de destino e o Nome
da estação de trabalho para determinar a origem.
Esse evento deve exigir uma investigação, pois
pode indicar uma possível tentativa de invasão
por ex-usuários da conta.
576 Privilégios
especiais
atribuídos ao
novo logon
Indica uma atribuição de privilégio que pode
conceder um privilégio administrativo à nova
conta ou a capacidade de alterar a trilha de
auditoria. Compare o campo de identificação de
logon com os eventos 528 ou 540 para determinar
facilmente se uma conta obteve equivalência de
administrador.
Uma outra questão de segurança que envolve o uso não autorizado de credenciais de conta
origina-se da utilização de diretivas de senhas eficazes, como diretivas de senhas de alta
segurança e períodos de expiração de senhas mais curtos; por vezes, os usuários anotam, ou
registram de alguma forma, as suas senhas de modo a se lembrarem delas. Essa questão é
especialmente evidente em ambientes que tenham vários armazenamentos de identidades sem
serviços de gerenciamento de identidades, o que exige o uso de várias senhas e contas.
31
Observação Para obter mais informações sobre o gerenciamento de senhas em ambientes
heterogêneos, consulte a Série de Gerenciamento de Identidade e Acesso da Microsoft (a
página pode estar em inglês) em
http://www.microsoft.com/technet/security/guidance/identitymanagement/idmanage/default.m
spx?mfr=true.
As organizações devem se proteger contra usuários que registram suas senhas, especialmente à
vista de todos, porque indivíduos não autorizados poderiam descobrir e usar essa informação
para iniciar um ataque. O monitoramento desse tipo de invasão é possível usando-se
informações da tabela anterior, mas envolve uma correlação cruzada dessas informações com
um histórico de logons com êxito na conta do usuário em questão, de modo que possa ser
criada uma lista de estações de trabalho comuns que aquela conta pode acessar, para fins de
comparação.
Observação É possível restringir contas de usuário a estações de trabalho específicas usando-
se a funcionalidade incorporada do Active Directory. Porém, para se usar essa funcionalidade, a
rede deve oferecer suporte à nomenclatura NetBIOS (sistema de entrada/saída da rede),
conforme fornecido pelo WINS (Windows Internet Naming Service), por exemplo.
Logon interativo com credenciais de contas de serviço
Quando os serviços são iniciados, eles devem apresentar credenciais de logon. Às vezes, certos
serviços podem requerer o uso de uma conta de domínio para executar serviços ou conectar
computadores remotos. Alguns serviços podem até mesmo requerer credenciais de
administrador ou devem interagir também com a área de trabalho.
No Windows Server 2003 e posterior, algumas contas de serviço (como o Serviço de alerta)
podem ser iniciadas com a opção –LocalService. Além disso, os serviços que requerem
conectividade de rede podem usar a conta de Serviço de rede NT AUTHORITY\Network Service.
Todos os serviços que requerem contas de usuário devem ser verificados para garantir que elas
estejam protegidas por senhas de alta segurança. O monitoramento de segurança deve
confirmar que os eventos de logon nessas contas ocorrem apenas quando os serviços
associados são iniciados. Para obter mais informações sobre o aumento de segurança para
contas de serviço, consulte o Guia de Planejamento de Segurança dos Serviços e Contas de
Serviço (a página pode estar em inglês)
http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.msp
x.
A principal preocupação da segurança com contas de serviço começa quando essas contas
fazem logon interativamente, e não como um serviço. Esses eventos ocorrem apenas quando
uma conta de serviço tornou-se comprometida por um invasor e efetua logon nessa conta. Se a
conta de serviço comprometida tiver privilégios de administrador, o invasor terá obtido acesso a
uma capacidade substancial e poderá interromper os serviços normais da rede.
Todos os recursos que as contas de serviço podem acessar devem ser identificados e não
devem ter permissões não explicadas que envolvam acesso a dados de alto valor. Por exemplo,
uma conta de serviço pode, às vezes, requerer acesso de gravação em um diretório de arquivo
de log, mas em geral esse não é o caso. As contas de serviço que podem interagir com a área
de trabalho merecem investigação especial porque elas fornecem maiores oportunidades ao
ataque de hackers.
A tabela a seguir lista eventos de auditoria de logon de conta e logon que identificam o uso não
autorizado de credenciais de contas de serviço.
Tabela 10. Eventos de logon com credenciais de contas de serviço
Tabela 10. Eventos de logon com credenciais de contas de serviço
32
Identificação
do evento Ocorrência Comentários
528 Logon com
êxito –
Ataque a
console ou
serviços de
terminal
Indica um ataque em andamento se um tipo de logon
10, uma conta de serviço ou a conta de sistema local
estiver associada a esse evento. Esse evento exige uma
investigação imediata.
534 Falha de
logon –
Tipo de
logon não
permitido
Indica falha na tentativa de logon interativo com
credenciais de conta de serviço quando estiver
proibido por configurações de Diretiva de Grupo.
Quando esse evento ocorrer, verifique o Nome da
conta de destino, o Nome da estação de trabalho e o
Tipo de logon.
600 Um token
primário
foi
atribuído a
um
processo
Indica que um serviço está usando uma conta
nomeada para fazer logon em um sistema que executa
o Windows XP ou posterior. Correlacione as
informações nos eventos 672, 673, 528 e 592 para
investigar.
601 Tentativa
do usuário
de instalar
um serviço
Esse evento não deve ocorrer com freqüência em um
ambiente corporativo com uma diretiva de aplicativos
aceitáveis e um processo de padronização de sistema
claramente definidos. Esse evento deve exigir
investigação quando os processos de controle de
alterações não se correlacionarem nesses ambientes.
Execução de programa não autorizado
Contas de nível de administrador têm capacidade para instalar e executar programas e,
portanto, são normalmente delegadas a pessoas confiáveis que requerem essas capacidades
elevadas. Por causa dos riscos associados a programas não testados, é importante projetar uma
lista de programas aprovados e licenciados juntamente com um processo para solicitação, teste
e aprovação de novos aplicativos. Os aplicativos não aprovados devem ser limitados a um
ambiente de teste isolado e não devem ser instalados no ambiente de rede de produção fora de
um processo de controle de alterações estabelecido. Mesmo assim, eles só devem ser
permitidos depois de adicionados a uma lista de programas aprovados.
A tabela a seguir lista eventos de acompanhamento de processos que podem identificar o uso
de programas não autorizados.
Tabela 11. Eventos de execução de programas não autorizados
Identificação
do evento Ocorrência Comentários
592 Criando
um novo
Indica que um novo processo foi criado. Examine os
campos Nome do arquivo de imagem e Nome de
33
processo usuário e compare com uma lista de programas
autorizados quando houver uma diretiva de programas
permitidos estabelecida na empresa. Procure também
ocorrências onde LocalSystem seja usado para iniciar
um prompt de comando, porque esse é um método
comum para escapar de uma trilha de auditoria.
602 Criando
um
trabalho
agendado
Examine os campos Nome de destino e Horário da
tarefa quando esses eventos ocorrerem em horários
inesperados.
Observação As auditorias de segurança para acompanhamento de processos são capazes de
identificar programas não autorizados. Entretanto, o acompanhamento de processos gera várias
entradas no log de segurança, por isso é preciso ter muito cuidado para que o número de
eventos não sobrecarregue os mecanismos de detecção de segurança.
Acesso a recursos não autorizados
A tabela de eventos de auditoria de acesso a objetos a seguir envolve tentativas de acesso a
recursos para os quais o usuário não tem autorização de uso.
Tabela 12. Tentativas de acesso a eventos de recursos não autorizados
Identificação
do evento Ocorrência Comentários
560 Acesso
recusado a
objeto
existente
Examine o campo Nome do objeto para determinar
o recurso acessado e correlacionar os campos Nome
de usuário principal e Domínio primário, ou os
campos Nome de usuário cliente e Domínio de
cliente para determinar a origem.
568 Tentativa de
criação de
um vínculo
físico com um
arquivo
auditado
Indica que um usuário ou programa tentou criar um
vínculo físico com um arquivo ou objeto. Um vínculo
físico estabelecido permite que uma conta manipule
um arquivo sem criar uma trilha de auditoria se a
conta não tiver direitos referentes ao objeto.
Uso de sistemas operacionais não autorizados
O uso de sistemas operacionais não autorizados pode causar problemas significativos que
variam desde a diminuição da proteção, por causa de ataques à vulnerabilidade, até o aumento
da probabilidade de corrupção de dados nos sistemas de arquivos. Os administradores e
usuários podem introduzir sistemas operacionais não autorizados em uma rede através dos
mecanismos a seguir:
Computadores pessoais conectados à rede local ou remotamente.
Sistemas operacionais inicializáveis via CD.
Reinstalação de um sistema operacional Windows.
Uso de imagens do PC Virtual.
34
As diretivas organizacionais podem especificar como os usuários podem se conectar à rede
remotamente, através de uma rede particular virtual ou de um serviço de acesso remoto, e
incluir requisitos para a conexão de sistemas, como o tipo do sistema operacional, o nível de
atualização e a instalação de medidas de proteção, como firewalls pessoais e software antivírus.
Para obter mais informações sobre como garantir que os sistemas remotos sejam compatíveis
com as diretivas de segurança da empresa, consulte o Guia de Planejamento de Implementação
dos Serviços de Quarentena com VPN da Microsoft(a página pode estar em inglês) em
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/quarantineservices/de
fault.mspx.
Também é possível que os usuários utilizem os CDs de instalação do Windows XP e reiniciem
seus computadores para instalar um sistema operacional não gerenciado. Nesses casos, talvez
seja possível detectar esse tipo de atividade pela localização das tentativas de logon de uma
conta de usuário Administrador a partir de um nome de grupo de trabalho não identificado ou
do nome de grupo de trabalho padrão.
Observação Estão disponíveis algumas distribuições de código-fonte aberto sob a forma de
CD inicializável que permite o uso do sistema operacional sem a instalação em um sistema local.
Como o sistema operacional não está, de fato, instalado no computador local, é difícil perceber
essa atividade. Entretanto, tentativas de logon de contas de usuários de nome “raiz” em um
ambiente de rede homogêneo ou de nomes de computador inesperados podem indicar a
utilização de um sistema operacional não autorizado. É possível impedir esse tipo de atividade
desativando a capacidade de inicialização via CD nas configurações do BIOS do computador e,
depois, protegendo por senha a configuração do BIOS, mas esse método pode não ser prático
em alguns ambientes.
Imagens do PC Virtual fornecem uma emulação completa de um ambiente de computador em
um computador host. Essa emulação executa seu próprio sistema operacional com seus
próprios nome de computador, contas de usuário, estrutura de serviços de diretório e
programas em um ambiente virtual. Uma instância de PC Virtual também é capaz de iniciar,
executar e parar independentemente de um sistema host e, portanto, provavelmente não criará
eventos de auditoria nesse computador host. Essa capacidade, mais a capacidade de um
computador virtual se conectar à rede do host, obter endereços IP e, até mesmo, mapear
unidades compartilhadas, apresenta vários riscos para a segurança, desde a proteção por senha
fraca até uma maior vulnerabilidade a ataques, porque tal capacidade provavelmente não seria
governada por nenhum processo de atualização estabelecido na rede. Devido aos riscos
apresentados por PCs virtuais, é importante restringir a utilização de software de PC virtual a
pessoas autorizadas e estabelecer processos documentados referentes à criação e à utilização
de instâncias de PC virtual.
Para detectar a utilização de sistema operacional não autorizado, uma solução de
monitoramento de segurança precisa ser capaz de detectar o seguinte:
Contas de usuário, nomes de computador, grupos de trabalho ou nomes de domínio
não reconhecidos.
Endereços IP duplicados ou fora do intervalo.
Tentativas de logon com conta de administrador padrão.
Os eventos de acompanhamento de processos listados na tabela a seguir podem ser usados
para detectar a utilização de sistemas operacionais não autorizados.
35
Tabela 13. Eventos de utilização de plataforma não autorizada
Identificação
do evento Ocorrência Comentários
529 Falha de logon – nome
ou senha de usuário
desconhecido(a)
Verifique as tentativas nas quais o campo
Nome da conta de destino seja
administrador ou raiz ou onde o Nome
de domínio seja desconhecido.
533 Falha de logon – O
usuário não tem
permissão para efetuar
logon no computador
Indica que o usuário pode estar tentando
efetuar logon em estações de trabalho
restritas.
592 Criando um novo
processo
Verifique os campos Nome do arquivo de
imagem e Nome de usuário para verificar
se a conta tem autorização para utilizar o
programa.
Criar ou invalidar relacionamentos de confiança
Relacionamentos de confiança permitem que as contas em um domínio acessem recursos que
residem em outro domínio. A criação de relacionamentos de confiança não é, obviamente, uma
operação rotineira e deve ocorrer somente dentro do escopo de um processo de controle de
alterações estabelecido. A invalidação ou quebra de relacionamentos de confiança também é
uma atividade que deve ser executada somente após aprovada em um processo de controle de
alterações e após a análise cuidadosa dos efeitos dessa ação sobre a rede.
Os eventos de auditoria de alteração de diretivas na tabela a seguir identificam atividades de
relacionamento de confiança.
Tabela 14. Eventos de alteração de relacionamentos de confiança
Identificação
do evento Ocorrência Comentários
610
611
620
Um
relacionamento
de confiança
com outro
domínio foi
criado,
excluído ou
modificado
Esses eventos serão gerados no controlador do
domínio que estabeleceu o relacionamento de
confiança. Esse evento deve exigir investigação
imediata quando não estiver correlacionado com
um processo de solicitação de controle de
alterações estabelecido. Examine o campo Nome
de usuário para determinar a conta solicitante.
Alterações de diretivas de segurança não autorizadas
Alterações em configurações de uma diretiva de segurança aprovada somente podem ocorrer
dentro da estrutura de um processo de controle de alterações estabelecido. Todas as alterações
que ocorrerem fora desse processo de aprovação devem exigir investigação imediata.
36
Esse tipo de alteração de diretivas de segurança inclui:
Configurações de Diretiva de Grupo
o Diretiva de senha de conta de usuário
o Diretiva de bloqueio de conta de usuário
o Diretiva de auditoria
o Configurações de log de eventos que se aplicam ao log de eventos de
segurança
o Diretiva IPsec
o Diretivas de rede sem fio (IEEE 802.1x)
o Diretivas de chave pública e de Sistema de arquivos com criptografia (EFS)
o Diretivas de restrição de software
Configurações de segurança
o Configurações dos direitos de usuário
o Diretiva de senha de conta de usuário
o Opções de segurança
A lista anterior representa apenas os requisitos mínimos, porque a maioria das empresas
provavelmente adicionará mais configurações de Diretiva de Grupo a seus ambientes. As
auditorias de segurança precisam identificar tentativas, com ou sem êxito, de alteração dessas
configurações, porque as tentativas com êxito devem corresponder a contas com a autoridade
para fazer as alterações dentro de um processo estabelecido para tanto.
A tabela a seguir lista eventos de auditoria de alteração de diretivas que identificam alterações
em Diretiva de Grupo e em diretivas do sistema local.
Tabela 15. Eventos de alteração de diretivas
Identificação
do evento Ocorrência Comentários
612 Alterando
diretiva de
auditoria
Indica uma alteração em uma diretiva de auditoria.
Esses eventos devem ser correlacionados com uma
diretiva de controle de alterações estabelecida para
determinar se elas foram autorizadas.
613
614
615
Alterando
diretiva IPsec
Indica uma alteração em uma diretiva IPsec. Deve
ser investigado quando ocorrer fora da inicialização
do sistema.
618 Diretiva de
recuperação
de dados
criptografados
Esses eventos ocorrem quando é usada uma diretiva
de recuperação de dados criptografados. Qualquer
ocorrência fora de diretivas especificadas exige uma
investigação.
Observação Para obter mais informações sobre configurações de Diretiva de Grupo, consulte
a seção "Configurações de diretiva de segurança" (a página pode estar em inglês) em
http://technet2.microsoft.com/WindowsServer/en/library/bcd7ea4c-f989-4cee-969a-
920f62f555111033.mspx?mfr=true.
Tentativa de comprometimento de credenciais
Os hackers podem usar diversos métodos, desde ataques de dicionário até esforços de
engenharia social, para obter credenciais de conta de usuário. Embora o método mais
conhecido envolva ataques de dicionário contra uma única conta, outro método comum é o uso
de um conjunto de senhas em todas as contas em um banco de dados de serviços de diretório.
No segundo caso, é provável que o hacker acesse o banco de dados de diretório da
organização ou adivinhe a nomenclatura de nomes de usuário e tenha uma lista de
37
funcionários. Para detectar esse tipo de ataque, é necessário ter a capacidade de detectar várias
falhas de logon em várias contas, mesmo que os limites de bloqueio de conta não tenham sido
acionados.
Redefinições de senha são outra forma de obter o controle de informações de credenciais de
contas. Como as operações de redefinição ou alteração de senha geram o mesmo evento,
tenham elas êxito ou não, um hacker pode evitar a detecção contornando a diretiva de bloqueio
de contas. Para impedir essas tentativas, uma solução de monitoramento de segurança deve ser
capaz de identificar várias tentativas de alteração ou redefinição de senhas, especialmente as
que ocorrerem fora de estruturas de processos corporativos e diretivas estabelecidas.
Embora testar um ciclo de senhas não seja um ataque (isso ocorre quando os usuários tentam
contornar as diretivas de reutilização de senhas usando scripts para passar por várias senhas e
tentar usar a senha original), ainda representa uma ameaça aos esforços de segurança. Durante
essas ações, o número de redefinições de senha será quase igual ao limite de reutilização de
senhas e, portanto, aparecerá como uma rápida série de eventos 627. A implementação de
diretivas de tempo de validade mínimo de senhas pode fazer essas tentativas falharem.
A tabela a seguir lista eventos que podem surgir de tentativas de ataque contra credenciais de
autenticação, mas esses eventos também podem ocorrer como parte de operações de rede
normais, como quando usuários legítimos se esquecem de suas senhas.
Tabela 16. Eventos de ataques contra credenciais de autenticação
Identificação
do evento Ocorrência Comentários
529 Falha de logon –
nome ou senha
de usuário
desconhecido(a)
Verifique se houve tentativas em que o Nome da
conta de destino seja administrador ou alguma
outra conta de nível administrativo que possa
não estar autorizada a alterar senhas. Verifique
também várias falhas de logon que estejam
abaixo do limite de bloqueio. Correlacione o
evento 529 com o evento 539 para identificar
padrões de bloqueios de conta contínuos.
534 Falha de logon –
Tipo de logon
não permitido
Indica que um usuário tentou fazer logon em um
tipo de conta proibido, como rede, interativo,
lote ou serviço. Verifique os campos Nome da
conta de destino, Nome da estação de trabalho e
Tipo de logon.
539 Conta bloqueada Indica uma tentativa de logon em uma conta que
foi bloqueada. Correlacione com o evento 529
para detectar padrões de bloqueios contínuos.
553 Repetição de
ataque detectada
Indica que um pacote de autenticação,
geralmente Kerberos, detectou uma tentativa de
logon pela repetição de credenciais de um
usuário. Embora esse evento possa ser sinal de
uma configuração de rede incorreta, ele ainda
exige uma investigação imediata.
627 Tentativa de Indica que alguém que não é o detentor da
38
alteração de
senha
conta tentou alterar uma senha quando o campo
Nome de conta primário não correspondeu ao
campo Nome da conta de destino.
628 Definição ou
redefinição de
senha de conta
de usuário
Essa atividade deve ser restrita a contas
autorizadas, como uma conta do suporte técnico,
ou uma conta que solicite uma redefinição de
senha via auto-atendimento.
644 Conta de usuário
bloqueada
automaticamente
Indica um bloqueio de conta porque o número
de sucessivas tentativas malsucedidas de logon é
maior que o limite de bloqueio da conta.
Correlacione com os eventos 529, 675, 681 e 676
(apenas Windows 2000 Server). Consulte
também a entrada do evento 12294 nesta tabela.
675 Falha na pré-
autenticação
Indica um possível problema de sincronização de
hora ou contas do computador que não estão
corretamente associadas ao domínio.
Correlacione com o evento 529 para determinar
o motivo exato da falha de logon.
12294 Tentativa de
bloqueio de
conta
Indica um possível ataque de força bruta contra a
conta de administrador padrão. Como as
diretivas de bloqueio de conta não são impostas
a essa conta, o ataque é registrado como evento
do SAM 12294 no log de eventos do sistema.
Qualquer ocorrência desse evento exige uma
investigação porque ele pode indicar o uso de
um sistema operacional não autorizado.
Verifique o campo Nome de domínio em busca
de domínios desconhecidos.
Ataques a vulnerabilidades
As vulnerabilidades são o alvo principal do ataque de um hacker em uma tentativa de invasão
porque elas podem existir em qualquer computador e exigem tempo e esforço para sua
correção. O tempo entre a descoberta das vulnerabilidades e o desenvolvimento de formas de
ataque contra elas, normalmente chamado de 'vulnerabilidade para janela de ataque', tem se
tornado menor, o que significa que há menos tempo para desenvolver, testar e distribuir
patches para essas vulnerabilidades.
A melhor defesa contra ataques a vulnerabilidades ainda é um processo eficaz de
gerenciamento de patches que testa e implanta rapidamente as atualizações dentro de um
ambiente. Alguns serviços que podem ajudar nesse processo são o Microsoft Systems
Management Server (SMS) 2003 ou o Windows Software Update Service (WSUS).
Com relação a isso, o monitoramento de segurança na rede de perímetro também é muito
importante porque os computadores que residem lá estão mais disponíveis para um hacker.
Sem mecanismos instalados para detectar ataques no momento em que ocorrem, uma
organização pode vir a se dar conta dos danos somente após a rede estar comprometida. Por
isso, é fundamental que os computadores residentes na rede de perímetro sejam
cuidadosamente monitorados quanto a um amplo espectro de eventos de auditoria.
39
Além dos eventos já discutidos, os eventos mais notórios detalhados na seção “Tentativa de
comprometimento de credenciais" incluem tentativas de acesso não autorizado e utilização de
identidade com privilégio. A tabela a seguir lista alguns eventos que podem identificar esses
ataques.
Tabela 17. Eventos de vulnerabilidade causados pela exploração de vulnerabilidade de
elevação de privilégios
Identificação
do evento Ocorrência Comentários
528
538
Logon e
logoff
locais
Correlacione o campo de identificação de logon
quando esses eventos ocorrerem em computadores de
perímetro. Exigem investigação quando os campos
Nome de conta de usuário, Hora ou Nome da estação
de trabalho contiverem valores inesperados.
551 Usuário
inicia o
logoff
Esse evento pode ser considerado equivalente ao
evento 538, porque um vazamento de token pode
causar uma falha na auditoria do evento 538 mas, em
vez disso, causará a ocorrência do evento 551.
576 Logon
privilegiado
Indica um logon de conta de administrador, um logon
de conta com privilégios suficientes para interferir no
TCP (base em computação confiável) ou para assumir
o controle de um computador em um Windows Server
2003 com SP1 ou posterior. Nas versões anteriores do
Windows, esse evento só gera interesse se associado a
privilégios confidenciais, como SeSecurityPrivilege ou
SeDebugPrivelege.
Observação Nas versões do Windows anteriores ao Windows Server 2003, o evento 576 é
listado na categoria Uso privilegiado. No Windows Server 2003 e posterior, a categoria Logon
também lista esse evento. Por isso, a configuração de parâmetros de auditoria para uma ou
outra categoria fará o evento aparecer.
Tentativas de contornar a auditoria
Assim como existem vários métodos de ataque a uma rede corporativa, existem também várias
técnicas para ocultar as tentativas e evitar sua descoberta. Por exemplo, um hacker pode alterar
a diretiva de segurança em um sistema ou domínio comprometido para impedir que os logs de
eventos registrem atividades suspeitas, ou um log de segurança pode ser deliberadamente
apagado de modo que as informações auditadas se percam.
É possível detectar tentativas de enganar uma solução de monitoramento de segurança com
essas técnicas, mas trata-se de um desafio porque muitos dos mesmos eventos que podem
ocorrer durante uma tentativa de cobrir as pistas da atividade invasiva ocorrem regularmente
em qualquer rede corporativa típica.
A tabela com vários tipos de evento a seguir pode ajudar a identificar tentativas de enganar a
auditoria feitas por hackers que tentam ocultar provas de uma violação de segurança.
40
Tabela 18. Eventos de contorno da auditoria de eventos
Identificação
do evento Ocorrência Comentários
512 Inicialização
do Windows
Em geral, ocorre após o evento 513. Reinícios
inesperados devem ser investigados.
513 Desligamento
do Windows
Em geral, ocorre antes do evento 512.
Computadores de alto valor só devem ser reiniciados
por pessoal autorizado e, mesmo assim, somente de
acordo com um controle de alterações ou outro
procedimento estabelecido. A ocorrência desse
evento em qualquer servidor deve exigir
investigação imediata.
516 Falha de
auditoria
Esse evento pode ocorrer quando muitos eventos
sobrecarregam o buffer do log de eventos ou
quando o log de segurança não está configurado
para sobrescrever. Embora esses problemas possam
ser evitados limitando-se os tipos de evento
monitorados na maioria dos computadores, as
máquinas de alto valor ou vulneráveis requerem
monitoramento mais detalhado de sua proteção e,
portanto, precisam ser cuidadosamente controladas.
517 Limpando o
log de
eventos de
segurança
Os logs de eventos de segurança nunca devem ser
limpos sem autorização. Verifique os campos Nome
de usuário cliente e Domínio de cliente para fazer a
correlação cruzada com os registros de pessoal
autorizado e aprovação de procedimentos.
520 Alterando a
hora do
sistema
Essa atividade pode ser usada para enganar
investigações forenses ou fornecer falso álibi aos
hackers. Verifique os campos Nome de usuário
cliente e Domínio de cliente para fazer a correlação
cruzada com os registros de pessoal autorizado,
além de verificar o Nome do processo para se
certificar de que esteja listado como
%windir%\system32\svchost.exe.
521 Não é
possível
registrar
eventos no
log
Ocorre quando o Windows não consegue registrar
eventos no log de eventos. Esse evento deve ser
investigado sempre que ocorrer em qualquer
sistema de alto valor.
608 Foi atribuído
um privilégio
de conta de
Ocorre quando um novo privilégio é atribuído a uma
conta de usuário. O log de eventos registra essa
ação juntamente com o SID (identificador de
41
usuário segurança) da conta de usuário, e não o nome da
conta de usuário.
609 Foi removido
um privilégio
de conta de
usuário
Ocorre quando um privilégio foi removido de uma
conta de usuário. O log de eventos registra essa
ação juntamente com o SID da conta de usuário, e
não o nome da conta de usuário.
612 Alterando
diretiva de
auditoria
Embora esse evento não indique necessariamente a
existência de um problema, um hacker pode
modificar diretivas de auditoria como parte de um
ataque. Esse evento deve ser monitorado em
computadores de alto valor e em controladores de
domínio.
621 Acesso ao
sistema
concedido a
uma conta
Ocorre quando o acesso a um sistema é concedido a
um usuário. Os campos Nome de usuário e Conta
modificada devem ser verificados quando a
permissão de acesso é listada como interativa.
622 Acesso ao
sistema
removido de
um sistema
Esse evento pode indicar que um hacker tentou
remover provas que envolvem o evento 621 ou está
tentando negar serviço a outra(s) conta(s).
643 Alterando
diretiva de
segurança de
domínio
Ocorre quando existe uma tentativa de modificar
configurações de diretiva de senha ou diretiva de
segurança de domínio. Verifique o Nome de usuário
e correlacione com todos os registros de
autorização.
Análise forense Embora a análise forense se baseie em muitos elementos discutidos neste documento, ela ainda
é fundamentalmente diferente de outras soluções de monitoramento e detecção de ataque
abordadas, porque se concentra no armazenamento e na análise de informações de segurança e
é usada em resposta a um ataque após sua ocorrência. A maioria das investigações forenses
começa como uma lista de eventos associados a um usuário ou sistema específico.
O monitoramento de segurança para análise forense requer:
Arquivamento de tipos de evento selecionados.
Uma estimativa do número esperado de eventos por dia.
Definição de limites de tempo para armazenamento online, offline e arquivamento.
Bancos de dados ajustados para lidar com o número esperado de eventos.
Sistema de backup capaz de lidar com a carga diária de eventos esperada.
Definição de diretivas relativas ao gerenciamento do sistema de arquivamento.
Existem três fatores principais para determinar os requisitos de armazenamento para um
programa de análise forense:
O número de eventos que deve ser registrado.
A taxa em que esses eventos são gerados por computadores de destino.
A duração do armazenamento online para fins de disponibilidade.
42
A compreensão das necessidades da empresa, juntamente com as informações fornecidas nas
seções anteriores, devem ajudar na tomada de decisões relativas a esses três fatores de modo
que requisitos de armazenamento aceitáveis possam ser atendidos.
Início da página
Resumo Fica claro que, nos atuais ambientes de rede, uma solução eficaz e abrangente para
monitoramento de segurança e detecção de ataques não é opcional e, sim, necessária para
qualquer empresa de médio porte. As ameaças e os riscos que as redes corporativas enfrentam
são numerosos e não se originam apenas de fora do perímetro, mas incluem também ameaças
internas, tanto intencionais quanto acidentais. Sistemas de monitoramento de segurança bem
elaborados levam em conta todos os riscos e exigem uma compreensão plena desses riscos,
além da arquitetura da rede corporativa e dos elementos comuns de ameaças e atividades
potenciais que poderiam colocar em perigo os dados residentes nos sistemas dessas redes.
A Microsoft, obviamente, considera a segurança com muita seriedade e, por conseguinte, tem
fornecido muitas ferramentas que podem ser usadas para ajudar a criar um sistema eficaz de
monitoramento de segurança e detecção de ataques. O Windows Server 2003 e outras versões
do sistema operacional Windows ajudam a fornecer a base para essa solução de
monitoramento de segurança com suas funcionalidades de log de auditoria de segurança
incorporadas. Quando combinadas com outros componentes, como o Microsoft Operations
Manager e o EventCombMT, e com as diretivas e processos corporativos necessários, pode ser
desenvolvido um sistema de monitoramento abrangente.
Início da página
Apêndice A: Excluindo eventos desnecessários Os eventos listados na tabela a seguir são normalmente excluídos das consultas de
monitoramento de segurança por causa de sua freqüência e porque, em geral, não fornecem
resultados úteis quando incluídos em uma solução para monitoramento de segurança.
Tabela A1. Eventos desnecessários
Identificação
do evento Ocorrência Comentários
538 Logoff de usuário Esse evento não indica necessariamente a hora
em que um usuário parou de usar o sistema. Por
exemplo, se o computador é encerrado ou
perde conectividade de rede, pode não registrar
um evento de logoff.
562 Um identificador
de um objeto foi
fechado
Sempre registrado como êxito.
571 Contexto de
cliente excluído
pelo Gerenciador
de Autorização
Ocorrência esperada quando o Gerenciador de
Autorização está em uso.
573 O processo gera Atividade esperada.
43
evento de
auditoria que não
é do sistema com
AuthZ API
(Authorization
Application
Programming
Interface)
577
578
Chamada de
serviço com
privilégios,
Operação de
objetos com
privilégios
São eventos de alto volume que, normalmente,
não contêm informações suficientes para exame
porque não descrevem qual operação ocorreu.
594 Um identificador
de um objeto foi
duplicado
Atividade esperada.
595 Foi obtido acesso
indireto a um
objeto
Atividade esperada.
596 Backup da chave
mestra de
proteção de
dados
Atividade esperada. Ocorre a cada 90 dias sob
configurações padrão.
597 Recuperação da
chave mestra de
proteção de
dados
Atividade esperada.
672 Solicitação de
permissão
Kerberos AS
Não contém informações adicionais se os
detalhes de auditoria provenientes dos eventos
de logon 528 e 540 já tiverem sido coletados.
Esse evento registra que um TGT Kerberos foi
concedido, e o acesso real não ocorrerá até que
uma permissão de serviço seja concedida, o que
é auditado pelo evento 673. Se PATYPE for
PKINIT, o logon foi feito via cartão inteligente.
680 Logon de conta Atividade já registrada por outros eventos.
697 Diretiva de senha
de verificação de
API chamada
Atividade esperada.
44
768 Colisão de
espaços para
nome em floresta
Esse evento não está relacionado à segurança.
769
770
771
Informações de
floresta confiáveis
adicionadas,
excluídas ou
modificadas
Atividade esperada. Esses eventos não devem
ser confundidos com a adição, modificação ou
exclusão da própria confiança.
832
833
834
835
836
837
838
839
840
841
Vários eventos de
replicação do
Active Directory
Esses eventos não estão relacionados à
segurança.
Observação Existem alguns riscos associados com a exclusão de quaisquer informações de
uma auditoria, mas esse nível de risco deve ser comparado com os benefícios envolvidos na
redução da carga sobre um agente de análise.
Início da página
Apêndice B: Implementando configurações de Diretiva de
Grupo Este apêndice deve ser usado para verificar as configurações atuais em um ambiente e inclui
configurações adicionais que afetam o monitoramento de segurança e a detecção de ataques.
Para configurar corretamente os eventos de auditoria de segurança de Diretiva de Grupo, as
configurações na tabela a seguir têm que ser aplicadas.
Tabela B1. Configurações de auditoria de segurança de Diretiva de Grupo
Caminho
da
diretiva
Diretiva Configuração da diretiva e comentários
Diretivas
locais/
Diretiva
de
auditoria
Eventos de logon
de conta de
auditoria
Ative a auditoria com êxito para todos os
computadores porque esse evento registra quem
acessa o computador. Ative a auditoria sem êxito
com cuidado porque um hacker com acesso à rede,
mas sem credenciais, pode iniciar um ataque DoS
(negação de serviço) forçando o computador a
consumir recursos enquanto registra esses eventos.
Ative também a auditoria com êxito com cuidado
porque essa configuração pode resultar em
ataques DoS se os computadores estiverem
configurados para modo de desligamento quando
45
os logs de auditoria estiverem cheios. Correlacione
todos os logons de administrador com todas as
entradas suspeitas.
Diretivas
locais/
Diretiva
de
auditoria
Gerenciamento de
conta de auditoria
Ative eventos com êxito e sem êxito. Correlacione
todas as entradas de auditoria com êxito com
autorizações de administrador. Todas as falhas
devem ser consideradas suspeitas.
Diretivas
locais/
Diretiva
de
auditoria
Acesso a serviço
de diretório de
auditoria
A Diretiva de Grupo de controladores de domínio
padrão ativa essa configuração por padrão.
Configure parâmetros de auditoria em objetos de
diretório confidenciais usando SACLs (listas de
controle de acesso do sistema) em Usuários e
Computadores do Active Directory ou ADSI Editar
(Active Directory Services Interface Editor). Você
deve planejar a implementação de SACLs e deve
testá-las em um ambiente de teste real antes de
implantá-las em um ambiente de produção. Esse
método impede a sobrecarga dos logs de
segurança com excesso de dados.
Diretivas
locais/
Diretiva
de
auditoria
Eventos de logon
de auditoria
Ative a auditoria com êxito para todos os
computadores porque esse evento registra quem
acessa o computador. Ative a auditoria sem êxito
com cuidado porque um hacker com acesso à rede,
mas sem credenciais, pode iniciar um ataque DoS
(negação de serviço) gerando falhas em excesso.
Diretivas
locais/
Diretiva
de
auditoria
Acesso a objetos
de auditoria
Tenha cuidado ao ativar essa configuração porque
ela pode resultar em um volume muito alto de
auditoria. Configure os parâmetros de auditoria
apenas para pastas de alto volume via SACLs e
somente faça a auditoria de tipos específicos de
acesso que sejam de interesse. Se possível, faça
auditoria apenas de eventos de gravação, e não de
eventos de leitura.
Diretivas
locais/
Diretiva
de
auditoria
Alteração de
diretiva de
auditoria
Ative auditoria com êxito e sem êxito. Faça a
correlação cruzada de todos os eventos com êxito
com as autorizações administrativas.
Diretivas
locais/
Diretiva
de
Auditoria de uso
de privilégios
Não ative a auditoria para uso de privilégio por
causa do grande volume de eventos que essa
configuração gera.
46
auditoria
Diretivas
locais/
Diretiva
de
auditoria
Acompanhamento
do processo de
auditoria
Ative essa configuração em computadores
vulneráveis e investigue imediatamente atividades
inesperadas de aplicativos, isolando o sistema se
necessário. Não ative essa configuração em
servidores Web CGI (Common Gateway Interface),
sistemas de teste, servidores que executam
processos em lotes ou estações de trabalho de
desenvolvedores porque ela pode encher os logs
de evento.
Diretivas
locais/
Diretiva
de
auditoria
Auditoria de
eventos de
sistema
Ative auditoria com êxito e sem êxito.
Diretivas
locais/
Atribuição
de
direitos
de
usuário
Gerar auditorias
de segurança
Essa configuração é atribuída por padrão a Sistema
local, Servidor local e Serviço de rede. Esse direito
somente deve ser aplicado a contas de serviço e a
mais nenhuma outra. Um hacker pode usar essa
configuração para gerar eventos espúrios ou
imprecisos no log de segurança.
Diretivas
locais/
Atribuição
de
direitos
de
usuário
Gerenciar log de
auditoria e de
segurança
Use essa configuração para evitar que os
administradores façam alterações nas
configurações de auditoria em arquivos, pastas e
no Registro. Considere criar um grupo de
segurança de administradores que tenha
permissão para alterar configurações de auditoria e
remover o grupo de administradores das
configurações da Diretiva de Segurança Local.
Apenas os membros de um grupo de segurança
devem poder configurar a auditoria.
Diretivas
locais/
Opções
de
segurança
Auditoria: Fazer
auditoria do
acesso a objetos
do sistema global
Essa configuração adiciona SACLs a objetos do
sistema nomeados, como exclusões mútuas,
semáforos e dispositivos MS-DOS. As
configurações padrão do Windows Server 2003
não ativam essa opção. Não ative essa
configuração porque ela resulta em um grande
volume de eventos.
Diretivas
locais/
Opções
de
Auditoria: Fazer
auditoria do uso
de privilégio de
backup e
Operações de backup e restauração fornecem uma
oportunidade de roubo de dados por meio do
contorno das ACLs. Não ative essa configuração
porque ela resulta em um volume muito grande de
47
segurança restauração eventos.
Diretivas
locais/
Opções
de
segurança
Auditoria: Desligar
o sistema
imediatamente se
não for possível
registrar eventos
de segurança
Somente ative essa configuração após avaliação
criteriosa e apenas em computadores de alto
volume porque os hackers podem usá-la para
iniciar ataques DoS.
Log de
eventos
Tamanho máximo
do log de
segurança
As configurações recomendadas dependem de
volumes de eventos projetados e de configurações
para retenção de logs de segurança. Essa
configuração só pode usar incrementos de 64 KB, e
o tamanho médio de cada evento é 0,5 KB. Em
ambientes de alto volume, essa configuração pode
ser definida até 250 MB, mas o tamanho total de
todos os logs de eventos combinados não pode
exceder 300 MB.
Log de
eventos
Impedir que
grupos de
convidados locais
acessem o log de
segurança
O Windows Server 2003 ativa essa configuração
por padrão, não a altere.
Log de
eventos
Reter log de
segurança
Somente ative essa configuração se o método de
retenção selecionado for “Substituir eventos
periodicamente”. Se for usado um sistema de
correlação de eventos que pesquisa eventos,
verifique se o número de dias é, pelo menos, três
vezes maior que a freqüência da pesquisa para
permitir falhas nos seus ciclos.
Log de
eventos
Método de
retenção do log
de segurança
Ative a configuração Não substituir eventos em
ambientes de alta segurança. Se esse for o caso,
estabeleça procedimentos para esvaziar e arquivar
os logs regularmente, em especial se estiver
ativada a configuração Desligar o sistema
imediatamente se não for possível o log de
auditorias seguras.