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.