Capítulo 40 — Laboratório de verificação II
Mapa da aula
Aula 40 publicada. Mapa, exemplo, EX118.
flowchart TD
N0["40.1 Ponta a ponta"]
N1["40.2 Falhas"]
N2["40.3 Aprovação"]
N3["Nota prática"]
N4["40.1b Observabilidade e paridade"]
N5["Nota de campo — pacote malicioso"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX118"]
Desenho lógico
flowchart LR
N0["40.1 Ponta a ponta"]
N1["40.2 Falhas"]
N2["40.3 Aprovação"]
N3["Nota prática"]
N4["40.1b Observabilidade e paridade"]
N5["Nota de campo — pacote malicioso"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX118"]
[40.1 Ponta a ponta]
|
v
[40.2 Falhas]
|
v
[40.3 Aprovação]
|
v
[Nota prática]
|
v
[40.1b Observabilidade e paridade]
|
v
[Nota de campo — pacote malicioso]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX118]
Objetivos de aprendizagem
Você vai (1) verificar o fluxo de ponta a ponta, do quadro ao ticket e à cobertura; (2) injetar falhas; (3) assinar uma versão candidata.
40.1 Ponta a ponta
Quadro sintético para decisão do monitor para evento para ticket de constatação para atualização da cobertura. Registre os hashes em cada salto.
No Laboratório II da ABP, Lena reproduz um quadro sintético na bancada e o acompanha por cada etapa: a decisão da função permit com o seu código de motivo, o alerta, a ordem de serviço no sistema de manutenção, o ticket da constatação e a atualização da cobertura. Um hash é registrado em cada salto, para que o dossiê possa provar que o ticket descreve o mesmo evento que o monitor viu. Uma cadeia que não pode ser rastreada salto a salto não conta como aprovada, mesmo quando o resultado final parece certo.
40.2 Falhas
Derrube o repositório de constatações no meio do fluxo; confirme que o monitor continua negando e que os rascunhos são enfileirados. Corrompa um arquivo de evidência; confirme o alerta de divergência de hash. Alimente uma lista de arestas plana (insegura); confirme que a alcançabilidade reprova a verificação do SIS.
# Lab 23 - reachability count on a synthetic Purdue-layered OT network
# Nodes: L5-ERP, L4-Office, L3.5-DMZ, L3-Hist, L2-SCADA, L1-PLC, L1-SIS, L0-IO
edges_flat=[("L5","L4"),("L4","L3"),("L3","L2"),("L2","L1-PLC"),("L2","L1-SIS"),("L1-PLC","L0"),("L1-SIS","L0"),("L4","L2")]
edges_zoned=[("L5","L4"),("L4","L3.5"),("L3.5","L3"),("L3","L2"),("L2","L1-PLC"),("L1-SIS","L0"),("L1-PLC","L0")] # SIS not reachable from SCADA
def reach(edges, start):
g={};
for a,b in edges: g.setdefault(a,[]).append(b)
seen=set(); stack=[start]
while stack:
n=stack.pop()
if n in seen: continue
seen.add(n); stack.extend(g.get(n,[]))
return seen
for name,e in (("flat",edges_flat),("zoned",edges_zoned)):
r=reach(e,"L4")
print(f"{name}: L4 reaches {sorted(r)} count={len(r)} writes_to_SIS={'L1-SIS' in r}")
Saída esperada:
flat: L4 reaches ['L0', 'L1-PLC', 'L1-SIS', 'L2', 'L3', 'L4'] count=6 writes_to_SIS=True
zoned: L4 reaches ['L0', 'L1-PLC', 'L2', 'L3', 'L3.5', 'L4'] count=6 writes_to_SIS=False
As falhas do Laboratório II de Lena incluem também a perda de energia do coletor, que gerou o alerta de visibilidade degradada em 40 segundos, e 90 segundos de defasagem de relógio na cópia de bancada do PLC-A. Cada falha é injetada separadamente e depois em pares, porque uma falha inofensiva sozinha pode corromper evidências quando combinada com outra.
40.3 Aprovação
Checklist da versão candidata do monitor assinado pelo implementador e pelo revisor; as linhas de segurança de processo precisam estar verdes.
Caso sintético — Ashford Batch Plant. O Laboratório II descobriu que a cobertura era atualizada antes da criação do ticket numa nova tentativa — a ordem foi corrigida com um outbox.
Na ABP, a aprovação do Laboratório II lista cada linha com o seu resultado e todo defeito aberto com um dono, como a ordenação errada de eventos causada pela defasagem de relógio. A correção de ordenação de Lena garante que o ticket seja gravado antes que o painel de cobertura seja atualizado, para que uma nova tentativa não possa contar uma constatação que nunca foi registrada.
40.4 Erros e limites
Um teste de ponta a ponta sem injeção de falhas só prova o caminho feliz.
A primeira execução de ponta a ponta de Lena na ABP passou em todas as linhas, mas o Laboratório II com falhas injetadas descobriu que a defasagem de relógio desordenava dois eventos no dossiê e que uma nova tentativa atualizava a cobertura antes de o ticket existir. Nenhum dos dois defeitos apareceria numa execução limpa, porque ambos dependem de falhas de tempo que só ocorrem quando algo quebra. A aprovação do Laboratório II exige, por isso, que cada script de falha tenha rodado e que o seu resultado esteja registrado, e uma execução sem falhas é relatada como teste de fumaça.
Nota prática
Pacote de dados de teste maliciosos: hashes errados, eventos reordenados, timestamps no futuro, grafo plano alegando ser zoneado. Passar só nos dados de teste felizes é um laboratório incompleto.
40.1b Observabilidade e paridade
O Laboratório II ativa logs de depuração temporariamente, mas lacra uma cópia redigida. Deixar a depuração ligada nos builds da janela pode vazar segredos. O ambiente do laboratório espelha as versões das ferramentas de produção e as chaves de assinatura das políticas (chaves de teste). Uma execução do Laboratório II que só passa na nova tentativa bloqueia a versão do monitor; ela não é repetida até ficar verde.
Um script de falha que não consegue rodar é registrado como linha reprovada, não pulado. Os scripts que injetam falhas na bancada, como um arquivo de política ausente, ficam na pasta do laboratório e são fixados por SHA no relatório. As lacunas de paridade de ambiente explicam as surpresas de "verde no laboratório, vermelho na janela".
A aprovação de Lena procura lacunas de paridade.
Nota de campo — pacote malicioso
O pacote malicioso do Laboratório II incluía um grafo plano rotulado como zoneado. A verificação de alcançabilidade falhou de forma fechada e bloqueou a versão. Laboratórios só de caminho feliz publicam mentiras.
Lena lacra os logs do Laboratório II com a mesma ferramenta de manifesto do dossiê do CNHP, para que a bancada e a planta usem um único fluxo de hashes.
Testes instáveis são postos em quarentena e corrigidos; publicar com um "às vezes falha fechado" é publicar falha aberta.
40.5 Exemplo resolvido — injeção de falhas de ponta a ponta (ABP sintética)
O Laboratório II exercita a cadeia completa na bancada: tráfego reproduzido → função permit → alerta → ordem de serviço no sistema de manutenção → dossiê. Falhas injetadas: perda de energia do coletor, defasagem de relógio de 90 segundos no PLC-A, um evento malformado e um acúmulo na fila de mensagens mortas. Resultados: a perda de energia gerou "visibilidade degradada" em 40 s; a defasagem de relógio foi detectada pela verificação da fonte de tempo, mas desordenou dois eventos no dossiê até que a correção de deslocamento fosse aplicada; o evento malformado chegou à fila de mensagens mortas; o acúmulo foi esvaziado em 7 minutos. A aprovação lista a desordenação como um defeito aberto, com dono.
Exercícios
- EX118 — Ordenação. Por que criar o ticket antes de a contagem de cobertura aumentar? Rubrica: 3 = a cobertura precisa refletir constatações registradas; 2 = vago; 1 = qualquer ordem; 0 = nada.
- EX119 — Falha. Comportamento esperado do monitor quando o repositório de constatações está fora do ar. Rubrica: 3 = continua avaliando/negando; enfileira rascunhos; 2 = parcial; 1 = falha aberta; 0 = nada.
- EX120 — Aprovação. Duas assinaturas exigidas — de quem? Rubrica: 3 = implementador + revisor independente; 2 = uma; 1 = só o gerente; 0 = nada.
Síntese
Ponta a ponta com falhas; segurança física verde; duas assinaturas.
Continue estudando — capítulo 40 de 50
← Capítulo 39 · Índice de capítulos do curso · Capítulo 41 →
Siga para a próxima lição escrita.