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

Image result for Monitoramento de segurança e detecção de ataques

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 emhttp://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 emhttp://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.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s