As disputas de software geralmente come\u00e7am com uma pergunta simples : o que foi entregue , configurado , testado ou adotado , e quando ? A resposta raramente est\u00e1 contida em um \u00fanico contrato , ticket ou registro de sistema . Normalmente, ela est\u00e1 dispersa por ambientes t\u00e9cnicos , registros de projeto , materiais de aceita\u00e7\u00e3o e comunica\u00e7\u00f5es entre as partes . <\/p>\n
Uma avalia\u00e7\u00e3o defens\u00e1vel, portanto, exige mais do que identificar uma falha no sistema. Requer a reconstru\u00e7\u00e3o da sequ\u00eancia relevante de eventos, o exame da proveni\u00eancia e integridade dos registros dispon\u00edveis e a distin\u00e7\u00e3o entre a atividade do fornecedor e os problemas de configura\u00e7\u00e3o, governan\u00e7a ou ado\u00e7\u00e3o do lado do cliente. A conclus\u00e3o pode apontar para uma das partes, uma combina\u00e7\u00e3o de fatores ou uma limita\u00e7\u00e3o probat\u00f3ria n\u00e3o resolvida. <\/p>\n
As evid\u00eancias digitais podem fornecer uma base estruturada para reconstruir o que ocorreu em uma implementa\u00e7\u00e3o de software. Seu valor depende da preserva\u00e7\u00e3o, da proveni\u00eancia, da valida\u00e7\u00e3o do m\u00e9todo e da interpreta\u00e7\u00e3o cuidadosa. A reconstru\u00e7\u00e3o t\u00e9cnica pode esclarecer quest\u00f5es contratuais e comerciais; ela n\u00e3o determina, por si s\u00f3, a responsabilidade legal ou a admissibilidade. <\/p>\n
O primeiro passo \u00e9 definir a pergunta que as evid\u00eancias devem responder. Exemplos podem incluir: <\/p>\n
Essa abordagem impede que uma investiga\u00e7\u00e3o se torne uma revis\u00e3o ampla de todos os registros de sistema dispon\u00edveis. Ela tamb\u00e9m cria uma base para mapear cada quest\u00e3o \u00e0s fontes mais adequadas para respond\u00ea-la. <\/p>\n
Uma disputa sobre se uma implanta\u00e7\u00e3o ocorreu de fato pode exigir registros de controle de vers\u00e3o, artefatos de compila\u00e7\u00e3o, logs de CI\/CD, registros de orquestra\u00e7\u00e3o de implanta\u00e7\u00e3o e documenta\u00e7\u00e3o de entrega. Uma disputa sobre se o sistema resultante atendeu aos requisitos acordados pode exigir o contrato ou declara\u00e7\u00e3o de trabalho, planos de UAT, resultados de testes, registros de defeitos, certificados de aceita\u00e7\u00e3o e evid\u00eancias relevantes do aplicativo ou banco de dados. <\/p>\n
Os hist\u00f3ricos de commits do Git, metadados de pull requests, coment\u00e1rios de revis\u00e3o de c\u00f3digo, registros de CI\/CD, artefatos de compila\u00e7\u00e3o e metadados de reposit\u00f3rios de artefatos podem registrar a atividade da conta, informa\u00e7\u00f5es de autoria registradas, altera\u00e7\u00f5es associadas a uma compila\u00e7\u00e3o e rela\u00e7\u00f5es entre o c\u00f3digo e os artefatos de implanta\u00e7\u00e3o.<\/p>\n
Esses registros n\u00e3o devem ser considerados como comprova\u00e7\u00e3o de que uma pessoa identificada realizou ou autorizou uma a\u00e7\u00e3o. As strings de autoria, os carimbos de data\/hora e os registros de conta podem estar incorretos, alterados ou usados \u200b\u200bpor algu\u00e9m que n\u00e3o seja o titular da conta. Um commit assinado pode fornecer uma vincula\u00e7\u00e3o criptogr\u00e1fica a uma chave de assinatura, e artefatos de compila\u00e7\u00e3o reproduz\u00edveis podem auxiliar na compara\u00e7\u00e3o com um estado de compila\u00e7\u00e3o espec\u00edfico. Nenhum deles, por si s\u00f3, comprova a autoria humana, a autoriza\u00e7\u00e3o, a integridade ou a aus\u00eancia de comprometimento. <\/p>\n
Os registros de pipeline, registros de execu\u00e7\u00e3o, registros de orquestra\u00e7\u00e3o de implanta\u00e7\u00e3o e resumos de imagens de cont\u00eainer podem registrar etapas de implanta\u00e7\u00e3o, scripts invocados, vari\u00e1veis \u200b\u200bde ambiente usadas no momento da implanta\u00e7\u00e3o, a conta iniciadora e pontos de falha. A correla\u00e7\u00e3o com registros de controle de vers\u00e3o e artefatos pode ajudar a avaliar se uma altera\u00e7\u00e3o de c\u00f3digo ou configura\u00e7\u00e3o originada pelo fornecedor foi implantada ou se ocorreu uma falha no ambiente de destino. <\/p>\n
Os registros de CI\/CD podem ser exclu\u00eddos ou alterados. O arquivamento externo e a correla\u00e7\u00e3o cruzada com fontes independentes podem auxiliar na preserva\u00e7\u00e3o e compara\u00e7\u00e3o, mas um registro de pipeline n\u00e3o equivale \u00e0 comprova\u00e7\u00e3o de que o resultado pretendido foi alcan\u00e7ado no ambiente de produ\u00e7\u00e3o ou de aceita\u00e7\u00e3o. <\/p>\n
Os registros de eventos do aplicativo, os registros do gateway de API, as pilhas de erros, a telemetria da plataforma, os registros do middleware e os identificadores de solicita\u00e7\u00e3o ou correla\u00e7\u00e3o podem ajudar a mostrar erros de tempo de execu\u00e7\u00e3o, incompatibilidades de configura\u00e7\u00e3o, falhas de integra\u00e7\u00e3o e se os fluxos de dados esperados ocorreram. Os identificadores de correla\u00e7\u00e3o podem permitir que uma transa\u00e7\u00e3o seja rastreada entre sistemas. <\/p>\n
O per\u00edodo de reten\u00e7\u00e3o varia conforme a plataforma. Em ambientes SaaS, recursos espec\u00edficos de auditoria ou registro de eventos podem ser opcionais, pagos ou sujeitos a curtos per\u00edodos de reten\u00e7\u00e3o padr\u00e3o. Se os registros relevantes n\u00e3o forem exportados antes do vencimento, a reconstru\u00e7\u00e3o resultante poder\u00e1 estar incompleta. <\/p>\n
Os registros de transa\u00e7\u00f5es do banco de dados, trilhas de auditoria, hist\u00f3rico em n\u00edvel de linha e imagens de backup podem fornecer evid\u00eancias de altera\u00e7\u00f5es nos dados ou da ordem das transa\u00e7\u00f5es registradas. O que eles capturam e a confiabilidade com que suportam uma avalia\u00e7\u00e3o de ordem ou altera\u00e7\u00e3o dependem da tecnologia do banco de dados, da configura\u00e7\u00e3o, do modo de registro, da reten\u00e7\u00e3o e do m\u00e9todo de extra\u00e7\u00e3o. Um estado atual do banco de dados pode mostrar o que existe agora sem estabelecer todos os eventos que levaram a esse estado. <\/p>\n
Os planos de UAT (Teste de Aceita\u00e7\u00e3o do Usu\u00e1rio), os resultados da execu\u00e7\u00e3o dos testes, os registros de defeitos, as solicita\u00e7\u00f5es de mudan\u00e7a, os certificados de aceita\u00e7\u00e3o, as declara\u00e7\u00f5es de trabalho, as atas de reuni\u00e3o, os registros de treinamento e os manuais do usu\u00e1rio podem conectar eventos t\u00e9cnicos aos requisitos acordados e \u00e0s responsabilidades do projeto.<\/p>\n
Esses materiais podem demonstrar se os testes de aceita\u00e7\u00e3o foram definidos e executados, quais defeitos foram relatados, como os problemas foram priorizados e se o treinamento ou as atividades de ado\u00e7\u00e3o acordadas com o cliente foram realizadas. Crit\u00e9rios de aceita\u00e7\u00e3o expl\u00edcitos e test\u00e1veis \u200b\u200bs\u00e3o particularmente importantes quando as partes discordam posteriormente sobre se um sistema estava completo ou adequado ao processo pretendido. <\/p>\n
Os tickets de suporte, e-mails, grava\u00e7\u00f5es de sess\u00f5es de projeto, aprova\u00e7\u00f5es de altera\u00e7\u00f5es, notas de entrega e registros de escalonamento podem preservar relatos contempor\u00e2neos de falhas, corre\u00e7\u00f5es prometidas, patches entregues e as respostas das partes envolvidas.<\/p>\n
As comunica\u00e7\u00f5es devem ser preservadas com os metadados relevantes, incluindo cabe\u00e7alhos e registros de data e hora, quando dispon\u00edveis, e interpretadas juntamente com os registros t\u00e9cnicos. Uma declara\u00e7\u00e3o de que uma corre\u00e7\u00e3o foi entregue, por exemplo, pode precisar ser comparada com os registros de implanta\u00e7\u00e3o, informa\u00e7\u00f5es do artefato, comportamento do sistema e atividades de suporte subsequentes. <\/p>\n
Essas categorias n\u00e3o s\u00e3o exaustivas e n\u00e3o possuem a mesma relev\u00e2ncia probat\u00f3ria em todas as disputas. Sua relev\u00e2ncia depende da quest\u00e3o em an\u00e1lise, dos registros efetivamente dispon\u00edveis e do m\u00e9todo utilizado para interpret\u00e1-los. <\/p>\n
Um processo eficaz come\u00e7a com o planejamento e a preserva\u00e7\u00e3o. As partes ou seus consultores devem identificar as fontes cr\u00edticas relacionadas \u00e0s quest\u00f5es em disputa, emitir instru\u00e7\u00f5es adequadas de preserva\u00e7\u00e3o e documentar as medidas tomadas para proteger registros, backups, snapshots, registros de configura\u00e7\u00e3o e materiais do projeto. <\/p>\n
A coleta deve utilizar m\u00e9todos repet\u00edveis e documentados. Em ambientes locais ou de m\u00e1quinas virtuais, isso pode incluir imagens de disco, exporta\u00e7\u00f5es de banco de dados e preserva\u00e7\u00e3o de logs de transa\u00e7\u00f5es. Em ambientes SaaS, a cria\u00e7\u00e3o completa de imagens pode n\u00e3o ser poss\u00edvel, sendo necess\u00e1rio o uso de APIs ou exporta\u00e7\u00f5es forenses. O registro de coleta deve identificar quem realizou a coleta, quando ela ocorreu, como foi realizada e como a exporta\u00e7\u00e3o ou o artefato derivado foi tratado. <\/p>\n
Hashes ou checksums podem ajudar a documentar ou testar se um determinado artefato capturado foi alterado ap\u00f3s a gera\u00e7\u00e3o do hash. Eles n\u00e3o estabelecem, por si s\u00f3, a proveni\u00eancia, autenticidade, integridade, coleta correta, confiabilidade do sistema de origem ou representa\u00e7\u00e3o do registro original do artefato. Essas quest\u00f5es exigem documenta\u00e7\u00e3o e controles separados que abordem a coleta, o acesso, a reten\u00e7\u00e3o e o contexto de origem dispon\u00edvel. O armazenamento descrito como imut\u00e1vel pode ser um controle de preserva\u00e7\u00e3o,. <\/p>\n
A pr\u00f3xima etapa \u00e9 a correla\u00e7\u00e3o. Eventos provenientes de sistemas de controle de vers\u00e3o, CI\/CD, ferramentas de implanta\u00e7\u00e3o, plataformas de aplicativos e bancos de dados devem ser alinhados usando marcadores apropriados, como identificadores de requisi\u00e7\u00e3o, identificadores de correla\u00e7\u00e3o e timestamps normalizados. A normaliza\u00e7\u00e3o de tempo deve levar em conta fusos hor\u00e1rios e poss\u00edveis diferen\u00e7as de rel\u00f3gio. Uma sequ\u00eancia pode ser significativa, mas deve ser testada em rela\u00e7\u00e3o a outros registros dispon\u00edveis e n\u00e3o deve ser considerada como prova de causalidade por si s\u00f3. <\/p>\n
Uma linha do tempo de evid\u00eancias anotada pode vincular eventos materiais a artefatos subjacentes e distinguir eventos registrados diretamente de infer\u00eancias extra\u00eddas de m\u00faltiplas fontes.<\/p>\n
A evid\u00eancia digital \u00e9 mais \u00fatil quando os m\u00e9todos de coleta e an\u00e1lise s\u00e3o adequados \u00e0 quest\u00e3o, documentados e reproduz\u00edveis. A norma ISO\/IEC 27037 fornece orienta\u00e7\u00f5es para identifica\u00e7\u00e3o, coleta, aquisi\u00e7\u00e3o e preserva\u00e7\u00e3o. A ISO\/IEC 27042 aborda a an\u00e1lise e interpreta\u00e7\u00e3o de evid\u00eancias digitais. As diretrizes do NIST tamb\u00e9m abordam a preserva\u00e7\u00e3o e a prepara\u00e7\u00e3o forense espec\u00edfica para a nuvem. <\/p>\n
Uma an\u00e1lise deve registrar as ferramentas e vers\u00f5es utilizadas, os par\u00e2metros relevantes, as etapas de processamento, as exporta\u00e7\u00f5es de origem, os hashes e os artefatos derivados. A an\u00e1lise n\u00e3o padronizada de logs propriet\u00e1rios ou detalhes internos de bancos de dados exige cuidado especial e pode requerer valida\u00e7\u00e3o t\u00e9cnica e revis\u00e3o por pares. <\/p>\n
M\u00e9todos automatizados ou estat\u00edsticos exigem cautela adicional. Se um m\u00e9todo for usado para classificar eventos como causados \u200b\u200bpelo fornecedor ou pelo cliente, seus limiares, pressupostos e potenciais resultados falso-positivos e falso-negativos devem ser documentados e pass\u00edveis de revis\u00e3o humana. Um resultado de classifica\u00e7\u00e3o n\u00e3o deve ser apresentado como uma conclus\u00e3o definitiva de causalidade sem a devida valida\u00e7\u00e3o. <\/p>\n
As evid\u00eancias devem ser avaliadas considerando o contexto contratual e t\u00e9cnico, em vez de serem categorizadas prematuramente em uma classifica\u00e7\u00e3o bin\u00e1ria.<\/p>\n
Os potenciais indicadores de implementa\u00e7\u00e3o do fornecedor podem incluir implanta\u00e7\u00f5es, commits ou altera\u00e7\u00f5es de configura\u00e7\u00e3o originadas pelo fornecedor; patches ou pacotes entregues; falhas no ambiente de aceita\u00e7\u00e3o associadas ao c\u00f3digo ou configura\u00e7\u00e3o implantados; e registros de suporte que reconhe\u00e7am um defeito ou plano de corre\u00e7\u00e3o. Esses indicadores devem ser testados em rela\u00e7\u00e3o aos registros de implanta\u00e7\u00e3o, informa\u00e7\u00f5es do artefato, materiais de entrega assinados e a declara\u00e7\u00e3o de trabalho aplic\u00e1vel. <\/p>\n
Os potenciais indicadores internos de ado\u00e7\u00e3o ou governan\u00e7a podem incluir testes de aceita\u00e7\u00e3o incompletos, configura\u00e7\u00f5es ausentes no lado do cliente, falha na ativa\u00e7\u00e3o de funcionalidades acordadas, mapeamentos de dados incompletos, registros de treinamento inadequados ou altera\u00e7\u00f5es de configura\u00e7\u00e3o iniciadas pelo cliente. Esses indicadores devem ser avaliados em rela\u00e7\u00e3o aos materiais de UAT, registros de treinamento, aprova\u00e7\u00f5es de altera\u00e7\u00f5es e as responsabilidades definidas no contrato ou na documenta\u00e7\u00e3o do projeto. <\/p>\n
Muitas disputas envolvem responsabilidade mista. Um fornecedor pode ter entregue um componente enquanto a configura\u00e7\u00e3o ou o mapeamento de dados do cliente permaneciam incompletos. Uma reconstru\u00e7\u00e3o tecnicamente confi\u00e1vel deve descrever a sequ\u00eancia e as depend\u00eancias, identificar o que cada registro comprova e indicar onde as evid\u00eancias n\u00e3o resolvem a quest\u00e3o. A atribui\u00e7\u00e3o de responsabilidade legal continua sendo uma quest\u00e3o para o advogado e o respons\u00e1vel pela decis\u00e3o, sendo fundamentada, mas n\u00e3o substitu\u00edda, pela an\u00e1lise t\u00e9cnica. <\/p>\n
Os ambientes em nuvem imp\u00f5em limita\u00e7\u00f5es pr\u00e1ticas \u00e0 coleta de evid\u00eancias. Plataformas SaaS multilocat\u00e1rias podem n\u00e3o expor registros de baixo n\u00edvel do plano de controle aos clientes. Auditorias aprimoradas podem estar sujeitas a taxas adicionais, e os per\u00edodos de reten\u00e7\u00e3o nativos podem ser curtos. A capacidade de recuperar registros expirados ou exclu\u00eddos \u00e9 espec\u00edfica do fornecedor e pode ser parcial ou indispon\u00edvel. <\/p>\n
Essas limita\u00e7\u00f5es tornam a preserva\u00e7\u00e3o precoce importante. Acordos contratuais podem abordar registro, reten\u00e7\u00e3o, transmiss\u00e3o de eventos externos, coopera\u00e7\u00e3o com fornecedores, vias de acesso, janelas de preserva\u00e7\u00e3o e custos associados. Quando registros cr\u00edticos s\u00e3o retidos pelo cliente, a exporta\u00e7\u00e3o peri\u00f3dica para armazenamento controlado pode auxiliar na prepara\u00e7\u00e3o para disputas. Tal armazenamento permanece uma medida de preserva\u00e7\u00e3o, n\u00e3o uma prova independente da autenticidade ou integridade dos registros subjacentes. <\/p>\n
A aus\u00eancia de um registro n\u00e3o comprova automaticamente que um evento n\u00e3o ocorreu. Pelo contr\u00e1rio, pode limitar o que pode ser reconstru\u00eddo. Se a an\u00e1lise depender de indicadores secund\u00e1rios, como o estado atual do banco de dados e backups, a infer\u00eancia resultante deve ser identificada como tal e n\u00e3o deve ser apresentada como um evento definitivo ou uma cadeia de causalidade sem valida\u00e7\u00e3o espec\u00edfica para o caso. <\/p>\n
A atribui\u00e7\u00e3o tamb\u00e9m pode permanecer incerta. Contas de servi\u00e7o compartilhadas, administra\u00e7\u00e3o delegada, proxy e credenciais ef\u00eameras podem dificultar a associa\u00e7\u00e3o de um evento de API ou de linha de comando a um indiv\u00edduo espec\u00edfico. Registros de autentica\u00e7\u00e3o, chaves de API, informa\u00e7\u00f5es de IP e registros de acesso condicional podem auxiliar, mas qualquer incerteza residual deve ser relatada, e n\u00e3o ocultada. <\/p>\n
Para media\u00e7\u00e3o, concilia\u00e7\u00e3o ou prepara\u00e7\u00e3o para lit\u00edgios, um pacote t\u00e9cnico com escopo restrito pode ser mais \u00fatil do que uma an\u00e1lise de dados gen\u00e9rica. Dependendo das quest\u00f5es em disputa, ele pode incluir: <\/p>\n
O relat\u00f3rio deve separar os fatos observados, as infer\u00eancias fundamentadas, as quest\u00f5es n\u00e3o resolvidas e as limita\u00e7\u00f5es. Deve explicar a base de cada conclus\u00e3o em linguagem intelig\u00edvel para os tomadores de decis\u00e3o, sem obscurecer a qualifica\u00e7\u00e3o t\u00e9cnica subjacente. <\/p>\n
Uma abordagem disciplinada consiste em delimitar as quest\u00f5es, preservar as fontes relevantes, colet\u00e1-las utilizando m\u00e9todos documentados, correlacionar eventos entre sistemas, avaliar a abordagem anal\u00edtica e relatar o resultado com suas limita\u00e7\u00f5es. Os crit\u00e9rios de aceita\u00e7\u00e3o podem ser amb\u00edguos, os registros podem ter expirado, a coopera\u00e7\u00e3o do fornecedor pode n\u00e3o ter sido garantida e a responsabilidade pela configura\u00e7\u00e3o do lado do cliente pode ser contestada. Essas condi\u00e7\u00f5es afetam o que ainda pode ser estabelecido e devem ser identificadas desde o in\u00edcio. <\/p>\n
A perspectiva da IVIDENTIA \u00e9 que o valor das provas digitais reside n\u00e3o no volume de registros coletados, mas na conex\u00e3o entre uma quest\u00e3o controversa, uma fonte relevante e um m\u00e9todo reproduz\u00edvel. Quando as provas sustentam uma conclus\u00e3o, esta deve ser declarada com precis\u00e3o. Quando n\u00e3o a sustentam, essa limita\u00e7\u00e3o faz parte da resposta. <\/p>\n
Se uma disputa sobre a implementa\u00e7\u00e3o de um software depender da reconstru\u00e7\u00e3o de implanta\u00e7\u00f5es, altera\u00e7\u00f5es de configura\u00e7\u00e3o, eventos de aceita\u00e7\u00e3o ou atividades de dados, um exerc\u00edcio inicial de mapeamento de evid\u00eancias pode ajudar a identificar as prioridades de preserva\u00e7\u00e3o e esclarecer quais perguntas os registros dispon\u00edveis podem responder.<\/p>\n
As disputas de software geralmente come\u00e7am com uma pergunta simples : o que foi entregue , configurado , testado ou adotado , e quando ? A resposta raramente est\u00e1 contida em um \u00fanico contrato , ticket ou registro de sistema . Normalmente, ela est\u00e1 dispersa por ambientes t\u00e9cnicos , registros de projeto , materiais de […]<\/p>\n","protected":false},"author":9,"featured_media":12526,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[43,42,44],"tags":[56,55,60,53,54,52,57],"tax-filters":[],"class_list":["post-12527","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-auditoria-de-software","category-expert-reports-for-law-enforcement","category-software-audit-code-analysis","tag-crm","tag-dispute","tag-erp","tag-forensics","tag-law","tag-software-audit","tag-wms"],"yoast_head":"\n