5.3 Identificando um Incidente

5.3.1 É Real?

Esta fase envolve determinar se um problema realmente existe. Naturalmente muitos, se não a maioria, dos sinais associados freqüentemente com infecção de vírus, intrusões de sistema, usuários maliciosos, etc., simplesmente são anomalias tal como falhas de hardware ou comportamento de suspeito de sistema/usuário. Para ajudar a identificar se realmente há um incidente, é normalmente útil obter e usar qualquer software de detecção que possa estar disponível. Informação de auditoria também é extremamente útil, especialmente para determinar se há um ataque a rede. É extremamente importante obter um retrato instantâneo do sistema assim que se suspeite que algo está errado. Muitos incidentes levam uma cadeia dinâmica de eventos a acontecer, e um retrato instantâneo do sistema inicial pode ser a mais valiosa ferramenta para identificar o problema e qualquer fonte de ataque. Finalmente, é importante começar um livro de log. Gravar eventos de sistemas , conversas de telefone, timestamps, etc., pode conduzir a uma identificação mais rápida e sistemática do problema, e é a base para fases subseqüentes de tratamento de incidente.

Há certas indicações ou " sintomas " de um incidente que merecem atenção especial:

De forma alguma esta lista é completa; nós listamos apenas um certo número de indicadores comuns. É melhor colaborar com outro pessoal técnico e de segurança de computador para tomar uma decisão como um grupo sobre se um incidente está acontecendo.

5.3.2 Tipos e Escopo de Incidentes

Junto com a identificação do incidente, está a avaliação do âmbito e impacto do problema. É importante identificar os limites do incidente corretamente para lidar efetivamente com ele e priorizar respostas.

Para identificar o escopo e impacto um conjunto de critérios deveria ser definido, o qual é apropriado para o site e para o tipo de conexões disponíveis. Alguns dos pontos incluem:

5.3.3 Avaliando Dano e Extensão

A análise do dano e extensão do incidente pode consumir muito tempo, mas deveria conduzir a alguma idéia sobre a natureza do incidente, e ajudar na investigação e prossecução. Assim que a brecha tenha acontecido, o sistema inteiro e todos seus componentes deveriam ser considerado suspeitos. Software de sistema é o alvo mais provável. Preparação é chave para poder descobrir todas as mudanças num sistema possivelmente afetado. Isto inclui fazer checksum de todas os meios do vendedor usando um algoritmo que é resistente a falsificações. (Veja seções 4.3)

Assumindo que meios de distribuição originais do vendedor estão disponíveis, uma análise de todos os arquivos de sistemas deveria começar, e qualquer irregularidade deveria ser notada e deveria referida a todas as partes envolvidas no tratamento do incidente. Pode ser muito difícil, em alguns casos, decidir que meios de backup estão mostrando um estado de sistema correto. Considere, por exemplo que o incidente pode ter continuado por meses ou anos antes de descoberta, e o suspeito pode ser um empregado do site, ou que tenha conhecimento íntimo ou acesso aos sistemas. Em todos os casos, a preparação antes do incidente determinará se a recuperação é possível.

Se o sistema suporta logs centralizados (a maioria o faz), volte para os logs e procure anormalidades. Se contabilidade de processo e tempo de conexão estiver habilitada, procure padrões de uso do sistema. Numa menor extensão, o uso do disco pode jogar luz no incidente. Contabilidade pode prover muita informação útil em uma análise de um incidente e prossecução subseqüente. Sua habilidade para verificar todos os aspectos de um incidente específico depende fortemente do sucesso desta análise.

5.4 Tratando um Incidente

São necessários certos passos durante o tratamento de um incidente. Em todas as atividades de segurança relacionadas, o mais importante ponto à ser feito é que todos os sites deveriam ter políticas no local.

Sem políticas e metas definidas, as atividades empreendidas permanecerão sem enfoque. As metas deveriam ser definidas com antecedência pela administração e com deliberação legal.

Um dos objetivos mais fundamentais é restabelecer controle dos sistemas afetados e limitar o impacto e dano. No pior caso, fechando o sistema, ou desconectando o sistema da rede, possa ser a única solução prática.

Como as atividades envolvidas são complexas, tente adquirir tanta ajuda quanto necessário. Enquanto tenta resolver o problema sozinho, danos reais podem acontecer devido a demoras ou a informações perdidas. A maioria administradores levam a descoberta de um intruso como um desafio pessoal.

Procedendo deste modo, outros objetivos como esboçou em suas políticas locais sempre podem não ser consideradas. Tentar pegar os intrusos pode ser uma prioridade muito baixa, se comparada a integridade do sistema, por exemplo. Monitorar a atividade de um hacker é útil, mas pode não sido considerado preço o risco para permitir o acesso continuado.

5.4.1 Tipos de Notificação e Troca de Informação

Quando você confirmou que um incidente está acontecendo, o pessoal apropriado deve ser notificado. Como esta notificação é passada é muito importante para mantenção do evento sob controle ambos pontos de vista, o técnico e o emocional. As circunstâncias devem ser descritas em tantos detalhes quanto possível para facilitar o pronto reconhecimento e entender o problema. Muito cuidado quando determinar para quais grupos técnicos a informação será enviada durante a notificação.Por exemplo, é útil passar este tipo de informação para um grupo de tratamento de incidentes pois eles podem lhe ajudar com sugestões úteis para erradicar as vulnerabilidades envolvidas em um incidente. Por outro lado, pondo o conhecimento crítico no domínio público (por exemplo, por newsgroups de USENET ou remetendo para listas) pode pôr um número grande de sistemas potencialmente a risco de intrusão. É nulo assumir que todos os administradores que lêem um newsgroup particular têm acesso ao código fonte do sistema operacional, ou podem entender o bastante para fazer os passos adequados.

Em primeiro lugar, qualquer notificação para local ou pessoal de fora do site deve ser explícito. Isto requer que qualquer declaração (seja isto uma mensagem de correio eletrônico, telefonema, fac-símile, beeper, ou semaphone) provendo informação sobre o incidente seja clara, concisa, e completamente qualificada. Quando você está notificando outros que o ajudarão a tratar um evento, uma "tela de fumaça" só dividirá o esforço e criará confusão. Se uma divisão de trabalho é sugerida, é útil prover informações para cada participante sobre o que está sendo realizado em outros esforços. Isto não só reduzirá duplicação de esforços, mas permite que as pessoas que trabalham em partes do problema possam saber onde obter informações pertinentes a parte deles no incidente.

Outra consideração importante quando comunicar sobre o incidente é ser efetivo. Tentar esconder aspectos do incidente provendo falsa ou incompleta informação não só podem evitar uma solução com sucesso para o incidente, mas pode até mesmo piorar a situação.

A escolha do idioma usado quando notificar as pessoas sobre o incidente pode ter um efeito profundo no modo que informação é recebida. Quando você usa termos emocionais ou inflamatórios, você eleva o potencial para dano e resultados negativos do incidente. É importante permanecer tranqüilo ambos as comunicações escrita e falada.

Outra consideração é que nem todas as pessoas falam o mesmo idioma.

Devido a este fato, podem surgir enganos e demora, especialmente se é um incidente multi-nacional. Em outras preocupações internacionais inclua a diferença nas implicações legais de um incidente de segurança e diferenças culturais. Porém, diferenças culturais não só existem entre países. Elas igualmente existem dentro de países, entre diferente grupos sociais ou de usuários. Por exemplo, administrador de um sistema universitário é muito relaxado sobre tentativas para conectar o sistema por telnet, mas é provável que o administrador de um sistema militar considere a mesma ação como um possível ataque.

Outro assunto associado com a escolha de idioma é a notificação de pessoas não técnicas ou de fora do site. É importante descrever o incidente com precisão sem gerar alarme impróprio ou confusão. Enquanto é mais difícil de descrever o incidente a uma conjunto de pessoas não-técnicas, é freqüentemente mais importante. Uma descrição não-técnica pode ser requerida pela administração de níveis superiores, a imprensa, ou instituições responáveis pela execução de lei. A importância destas comunicações não pode ser menosprezada e pode fazer a diferença entre a solução do incidente corretamente ou eleva-lo a algum nível mais alto de dano.

Se um grupo de resposta a incidentes é envolvido, poderia ser necessário preencher um modelo para a troca de informação. Embora isto possa parecer ser um fardo adicional e possa somar uma certa demora, isto, ajuda o grupo para agir neste mínimo conjunto de informação. O grupo de resposta poderá responder a aspectos do incidente do qual o administrador local é desavisado. Se a informação é dada para uma pessoa de fora então, esta pessoa deveria ter um mínimo de informação contando o seguinte:

Se informações locais (i.e., IDs de usuários locais) são incluídas nas entradas de logs, será anteriormente necessário a **sanitize** as entradas para evitar assuntos de isolamento. Em geral, toda a informação que poderia ajudar um local distante solucionando um incidente deveria ser distribuídas, a menos que políticas locais proibem isto.

5.4.2 Protegendo as Evidências e Logs de Atividade

Quando você responde a um incidente, documente todos os detalhes relacionados ao incidente. Isto proverá valiosa informação para você e outros como você tentando desvendar o curso dos eventos. Documentando todos os detalhes economizarão em última instância, seu tempo. Se você não documenta todos os telefonemas importantes, por exemplo, é provável que você esqueça uma porção significante de informação você obtém o que requer que voce contacte a fonte de informação novamente. Ao mesmo tempo, detalhes armazenados proverão evidências para esforços de prossecução e proverão os movimentos naquela direção. A documentação de um incidente também lhe ajudarão a executar uma taxa final de dano (alguém da administração, como também institições de execução de lei, poderão querer saber), e proverá a base para mais recentes fases do processo de tratamento de incidentes:

erradicação, recuperação, e seqüência, "lições aprendidas".

Durante as fases iniciais de um incidente, é freqüentemente imprevisível determinar se a prossecução é viável, assim você deveria documentar como se você pois está juntando evidências para um caso de tribunal. Um mínimo, você deverá registrar:

O modo mais direto para manter documentação é mantendo um livro de log. Isto lhe permite ter uma centralizada e cronológica fonte de informação quando você precisar disto, em vez do requerer, chame por folhas individuais de papel. Muitas destas informações são evidências potenciais em um tribunal de lei. Assim, quando um procedimento legal é uma possibilidade, a pessoa deveria seguir os procedimentos preparados e evitar por em perigo o procedimento legal por manipulação imprópria de possível evidência. Se apropriado, os passos seguintes podem ser levados.

1. regularmente (por exemplo, diariamente) fazer cópias assinadas de seu logbook (como também mídias que você usa para registrar eventos de sistemas) para um adminitrador de documentos.

2. adminitrador deveria armazenar estas páginas copiadas em um seguro lugar (por exemplo, uma caixa forte).

3. quando você submete informação para armazenamento, você deve receba um recibo datado e assinado pelo administrador do documento.

Fracasso para observar estes procedimentos pode resultar em invalidação de qualquer evidência que você obtém em um tribunal de lei.

5.4.3 Retenção

O propósito de retenção é limitar a extensão de um ataque. Uma parte essencial de retenção é decisão do que fazer (por exemplo, determinando desligar um sistema, desconectar da rede, monitorar sistemas ou atividades de rede, set traps, incapacitar funções como transferência de arquivo remotoss, etc.).

Às vezes esta decisão é trivial; desligar o sistema se a informação é secreta, importante, ou proprietária. Tenha em mente que isso remove todo o acesso enquanto um incidente está em prograsso, obviamente notifique todos os usuários, inclusive os usuários que alegaram problemas, que os administradores estão atentos ao problema; isto pode ter um efeito danoso uma investigação. Em alguns casos, é prudente remover todo o acesso ou funcionalidade o mais cedo possível, então restabeleça operação normal em fases limitadas. Em outros casos, vale a pena arriscar algum dano para o sistema, se manter o sistema poderiam habilitar você à identificar o intruso.

Esta fase deveria se desenvolver levando a cabo procedimentos predeterminados.

Sua organização ou site devem, por exemplo, definir riscos aceitável lidando com um incidente, e deveria prescrever ações específicas e estratégias adequadas. Isto é especialmente importante quando uma decisão rápida é necessária e não é possível contactar todas as partes envolvidas primeiro para discutir a decisão. Na ausência de procedimentos predefinidos, a pessoa no cargo do incidente não terá freqüentemente o poder para tomar decisões de administração difíceis (como perder os resultados de uma experiência cara desligando um sistema). Uma atividade final que deveria acontecer durante esta fase de tratamento do incidente é a notificação de autoridades apropriadas.

5.4.4 Erradicação

Uma vez que o incidente foi contido, é tempo para erradicar a causa. Mas antes de erradicar a causa, deveria ser tomado grande cuidado colecionar todas as informações necessárias sobre os sistemas comprometidos e a causa do incidente como elas serão provavelmente serão perdidas quando o sistema for limpo.

Softwares podem estar disponíveis para ajudar no processo de erradicação, como software de anti-vírus. Se qualquer falso arquivos foram criados, devem ser apagados. No caso de infecções de vírus, é importante limpar e reformatar qualquer mídia que contém arquivos infetados. Finalmente, assegura que todos os backups estão limpos. Muitos sistemas infetados com vírus ficam periodicamente ré-infetados simplesmente porque as pessoas não erradicam o vírus do backup. Depois de erradicação, deveria ser feito um novo backup.

Removendo todas as vulnerabilidades uma vez um incidente aconteceu é difícil. A chave para remover vulnerabilidades é conhecimento e entendimento da brecha.

Pode ser necessário voltar para as mídia de distribuição originais e ré-customizar o sistema. Para facilitar esta situação de pior caso, um registro do setup do sistema original e de cada mudança de customização deveria ser mantido. No caso de um ataque baseado na rede, é importante instalar remendos para cada vulnerabilidade de sistema operacional que foi explorado.

Como discutido na seção 5.4.2, um log de segurança pode ser muito valioso durante esta fase de remover vulnerabilidade. Os logs que mostram como o incidente foi descoberto e foi contido pode ser usado para ajudar depois a determinar qual a extensão do dano de um determinado incidente. O passos podem ser usados no futuro para ter certeza que o problema não irá ocorrer. Idealmente, a pessoa deveria automatizar e regularmente deveria aplicar o mesmo teste como foi usado para descobrir o incidente de segurança.

Se uma vulnerabilidade particular é isolada como explorada, o próximo passo é achar um mecanismo para proteger seu sistema. A segurança que remete listas e boletins seria um lugar bom para procurar esta informação, e você pode obter conselhos dos grupos de resposta a incidentes.

5.4.5 Recuperação

Uma vez que a causa de um incidente foi erradicada, a fase de recuperação define a próxima fase de ação. A meta de recuperação é retornar o sistema ao normal. Em geral, expondo serviços na ordem de demanda e com um mínimo de inconveniência aos usuário é a melhor prática. Entenda que os procedimentos de recuperação formais para o sistema é extremamente importante e deveria ser específico para o site.

5.4.6 Prosseguimento

Uma vez que você acredita que o sistema foi restabelecido a um " estado seguro ", ainda é possível que buracos, e até mesmo armadilhas, podem estar espreitando o sistema. Uma das fases mais importantes de respostas a incidentes também é freqüentemente omitida, a fase de seguimento. Na fase de seguimento, o sistema deveria ser monitorado com vistas à aspectos que podem ter sido perdidos durante a fase de cleanup. Seria prudente utilizar, como um começo, algumas das ferramentas mencionados no capítulo 7.

Lembre-se, estas ferramentas não substituem uma monitoração continuada do sistema e boas práticas de administração de sistemas.

O elemento mais importante da fase de seguimento é executar uma análise de pos morte. Exatamente o que aconteceu, e quanto tempo? Como foi a performance do pessoal envolvido com o incidente? Que tipo de informação foi necessária rapidamente para o pessoal, e como eles adquirir aquela informação o mais cedo possível? O que faria o pessoal diferentemente da próxima vez?

Após um incidente, é prudente escrever um relatório que descreve a sucessão exata de eventos: o método de descoberta, procedimento de correção, procedimento de monitoração, e um resumo da lição aprendida.

Isto ajudará na compreensão clara do problema. Criando uma cronologia formal de eventos (inclusive time stamps) também é importante por razões legais.

Um relatório de seguimento é valioso por muitas razões. Provê uma referências a serem usadas no caso de outros incidentes semelhantes. Também é importante para que, tão depressa quanto possível obtenha-se uma estimativa da quantia monetária dos danos que o incidente causou. Esta estimativa deve incluir custos associados com qualquer perda de software e arquivos(especialmente o valor de dados proprietário que podem ter sido descoberto), dano de hardware, e força de trabalho usada para restabelecer arquivos alterados, reconfigure sistemas afetados, e assim sucessivamente. Esta estimativa pode se tornar a base para atividade de prossecução subseqüente. O relatório também pode ajudar justifique o esforço de segurança dos computadores de uma organização para administração.

5.5 Resultado de um Incidente

Após um incidente, deveriam acontecer várias ações. Estas ações podem ser resumidas nas seguintes:

Se um incidente está baseado em política pobre, e a menos que a política seja mudada, você então é sentenciado repetir o passado. Uma vez que um site se recuperou de um incidente deveriam ser revisadas a política do site e os procedimentos para cercar mudanças para prevenir incidentes semelhantes. Até mesmo sem um incidente, seria prudente revisar políticas e procedimentos com uma base regular. Revisões são imperativas devido aos ambientes de computação variáveis de hoje.

O propósito inteiro deste processo de pos morte é melhorar tuda a segurança para proteger o site contra ataques futuros. Como resultado de um incidente, um site ou organização ganhar conhecimento prático da experiência. Uma meta concreta do pos morte é desenvolver novos métodos de proactive. Outra faceta importante do resultado pode ser a educação do usuário final e administrador para prevenir a nova ocorrência do problema de segurança.