Rastreabilidade na auditoria ISO 21434: fazendo o fuzzing contar

A ISO/SAE 21434 não pede apenas que você seja seguro. Ela pede que você demonstre isso, a um avaliador, com evidências. É nessa diferença que muito trabalho bom de segurança desmorona em uma auditoria, e o teste de segurança é o exemplo mais claro.

A norma pede os testes. Ela também pede o rastro documental

Os requisitos de teste são bastante claros. A Clause 10.4.2 (integração e verificação) exige que você verifique que a implementação atende à especificação de cibersegurança ([RQ-10-09]), e a [RC-10-12] recomenda testes de componente, com fuzz testing e varredura de vulnerabilidades, para minimizar fraquezas não identificadas. A Clause 11 (validação de cibersegurança) cita testes de penetração ([RQ-11-01]). A partir de CAL 2, o fuzzing das interfaces de comunicação é, na prática, esperado.

Mas uma avaliação 21434 não é pontuada por você ter rodado um fuzzer. Ela é pontuada pelos seus produtos de trabalho: o relatório de verificação, o relatório de validação e, no fim, o cybersecurity case que argumenta que o seu item é adequadamente seguro, julgado na avaliação de cibersegurança (Clause 6.4.9). O avaliador lê o argumento e a evidência por trás dele. Uma campanha de fuzzing que não está escrita nesse argumento é como se nunca tivesse acontecido.

Rastreabilidade bidirecional, em uma frase

O que os avaliadores pedem o tempo todo é rastreabilidade bidirecional: um link documentado de cada requisito de cibersegurança ao teste que o verifica, e de cada teste de volta a um requisito.

Para testes de segurança, isso significa que um avaliador pode partir de um objetivo de cibersegurança (“a ECU não deve aceitar escritas de diagnóstico sem autenticação”), segui-lo até um requisito de cibersegurança, seguir esse requisito até o teste que o verifica e ver o resultado, a data e o que aconteceu com qualquer achado. E ele pode ir no sentido contrário: pegar um achado e rastreá-lo até o requisito que ele ameaça.

A maioria das equipes consegue apresentar os testes. Bem menos conseguem apresentar essa cadeia no dia da avaliação.

Onde o fuzzing fica especialmente difícil

O fuzzing é particularmente complicado de tornar rastreável, por três motivos:

• Ele é não determinístico por natureza. Se um crash não pode ser reproduzido, é uma anedota, não uma evidência. Um avaliador não pode aceitar “deu crash uma vez em março”.
• Ele produz volume, não estrutura. Milhões de iterações e uma pilha de logs não se encaixam de forma limpa em uma lista curta de requisitos de cibersegurança.
• Ele roda tarde e raramente. Uma campanha única antes de uma auditoria fala sobre o software que você tinha naquela semana, não sobre o software que você entrega, e não carrega histórico nenhum.

Então a pergunta que um avaliador realmente faz sobre o seu fuzzing não é “você fez fuzzing?”. É: você consegue reproduzir este achado, quando o viu pela primeira vez, a qual requisito ele se relaciona e o que você fez a respeito?

Como é uma evidência de teste de segurança pronta para auditoria

Seja qual for a ferramenta que você usa, a evidência precisa carregar cinco coisas:

1. Reprodutibilidade. Uma seed ou configuração armazenada para que qualquer achado possa ser reexecutado sob demanda, por você e pelo avaliador.
2. Um histórico datado. Não um instantâneo, mas um registro do que foi testado e quando, ao longo da vida da ECU, para que você mostre a tendência, não apenas o estado final.
3. Vínculo com requisitos. Cada achado ligado ao requisito de cibersegurança ou ticket que ele afeta, para que o rastro bidirecional se sustente.
4. Aceitação de risco documentada. Quando um risco residual é aceito, a decisão e a sua justificativa ficam registradas e sobrevivem até o próximo ciclo de teste.
5. Uma exportação legível. A evidência precisa sair da ferramenta em um formato que o avaliador e o seu próprio tracker consigam consumir, PDF para o arquivo e SARIF para as ferramentas.

Acerte essas cinco coisas e uma campanha de fuzzing deixa de ser um arquivo de log e vira um produto de trabalho.

Como o AutoST foi construído para isso

Esta é a parte de um programa 21434 que o AutoST foi projetado para carregar.

Cada execução é reprodutível: a seed de fuzzing é armazenada e exibida, para que um crash possa ser reexecutado exatamente. Cada scan é datado e preservado, para que o histórico ao longo da vida de uma ECU esteja lá, e não precise ser reconstruído. Cada achado carrega uma severidade e uma correção concreta, e o Fix Plan dá a cada tarefa um status e um campo de referência ALM/PLM, que é onde mora o link de volta ao seu requisito ou ticket. A aceitação de risco e os comentários são mantidos entre retestes, para que um risco residual aceito continue documentado e um problema corrigido apareça como resolvido. E a saída é PDF para o arquivo de auditoria e SARIF para as suas ferramentas.

Como o AutoST roda a partir da API e no CI, o teste se torna uma atividade contínua no sentido que a Clause 8.5 pretende, em vez de uma correria antes da avaliação. O avaliador vê uma tendência e um rastro, não uma única campanha heroica.

O limite honesto

O AutoST produz a evidência de teste e a mantém rastreável. Ele não escreve a sua TARA, não opera o seu sistema de gestão de cibersegurança nem redige o seu cybersecurity case. Isso é trabalho de processo e de julgamento de engenharia. A Zyberum faz esse lado também, como consultoria, com uma equipe que possui a certificação SAE e TÜV SÜD Automotive Cybersecurity para ISO/SAE 21434 e já conduziu programas de Tier 1, Tier 2 e OEM exatamente por isso. Referências disponíveis mediante solicitação.

Se você quer ver como é uma evidência de teste pronta para auditoria na sua própria ECU, agende uma demo e nós a executaremos contra um alvo real.