Capítulo 34 — Segurança de TO, IoT e sistemas ciberfísicos: integração

Mapa da aula

Aula 34 publicada. Mapa, exemplo, EX100.

flowchart TD
  N0["34.1 Contrato de eventos"]
  N1["34.2 Consumidores idempotentes"]
  N2["34.3 Testes de contrato"]
  N3["Nota prática"]
  N4["34.1b Mensagens mortas e exercícios de esquema"]
  N5["Nota de campo — quarentena de eventos envenenados"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX100"]

Desenho lógico

flowchart LR
  N0["34.1 Contrato de eventos"]
  N1["34.2 Consumidores idempotentes"]
  N2["34.3 Testes de contrato"]
  N3["Nota prática"]
  N4["34.1b Mensagens mortas e exercícios de esquema"]
  N5["Nota de campo — quarentena de eventos envenenados"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX100"]

[34.1 Contrato de eventos]
    |
    v
[34.2 Consumidores idempotentes]
    |
    v
[34.3 Testes de contrato]
    |
    v
[Nota prática]
    |
    v
[34.1b Mensagens mortas e exercícios de esquema]
    |
    v
[Nota de campo — quarentena de eventos envenenados]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX100]

Objetivos de aprendizagem

Você vai (1) integrar os eventos do monitor ao repositório de constatações; (2) definir consumidores idempotentes; (3) testar contratos com dados de teste.

34.1 Contrato de eventos

Eventos de negação/permissão: versão do esquema, ids, timestamps em UTC, origem, fc, registrador, motivo, versão da política. Os consumidores ignoram campos desconhecidos; os produtores permanecem aditivos.

O contrato de eventos de Lena na ABP é versionado e publicado com dados de teste para cada código de motivo. Cada evento traz tanto o horário em que aconteceu quanto o horário em que foi recebido, além da fonte do relógio. Os produtores podem acrescentar campos, mas nunca removê-los ou renomeá-los dentro de uma versão, para que os consumidores mais antigos continuem funcionando. Os dados de teste ficam no repositório. As mudanças são revisadas.

34.2 Consumidores idempotentes

O repositório de constatações registra os eventos processados pelo event_id. Reproduzir o log não pode criar constatações duplicadas.

Lena testa a reprodução na bancada passando o log de eventos de um dia inteiro duas vezes pelo consumidor e conferindo que a contagem de constatações não muda. O teste pegou um defeito em que os eventos eram identificados pelo timestamp em vez do event_id, o que duplicou três tickets durante uma tempestade de reprodução antes que a correção chegasse. Os testes de reprodução rodam na integração contínua. As falhas bloqueiam o merge. O teste roda toda noite.

34.3 Testes de contrato

JSON de dados de teste para cada código de motivo do monitor, como register-out-of-range; os testes do consumidor afirmam os campos do ticket resultante. Rodam na integração contínua sobre dados de teste sintéticos.

Caso sintético — Ashford Batch Plant. Uma tempestade de reprodução duplicou três tickets até que a idempotência por event_id fosse implantada.

Os testes de contrato de Lena rodam em todo pull request e de forma agendada. Eles usam um dado de teste para cada código de motivo e afirmam os campos do ticket que o consumidor deve criar, como ativo, técnica e severidade. Uma execução agendada contra o ambiente de homologação pega mudanças do produtor mesmo quando não há nenhum pull request aberto, então a deriva é encontrada antes de uma janela, e não durante uma.

34.4 Erros e limites

A defasagem de relógio confunde as linhas do tempo; prefira o horário do evento mais o horário de recebimento.

A visão de linha do tempo de Lena na ABP mostra o horário do evento e o horário de recebimento lado a lado, para que um leitor veja quando o relógio de um dispositivo está errado. O Laboratório II depois injetou uma defasagem de 90 segundos no PLC-A e descobriu que dois eventos ficavam fora de ordem no dossiê até que uma correção de deslocamento fosse aplicada. As fontes de relógio são registradas em cada evento exatamente por esse motivo. Lena mantém os relógios sincronizados onde possível. A deriva gera alarme.

Nota prática

Eventos envenenados (timestamps no futuro, versões de política desconhecidas) vão para uma fila de mensagens mortas com um alerta — não para as constatações e não para /dev/null.

34.1b Mensagens mortas e exercícios de esquema

Cada evento enviado à fila de mensagens mortas guarda o erro de validação que o rejeitou. Os operadores reproduzem depois de corrigir o produtor. Uma vez por período, a equipe do CNHP acrescenta um campo opcional de ponta a ponta numa simulação na bancada: produtor, consumidor, dado de teste, documentação. Equipes que só evoluem esquemas em emergências inventam atalhos incompatíveis.

Uma execução agendada que falha abre um ticket para a equipe do produtor, não para a do consumidor. A idade das mensagens mortas é um gráfico de SLO ao lado da latência do caminho de negação.

A ABP faz um exercício de esquema a cada período. Os resultados dos exercícios são registrados com as versões do produtor e do consumidor envolvidas, como o exercício que acrescentou o horário de recebimento ao lado do horário do evento nas negações do PLC-A.

Nota de campo — quarentena de eventos envenenados

Um defeito num produtor emitiu eventos com timestamps em 2099. A quarentena de mensagens mortas os pegou; nenhuma constatação foi criada contra hosts aleatórios. Descartes invisíveis teriam sido piores — ao menos a quarentena aciona alguém.

O canário do consumidor do CNHP reprova a implantação se os eventos envenenados vindos do monitor não forem postos em quarentena em até um minuto na homologação.

Cada exercício termina com o novo campo visível num ticket de homologação para uma negação sintética do PLC-A, e com a duração do exercício registrada.

34.5 Exemplo resolvido — integrando os alertas ao sistema de manutenção (ABP sintética)

Os alertas do CNHP fluem para o sistema de gestão da manutenção da ABP, para que um alerta de "download de programa para o PLC-A" possa ser casado com uma ordem de serviço aberta. O contrato de eventos traz um ID de evento, a etiqueta do ativo, a técnica do ATT&CK for ICS (T0843 Program Download), o horário com a fonte do relógio e o hash da evidência. O consumidor é idempotente no ID do evento, então um alerta reproduzido não cria duas ordens de serviço. Os testes de contrato rodam na integração contínua com dados de teste dos dois lados; um evento sem o campo de técnica é enviado para uma fila de mensagens mortas e revisado diariamente, em vez de descartado. Um download sem ordem de serviço correspondente é escalado ao líder de turno em até cinco minutos.

Exercícios

• EX100 — Campo. Por que incluir policy_version em todo evento? Rubrica: 3 = auditar quais regras se aplicaram; 2 = vago; 1 = errado; 0 = nada.
• EX101 — Reprodução. Como o event_id impede constatações duplicadas? Rubrica: 3 = upsert/ignorar duplicatas; 2 = vago; 1 = errado; 0 = nada.
• EX102 — Dado de teste. Dois dados de teste exigidos antes de um novo código de motivo. Rubrica: 3 = exemplo do produtor + ticket esperado do consumidor; 2 = um; 1 = vago; 0 = nada.

Síntese

Contratos, consumidores idempotentes, testes com dados de teste.