Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Respondendo a incidentes de segurança de TI

Nesta página

Introdução
Antes de começar
Minimizando o número e a gravidade dos incidentes de segurança
Montando a base da CSIRT
Definindo um plano de resposta a incidentes
Contendo os danos e minimizando os riscos
Informações relacionadas

Introdução

Qual é o nível de preparação do seu departamento de TI ou do administrador para tratar de incidentes de segurança? Muitas organizações só aprendem a responder a incidentes de segurança após sofrerem os ataques. Nesse momento, os incidentes costumam ficar muito mais caros do que o necessário. A resposta adequada aos incidentes deve ser parte integrante da sua diretiva de segurança geral e da estratégia de atenuação dos riscos.

Há benefícios diretos evidentes na resposta a incidentes de segurança. No entanto, também pode haver benefícios financeiros indiretos. Por exemplo, a sua seguradora pode oferecer descontos caso você demonstre que a sua organização é capaz de tratar dos ataques de maneira rápida e econômica. Ou, caso você seja um provedor de serviços, um plano formal de resposta a incidentes pode ajudar a atrair negócios, pois mostra que você leva a sério o processo de segurança adequada das informações.

Este documento fornecerá a você um processo recomendado e procedimentos a serem usados em resposta a intrusões identificadas em um ambiente de rede SMB (small-to medium-based). É explicada a importância da formação de uma equipe de resposta a incidentes de segurança com funções explícitas dos membros da equipe, bem como a forma de definição de um plano de resposta a esses incidentes.

Para responder a incidentes com êxito, você precisa:

  • Minimizar o número e a gravidade dos incidentes de segurança.

  • Montar a base da CSIRT (equipe de resposta a incidentes de segurança em computadores).

  • Definir um plano de resposta a incidentes.

  • Conter os danos e minimizar os riscos.

Antes de começar

Os administradores de sistemas gastam muito tempo com ambientes de rede e estão muito familiarizados com as redes. Eles documentam os ambientes e têm backups à mão. Já deve haver um processo de auditoria em andamento para monitorar o desempenho e a utilização. Já deve haver um nível de percepção obtido antes da implementação de uma equipe de resposta a incidentes.

Não importa em que nível de detalhes você conhece o ambiente de rede, pois o risco de ser atacado permanece. Qualquer estratégia mínima de segurança deve incluir detalhes sobre como responder a tipos diferentes de ataque.

Minimizando o número e a gravidade dos incidentes de segurança

Na vida em geral, prevenir é melhor do que remediar, e com a segurança não é diferente. Sempre que possível, é aconselhável impedir, primeiramente, que os incidentes de segurança aconteçam. No entanto, é impossível impedir todos os incidentes de segurança. Quando houver um incidente de segurança, você precisará assegurar que seu impacto seja minimizado. Para minimizar o número e o impacto dos incidentes de segurança, você deve:

  • Estabelecer claramente e aplicar todas as diretivas e procedimentos. Muitos incidentes de segurança são criados por acaso pela equipe de TI, que não seguiu (ou não entendeu) os procedimentos de gerenciamento de alterações ou configurou incorretamente os dispositivos de segurança, como firewalls e sistemas de autenticação. As diretivas e os procedimentos devem ser testados integralmente para garantir que eles sejam práticos e claros e, assim, ofereçam o nível apropriado de segurança.

  • Obter o suporte da gerência a respeito das diretivas de segurança e do tratamento de incidentes.

  • Avaliar regularmente as vulnerabilidades do seu ambiente. As avaliações devem ser feitas por um especialista em segurança com o distanciamento adequado para realizar essas ações (ou seja, direitos de administrador vinculados e concedidos aos sistemas).

  • Verificar regularmente todos os sistemas de computadores e dispositivos de rede para garantir que todos eles tenham os patches mais recentes instalados.

  • Estabelecer programas de treinamento em segurança para a equipe de TI e os usuários finais. A maior vulnerabilidade em qualquer sistema é o usuário inexperiente? O worm ILOVEYOU explorou de maneira efetiva essa vulnerabilidade em meio à equipe de TI e aos usuários finais.

  • Postar faixas de segurança que lembrem os usuários de suas responsabilidades e restrições, além de um aviso sobre a possibilidade de ações em caso de violação. Essas faixas facilitam a obtenção de evidências e o processo ao qual os invasores estarão sujeitos. Você deve obter orientação jurídica para assegurar a adequação das palavras contidas em sua faixa de segurança.

  • Desenvolver, implementar e aplicar uma diretiva que exija senhas fortes. Você pode aprender mais sobre as senhas no kit de orientações de segurança "Enforcing Strong Password Usage Throughout Your Organization".

  • Monitorar e analisar regularmente o tráfego da rede e o desempenho do sistema.

  • Verificar regularmente todos os logs e mecanismos de registro, inclusive logs de eventos do sistema operacional, logs de aplicativos específicos e logs do sistema de detecção de intrusões.

  • Verificar seus procedimentos de backup e restauração. Você deve estar atento ao local onde os backups são mantidos, a quem pode acessá-los e aos seus procedimentos para a restauração dos dados e a recuperação do sistema. Não se esqueça de verificar regularmente os backups e as mídias, restaurando dados de maneira seletiva.

  • Criar uma CSIRT para lidar com incidentes de segurança. Você pode saber mais sobre a CSIRT na próxima seção deste documento.

Montando a base da CSIRT

A CSIRT é o ponto focal para lidar com incidentes de segurança do computador em seu ambiente. A sua equipe deve ser formada por um grupo de pessoas com responsabilidades para lidar com qualquer incidente de segurança. As tarefas dos membros da equipe devem ser definidas claramente para garantir que nenhuma área da sua resposta seja deixada de lado.

Montar uma equipe antes da ocorrência de um incidente é muito importante para a sua organização, e isso influenciará positivamente na forma como os incidentes são tratados. Uma equipe bem-sucedida irá:

  • Monitorar os sistemas em busca de violações de segurança.

  • Funcionar como um ponto central de comunicação, tanto para receber relatórios dos incidentes de segurança quanto para disseminar informações vitais a respeito do incidente para as entidades adequadas.

  • Documentar e catalogar os incidentes de segurança.

  • Promover a percepção da segurança dentro da empresa para ajudar a impedir que os incidentes ocorram em sua organização.

  • Oferecer suporte à auditoria do sistema e da rede por meio de processos como, por exemplo, a avaliação da vulnerabilidade e o teste de penetração.

  • Saber mais sobre novas vulnerabilidades e estratégias de ataque empregadas pelos invasores.

  • Pesquisar novos patches de software.

  • Analisar e desenvolver novas tecnologias para minimizar vulnerabilidades e riscos de segurança.

  • Prestar serviços de consultoria em segurança.

  • Refinar e atualizar sempre os sistemas e os procedimentos atuais.

Quando você criar uma CSIRT, prepare a equipe para que ela seja capaz de lidar com os incidentes. Para preparar a equipe, você deve:

  • Treiná-la de acordo com o uso adequado e a localização das ferramentas de segurança essenciais. Você também deve levar em consideração o fornecimento de computadores portáteis pré-configurados com essas ferramentas para garantir que não se perca tempo com instalações e configurações durante a resposta a um incidente. Esses sistemas e as ferramentas associadas devem ter a proteção adequada quando não estiverem em uso.

  • Reunir todas as informações de comunicação relevantes. Você deve verificar se tem os nomes dos contatos e os números dos telefones das pessoas da sua organização que devem ser notificadas (inclusive dos membros da CSIRT, dos responsáveis pelo suporte a todos os sistemas e os encarregados das relações com a imprensa). Você também precisará dos detalhes do seu provedor de serviços de Internet e das autoridades locais e nacionais competentes. Converse com o seu orientador jurídico a respeito de como contatar a agência local antes da ocorrência de um incidente. Isso ajudará você a ter a certeza de que compreendeu os procedimentos adequados à comunicação de incidentes e à obtenção de evidências. O orientador jurídico também deve estar informado a respeito de todos os contatos com as autoridades competentes.

  • Dispor todas as informações do sistema de emergência em um local central, offline, como um fichário físico ou um computador offline. Entre essas informações de emergência estão senhas de sistemas, endereços IP, informações de configuração do roteador, listas de conjuntos de regras para o firewall, cópias das chaves de autoridade da certificação, nomes de contatos, números de telefones, procedimentos de escalonamento etc. Essas informações devem estar prontamente disponíveis e ser mantidas sob extrema segurança física. Um método de proteger e tornar essas informações prontamente disponíveis é criptografá-las em um computador portátil com segurança dedicada colocado em um cofre e limitar o acesso a ele apenas a pessoas autorizadas como, por exemplo, o líder da CSIRT e o CIO ou CTO.

A associação e a estrutura ideais da CSIRT dependem do tipo da sua organização e da sua estratégia de gerenciamento dos riscos. No entanto, a CSIRT costuma fazer parte ou constituir toda a equipe de segurança da sua organização. Na equipe base estão profissionais de segurança responsáveis pela coordenação de uma resposta a todos os incidentes. O número de membros da CSIRT normalmente dependerá do tamanho e da complexidade da sua organização. No entanto, você deve verificar se há membros o suficiente para que todas as tarefas da equipe sejam realizadas adequadamente a qualquer momento.

Estabelecendo funções na equipe

Uma equipe de CSIRT bem-sucedida é formada por vários membros-chave.

Líder da equipe CSIRT. A CSIRT deve ter uma pessoa responsável por suas atividades. Normalmente, o líder da equipe CSIRT será o responsável pelas atividades da CSIRT e coordenará as revisões de suas ações. Isso pode acarretar mudanças nas diretivas e nos procedimentos para lidar com incidentes futuros.

Líder de incidentes da CSIRT. Em caso de acidente, você deve designar uma pessoa responsável pela coordenação da resposta. É de propriedade do líder de incidentes da CSIRT um incidente em particular ou um conjunto de incidentes de segurança relacionados. Toda a comunicação a respeito do evento é coordenada pelo líder de incidentes e, durante a comunicação fora da CSIRT, é o líder quem representa toda a CSIRT. O líder de incidentes pode variar de acordo com a natureza do incidente e costuma não ser a mesma pessoa líder da equipe CSIRT.

Membros associados da CSIRT. Além da base da equipe CSIRT, você deve contar com algumas pessoas específicas que tratam e respondem a determinados incidentes. Os membros associados virão de vários departamentos diferentes da sua organização. Eles devem ser especializados nas áreas afetadas pelos incidentes de segurança, mas que não são tratadas diretamente pela base da CSIRT. Os membros associados podem estar diretamente envolvidos em um incidente ou funcionar como pontos de entrada para delegar a responsabilidade a uma pessoa mais indicada dentro de seus departamentos. A seguinte tabela mostra alguns membros associados sugeridos e suas funções.

Membros associados da CSIRT

Membro associado

Descrição da função

Contato de TI

Este membro é essencialmente responsável pela coordenação da comunicação entre o líder de incidentes da CSIRT e o restante do grupo de TI. O contato de TI não deve ter a experiência técnica específica para responder ao incidente em especial. No entanto, ele será basicamente responsável pela localização das pessoas no grupo de TI que devem tratar eventos de segurança em especial.

Representante legal

Este membro é um advogado muito familiarizado com as diretivas estabelecidas de resposta a incidentes. O representante legal determina como proceder durante um incidente com responsabilidade legal mínima e autorização máxima para processar transgressores.

Antes que haja um incidente, o representante legal deve ter informações sobre as diretivas de monitoramento e resposta para assegurar que a organização não esteja correndo riscos legais durante uma operação de limpeza ou de retenção. É muito importante levar em consideração as implicações legais do desligamento de um sistema e da possibilidade de violação dos contratos de nível de serviço ou de associação firmados com seus clientes ou do não desligamento de um sistema com e responsável por danos causados por ataques iniciados a partir deste sistema.

Toda a comunicação externa com autoridades competentes ou órgãos investigativos externos deve ser coordenada com o representante legal.

Diretor de relações públicas

Normalmente, este membro faz parte do departamento de relações públicas, sendo responsável por resguardar e promover a imagem da organização.

Essa pessoa não pode ser a pessoa de contato real com a imprensa e os clientes, e sim a responsável pela elaboração da mensagem (o conteúdo e o objetivo desta mensagem costumam ser de responsabilidade da gerência). Todas as solicitações de imprensa devem ser direcionadas ao departamento de Relações Públicas.

Gerência

Dependendo do incidente em especial, você deve envolver apenas os gerentes do departamento ou todos os gerentes de toda a organização. A pessoa responsável pela gerência apropriada irá variar de acordo com o impacto, o local, a gravidade e o tipo de incidente.

Caso tenha um ponto de contato administrativo, você pode identificar rapidamente a pessoa mais indicada para as circunstâncias específicas. A Gerência é responsável pela aprovação e orientação da diretiva de segurança.

Ela também é responsável pela determinação do impacto total (em termos financeiros ou não) do incidente na organização. A Gerência orienta o diretor de comunicação a respeito das informações a serem divulgadas à imprensa e determina o nível de interação entre o Representante legal e as autoridades competentes.

Respondendo a um incidente

Em caso de um incidente, a CSIRT coordenará uma resposta da base da CSIRT e a comunicará aos seus membros associados. A seguinte tabela mostra as responsabilidades dessas pessoas durante o processo de resposta ao incidente.

Responsabilidades da CSIRT durante o processo de resposta ao incidente

Atividade

Função

 

Líder de incidentes da CSIRT

Contato de TI

Representante legal

Diretor de comunicação

Gerência

Avaliação inicial

Proprietário

Avisa

Nenhuma

Nenhuma

Nenhuma

Resposta inicial

Proprietário

Implementa

Atualiza

Atualiza

Atualiza

Obtém evidências forenses

Implementa

Avisa

Proprietário

Nenhuma

Nenhuma

Implementa correção temporária

Proprietário

Implementa

Atualiza

Atualiza

Avisa

Envia a comunicação

Avisa

Avisa

Avisa

Implementa

Proprietário

Consultar as autoridades competentes locais

Atualiza

Atualiza

Implementa

Atualiza

Proprietário

Implementa correção permanente

Proprietário

Implementa

Atualiza

Atualiza

Atualiza

Determina o impacto financeiro nos negócios

Atualiza

Atualiza

Avisa

Atualiza

Proprietário

Definindo um plano de resposta a incidentes

Todos os membros do seu ambiente de TI devem ficar atentos ao que fazer em caso de um incidente. A CSIRT desempenhará a maioria das ações em resposta a um incidente, mas todos os níveis da sua equipe de TI devem estar atentos à maneira como informar os incidentes internamente. Os usuários finais devem informar atividades suspeitas à equipe de TI diretamente ou por um suporte técnico, e não diretamente à CSIRT.

Todos os membros da equipe devem examinar detalhadamente o plano de resposta a incidentes. Ter o plano facilmente acessível a toda a equipe de TI ajudará a garantir que os procedimentos corretos sejam seguidos em caso de um incidente.

Para que haja um plano de resposta a incidentes bem-sucedido, você deve:

  • Fazer uma avaliação inicial.

  • Comunicar o incidente.

  • Conter os danos e minimizar os riscos.

  • Identificar o tipo e a gravidade do comprometimento.

  • Proteger as evidências.

  • Notificar órgãos externos, se apropriado.

  • Recuperar sistemas.

  • Compilar e organizar a documentação do incidente.

  • Avaliar os danos e os custos do incidente.

  • Examinar as políticas de resposta e atualização.

Essas etapas não são necessariamente em seqüência. Na verdade, elas acontecem durante todo o incidente. Por exemplo, a documentação começa logo no início e continua durante todo o ciclo de vida do incidente; a comunicação também acontece durante todo o incidente.

Os outros aspectos do processo coexistirão. Por exemplo, como parte da sua avaliação inicial, você terá uma idéia da natureza geral do ataque. É importante usar essas informações para conter o dano e minimizar o risco o mais rápido possível. Se você agir rapidamente, poderá ajudar a economizar tempo e dinheiro, além de salvar a reputação da sua organização.

No entanto, até entender mais detalhadamente o tipo e a gravidade do comprometimento, você não poderá conter efetivamente o dano e minimizar o risco. Uma resposta superzelosa poderia até mesmo causar mais danos do que o ataque inicial. Ao trabalhar essas etapas em harmonia, você terá o melhor comprometimento entre as ações rápidas e efetivas.

Observação: é muito importante que você teste todo o seu processo de resposta a incidentes antes que ocorra um incidente. Sem um teste completo, não há garantia de que as medidas aplicadas sejam efetivas na resposta aos incidentes.

Fazendo uma avaliação inicial

Muitas atividades poderiam indicar um possível ataque em sua organização. Por exemplo, um administrador de rede que esteja realizando uma manutenção legítima do sistema pode parecer com alguém que esteja iniciando alguma forma de ataque. Em outros casos, um sistema mal configurado pode acarretar vários positivos falsos em um sistema de detecção de intrusões, o que poderia dificultar ainda mais a localização de incidentes genuínos.

Como parte da sua avaliação inicial, você deve:

  • Executar etapas para determinar se está lidando com um incidente real ou um positivo falso.

  • Obter uma idéia geral do tipo e da gravidade do ataque. Você deve obter informações o suficiente para começar a comunicá-lo tendo em vista uma pesquisa aprofundada e começar a conter o dano e minimizar o risco.

  • Registrar todas as suas ações. Mais tarde, esses registros serão usados na documentação do incidente (independentemente de ser real ou falso).

Observação: você deve evitar positivos falsos sempre que possível; no entanto, é sempre melhor agir com base em um positivo falso do que em um incidente genuíno. Por isso, a sua avaliação inicial deve ser o mais breve possível, embora, ainda assim, eliminando positivos falsos óbvios.

Comunicando o incidente

Assim que suspeitar de que haja um incidente de segurança, você deve comunicar rapidamente a violação ao restante da base da CSIRT. O Líder de incidentes, com o restante da equipe, deve identificar rapidamente quem precisa ser contatado fora da base da CSIRT. Isso ajudará a assegurar a possibilidade de manutenção do controle apropriado e de coordenação do incidente, além de minimizar a extensão do dano.

Esteja ciente de que o dano pode surgir de várias formas e de que uma manchete nos jornais descrevendo uma violação da segurança pode ser muito mais destrutiva do que muitas intrusões no sistema. Por essa razão, e para evitar que um invasor seja colocado para fora, somente aqueles que desempenham uma função na resposta a incidentes devem ser informados até que o incidente seja controlado adequadamente. Exclusivamente com base na situação, a sua equipe determinará quem precisa ser informado a respeito do incidente. Poderia ser qualquer pessoa, desde indivíduos específicos até toda a empresa e os clientes externos. A comunicação externa deve ser coordenada com o Representante legal.

Contendo os danos e minimizando os riscos

Ao agir rapidamente para reduzir os efeitos real e potencial de um ataque, você pode fazer a diferença entre pequenas e grandes proporções. A resposta exata dependerá da sua organização e da natureza do ataque enfrentado. No entanto, as seguintes prioridades são sugeridas como um ponto de partida:

  1. Proteger a vida humana e a segurança das pessoas. É claro que essa deve ser sempre a sua grande prioridade.

  2. Proteger dados secretos e confidenciais. Como parte do seu planejamento para resposta a incidentes, você deve definir claramente os dados secretos e os confidenciais. Isso permitirá que você priorize suas respostas para proteger os dados.

  3. Proteger outros dados, inclusive proprietários, científicos e administrativos. Mesmo assim, outros dados em seu ambiente podem ser muito importantes. Você deve agir de forma a proteger os dados mais importantes antes de passar a outros dados menos úteis.

  4. Proteger o hardware e o software contra ataques. Isso inclui a proteção contra a perda ou a alteração dos arquivos do sistema e danos físicos ao hardware. Os danos aos sistemas podem acarretar um tempo de inatividade muito caro.

  5. Minimizar a interrupção dos recursos computacionais (inclusive processos). Embora o tempo de atividade seja muito importante na maioria dos ambientes, manter os sistemas funcionando durante um ataque pode resultar em problemas maiores no futuro. Por essa razão, minimizar a interrupção dos recursos computacionais deve ser uma prioridade relativamente baixa.

Há várias medidas que você pode seguir para conter o dano e minimizar o risco no seu ambiente. Você deve, pelo menos:

  • Tentar impedir que os invasores saibam que você está atento a suas atividades. Isso pode ser difícil, pois algumas respostas essenciais podem alertá-los. Por exemplo, se houver uma reunião de emergência da CSIRT ou você solicitar uma alteração imediata de todas as senhas, todos os invasores internos poderão saber que você está atento a um incidente.

  • Comparar os custos de colocação dos sistemas comprometidos e relacionados offline com os riscos da continuidade das operações. Na grande maioria dos casos, você deve desconectar imediatamente o sistema da rede. No entanto, talvez você tenha contratos de serviço em vigência que exijam a manutenção da disponibilidade dos sistemas, mesmo com a possibilidade de ocorrência de mais danos. Nessas circunstâncias, você pode optar por manter um sistema online com conectividade limitada para obter evidências adicionais durante um ataque.
    Em alguns casos, o dano e o escopo de um incidente podem ser tão amplos que você talvez precise realizar uma ação que invoque as cláusulas penais especificadas em seus contratos de nível de serviço. De qualquer forma, é muito importante que as ações realizadas em caso de um incidente sejam discutidas com antecedência e estejam descritas em seu plano de respostas para que a ação imediata possa ser realizada quando houver um ataque.

  • Determinar o(s) ponto(s) de acesso usado(s) pelo invasor e implementar medidas que impeçam o acesso futuro. As medidas podem incluir: desabilitar um modem, adicionar entradas de controle de acesso a um roteador ou firewall ou aumentar as medidas de segurança física.

  • Levar em consideração a recriação de um sistema totalmente novo com novos discos rígidos (os discos rígidos existentes devem ser removidos e armazenados porque podem ser usados como evidência caso você opte por processar os invasores). Não se esqueça de alterar todas as senhas locais. Você também deve alterar as senhas administrativas e de contas de serviço em todo o ambiente.

Identificando a gravidade do comprometimento

Para poder se recuperar de um ataque de maneira eficiente, você precisa determinar com que gravidade os seus sistemas foram comprometidos. Isso determinará como conter e minimizar ainda mais o risco, como se recuperar, com que velocidade e para quem você deve comunicar o incidente e se deve buscar reparos legais.

Você deve tentar:

  • Determinar a natureza do ataque (isso pode ser diferente das sugestões da avaliação inicial).

  • Determinar o ponto de origem do ataque.

  • Determinar a intenção do ataque. O ataque estava direcionado especificamente à sua organização para adquirir informações específicas ou foi aleatório?

  • Identificar os sistemas que foram comprometidos.

  • Identificar os arquivos que foram acessados e determinar sua confidencialidade.

Ao realizar essas ações, você será capaz de determinar as respostas apropriadas ao seu ambiente. Um bom plano de resposta a incidentes descreverá procedimentos específicos a serem seguidos enquanto você aprende mais sobre o ataque. Normalmente, a natureza dos sintomas do ataque determinará a ordem na qual você segue os procedimentos definidos em seu plano. Como o tempo é essencial, procedimentos menos demorados devem ser realizados antes dos mais demorados. Para ajudar a determinar a gravidade do comprometimento, você deve:

  • Contatar os demais membros da equipe de resposta para informá-los de suas descobertas, fazê-los verificar os resultados independentemente de estarem atentos a atividades de ataques relacionadas ou potenciais e ajudar a identificar se o incidente é um positivo falso. Em alguns casos, o que pode parecer um incidente genuíno durante a avaliação inicial se mostrará um positivo falso.

  • Determinar se o hardware não autorizado foi conectado à rede ou se há sinais de acesso não autorizado com o comprometimento dos controles de segurança física.

  • Examinar os grupos principais (administradores de domínio, administradores etc.) em busca de entradas não autorizadas.

  • Procurar softwares de avaliação da segurança ou de exploração. Utilitários de decodificação costumam ser encontrados em sistemas comprometidos durante a obtenção de evidências.

  • Procurar processos não autorizados ou aplicativos em execução ou configurados para serem executados usando pastas de inicialização ou entradas do Registro.

  • Procurar falhas ou logs de sistema ausentes.

  • Examinar logs do sistema de detecção de intrusões em busca de sinais de intrusão, os sistemas afetados, os métodos de ataque, a hora e a duração do ataque, além da extensão geral do dano potencial.

  • Examinar outros arquivos de log em busca de conexões incomuns; êxitos incomuns de auditoria de segurança; falhas em tentativas de logon; tentativas de logon em contas padrão; atividade fora do horário de expediente; alterações de permissão em arquivo, diretório e compartilhamento e permissões de usuário elevadas ou alteradas.

  • Comparar sistemas com verificações de integridade de arquivo/sistema realizadas anteriormente. Isso permite que você identifique inclusões, exclusões, modificações e modificações de permissão e controle no sistema de arquivos e no registro. Você pode economizar muito tempo ao responder a incidentes caso identifique exatamente o que foi comprometido e quais áreas precisam ser recuperadas.

  • Procurar dados confidenciais, como números de cartão de crédito e dados do funcionário ou do cliente, que talvez tenham sido movidos ou ocultados para recuperação ou modificações futuras. Você talvez também tenha que verificar sistemas em busca de dados não comerciais, cópias ilegais de software, emails ou outros registros que possam ajudar em uma investigação. Caso haja uma possibilidade de violação da privacidade ou de outras leis com a procura em um sistema para fins investigativos, você deve contatar o departamento jurídico antes de continuar.

  • Comparar o desempenho dos sistemas suspeitos com seus níveis de desempenho da linha de base. É claro que isso pressupõe que as linhas de base tenham sido criadas e atualizadas corretamente.

Ao determinar os sistemas comprometidos e como isso aconteceu, você irá comparar os seus sistemas com uma linha de base registrada anteriormente do mesmo sistema antes do seu comprometimento. Pressupor que uma cópia de sombra recente do sistema seja suficiente para comparação pode colocá-lo em uma situação difícil caso a cópia de sombra anterior seja de um sistema que já foi atacado.

Observação: ferramentas como EventCombMT, DumpEL e MOM (Microsoft Operations Manager) podem ajudar você a determinar até onde um sistema foi atacado. Sistemas de detecção de intrusões de terceiros informam ataques com antecedência, e outras ferramentas mostrarão as alterações de arquivo em seus sistemas.

Protegendo as evidências

Em muitos casos, caso o seu ambiente tenha sido atacado deliberadamente, você talvez queira tomar medidas legais contra os perpetradores. Para preservar essa opção, você deve obter evidências que possam ser usadas contra eles, mesmo que uma decisão tenha sido tomada para não tomar essa medida. É extremamente importante fazer o backup dos sistemas comprometidos assim que possível. Faça o backup dos sistemas antes de realizar qualquer ação que possa afetar a integridade dos dados na mídia original.

Alguém com habilidades computacionais forenses devem fazer pelo menos dois backups completos bit a bit de todo o sistema usando mídias totalmente novas. Pelo menos um backup deve estar em uma mídia de gravação única, mas de várias leituras, como um CD-R ou DVD-R. Esse backup só deve ser usado na ação contra o invasor e estar fisicamente protegido até quando for necessário.

Os demais backups podem ser usados na recuperação dos dados. Como esses backups não devem ser acessados, exceto para fins legais, você deve protegê-los fisicamente. Você também precisará documentar as informações sobre os backups como, por exemplo, quem fez o backup dos sistemas, a que hora, como eles foram protegidos e quem teve acesso a eles.

Assim que os backups forem feitos, você deve remover os discos rígidos originais e armazená-los em um local protegido fisicamente. Esses discos podem ser usados como evidências forenses em caso de uma ação. Novos discos rígidos devem ser usados para restaurar o sistema.

Em alguns casos, o benefício de preservar dados pode não equivaler ao custo de atrasar a resposta e a recuperação do sistema. Os custos e os benefícios de preservar dados devem ser comparados aos de recuperação mais rápida de cada evento.

Para sistemas muito grandes, backups abrangentes de todos os sistemas comprometidos talvez não sejam viáveis. Na verdade, você deve fazer o backup de todos os logs e das partes violadas e selecionadas do sistema.

Se possível, também faça o backup dos dados do estado do sistema. Como pode levar meses ou anos até que haja a ação, é importante ter o máximo de detalhes do incidente arquivado para uso futuro.

Normalmente, o aspecto legal mais difícil de processar um crime eletrônico é obter evidências de maneira aceitável, de acordo com as leis para o envio de evidências da jurisdição em especial. Portanto, o componente mais crítico do processo forense é a documentação detalhada e completa da forma como os sistemas eram tratados, por quem e quando, para demonstrar evidências confiáveis. Assine e coloque a data em todas as páginas da documentação.

Uma vez que você tenha backups verificados e em funcionamento, poderá limpar os sistemas infectados e recriá-los. Isso permitirá que você comece a executar a operação novamente. Os backups oferecem as evidências críticas e inequívocas necessárias à ação. Um backup diferente do backup forense deve ser usado para restaurar os dados.

Notificando órgãos externos

Depois que o incidente for contido e os dados forem preservados para uma possível ação, você deve levar em consideração se precisa começar a notificar as entidades externas apropriadas. Todas as divulgações externas devem ser coordenadas com seu Representante legal. Entre os órgãos em potencial estão autoridades competentes locais e nacionais, órgãos de segurança externos e especialistas em vírus. Os órgãos externos podem fornecer assistência técnica, oferecer uma resolução mais rápida e dar informações assimiladas de incidentes semelhantes para ajudar você a se recuperar do incidente e impedir que ele ocorra no futuro.

Para setores e tipos de violações específicos, você talvez tenha que notificar os clientes e o público em geral, especialmente caso os clientes sejam afetados pelo incidente de maneira direta.

Caso o evento tenha causado um impacto financeiro, talvez você queira informar o incidente às autoridades competentes.

Para empresas e incidentes de perfil alto, a imprensa talvez esteja envolvida. A atenção da imprensa a um incidente de segurança é raramente desejável, mas dificilmente é evitada. A atenção da imprensa pode permitir que sua organização assuma uma postura proativa na comunicação do incidente. Pelo menos, os procedimentos de resposta a incidentes devem definir claramente as pessoas autorizadas a se dirigir aos representantes da imprensa.

Normalmente, o departamento de relações públicas dentro da sua organização irá se dirigir à imprensa. Você não deve tentar negar à imprensa que houve um incidente, já que isso deve prejudicar sua reputação mais do que a admissão proativa e as respostas visíveis jamais farão. Isso não significa que você precise notificar à imprensa todos os incidentes independentemente de sua natureza ou gravidade. Você deve avaliar a resposta apropriada à imprensa caso a caso.

Recuperando sistemas

Como você recupera o seu sistema normalmente dependerá da extensão da violação da segurança. Você precisará determinar se é possível restaurar o sistema existente deixando-o intacto o máximo possível ou se é necessário recriar totalmente o sistema.

Restaurar dados pressupõe, claro, que você tenha backups limpos? Backups feitos antes do incidente ter ocorrido. O software de integridade do arquivo pode ajudar a identificar a primeira ocorrência de dano. Caso o software alerte você para um arquivo alterado, você sabe que o backup feito antes do alerta é bom e que deve ser preservado para uso durante a recriação do sistema comprometido.

Um incidente poderia corromper os dados muitos meses antes de sua descoberta. Por isso, é muito importante que, como parte do seu processo de resposta a incidentes, você determine a duração do incidente. (Software de integridade do arquivo/sistema e sistemas de detecção de intrusão podem ajudá-lo nisso.) Como em alguns casos, os backups mais recentes ou mesmo vários anteriores talvez não sejam longos o bastante para se obter um estado limpo, você deve arquivar regularmente os backups de dados em um local externo seguro.

Compilando e organizando a documentação do incidente

A CSIRT deve documentar todos os processos ao lidar com qualquer incidente. Isso deve incluir uma descrição da violação e os detalhes das ações executadas (quem executou a ação, quando ela foi executada e sua justificativa). Todas as pessoas envolvidas com o acesso devem ser indicadas durante todo o processo de resposta.

Mais tarde, a documentação deve ser organizada em ordem cronológica, verificada, assinada e revisada pelos representantes administrativos e legais. Você também precisará proteger as evidências obtidas na fase de proteção das evidências. Você deve levar em consideração ter duas pessoas presentes durante todas as fases que possam assinar em cada etapa. Isso ajudará a reduzir a probabilidade das evidências serem inadmissíveis e a possibilidade delas serem modificadas posteriormente.

Lembre-se de que o invasor pode ser um funcionário, um contratado, um funcionário temporário ou outros dentro de sua organização. Sem uma documentação completa, detalhada, identificar um invasor interno será muito difícil. A documentação adequada também oferece a melhor chance de processar os invasores.

Avaliando os danos e os custos do incidente

Ao determinar o dano à sua organização, você deve levar em consideração tanto os custos diretos quanto os indiretos. Os danos e os custos do incidente serão evidências importantes, necessárias caso você opte por executar qualquer ação legal. Entre eles podem estar:

  • Custos devidos à perda de margem competitiva com a divulgação de informações proprietárias ou confidenciais.

  • Custos legais.

  • Custos com mão-de-obra para analisar as violações, reinstalar o software e recuperar os dados.

  • Custos relacionados ao tempo de inatividade do sistema (por exemplo, perda de produtividade dos funcionários, perda de vendas, substituição de hardware, software e outras propriedades).

  • Custos relacionados ao reparo e possibilidade de atualização de medidas de segurança físicas danificadas ou ineficazes (travas, paredes, gaiolas etc.)

  • Outros danos conseqüentes como, por exemplo, perda de reputação ou de confiança do cliente.

Examinando as políticas de resposta e atualização

Assim que as fases de documentação e de recuperação forem concluídas, você deverá examinar todo o processo. Discuta com sua equipe quais foram as etapas executadas com êxito e quais foram os enganos cometidos. Em praticamente todos os casos, você encontrará alguns processos que precisam ser modificados para que seja possível mais bem tratar incidentes futuros.

Você encontrará pontos fracos em seu plano de resposta a incidentes; o ponto desse exercício post-mortem? Você está procurando oportunidades para melhorar, o que deve iniciar uma rodada totalmente nova do processo de planejamento de resposta a incidentes.

Informações relacionadas

Grande parte deste documento lidou com medidas que você pode seguir para minimizar o risco de ataques. No entanto, as organizações conseguem obter mais sucesso em sua busca para atingir as metas de segurança quando fazem todo o possível para minimizar suas chances de ataque e, em seguida, planejam o que farão quando forem atacadas. Parte desse processo é fazer uma auditoria cuidadosa de um ataque. Outra parte igualmente importante é ter um conjunto claramente definido de respostas bem treinadas, que você poderá colocar em prática se ocorrer um ataque.

Para obter mais informações sobre como criar um plano de resposta a incidentes, consulte:

Para obter mais informações sobre segurança, consulte:

  • The Internet Security Guidebook: >From Planning to Deployment de Juanita Ellis e Tim Speed (Academic Press, ISBN: 0223747).


Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft