Requisitos em análise forense digital Definição: observações de um estudo no Reino Unido

 

de Angus M. Marshall e Richard Paige

Resumo

Durante um projeto para examinar a potencial utilidade de evidências de verificação de ferramentas como parte da validação de métodos para a acreditação ISO 17025, os autores examinaram as declarações de requisitos em várias descrições e ferramentas de métodos forenses digitais. Eles identificaram que há uma ausência de declarações de requisitos claras nos métodos e uma relutância ou incapacidade de divulgar os requisitos por parte dos produtores de ferramentas. Isso leva a uma quebra na evidência de correção para ferramentas e métodos, resultando em validação incompleta. Eles comparam a situação forense digital com outras organizações acreditadas pela ISO 17025, tanto forenses quanto não-forenses, e propõem um meio de fechar a lacuna e melhorar a validação. Eles também analisam projetos existentes que podem ajudar na solução proposta.

1. Introdução

A ISO / IEC 27041 [1], como parte de um grupo de normas que tratam de investigações digitais, é o padrão que descreve um processo pelo qual um método pode ser mostrado como apto para o propósito pretendido. Para isso, propõe um processo para a validação de métodos utilizados em uma investigação digital. Na descrição da validação, sugere que a evidência da verificação de uma ferramenta em relação a um conjunto declarado de requisitos pode ser usada como meio de reduzir a quantidade de validação necessária para processos nos quais a ferramenta participa, ou seja, sugere que esses requisitos de processo são totalmente satisfeitos pela ferramenta, e para o qual existe evidência de verificação, não precisa ser submetida a testes adicionais.

Observação: neste projeto, nos concentramos apenas no problema de validação e verificação. Os outros padrões do grupo propõem modelos de coleta e processamento de evidências que. embora úteis, não são considerados problemas centrais para este trabalho.

Do ponto de vista da engenharia de software, a proposta da ISO / IEC 17 27041 [1] é totalmente aceitável. No entanto, para que esse mecanismo seja bem-sucedido, a ferramenta e o processo no qual ela participa devem ser especificados em termos de requisitos que podem ser mapeados um contra o outro para mostrar como a ferramenta atende ou cumpre parcialmente os requisitos do processo.

Com efeito, a proposta é que haja algum grau de sobreposição entre os requisitos da ferramenta e os requisitos do método, variando da possibilidade de que os requisitos de uma ferramenta sejam um subconjunto completo dos requisitos de um método (Figura 1) para a situação potencialmente Os requisitos do método são um subconjunto de uma ferramenta (Figura 1).

Na prática, como alguns dos requisitos para um método com um contexto investigativo serão de natureza não técnica, acredita-se que a situação mais comum será aquela mostrada na Figura 1, onde os requisitos de uma ferramenta se cruzam com os de um método, e somente os requisitos de ferramentas que estão na interseção são relevantes para a validação do método.

 

Durante a pesquisa sobre como esse mecanismo poderia ser aplicado na prática, particularmente para permitir que produtores de ferramentas para processos forenses digitais apoiem a conformidade de seus clientes com o requisito de validação da ISO 17025 [2], através da divulgação de provas de teste e sem comprometer informações comercialmente sensíveis, Como detalhes dos dados dos testes, os autores descobriram que esse mapeamento parece ser impossível no momento em que escrevo. Isso porque é impossível obter os níveis necessários de informações sobre os requisitos de qualquer um dos participantes do estudo. Dois fatores principais parecem afetar isso:

• Em primeiro lugar, as definições de processo examinadas em nosso estudo não contêm nenhum requisito técnico que possa ser mapeado. Em vez disso, eles contêm principalmente requisitos não técnicos alinhados às necessidades do Sistema de Justiça Criminal.
• Em segundo lugar, os produtores de ferramentas são incapazes (no caso da maioria dos pequenos provedores) ou não querem (no caso da maioria dos provedores maiores) fornecer informações sobre como eles capturam os requisitos do cliente, quanto mais divulgar quais são esses requisitos.

 

Alguns até chegaram a responder ao pedido de informações com declarações como “A informação que você procura é comercialmente sensível à medida que operamos em um cenário muito competitivo. Infelizmente, não podemos fornecer informações específicas sobre nossas técnicas de desenvolvimento de produtos para terceiros. ”Os autores lutam para entender esse tipo de resposta, pois nossas questões relacionadas a modelos de desenvolvimento de alto nível e métodos de captura de requisitos, em vez de detalhes específicos de implementação de ferramentas ou testes. Podemos apenas supor que os provedores de ferramentas que responderam dessa maneira ou não confiam em seus próprios produtos ou acreditam que estão usando técnicas de desenvolvimento inovadoras que nenhum outro desenvolvedor considerou.

2. Princípios da ISO 17025

Antes de examinar mais de perto o conceito de validação, pode ser útil revisar alguns dos princípios que sustentam a ISO 17025, que são incorporados na versão anterior e que influenciam seu uso em organizações “não-forenses”, como aquelas que realizam a calibração de ferramentas ou testes de compostos químicos ou ligas metálicas.

Gravel [3], escrevendo em 2002 sobre a versão de 1999 da ISO 17025 descreveu 8 princípios que foram incorporados dentro da norma como:

• Capacidade Conceito de que um laboratório possui os recursos (pessoas com as habilidades e conhecimentos necessários, o ambiente com as instalações e equipamentos necessários, o controle de qualidade e os procedimentos) para realizar o trabalho e produzir resultados competentes.
• Exercício de responsabilidade Conceito de que as pessoas na organização têm autoridade para executar funções específicas dentro do escopo geral do trabalho e que a organização pode demonstrar responsabilidade pelos resultados do trabalho.
• Método científico Conceito de que o trabalho realizado pela organização é baseado em abordagens científicas aceitas, de preferência baseadas em consensos, e que quaisquer desvios das abordagens científicas aceitas podem ser substanciados de uma maneira considerada geralmente aceitável por especialistas nesse campo.
• Objetividade dos resultados
  1. Conceito de que os resultados produzidos dentro do escopo de trabalho da organização baseiam-se principalmente em quantidades mensuráveis ​​ou derivadas.
  2. Conceito de que os resultados subjetivos dos testes são produzidos apenas por pessoas consideradas qualificadas para tal e que tais resultados são considerados subjetivos, ou são conhecidos por especialistas na área de testes como sendo principalmente subjetivos.
• Imparcialidade de conduta Conceito de que a busca de resultados competentes através do uso de abordagens científicas geralmente aceitas é a principal e preponderante influência no trabalho das pessoas que executam testes – todas as outras influências são consideradas secundárias e não podem ter precedência.
• Rastreabilidade da medição
  1. Conceito de que os resultados produzidos, dentro do escopo de trabalho do laboratório, são baseados em um sistema reconhecido de medição que deriva de quantidades conhecidas e aceitas (sistema SI) ou outros dispositivos ou quantidades intrínsecas ou bem caracterizadas.
  2. Conceito de que a cadeia de comparação de medidas entre essas quantidades conhecidas ou conhecidas, ou dispositivos intrínsecos ou quantidades, e o dispositivo fornecendo o resultado objetivo, é ininterrupta para a transferência de características de medição, incluindo incerteza, para toda a cadeia de medição.
• Repetibilidade do teste Conceito de que o teste que produziu os resultados objetivos, produzirá os mesmos resultados, dentro de desvios aceitos durante testes subseqüentes, e dentro das restrições de usar os mesmos procedimentos, equipamentos e pessoas usados ​​durante a execução anterior do teste.
• Transparência do processo O conceito de que os processos existentes no laboratório que produzem os resultados objetivos está aberto ao escrutínio interno e externo, de modo que fatores que possam afetar negativamente a busca de resultados objetivos pelo laboratório com base em método científico podem ser facilmente identificados e mitigados.

Com as exceções de Capacidade e Exercício de responsabilidade, esses princípios estabelecem a necessidade de mostrar não apenas que um método escolhido satisfaz os requisitos para um uso pretendido, mas que o método é fundamentalmente correto ou sólido e satisfaz os requisitos técnicos mais amplos.

De nossas revisões das versões de 2005 e 2017 da ISO 17025, parece que esses princípios foram mantidos nas versões mais recentes da norma.

3. Aplicação da ISO 17025: 2005 às disciplinas “não forenses”

Uma crítica regularmente expressa à ISO 17025 é que ela é, como o próprio título sugere, destinada a laboratórios de testes e calibração. Para entender como a ISO 17025 é aplicada nessas organizações “não-forenses” e para determinar se ou como ela é aplicada diferentemente em um contexto forense, os autores realizaram uma revisão dos registros de acreditação disponíveis publicamente.

O Serviço de Acreditação do Reino Unido (UKAS) mantém um registro de organismos credenciados [4], que está aberto à inspeção pública. As entradas neste registro incluem detalhes de cada teste para o qual um corpo foi credenciado, dando uma breve descrição do método usado quando apropriado ou necessário. O exame de uma amostra de 100 organizações acreditadas numa série de áreas “não forenses” e “não médicas” revela que estas organizações aplicam duas abordagens para definir os requisitos para o seu processo acreditado:

Propriedades físicas Quando a medição precisa de propriedades físicas é possível (por exemplo, volumétrico, força, torque, acústica), os cronogramas de acreditações especificam, usando unidades SI, a faixa de medição possível e as tolerâncias (incerteza) permitidas para essa medição.

Padrões externos Em outras circunstâncias, onde uma indústria definiu seus próprios padrões, a acreditação é baseada na implementação da norma publicada que define o intervalo e a incerteza para a medição, ou define o método em si.

Em ambos os casos, os requisitos para o método e, portanto, sua validação, estão disponíveis na forma publicada (diretamente no cronograma de acreditação ou no padrão publicado) e, portanto, podem ser submetidos a escrutínio independente e adotados por outros que praticam em o mesmo campo técnico. De facto, os requisitos publicados permitem uma verificação independente do método para mostrar correcção na forma de conformidade com um conjunto geral de requisitos padronizados em vez de apenas satisfazer os requisitos 150 para um caso de uso específico.

Além disso, a presença desses critérios publicados permite que os clientes identifiquem os corpos de teste cujos métodos podem satisfazer suas necessidades antes de entrar em discussões com o corpo de teste. Com efeito, os requisitos listados e testes associados tornam-se um menu a partir do qual o cliente e o corpo de teste podem escolher a maneira mais adequada de atender às necessidades específicas do cliente.

4. Discussão sobre validação

Em muitas discussões de credenciamento em relação ao padrão, o conceito de “validação da ferramenta” ou mesmo “credenciamento de ferramentas” é levantado por usuários e fornecedores como um meio de encurtar ou eliminar o processo. Para os autores, isso sugere que pode haver alguma confusão sobre os significados desses termos ou um uso diferente da linguagem em vigor. É, portanto, instrutivo considerar a distinção de engenharia de software entre verificação e validação e contrastá-la com a visão ISO 17025.

4.1. Abordagem ISO 17025: 2005 para validação.

A ISO 17025: 2005 [2] não contém nenhuma definição direta de validação, mas, de acordo com a prática ISO, encaminha o leitor para ISO 17000 e ISO 9000 para herança de definições relevantes. Essa prática, de depender de definições encontradas em outros padrões, é comum com a faixa de padrões ISO, mas pode causar problemas para alguns usuários, pois eles podem perceber um requisito para ter acesso ao padrão de definição, bem como ao padrão que estão tentando implementar, ou eles podem depender exclusivamente do uso comum da palavra, em oposição às definições estipulativas da ISO (também conhecida como a regra “Humpty Dumpty”, p. 173). Na prática, a ISO fornece uma plataforma de navegação on-line [6] (OBP), que permite o acesso a definições e outro texto sem despesas adicionais.

Usando o OBP, os autores descobriram que a ISO 17000 não contém nenhuma definição de validação. Assim, a definição da ISO 9000: 2005 [7] deve ser usada, pois é a versão mais recente publicada antes da publicação da ISO 179 17025: 2005. Isto dá a seguinte definição de validação:

Confirmação, através do fornecimento de evidência objetiva, de que os requisitos para um uso específico pretendido ou aplicação foram cumpridos. 

NOTA 1 O termo ‘validado’ é usado para designar o status correspondente.
NOTA 2 As condições de uso para validação podem ser reais ou simuladas.

e define evidência objetiva como:

Dados que suportam a existência ou a veracidade de alguma coisa.

NOTA: Evidência objetiva pode ser obtida através de observação, medição, teste ou outros meios.

com exigência como:

necessidade ou expectativa que é declarada, geralmente implícita ou obrigatória.

Nota 1 de entrada: Geralmente implícito significa que é costume ou prática comum para a organização (3.3.1), seus clientes (3.3.5) e outras partes interessadas (3.3.7), que a necessidade ou expectativa em consideração está implícita .
Nota 2 para entrada: Um qualificador pode ser usado para denotar um tipo específico de requisito, por exemplo, requisito de produto, requisito de gerenciamento de qualidade, requisito do cliente.
Nota 3 para entrada: Um requisito especificado é aquele que é declarado, por exemplo, em um documento (3.7.2).
Nota 4 à entrada: Os requisitos podem ser gerados por diferentes partes interessadas (3.3.7).
Nota 5 de entrada: Esta definição difere da fornecida em 3.12.1 das Directivas ISO / IEC, Parte 2: 2004. 3.12.1 Exigência de expressão no conteúdo de um documento contendo critérios a serem preenchidos para que possa ser requerida a conformidade com o documento e a partir do qual nenhum desvio seja permitido.

Isso sugere que a validação é uma demonstração de adequação para um caso de uso específico, que os requisitos para um processo validado devem ser derivados do caso de uso pretendido e que a validação deve ser o processo de obtenção de dados que mostra que um método ou processo atende esses requisitos específicos.

4.2. Abordagem de engenharia de software para verificação e validação

No mundo da análise forense digital, tendemos a confiar em ferramentas de terceiros nas quais confiamos que foram produzidas de acordo com boas práticas de engenharia. Para as ferramentas analíticas mais comuns, este é um software em que confiamos que foi especificado, implementado e testado corretamente. No entanto, as respostas às nossas perguntas sobre modelos de desenvolvimento sugerem que há alguma desconexão entre os produtores de ferramentas e a forma como se espera que os usuários finais forneçam evidências de adequação à finalidade. Para entender como isso pode ter surgido, recorremos à consideração da terminologia da Engenharia de Software para descobrir se existe uma diferença conceitual fundamental.

Na Engenharia de Software, geralmente parafraseamos a verificação como “estamos construindo o produto corretamente?” E a validação como “estamos construindo o produto certo?” [8]. ou seja, a verificação é uma demonstração da exatidão do produto, enquanto a validação é uma demonstração de adequação para um uso específico. Mais formalmente, o Glossário Padrão de Terminologia de Engenharia de Software do IEEE [9]

Verificação  (1) O processo de avaliação de um sistema ou componente para determinar se os produtos de uma determinada fase de desenvolvimento satisfazem as condições impostas no início dessa fase. (2) Prova formal de correção do programa.

Validação  O processo de avaliar um sistema ou componente durante ou no final do processo de desenvolvimento para determinar se ele satisfaz os requisitos especificados.

Para completar, [9] também define um requisito como (1) Uma condição ou capacidade necessária para que um usuário resolva um problema ou alcance um objetivo. (2) Uma condição ou capacidade que deve ser atendida ou possuída por um sistema ou componente do sistema para atender a um contrato, padrão, especificação ou outros documentos formalmente impostos. (3) Uma representação documentada de uma condição ou capacidade como em (1) ou (2).

Essas definições são completamente consistentes com as encontradas nos padrões ISO 248 e ISO / IEC em consideração.

Os produtos de software devem, portanto, ser submetidos a verificação durante o desenvolvimento – para mostrar que estão corretos e completos, e validação pós-desenvolvimento para mostrar que eles atendem aos requisitos para os casos de uso pretendidos. Em termos mais comuns, o teste de validação pode ser considerado um teste de aceitação.

No caso de software personalizado, produzido em resposta a um problema específico, o processo de verificação pode resultar na validação desse problema. No caso de software pronto para uso (por exemplo, processadores de texto, planilhas, ferramentas forenses comuns), a verificação durante as fases de desenvolvimento é baseada em uma declaração genérica de requisitos que atende às necessidades de um cliente ou de um grupo de clientes idealizados. É responsabilidade do cliente garantir que a ferramenta verificada forneça uma solução válida para seu problema como parte do processo de aquisição e pré-implantação.

É, portanto, totalmente possível verificar um produto que não pode ser validado, pois não fornece uma solução adequada para o problema em questão (por exemplo, uma planilha customizada pode ser completamente construída corretamente, mas não utilizável como um pacote de apresentação). Também é possível validar um produto não verificado mostrando que, apesar de suas falhas inerentes, o produto satisfaz um determinado conjunto de requisitos específicos de caso. Por exemplo, uma calculadora que sempre declara que 2 + 2 = 5 é improvável de ser verificável, mas pode participar de um método validado em que o requisito é calcular que 3 + 3 = 6. Da mesma forma, uma ferramenta projetada para analisar apenas os sistemas de arquivos FAT não analisará o NTFS. Portanto, não é verificável para NTFS, mas pode participar de métodos que são validados para exame de um sistema de arquivos formatado em FAT.

No último caso, o produto não verificado não pode ser mostrado para ter qualquer utilidade além das circunstâncias limitadas para as quais ele é validado.

No primeiro caso, no entanto, o produto verificado pode ser útil em outras situações e a presença de evidências de verificação pode ser usada para auxiliar o processo de escolhê-lo como uma solução potencial – isto é, a evidência de verificação pode mostrar que os requisitos de validação já foram cumpridas durante o processo de desenvolvimento.

Isso depende inteiramente da existência de declarações de requisitos adequadas para a ferramenta, tal como foi desenvolvida, e a situação na qual ela deve ser usada, e evidências satisfatórias de que esses requisitos foram atendidos.

 

 

4.3. Implicações para validação de métodos

Dado que as definições e uso de validação e verificação, conforme descrito acima, parecem ser consistentes, deve, portanto, ser possível usar evidência de verificação de engenharia de software, como sugerido na ISO / IEC 27041 [1] como parte da validação de um método adequadamente documentado.

5. Nosso estudo

5.1. Documentação de laboratório

Em nosso estudo, examinamos um pequeno conjunto de procedimentos operacionais padrão (SOPs) e planos de validação escolhidos aleatoriamente e registros de dois laboratórios forenses digitais credenciados. Os SOPs foram escritos em um formato que parece ser baseado no modelo SWGDE [10] e ser consistentes com o formato padrão aceito nos laboratórios de ciência forense do Reino Unido. Eles contêm seções detalhando Propósito, Escopo, Equipamento, Limitações, Procedimento, Processamento, Critérios de Sucesso / Falha e Referências. Nenhum desses POPs continha quaisquer definições óbvias de requisitos técnicos. Em vez disso, eles tendem a definir o sucesso em termos de processamento concluído sem que nenhum erro seja relatado e fornecem uma ampla área de aplicação na instrução Scope.

Os planos de validação continham alguns requisitos identificados, mas foram organizados como Usuário Final (o Sistema de Justiça Criminal), Jurídico (incluindo conformidade com a ISO 17025), Compatibilidade (somente formato de saída) e Ética. Não foram especificados requisitos técnicos óbvios de baixo nível em nenhum dos planos.

Os registros de validação mostraram que os processos de validação tendem a consistir em evidências de que o processo em teste produziu os mesmos resultados que o mesmo processo executou em outro equipamento ou que produziu os resultados esperados de um caso de teste específico.

O teste satisfez assim a carta da descrição de validação da ISO 17025: 2005, mas pode não ter atingido o nível sugerido pelos princípios em [3], particularmente em relação à Rastreabilidade e Transparência. Esta aparente falha não é pensada como um problema para outras disciplinas forenses cujas raízes estão em outras ciências como química, física ou biologia, onde os métodos utilizados em laboratórios forenses são adaptações específicas de métodos bem conhecidos que são utilizados para outros fins e que foram submetidos a rigorosa revisão por pares através da publicação e uso extensivo em outros trabalhos.

Digital Forensics, no entanto, tem suas raízes na engenharia e é altamente dependente de engenharia reversa de decisões e implementações feitas por outros. Muitas dessas implementações (por exemplo, firmware de disco rígido, implementações de sistema de arquivos, armazenamento em cache de dados) não são publicadas ou revisadas, pois são comercialmente sensíveis e / ou não há necessidade de a maioria dos usuários / clientes ter qualquer interesse particular no nível inferior. detalhe de implementação que é de particular interesse para um examinador ou analista forense digital. Como resultado, pode ser considerado difícil para os produtores ou usuários de ferramentas forenses mostrar que as ferramentas estão realmente corretas, exceto por métodos empíricos potencialmente demorados e dispendiosos.

Isso é composto por uma diferença fundamental na natureza da maneira como o software de prateleira (OTSS) é usado. Em um contexto não forense, o OTSS é tipicamente destinado a processar entradas fornecidas por um usuário para gerar uma saída específica. Nessa situação, as entradas são conhecidas ou podem ser examinadas antes que a saída seja vista e, assim, a detecção de resultados incorretos pode ser simples. No contexto forense, no entanto, os exames começam com uma fonte de evidência potencial cujo conteúdo é desconhecido. Assim, as entradas para todo o processo forense são desconhecidas. Embora o usuário possa ter alguma experiência de como as saídas anormais se parecem, isso depende inteiramente da ferramenta que realmente produz saídas anormais ou indicações de erros. É totalmente possível que uma ferramenta processe as entradas incorretamente e produza algo que ainda pareça consistente com a operação correta. Na ausência de evidências objetivas de verificação, a avaliação da exatidão, ou não, de quaisquer resultados produzidos por uma ferramenta depende exclusivamente da experiência do operador.

Também deve-se ter em mente que as atualizações de hardware e software podem não ter efeito aparente no comportamento do sistema no que se refere a um usuário típico, mas podem alterar drasticamente a maneira pela qual o processamento interno é executado e os dados armazenados. Isso afeta tanto a capacidade de recuperar e interpretar dados quanto o comportamento das ferramentas usadas para executar essas operações.

5.2. Prova do fornecedor de verificação

Nosso estudo fez circular um questionário e recebeu 14 respostas de provedores de ferramentas. Destes, 2 poderiam ser considerados provedores principais, embora um seja mais focado em e-Discovery do que investigações criminais.

Os 12 pequenos provedores pareciam confusos sobre o que significava os requisitos do cliente com respostas, incluindo “Eu sou meu próprio cliente”, “Desculpe, eu não entendi a pergunta”, “Fóruns, mídias sociais”, “Eu não – muitos clientes em potencial parecem totalmente confusos por que deveriam estar interessados ​​em tudo ”. Dos 14, 3 identificaram o uso do JIRA / Confluence / Github como meio de derivação de requisitos e outros três identificaram Reuniões e Comunicações com os usuários finais como os mecanismos utilizados.

Quando perguntados sobre como eles demonstraram que sua ferramenta atende aos requisitos do usuário, as respostas incluem o uso de imagens de disco de teste NIST, uso em laboratórios credenciados pela ISO 17025 e reuniões. Apenas um dos grupos de pesquisa mencionou o teste de conformidade.

Nós também, como notado na introdução, encontramos uma resistência considerável de alguns dos provedores mais conhecidos quando pedimos informações sobre este tópico. Como resultado, não podemos fornecer evidência objetiva para qualquer grau de confiança de que os fornecedores de ferramentas estão atendendo aos requisitos genuínos dos laboratórios forenses digitais.

Os clientes das ferramentas têm pouco incentivo para considerar os requisitos técnicos, pois parece ser possível obter a certificação ISO 17025: 2005 sem eles, e a maioria dos fornecedores de ferramentas não consegue ou não quer fornecer provas de que verificou suas ferramentas contra qualquer cliente ou técnico. requisitos.

6. Transição para a ISO 17025: 2017

A posição em relação à acreditação para a ISO 17025: 2017 [11] pode ser um pouco diferente, pois agora contém definições de validação e verificação que são muito semelhantes às usadas na ISO 27041 e no mundo da engenharia de software, a saber:

Verificação de Validação , onde os requisitos especificados são adequados para um uso pretendido.
Verificação Provisão de evidência objetiva de que um determinado item atende aos requisitos especificados.

Assim, a validação, na versão mais recente, depende da verificação em relação aos requisitos especificados e da comparação desses requisitos com os requisitos do caso de uso pretendido.

7. Conclusão

Ao contrário dos argumentos anteriores de que a ISO 17025 [12] é um padrão pesado para análise forense digital, devido à complexidade da validação, acreditamos que ela pode ser aplicada se certas condições prévias forem atendidas.

Para que a ISO 17025 seja aplicada com sucesso, o entendimento existente dos requisitos precisa ser reconsiderado. Em vez de confiar nos conceitos de “requisitos do cliente” [13], onde o cliente é o cliente do laboratório (ou seja, agentes policiais, advogados, o sistema de justiça criminal, etc.) para fornecer a base para a validação do método, provedores de ciência forense devem considerar os requisitos técnicos para seus próprios processos e usar os requisitos do cliente como um meio de selecionar os processos mais apropriados para implantar. Isso seria consistente com o modo como outras organizações de teste e calibração credenciadas “não-forenses” operam.

Dentro das disciplinas de ciências forenses, sugerimos que todos os laboratórios. terão os mesmos requisitos técnicos básicos comuns para tipos de métodos genéricos (por exemplo, na perícia digital, a criação de imagens de disco rígido é um processo central, assim como a extração de dados de dispositivos que executam versões específicas do iOS etc.) que devem ser estabelecidos por grupos técnicos dentro de cada disciplina, e documentado em padrões internacionais acordados que podem ser mantidos para uso e desenvolvimento pela comunidade.

Os requisitos contidos nesses padrões podem, então, formar a base de um mecanismo de especificação de métodos. A identificação clara dos requisitos técnicos versus os não técnicos permitiria aos produtores e usuários identificar áreas prioritárias para o desenvolvimento de novas ferramentas.

A publicação e manutenção pública deste conjunto comum de requisitos também permitiria a transparência no processo de verificação e validação. Em vez de confiar em informações “comercialmente sensíveis”, que podem ou não estar corretas, todos os envolvidos poderiam usar as informações divulgadas e fazer reivindicações (com evidências substanciais apropriadas) baseadas nelas.

Além disso, se a sugestão da ISO / IEC 27041: 2015 [1] que os processos devem ser projetados para serem de natureza atômica (isto é, pequeno, único propósito com baixo acoplamento e alta coesão a outros processos) pode ser seguido, o conjunto de requisitos para qualquer processo pode ser mantido no mínimo, resultando em um conjunto melhor definido de condições para validação e uma eliminação da revalidação que é acionada por mudanças em outras partes do processo. Todos os métodos que foram oferecidos para o nosso estudo eram de natureza monolítica e continham um alto grau de repetição de fases iniciais do processo (por exemplo, em cada SOP) (por exemplo, recuperação de itens físicos de uma loja de evidências) antes de progredir para os elementos únicos do processo.

8. Trabalhos relacionados existentes

8.1. Introdução

Desde o início do projeto original, tomamos conhecimento de alguns projetos que podem fornecer, pelo menos em parte, alguns dos requisitos, especificações e evidências de correção ausentes. Uma breve revisão de dois deles, no contexto de nossas análises e propostas, é apresentada abaixo.

8.2. Teste da ferramenta forense do computador de NIST / DHS

O Instituto Nacional de Ciência e Tecnologia (NIST) e o Departamento de Segurança Interna (DHS) iniciaram alguns desses trabalhos em seu programa Computer Forensics Tool Testing [14] (CFTT). Neste projeto, um grupo de direção define os requisitos para funções específicas da ferramenta e o NIST testa as ferramentas em relação às especificações resultantes. No momento em que escrevo, a cobertura é um tanto limitada, concentrando-se em algumas áreas que podem ser particularmente comuns em investigações, mas uma boa variedade de ferramentas foi considerada e um catálogo online de ferramentas e resultados foi produzido.

O projeto de teste da ferramenta federada como um subprojeto dessa iniciativa pode ser um modelo particularmente útil, pois disponibiliza um conjunto de testes que pode ser usado por qualquer pessoa que deseje testar ferramentas com relação aos requisitos já definidos pelo projeto e compartilhar seus resultados.

Não está claro, no entanto, como as áreas prioritárias do programa são estabelecidas ou como os requisitos são validados, já que esta parte do processo não parece ser documentada. Também é digno de nota que os requisitos são puramente no nível da ferramenta, e não no nível mais amplo do método. Isso pode resultar em uma ênfase indevida na produção de requisitos para as ferramentas existentes, em detrimento da produção de requisitos que ainda não foram satisfeitos, mas que devem ser considerados de alta prioridade, pois refletem uma área de problema real emergente.

Também sugerimos que uma consideração mais ampla poderia criar oportunidades para uma melhor integração de ferramentas (ou seja, melhor intercâmbio de dados entre ferramentas e melhor coesão para melhorar os fluxos de processos), bem como melhor concordância com requisitos externos, como questões legais.

8.3. Orientação SWGDE sobre teste e validação

O Grupo de Trabalho Científico sobre Evidência Digital (SWGDE) emitiu vários documentos que se destinam a ajudar na concepção, implementação e validação de métodos para processos forenses digitais. Destes, os dois que parecem ter aplicação mais direta na área que estamos investigando são

• Diretrizes Recomendadas do SWGDE para Teste de Validação [15]
• Requisitos Mínimos do SWGDE para Ferramentas de Teste usadas em Perícia Digital e Multimídia [16] (No momento da redação, este documento estava em forma de rascunho e havia sido emitido para consulta).

A orientação de validação do SWGDE [15] afirma que

O teste de validação deve ser aplicado a todas as ferramentas, técnicas e procedimentos

e ainda mais que

Ferramentas, técnicas e procedimentos que, em virtude de seu amplo uso, duração de uso e aceitação pela maior comunidade de tecnologia da informação, são geralmente reconhecidos como confiáveis ​​e confiáveis. Consideração pode ser dada à aceitação geral de uma ferramenta, técnica ou procedimento na determinação de se a validação é necessária.

O último parágrafo parece, até certo ponto, contradizer o primeiro. Em nossa experiência, parece que isso geralmente é interpretado como significando que algo que está em uso generalizado pode ser considerado confiável.

Argumentamos que essa não é a intenção da declaração de “aceitação geral”. Em parte, isso se deve à presença da frase “comunidade maior de tecnologia da informação”, que é uma indicação clara de que as ferramentas, técnicas e procedimentos em consideração são de natureza mais geral do que as ferramentas especializadas implantadas em um contexto investigativo. Planilhas, processadores de texto, programas de e-mail etc. geralmente podem ser considerados aceitáveis ​​porque têm impacto mínimo no produto probatório e, caso provem ter um erro, o grande número de usuários em todo o mundo significa que é provável que seja detectado e documentado rapidamente.

Mais importante, porém, se for permitido que esse princípio geral de aceitação se aplique a ferramentas, técnicas e procedimentos “forenses” comumente adotados, ele tem o potencial de resultar em evidências ruins. Se a ferramenta, técnica ou procedimento não tiver sido submetido a escrutínio independente (por exemplo, por meio de publicação revisada por pares ou testes de validação devidamente comprovados), não há evidências suficientes de que funcione corretamente. Como observamos acima, a análise forense digital depende muito da engenharia reversa para processar e interpretar dados. No nível em que a maioria dos usuários opera, ela não possui princípios científicos fundamentais suficientes para permitir a reversão aos primeiros princípios a serem aplicados para demonstrar a correção. É sempre provável que haja alguma dúvida ou incerteza sobre o modo como os dados estão sendo processados ​​e interpretados.

Nota: não vemos isso como uma falha na orientação do SWGDE, mas sim como uma grande parte da comunidade escolheu interpretar essa recomendação em particular. Deve-se notar que frases semelhantes aparecem em outras orientações e, em nossa experiência, são interpretadas de maneira semelhante.

O restante deste documento fornece uma visão geral de alto nível do desenvolvimento de um procedimento de teste que, se sustentado por requisitos bem definidos que permitam a identificação de casos de teste apropriados, pode resultar em boa evidência de validação e identificação de casos limites para métodos.

O guia de teste de ferramentas [16] é mais detalhado em suas recomendações e dá conselhos sobre tipos específicos de ferramentas e as condições que devem ser consideradas para seus testes. Novamente, no entanto, faz pouca referência ao uso de um conjunto bem definido de requisitos para auxiliar na identificação de casos de teste. Reconhece que o teste proposto é puramente mínimo e que as organizações devem considerar seus próprios requisitos particulares.

É nossa opinião que a evidência de teste, produzida da maneira recomendada, poderia ser aplicada como um complemento à validação do método, desde que os requisitos sejam adequadamente definidos e documentados. Deve ser lembrado, no entanto, que é improvável que o teste de ferramentas produza a evidência de validação exigida pela ISO 17025 [2] [11] ou ISO / IEC 27041 [1], a menos que possa ser claramente demonstrado que o método é total e exclusivamente implementado pela ferramenta (ver Figura 1).

9. Considerações Finais

Embora os projetos NIST e SWGDE descritos acima possam começar a fornecer o tipo de evidência necessário para demonstrar que um método é válido, a possível falta de transparência nos processos de definição de requisitos introduz outro elemento de incerteza. ou seja, se os requisitos não puderem ser mostrados como corretos, os testes baseados nesses requisitos podem ser corretos? Isso pode, em grande medida, ser resolvido adotando-se o modelo de organização “não-forense” da utilização de especificações / requisitos padrão acordados publicamente e / ou métodos que possam ser submetidos a escrutínio independente externo.

Também seria útil envolver-se em um processo mais aberto, semelhante aos propostos para uso na especificação e teste de sistemas críticos de segurança [17].

[1] ISO/IEC, ISO/IEC 27041:2016 guidance on assuring the suitability and adequacy of digital investigation method (2016).
[2] ISO, ISO 17025:2005 general requirements for the competence of testing and calibration laboratories (2005).
[3] J. Gravel, Principles behind the requirements of iso 17025, online at http://www.cala.ca/ISO-IEC 17025 Principals.pdf, 2002. Last accessed 543 25th April 2018. 18 544 [4] UKAS, Directory of accredited organisations, online at https://www.ukas.com/services/other-services/directory-of-accredited546 organisations/, 2018. Last viewed 4th June 2018
[5] Rev. Charles Dodgson (Lewis Carroll), Through the Looking Glass, 1872. 549
[6] ISO, ISO online browsing platform, online at https://www.iso.org/obp/ui/, 2018. Last accessed 13th August 2018.
[7] ISO, ISO 9000:2005 quality management systems – fundamentals and vocabulary (2005).
[8] B. W. Boehm, Verifying and validating software requirements and design specifications, IEEE Softw. 1 (1984) 75–88.
[9] IEEE, IEEE standard glossary of software engineering terminology, IEEE Std 610.12-1990 (1990) 1–84.
[10] Scientific Working Group on Digital Evidence (SWGDE), SWGDE 559 model standard operation procedures for computer forensics, online at https://www.swgde.org/documents/Current Documents/SWGDE 561 QAM and SOP Manuals/SWGDE Model SOP for Computer Forensics, 562 2012. Last viewed 5th June 2018.
[11] ISO, ISO 17025:2017 general requirements for the competence of testing and calibration laboratories (2017).
[12] P. Sommer, Accrediting digital forensics – what are the choices?, Digital Investigation (2018).
[13] International Laboratory Accreditation Cooperation, ILAC G19:08/2014 modules in a forensic science process (2014).
[14] National Institute for Science and Technology (NIST), Computer forensics tool testing programme, online at https://www.nist.gov/itl/ssd/software-quality-group/computer572 forensics-tool-testing-program-cftt, 2018. Last viewed 13th August 573 2018.
[15] Scientific Working Group on Digital Evidence (SWGDE), SWGDE Recommended Guidelines for Validation Testing (Version 2.0) (2014). Last accessed 13th August 2018.
[16] Scientific Working Group on Digital Evidence (SWGDE), SWGDE Minimum Requirements for Testing Tools used in Digital and Multimedia 579 Forensics (2018). Draft Version 1.0 dated 9th July 2018. Last accessed 13th August 2018.
[17] L. E. G. Martins, T. Gorschek, Requirements engineering for safety-critical systems: A systematic literature review, Information and Software Technology 75 (2016) 71 – 89.

 

A publicação original deste artigo está disponível em ResearchGate