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.
Aprenda mais no curso CFID
Gostou do artigo? Conheça o curso Computação Forense e Investigação Digital.
Este curso tem como objetivo apresentar os conceitos da Computação Forense e métodos de Investigação Digital, sendo baseado no conteúdo apresentado nas certificações mais conhecidas do mercado.
Hospedagem de site
digitalocean, excelente custo benefício.
Clique abaixo e aproveite!
