Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar
7 de 7 pessoas classificaram isso como útil - Avalie este tópico

Monitoramento de segurança e detecção de ataques

Publicado em: 29 de agosto de 2006

Nesta página

Introdução
Definição
O desafio das empresas de médio porte
Soluções
Resumo
Apêndice A: Excluindo eventos desnecessários
Apêndice B: Implementando configurações de Diretiva de Grupo

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:

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.

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:

Figura 1. Aplicando MOF

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.

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.

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

Cc875806.SMAAD2(pt-br,TechNet.10).gif

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.

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

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:

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

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 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:

  • 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 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 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 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.

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

Cc875806.SMAAD4(pt-br,TechNet.10).gif

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.

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.

  • 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.

Cc875806.SMAAD5(pt-br,TechNet.10).gif

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

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.

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.

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.

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.

Figura 6. Exemplo de arquivo de importação Auditusr.exe

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.

É 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

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

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

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

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.

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.

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.mspx?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.mspx.

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

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 processo

Indica que um novo processo foi criado. Examine os campos Nome do arquivo de imagem e Nome de 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.

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/default.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.

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.

Esse tipo de alteração de diretivas de segurança inclui:

  • Configurações de Diretiva de Grupo

    • Diretiva de senha de conta de usuário

    • Diretiva de bloqueio de conta de usuário

    • Diretiva de auditoria

    • Configurações de log de eventos que se aplicam ao log de eventos de segurança

    • Diretiva IPsec

    • Diretivas de rede sem fio (IEEE 802.1x)

    • Diretivas de chave pública e de Sistema de arquivos com criptografia (EFS)

    • Diretivas de restrição de software

  • Configurações de segurança

    • Configurações dos direitos de usuário

    • Diretiva de senha de conta de usuário

    • 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 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 alteração de senha

Indica que alguém que não é o detentor da 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.

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.

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 usuário

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

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.

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.

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 evento de auditoria que não é do sistema com AuthZ API (Authorization Application Programming Interface)

Atividade esperada.

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.

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.

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 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

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.

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 segurança

Auditoria: Fazer auditoria do uso de privilégio de backup e restauração

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

Download

Obtenha o artigo sobre monitoramento de segurança e detecção de ataques



Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft. Todos os direitos reservados.