RFC 3227 – Diretrizes para coleta e arquivamento de evidências

Status deste memorando

   Este documento especifica as melhores práticas atuais da Internet para o
   Comunidade da Internet e solicita discussão e sugestões para
   melhorias. A distribuição deste memorando é ilimitado.

Aviso de direitos autorais

   Direitos autorais (C) The Internet Society (2002). Todos os direitos reservados.

Resumo

   Um "incidente de segurança", conforme definido no "Glossário de segurança da Internet",
   RFC 2828 , é um evento do sistema relevante para a segurança, no qual os
   a política de segurança é desobedecida ou violada. O propósito de
   este documento é para fornecer aos administradores de sistema diretrizes sobre
   a coleta e o arquivamento de evidências relevantes para tal segurança
   incidente.

   Se a coleta de evidências for feita corretamente, será muito mais útil
   prender o atacante e tem uma chance muito maior de ser
   admissível em caso de acusação.

Índice

   1 Introdução ................................................ .... 2 
     1.1 Convenções usadas neste documento ........................... 2 
   2 Princípios orientadores durante a coleta de evidências ..... .............. 3 
     2.1 Ordem de Volatilidade ............................... .......... 4 
     2.2 Coisas a evitar ................................... .......... 4 
     2.3 Considerações sobre privacidade .................................... .. 5 
     2.4 Considerações legais ....................................... 5 
   3 A coleção Procedimento ....................................... 6
     3.1 Transparência ................................................ 6 
     3.2 Etapas de coleta ............................................ 6 
   4 O Procedimento de Arquivamento ........................................ 7 
     4.1 Cadeia de Custódia. ........................................... 7 
     4.2 Arquivo ... .............................................. 7 
   5 Ferramentas que você vai precisar ............................................... 7



Melhores práticas atuais de Brezinski e Killalea [Página 1]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002


   6 Referências ................................................ ...... 8 
   7 Agradecimentos ......................................... ... 8 
   8 Considerações de segurança ....................................... .. 8 
   9 Endereços dos autores ........................................... ... 9 
   10 Declaração completa de direitos autorais ....................................... 10

1 Introdução

   Um "incidente de segurança", conforme definido em [ RFC2828 ], é um item relevante para a segurança.
   evento do sistema em que a política de segurança do sistema é desobedecida ou
   caso contrário, violado. O objetivo deste documento é fornecer
   Administradores de sistemas com diretrizes sobre coleta e arquivamento
   evidência relevante para esse incidente de segurança. Não é nossa
   intenção de insistir que todos os administradores de sistema sigam rigidamente
   estas diretrizes sempre que ocorrerem um incidente de segurança. Em vez,
   queremos fornecer orientação sobre o que eles devem fazer se optarem por
   coletar e proteger informações relacionadas a uma invasão.

   Essa coleção representa um esforço considerável por parte da
   Administrador do sistema. Grandes progressos foram feitos nos últimos anos
   para acelerar a reinstalação do sistema operacional e para
   facilitar a reversão de um sistema para um estado 'conhecido', tornando
   a 'opção fácil' ainda mais atraente. Enquanto isso, pouco tem sido
   para fornecer maneiras fáceis de arquivar evidências (a difícil
   opção). Além disso, o aumento das capacidades de disco e memória e mais
   uso generalizado de táticas furtivas e encobrir seus rastros por atacantes
   exacerbaram o problema.

   Se a coleta de evidências for feita corretamente, será muito mais útil
   prender o atacante e tem uma chance muito maior de ser
   admissível em caso de acusação.

   Você deve usar essas diretrizes como base para formular sua
   procedimentos de coleta de evidências do site e deve incorporar
   procedimentos do site na documentação de Manuseio de incidentes. o
   diretrizes deste documento podem não ser apropriadas em todos os
   jurisdições. Depois de formular as evidências do seu site
   procedimentos de coleta, você deve ter aplicação da lei para o seu
   jurisdição confirmar que eles são adequados.

1.1 Convenções usadas neste documento

   As palavras-chave "NECESSÁRIO", "DEVE", "NÃO DEVE", "DEVE", "NÃO DEVE",
   e "PODE" neste documento devem ser interpretados conforme descrito em "
   palavras para uso em RFCs para indicar os níveis de exigência "[ RFC2119 ].






Melhores práticas atuais de Brezinski e Killalea [Página 2]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002

2 Princípios Orientadores durante a Coleta de Evidências

      - Adira à Política de Segurança do seu site e envolva-se no
         pessoal apropriado de Manuseio de Incidentes e de aplicação da lei.

      - Capture a imagem mais precisa possível do sistema.

      - Mantenha notas detalhadas. Estes devem incluir datas e horas. E se
         possível gerar uma transcrição automática. (por exemplo, no Unix
         sistemas, o programa 'script' pode ser usado, porém a saída
         O arquivo gerado não deve ser usado para mídia que faz parte do
         evidência). Notas e impressões devem ser assinadas e datadas.

      - Observe a diferença entre o relógio do sistema e o UTC. Para cada
         timestamp fornecido, indique se o UTC ou a hora local são usadas.

      - Esteja preparado para testemunhar (talvez anos depois) descrevendo
         ações que você tomou e a que horas. Notas detalhadas serão
         vital.

      - Minimize as alterações nos dados enquanto você os coleta. Isto é
         não limitado a alterações de conteúdo; você deve evitar atualizar o arquivo
         ou tempos de acesso ao diretório.

      - Remova caminhos externos para mudança.

      - Quando confrontado com uma escolha entre coleta e análise
         você deve fazer a coleta primeiro e a análise posteriormente.

      - Embora dificilmente precise ser declarado, seus procedimentos devem ser
         implementável. Como em qualquer aspecto de uma resposta a incidentes
         política, procedimentos devem ser testados para garantir a viabilidade,
         particularmente em uma crise. Se possíveis procedimentos devem ser
         automatizado por razões de velocidade e precisão. Seja metódico.

      - Para cada dispositivo, deve ser adotada uma abordagem metódica que
         segue as diretrizes estabelecidas no seu procedimento de coleta.
         A velocidade será muitas vezes crítica, portanto, onde existem várias
         dispositivos que requerem exame, pode ser apropriado espalhar
         o trabalho da sua equipe para coletar as evidências em paralelo.
         No entanto, em uma única coleta de sistema, deve ser feito o passo
         passo a passo.

      - Prossiga do volátil para o menos volátil (consulte o Pedido
         Volatilidade abaixo).






Melhores práticas atuais de Brezinski e Killalea [Página 3]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002


      - Você deve fazer uma cópia em nível de bit da mídia do sistema. Se vocês
         deseja fazer análise forense, você deve fazer uma cópia em nível de bit
         sua cópia de evidência para esse fim, pois sua análise será
         quase certamente alterar os tempos de acesso ao arquivo. Evite fazer
         forense na cópia da evidência.

2.1 Ordem de Volatilidade

   Ao coletar evidências, você deve passar do volátil para o
   menos volátil. Aqui está um exemplo de ordem de volatilidade para um típico
   sistema.

      - registros, cache

      - tabela de roteamento, cache arp, tabela de processos, estatísticas do kernel,
         memória

      - sistemas de arquivos temporários

      - disco

      - registro remoto e dados de monitoramento relevantes para o
         sistema em questão

      - configuração física, topologia de rede

      - mídia de arquivo

2.2 Coisas a evitar

   É muito fácil destruir evidências, mesmo que inadvertidamente.

      - Não desligue até concluir a coleta de evidências.
         Muitas evidências podem ser perdidas e o atacante pode ter alterado o
         scripts / serviços de inicialização / desligamento para destruir evidências.

      - Não confie nos programas no sistema. Execute sua evidência
         coleta de programas de mídia adequadamente protegida (consulte
         abaixo).

      - Não execute programas que modifiquem o tempo de acesso de todos os arquivos no
         o sistema (por exemplo, 'tar' ou 'xcopy').









Melhores práticas atuais de Brezinski e Killalea [Página 4]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002


      - Ao remover caminhos externos para mudança, observe que simplesmente
         desconectar ou filtrar da rede pode desencadear
         "interruptores deadman" que detectam quando estão fora da rede e
         limpe a evidência.

2.3 Considerações sobre privacidade

      - Respeite as regras e diretrizes de privacidade de sua empresa e
         sua jurisdição legal. Em particular, verifique se não
         informações coletadas junto com as evidências que você está pesquisando
         para está disponível para quem normalmente não teria acesso
         para esta informação. Isso inclui o acesso aos arquivos de log (que
         pode revelar padrões de comportamento do usuário), bem como dados pessoais
         arquivos.

      - Não se intrometa na privacidade das pessoas sem fortes
         justificação. Em particular, não colete informações de
         áreas às quais você normalmente não tem motivos para acessar (como
         arquivos pessoais), a menos que você tenha indicação suficiente
         que existe um incidente real.

      - Verifique se você tem o apoio da empresa estabelecida
         procedimentos para executar as etapas que você executa para coletar evidências de um
         incidente.

2.4 Considerações legais

   As evidências do computador precisam ser

      - Admissível: deve estar em conformidade com certas regras legais antes de
         pode ser levado a tribunal.

      - Autêntico: deve ser possível amarrar positivamente as provas
         material ao incidente.

      - Completo: deve contar a história toda e não apenas um
         perspectiva particular.

      - Confiável: não deve haver nada sobre como as evidências foram
         coletados e posteriormente manipulados que ponham em dúvida sua
         autenticidade e veracidade.

      - Acreditável: deve ser prontamente crível e compreensível
         por um tribunal.







Melhores práticas atuais de Brezinski e Killalea [Página 5]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002

3 O procedimento de coleta

   Seus procedimentos de coleta devem ser o mais detalhados possíveis. Como é
   caso com os procedimentos gerais de Manuseio de Incidentes, eles devem
   inequívoca e deve minimizar a quantidade de decisões tomadas
   necessário durante o processo de coleta.

3.1 Transparência

   Os métodos usados ​​para coletar evidências devem ser transparentes e
   reproduzível. Você deve estar preparado para reproduzir com precisão
   métodos que você usou e os testou por métodos independentes
   especialistas.

3.2 Etapas da coleta

      - Onde estão as evidências? Liste quais sistemas estavam envolvidos na
         incidente e do qual serão coletadas evidências.

      - Estabeleça o que é provável que seja relevante e admissível. Quando
         em dúvida, errar do lado de coletar muito, em vez de não
         o suficiente.

      - Para cada sistema, obtenha a ordem relevante de volatilidade.

      - Remova caminhos externos para mudança.

      - Seguindo a ordem da volatilidade, colete as evidências com
         ferramentas conforme discutido na Seção 5 .

      - Registre a extensão do desvio do relógio do sistema.

      - Pergunte o que mais pode ser evidência ao trabalhar com o
         etapas de coleta.

      - Documente cada etapa.

      - Não esqueça as pessoas envolvidas. Faça anotações de quem estava lá
         e o que eles estavam fazendo, o que observaram e como
         reagiu.

   Onde possível, considere gerar somas de verificação e
   assinar criptograficamente as evidências coletadas, pois isso pode torná-lo
   mais fácil preservar uma forte cadeia de evidências. Ao fazer isso, você deve
   não alterar as evidências.






Melhores práticas atuais de Brezinski e Killalea [Página 6]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002

4 O procedimento de arquivamento

   As evidências devem ser rigorosamente protegidas. Além disso, a Cadeia de Custódia
   precisa ser claramente documentado.

4.1 Cadeia de Custódia

   Você deve ser capaz de descrever claramente como as evidências foram encontradas,
   como foi tratado e tudo o que aconteceu com ele.

   O seguinte precisa ser documentado

      - Onde, quando e por quem as evidências foram descobertas e
         coletados.

      - Onde, quando e por quem as evidências foram tratadas ou examinadas.

      - Quem teve a custódia das provas, durante que período. Como foi
         armazenado.

      - Quando a evidência mudou a custódia, quando e como a
         a transferência ocorre (inclui números de remessa etc.).

4.2 Onde e como arquivar

   Se possível, mídia comumente usada (em vez de algum armazenamento obscuro
   mídia) deve ser usado para arquivamento.

   O acesso à evidência deve ser extremamente restrito e deve ser
   claramente documentado. Deve ser possível detectar não autorizado
   Acesso.

5 ferramentas necessárias

   Você deve ter os programas necessários para coletar evidências e
   forense em mídia somente leitura (por exemplo, um CD). Você deveria ter preparado
   um conjunto de ferramentas para cada um dos sistemas operacionais que você gerencia
   antes de ter que usá-lo.

   Seu conjunto de ferramentas deve incluir o seguinte:

      - um programa para examinar processos (por exemplo, 'ps').

      - programas para examinar o estado do sistema (por exemplo, 'showrev',
         'ifconfig', 'netstat', 'arp').

      - um programa para fazer cópias bit a bit (por exemplo, 'dd', 'SafeBack').




Melhores práticas atuais de Brezinski e Killalea [Página 7]

---

 
           Coleta e arquivamento de evidências da RFC 3227 fevereiro de 2002


      - programas para gerar somas de verificação e assinaturas (por exemplo,
         'sha1sum', um dd ativado por soma de verificação, 'SafeBack', 'pgp').

      - programas para gerar imagens principais e examiná-las
         (por exemplo, 'gcore', 'gdb').

      - scripts para automatizar a coleta de evidências (por exemplo, The Coroner's
         Kit de Ferramentas [ FAR1999 ]).

   Os programas no seu conjunto de ferramentas devem estar estaticamente vinculados e
   não deve exigir o uso de bibliotecas que não sejam as existentes no
   mídia somente leitura. Mesmo assim, como rootkits modernos podem ser instalados
   através de módulos carregáveis ​​do kernel, você deve considerar que suas ferramentas
   pode não estar fornecendo uma imagem completa do sistema.

   Você deve estar preparado para testemunhar a autenticidade e confiabilidade
   das ferramentas que você usa.

6 References

   [FAR1999]   Farmer, D., and W Venema, "Computer Forensics Analysis
               Class Handouts", http://www.fish.com/forensics/

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2196]   Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
               September 1997.

   [RFC2350]   Brownlee, N. and  E. Guttman, "Expectations for Computer
               Security Incident Response", FYI 8, RFC 2350, June 1998.

   [RFC2828]   Shirey, R., "Internet Security Glossary", FYI 36, RFC
               2828, May 2000.

7 Acknowledgements

   We gratefully acknowledge the constructive comments received from
   Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,
   Andrew Rees, Steve Romig and Floyd Short.

8 Security Considerations

   This entire document discuses security issues.







Brezinski & Killalea     Best Current Practice                  [Page 8]

---

 
RFC 3227           Evidence Collection and Archiving       February 2002

9 Authors’ Addresses

   Dominique Brezinski
   In-Q-Tel
   1000 Wilson Blvd., Ste. 2900
   Arlington, VA 22209
   USA

   EMail: [email protected]


   Tom Killalea
   Lisi/n na Bro/n
   Be/al A/tha na Muice
   Co. Mhaigh Eo
   IRELAND

   Phone: +1 206 266-2196
   EMail: [email protected]



Brezinski & Killalea     Best Current Practice                  [Page 9]

---

 
RFC 3227           Evidence Collection and Archiving       February 2002

10. Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.