Testes de cibersegurança para sistemas complexos e embebidos

O Midair transforma o que uma análise de código suspeita em testes que tentam prová-lo. Executa esses testes no seu sistema e guarda as evidências de cada execução.

Comece por uma via de entrada no seu produto que o preocupe, como o caminho de atualização do firmware. Um piloto executa o ciclo sobre ela, com a sua suite e o seu dispositivo.

Entrar na lista de espera Ver o ciclo
attack vector · firmware update path Exemplo 
what to provean image with a bad signature is never installed
analysis     template fw-main, suspicious places: security
test suite   update-ts, branch per round
delta device gw-lab-2
stage        judge, iteration 2 of 5
found        1 demonstrated, 1 suspected
trying       H3: rollback to an older image

O que são testes de cibersegurança.E porque uma só ferramenta não chega.

Os testes de cibersegurança verificam como um sistema se comporta quando alguém o tenta usar de forma abusiva. Procuram fraquezas que um atacante possa explorar: uso inseguro da memória, serviços expostos, builds frágeis e entradas por validar.

Uma só ferramenta raramente resolve a questão. A análise de código diz que uma cópia pode exceder o buffer. Um teste mostra se uma entrada longa chega lá. O dispositivo mostra como o binário foi compilado e o que corre ao lado dele.

O Midair junta as três vistas num só projeto. O utilizador diz o que o preocupa. O Midair analisa o código, escreve e executa testes, e indica o que cada execução demonstrou.

O ciclo do vetor de ataque.Cinco fases, repetidas até não surgir nada de novo.

Um vetor de ataque é uma via de entrada no sistema, com um ciclo que a continua a testar. Escolha uma fase para ver o que acontece nela.

01 Analisar

Quem faz
O Midair e o Visao
O que acontece
O Midair cria uma execução a partir do seu modelo de análise, com os locais suspeitos ativos. As ocorrências dizem o que está errado. Os locais suspeitos indicam onde o código decide algo que ninguém leu ainda.
Exemplo 
analysis run 318 · suspicious places: securitySUSPICIOUS  security  high  authorization-decision  verify.c:88
SUSPICIOUS  security  med   crypto-primitive        verify.c:41
finding     std/mem/overflow                     unpack.c:142:9
            Copy larger than the destination buffer
2 suspicious places, 1 finding go to the plan

02 Planear

Quem faz
O seu fornecedor de IA
O que acontece
Os locais suspeitos, as ocorrências e tudo o que as rondas anteriores aprenderam seguem para o fornecedor de IA. Este devolve as hipóteses a atacar, uma especificação para a suite de testes e uma norma para o agente Delta.
Exemplo 
plan · iteration 2H1  verify.c:88 accepts an image when the
    signature check returns an error
H2  unpack.c:142 overflows on a long file name
H3  an older signed image can be installed again
spec   tests for H1-H3 in group update_path
norm   forbid: module, memexec   ports: 22/tcp

03 Escrever testes

Quem faz
Claude Code ou Codex CLI
O que acontece
A especificação segue para o Claude Code ou para o Codex CLI. A ferramenta atualiza o repositório da suite de testes e envia um branch. O prompt de especificação da própria suite não muda.
Exemplo 
generator · Claude Code · update-tscloned   update-ts
added    update_path/bad_signature.c
added    update_path/long_name.c
added    update_path/rollback.c
pushed   av/update-path/iter-2

04 Executar

Quem faz
Test Environment e Delta
O que acontece
O Midair cria uma execução a partir do seu modelo de testes, fixada no branch novo. Quando há um dispositivo ligado, o Delta observa-o enquanto a suite corre.
Exemplo 
run 1207 · branch av/update-path/iter-2update_path/bad_signature  FAILED  H1: image installed
update_path/long_name      PASSED  H2: name rejected
update_path/rollback       SKIPPED H3: no older image
delta  gw-lab-2  cycle 4411 to 4415
       + port:4444/tcp/LISTEN

05 Julgar

Quem faz
O seu fornecedor de IA
O que acontece
Os veredictos e as alterações que o Delta viu voltam ao fornecedor. Este indica que hipóteses a execução resolveu, quais não conseguiu alcançar e se outra ronda traria algo de novo.
Exemplo 
judge · iteration 2demonstrated  H1  run 1207, bad_signature
not shown     H2  long names rejected
suspected     port 4444 opened during the run
not reached   H3  needs two signed images
another round: yes, for H3

O que o ciclo nunca faz.E quando para.

  1. Não altera o código em teste.

    O ciclo só edita a suite de testes. Um ciclo que pudesse editar o código também poderia fazer passar os seus próprios testes.

  2. Não decide o que é uma vulnerabilidade.

    Cada ocorrência leva as suas evidências e uma marca: demonstrada por uma execução, ou apenas suspeita. As demonstradas aparecem primeiro. Uma pessoa confirma-as.

  3. Para sozinho.

    O ciclo termina no limite de iterações que definir, ou antes, quando outra ronda já não traria nada de novo. Parar termina-o de imediato, e as execuções que já começaram terminam com resultados reais.

  4. Continua sem o seu navegador.

    O ciclo avança no servidor. Fechar a página não o para, e um reinício do servidor retoma-o. Uma fase que fique parada seis horas termina o ciclo com uma mensagem.

Um defeito, três camadas.Cada camada vê uma parte diferente.

A nossa suite de demonstração planta defeitos de propósito e verifica que os scanners os encontram. Este exemplo junta dois deles num pequeno programa: um strcpy para um buffer de 8 bytes e uma build sem proteção da pilha nem PIE.

unsafe.c · O defeito plantadoExemplo
1#include <string.h>2#include <stdio.h>3char buffer[8];4void copy_name(const char *name)5{6    strcpy(buffer, name);7}8int main(int argc, char **argv)9{10    if (argc > 1)11        copy_name(argv[1]);12    printf("%s\n", buffer);13}$cc -O0 -fno-builtin -fno-stack-protector \
     -fno-PIE -no-pie unsafe.c -o unsafe#instalado no dispositivo como /opt/demo/unsafe

O código-fonte mostra a cópia.

O que vê
A função copy_name() copia uma string de qualquer tamanho para um buffer de 8 bytes.
O que não vê sozinha
Como o binário foi compilado, e se uma entrada longa chega a esta linha.
visao · unsafe.c · Exemplounsafe.c:6:5  error  std/mem/overflow
              Copy larger than the destination buffer
1 finding

O teste mostra a build.

O que vê
O binário de release continua a chamar strcpy a partir de copy_name. Não tem stack canary e não é independente da posição (PIE).
O que não vê sozinha
O que mais está instalado e à escuta no dispositivo ao lado dele.
run 1211 · tsf-cybersec · Exemplobinscan  unsafe  NX yes  PIE no  canary no
objdump  banned call: strcpy in copy_name
release/hardening     FAILED  binary.no-canary
                              binary.not-pie
release/banned_calls  FAILED  binary.banned-call

O dispositivo mostra o que foi entregue.

O que vê
O binário instalado viola a política de hardening porque não tem stack canary. O Delta regista o checksum dele, por isso uma recompilação posterior aparece como alteração.
O que não vê sozinha
A linha de código. O Midair mostra o resultado do dispositivo ao lado da ocorrência no código, numa só lista de problemas.
delta --binaries /opt/demo --cfg policy.json · Exemplohardening  Binary '/opt/demo/unsafe' lacks
           required mitigation: stack canary
file       /opt/demo/unsafe  csum 3f9a…e10c
exit code 1

Perguntas.Respostas curtas.

O que são testes de cibersegurança?

Os testes de cibersegurança verificam como um sistema se comporta quando alguém o tenta usar de forma abusiva. Juntam análise de código, testes dirigidos e verificações no dispositivo em funcionamento para encontrar fraquezas que um atacante possa explorar.

O que é um vetor de ataque no Midair?

Um vetor de ataque é uma via de entrada no seu sistema que quer ver testada, como o caminho de atualização do firmware. O Midair executa um ciclo sobre ela: analisar, planear, escrever testes, executar e julgar. O ciclo repete-se até uma ronda não trazer nada de novo ou chegar ao seu limite de iterações.

O Midair decide o que conta como vulnerabilidade?

Não. O Midair marca cada ocorrência como demonstrada por uma execução ou apenas suspeita, e guarda as evidências ao lado. Uma pessoa confirma-a.

O ciclo altera o nosso código-fonte?

Não. O gerador de código só edita o repositório da suite de testes e envia um branch. O código em teste fica como está.

Como são os testes gerados?

São testes do Test Environment em C, que usam a biblioteca tsf-cybersec. Esta verifica como os binários foram compilados, o que um host tem à escuta, a que se liga e o tráfego capturado. Cada veredicto indica a hipótese que resolve.

O que precisamos para um piloto?

Uma via de entrada que o preocupe, o código-fonte, um repositório de suite de testes e, se tiver, um dispositivo numa bancada. O piloto configura consigo o primeiro vetor de ataque.

Comece por uma via de entrada.A que mais o preocupa.

Diga o que quer ver provado. Um piloto executa o ciclo sobre o seu código, a sua suite e o seu dispositivo, e mostra o que cada ronda demonstrou.

Entrar na lista de espera