RFC 3227 – Diretrizes para Coleta e Arquivamento de Evidências

RFC 3227

Melhores Práticas

rfc 3227 diretrizes para coleta e arquivamento de evidencias

rfc 3227 diretrizes para coleta e arquivamento de evidencias

 

Nosso colaborador Tiago Souza realizou a tradução da RFC 3227 e disponibilizou nesta página para acesso. Se você desejar acesso ao documento original completo clique aqui ou vá diretamente para o site oficial do IETF ORG. Veja também outras referências aqui

RFC 3227 – Diretrizes para Coleta e Arquivamento de Evidências

Situação deste Memorando

Este documento especifica as Melhores Práticas Atuais da Internet para a Comunidade da Internet e solicita discussão e sugestões para melhorias. A distribuição deste memorando é ilimitada.  RFC 3227:

Aviso de Direitos Autorais

Copyright (C) The Internet Society (2002). Todos os Direitos Reservados.

Resumo RFC 3227

Um “incidente de segurança”, conforme definido no “Internet Security Glossary”, RFC 2828, é um evento de sistema relevante para a segurança em que a política de segurança do sistema é infringida ou violada de outra forma. O objetivo deste documento é fornecer aos Administradores de Sistema diretrizes sobre a coleta e arquivamento de evidências relevantes para tal incidente de segurança.

Se a coleta de evidências for feita corretamente, é muito mais útil para deter o atacante, tendo uma chance muito maior de ser admissível no caso de uma acusação.

Índice

1 – Introdução

Um “incidente de segurança”, conforme definido em [RFC2828], é um evento de sistema relevante para a segurança no qual a política de segurança do sistema é infringida ou violada. O objetivo deste documento é fornecer aos Administradores de Sistema diretrizes sobre a coleta e o arquivamento de evidências relevantes para tal incidente de segurança. Não é nossa intenção insistir que todos os Administradores de Sistema sigam rigorosamente essas diretrizes sempre que tiverem um incidente de segurança. Em vez disso, queremos fornecer orientação sobre o que eles devem fazer se optarem por coletar e proteger as informações relacionadas a uma intrusão.

Essa coleção representa um esforço considerável por parte do 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 assim a “opção fácil” ainda mais atrativa. Entretanto, pouco tem sido feito para fornecer maneiras fáceis de arquivar evidências (a opção difícil). Além disso, o aumento das capacidades de disco e memória e o uso mais difundido de táticas sigilosas e de cobertura de rastros pelos atacantes tem agravado o problema.

Se a coleta de evidências for feita corretamente, é muito mais útil para deter o atacante, tendo uma chance muito maior de ser admissível no caso de uma acusação.

Você deve usar essas diretrizes como base para formular os procedimentos de coleta das evidências do local e deve incorporar os procedimentos do seu local na documentação de Manipulação de Incidentes. As diretrizes neste documento podem não ser apropriadas em todas as jurisdições. Depois de formular os procedimentos de coleta de evidências do seu local, você deve ter a aplicação da lei para sua jurisdição confirmar que eles são adequados.

1.1 – Convenções Utilizadas neste Documento

As palavras-chave “REQUER”, “DEVE”, “NÃO DEVE”, “PODERIA”, “NÃO PODERIA” e “PODE” neste documento devem ser interpretadas como descritas em “Key words for use in RFCs to Indicate Requirement Levels” [RFC2119].

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

    • Aderir à Política de Segurança do seu local e envolver o pessoal adequado da Manipulação de Incidentes e Aplicação da Lei.
    • Capture a imagem mais precisa possível do sistema.
    • Mantenha notas detalhadas. Estas devem incluir datas e horários. Se possível, gere uma transcrição automática (por exemplo, em sistemas Unix, o programa ‘script’ pode ser usado, no entanto, o arquivo de saída que ele gera não deve ser a mídia que fará parte da evidência). As 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 foi usado UTC ou a hora local.
    • Esteja preparado para testemunhar (talvez anos mais tarde) descrevendo todas as ações que você tomou e em que momentos. As notas detalhadas serão vitais.
    • Minimize as alterações nos dados que você estiver coletando. Isso não se limita às alterações de conteúdo; você deve evitar atualizar os tempos de acesso aos arquivos ou diretórios.
    • Remova as vias externas para a mudança.
    • Quando confrontado com uma escolha entre coleta e análise, você deve fazer a coleta primeiro e depois analisar.
    • Embora não seja necessário indicar, seus procedimentos devem ser implementáveis. Como em qualquer aspecto de uma política de resposta a incidentes, os procedimentos devem ser testados para assegurar a viabilidade, particularmente em uma crise. Se possível, os procedimentos devem ser automatizados por razões de velocidade e precisão. Seja metódico.
    • Para cada dispositivo, deve ser adotada uma abordagem metódica que siga as diretrizes estabelecidas no seu procedimento de coleta. A velocidade será muitas vezes crítica, então, onde há uma série de dispositivos que exigem análise, pode ser apropriado distribuir o trabalho entre sua equipe para coletar as evidências em paralelo. No entanto, em uma única coleta de sistema, deve ser feito passo a passo.
    • Proceda do volátil para o menos volátil (veja a Ordem de Volatilidade abaixo).
  • Você deve fazer uma cópia bit-a-bit da mídia do sistema. Se você deseja fazer análises forenses, você deve fazer uma cópia bit-a-bit da sua cópia da evidência para esse propósito, pois sua análise certamente irá alterar os tempos de acesso aos arquivos. Evite fazer perícias na cópia das evidências.

2.1 – Ordem de Volatilidade

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

    • Registros, cache
    • Tabela de roteamento, cache ARP, tabela de processo, 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 arquivamento

2.2 – Coisas para evitar

É muito fácil destruir a evidência, entretanto, involuntário.

    • Não desligue até completar a coleta das evidências. Muitas evidências podem ser perdidas e o atacante pode ter alterado os scripts/serviços de inicialização/desligamento para destruir as evidências.
    • Não confie nos programas do sistema. Execute seus programas de coleta de evidências de mídias adequadamente protegidos (veja abaixo).
    • Não execute programas que modifiquem o tempo de acesso de todos os arquivos no sistema (por exemplo, ‘tar’ ou ‘xcopy’).
  • Ao remover as vias externas para a nota de mudança, a simples desativação ou filtragem da rede pode desencadear “deadman switches” que detectam quando estão fora da rede e apagam evidências.

2.3 – Considerações de Privacidade

    • Respeite as regras de privacidade e diretrizes de sua empresa e sua jurisdição legal. Em particular, certifique-se de que nenhuma informação coletada juntamente com a evidência que você está procurando está disponível para qualquer pessoa que normalmente não tenha acesso a esta informação. Isso inclui acesso a arquivos de log (que podem revelar padrões de comportamento do usuário), bem como arquivos de dados pessoais.
    • Não invada a privacidade das pessoas sem uma forte justificativa. Em particular, não colete informações de áreas que normalmente não existem motivos para acessar (como armazenamento de arquivos pessoais), a menos que você tenha indicação suficiente de que exista um incidente real.
  • Certifique-se que você tem o apoio dos procedimentos estabelecidos da sua empresa para tomar as medidas que você faz para coletar evidências de um incidente.

2.4 – Considerações Legais

A evidência do computador precisa ser:

    • Admissível: Deve estar em conformidade com certas regras legais antes de poder ser submetida a um tribunal.
    • Autêntica: Deve ser possível amarrar positivamente o material probatório ao incidente.
    • Completa: Deve contar toda a história e não apenas uma perspectiva particular.
    • Confiável: Não deve haver nada sobre como a evidência foi coletada e, posteriormente, causando dúvidas da autenticidade e veracidade.
  • Crível ou Acreditável: Deve ser facilmente acreditável e compreensível por um tribunal.

3 – O Procedimento de Coleta

Seus procedimentos de coleta devem ser os mais detalhados possíveis. Tal como ocorre com os seus procedimentos de Manipulação de Incidentes, eles devem ser inequívocos e devem minimizar a quantidade de tomada de decisão necessária durante o processo de coleta.

3.1 – Transparência

Os métodos utilizados para coletar evidências devem ser transparentes e reprodutíveis. Você deve estar preparado para reproduzir com precisão os métodos que você usou e ter esses métodos testados por especialistas independentes.

3.2 – Etapas da Coleta

    • Onde estão as evidências? Liste quais sistemas foram envolvidos no incidente e de quais evidências serão coletadas.
    • Estabeleça o que é provável de ser relevante e admissível. Quando estiver com dúvidas, erre no lado da coleta a mais, em vez de não o suficiente.
    • Para cada sistema, obtenha a ordem de volatilidade relevante.
    • Remova as vias externas para a mudança.
    • Seguindo a ordem de volatilidade, colete a evidência com as ferramentas conforme discutido na Seção 5.
    • Registre a medida do relógio do sistema.
    • Pergunte o que mais pode ser evidência à medida que você trabalha através das etapas de coleta.
    • Documente cada passo.
  • Não se esqueça das pessoas envolvidas. Faça anotações sobre quem estava lá e o que eles estavam fazendo, o que eles observaram e como eles reagiram.

Quando possível, você deve considerar a geração da soma de verificação (checksums) e assinatura criptografada da evidência coletada, pois isso pode facilitar a preservação de uma forte cadeia de evidências. Ao fazê-lo, você não deve alterar a evidência.

4 – O Procedimento de Arquivamento

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

4.1 – Cadeia de Custódia

Você deve ser capaz de descrever claramente como a evidência foi encontrada, como ela foi tratada e tudo o que aconteceu com ela.

O seguinte deve ser documentado:

    • Onde, quando e por quem a evidência foi descoberta e coletada.
    • Onde, quando e por quem as evidências foram tratadas ou examinadas.
    • Quem teve a custódia da evidência, durante o período. Como foi armazenado.
  • Quando a evidência mudou de custódia, quando e como ocorreu a transferência (inclui números de envio, etc.).

4.2 – Onde e Como Arquivar

Se possível, a mídia comumente usada (em vez de alguns meios de armazenamento obscuros) deve ser usada para arquivamento.

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

5 – Ferramentas que você vai precisar

Você deve ter os programas que você precisa para fazer a coleta de evidências e forense em mídia somente leitura (por exemplo, um CD). Você deve ter preparado tal conjunto de ferramentas para cada um dos Sistemas Operacionais que você for gerenciar 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’).
    • Programas para gerar somas de verificação (checksums) e assinaturas (por exemplo, ‘sha1sum’, a checksum-enabled ‘dd’, ‘SafeBack’, ‘pgp’).
    • Programas para geração de imagens e para examiná-las (por exemplo, ‘gcore’, ‘gdb’)
  • Scripts para automatizar a coleta de evidências (por exemplo, The Coroner’s Toolkit [FAR1999]).

Os programas em seu conjunto de ferramentas devem estar vinculados de forma estática e não devem exigir o uso de quaisquer bibliotecas diferentes da mídia somente leitura. Mesmo assim, uma vez que os rootkits modernos podem ser instalados através de módulos de kernel carregáveis, você deve considerar que suas ferramentas podem não estar te dando uma imagem completa do sistema.

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

6 – Referências RFC 3227

    • [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 – Agradecimentos

Agradecemos os comentários construtivos recebidos de Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig e Floyd Short.

8 – Considerações de Segurança

Todo este documento discute questões de segurança. RFC 3227

9 – Endereços dos autores

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]

10 – Declaração de Direitos Autorais Completa

Copyright (C) The Internet Society (2002). Todos os Direitos Reservados.

Este documento e suas traduções podem ser copiados e fornecidos a terceiros, e as obras derivadas que comentam ou explicam ou auxiliam na sua implementação podem ser preparadas, copiadas, publicadas e distribuídas, no todo ou em parte, sem restrições de nenhum tipo, desde que o aviso de direitos autorais acima e este parágrafo estejam incluídos em todas essas cópias e trabalhos derivados. No entanto, este documento em si não pode ser modificado de forma alguma, como por exemplo, removendo o aviso de direitos autorais ou referências à Internet Society ou a outras organizações da Internet, exceto quando necessário, com o objetivo de desenvolver padrões da Internet, caso em que os procedimentos para direitos autorais definidos no processo de padrões da Internet devem ser seguidos, ou conforme necessário para traduzi-lo para outros idiomas além do inglês.

As permissões limitadas concedidas acima são perpétuas e não serão revogadas pela Internet Society ou seus sucessores ou atribuições.

Este documento e as informações aqui contidas são fornecidas “TAL COMO ESTÁ” e a INTERNET SOCIETY E A INTERNET ENGINEERING TASK FORCE RENUNCIAM TODAS AS GARANTIAS, EXPRESSAS OU IMPLÍCITAS, INCLUINDO, MAS NÃO SE LIMITANDO A QUALQUER GARANTIA DE QUE O USO DA INFORMAÇÃO AQUI NÃO INFRINGIRÁ QUAISQUER DIREITOS OU QUAISQUER GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO PARA UM DETERMINADO PROPÓSITO.

Reconhecimento

O financiamento para a função de RFC Editor é atualmente fornecido pela Internet Society.

Acesse o documento original completo aqui diretamente do IETF ORG

RFC 3227


Créditos da Tradução (pt-br) RFC 3227

 

Cadastre-se em nossa lista Vip

[email-subscribers namefield=”YES” desc=”” group=”Public”]

Deixe uma resposta