Capítulo 28 — Infraestrutura crítica e segurança setorial: análise de falhas

Mapa da aula

Aula 28 publicada. Mapa, exemplo, EX056.

flowchart TD
  N0["28.1 Árvores de falhas"]
  N1["28.2 FMEA"]
  N2["28.4 Revisão pós-incidente sem culpabilização"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX056"]

Desenho lógico

flowchart LR
  N0["28.1 Árvores de falhas"]
  N1["28.2 FMEA"]
  N2["28.4 Revisão pós-incidente sem culpabilização"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> Q["EX056"]

[28.1 Árvores de falhas]
    |
    v
[28.2 FMEA]
    |
    v
[28.4 Revisão pós-incidente sem culpabilização]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX056]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) construir uma árvore de falhas simples com portas E e OU e calcular a probabilidade do evento de topo sob independência; (2) realizar uma análise de modos e efeitos de falha (FMEA) para um sistema pequeno; (3) acrescentar um caminho cibernético a uma análise de safety e ver como ele muda o resultado; e (4) conduzir uma revisão pós-incidente sem culpabilização que procure as causas sistêmicas. O capítulo se apoia nos Capítulos 12, 21, 22 e 26 e prepara o Capítulo 29 (operações) e o Capítulo 31 (casos avançados).

28.1 Árvores de falhas

Uma árvore de falhas parte de um evento de topo indesejado e o decompõe em causas ligadas por portas. Uma porta E significa que todas as entradas precisam ocorrer; uma porta OU significa que qualquer uma basta. Com eventos básicos independentes, a porta E multiplica as probabilidades e a porta OU as combina como $1 - \prod (1 - p_i)$. As árvores de falhas tornam as premissas explícitas e mostram quais eventos básicos dominam. Elas são tradicionalmente construídas para falhas aleatórias; a análise de segurança acrescenta caminhos em que um adversário pode fazer um evento acontecer de propósito — e a "probabilidade" de um adversário não é uma propriedade do hardware.

28.2 FMEA

A análise de modos e efeitos de falha trabalha de baixo para cima: para cada componente, liste as formas como ele pode falhar (não parte, falha aberto, dá leitura falsa), o efeito sobre o sistema, como isso seria detectado e os controles existentes; depois, ordene. A FMEA encontra bem os problemas de componentes isolados e mal as interações, e é por isso que ela anda junto com a STPA (Capítulo 26) e as árvores de falhas.

O EX056 aplica a FMEA à bomba dosadora e ao analisador da CW.

Uma linha para a bomba dosadora da CW diz: componente bomba dosadora; modo funciona na vazão máxima; efeito supercloração na saída; detecção alarme do analisador de residual na saída; controle existente vazão máxima da bomba limitada por fiação.

28.3 Exemplo resolvido e Laboratório 11 (sintético)

Este caso é sintético. Evento de topo no CVH: "o hospital perde a energia com qualidade de rede para as cargas críticas". Fisicamente, isso exige uma interrupção da rede elétrica E a falha da reserva (o gerador não parte OU o combustível está contaminado OU a chave de transferência automática falha). Separadamente, o BMS do hospital consegue comandar o painel de alimentação essencial; um comprometimento do BMS poderia desligar as cargas críticas independentemente da rede.

# Lab 11 - a small fault tree for "hospital loses mains-quality power" (synthetic annual probabilities)
P = {"grid": 0.05, "gen_fails_start": 0.02, "fuel_contaminated": 0.005, "ats_fails": 0.01, "cyber_bms": 0.002}
# top = grid AND (backup fails); backup fails = gen_fails_start OR fuel_contaminated OR ats_fails
# separately: a compromised building-management system can shed critical loads whatever the grid state
backup_fails = 1 - (1 - P["gen_fails_start"]) * (1 - P["fuel_contaminated"]) * (1 - P["ats_fails"])
top_physical = P["grid"] * backup_fails
top = 1 - (1 - top_physical) * (1 - P["cyber_bms"])
print(f"P(backup fails on demand) = {backup_fails:.5f}")
print(f"P(top) physical only = {top_physical:.6f}")
print(f"P(top) with BMS path  = {top:.6f}")
print(f"share from cyber path ~ {P['cyber_bms'] / top:.0%}")

Saída esperada:

P(backup fails on demand) = 0.03465
P(top) physical only = 0.001733
P(top) with BMS path  = 0.003729
share from cyber path ~ 54%

Com esses números sintéticos, o projeto físico é bom: são necessárias duas falhas independentes. O caminho cibernético é um único evento que contorna a porta E e aproximadamente dobra a probabilidade do evento de topo. O ponto mais profundo não depende da estimativa de 0,002: um atacante não falha ao acaso, então um caminho que precisa de um único "evento" sob controle do adversário pode dominar qualquer número que você escreva. A resposta de engenharia é restaurar a estrutura E — tornar impossível desligar as cargas críticas a partir do BMS (um bloqueio por fiação, ou o controle do BMS limitado aos painéis não críticos) —, em vez de apenas baixar a probabilidade estimada.

28.4 Revisão pós-incidente sem culpabilização

Quando as falhas acontecem, uma revisão sem culpabilização pergunta como o sistema permitiu que a ação de uma pessoa razoável causasse dano, e não quem punir. O modelo de Reason dos acidentes organizacionais descreve as defesas como camadas com furos que ocasionalmente se alinham (Reason, 2000). Pergunte: o que as pessoas sabiam no momento; o que fez a sua ação parecer certa; quais defesas estavam ausentes ou foram contornadas; o que vamos mudar no sistema? A culpa suprime os relatos, e os quase acidentes não relatados são evidência perdida.

No caso do Laboratório 11, uma revisão sem culpabilização de um evento de perda de energia perguntaria por que o BMS conseguia desligar as cargas críticas.

28.5 Erros comuns e limites

• Multiplicar as probabilidades de eventos com causas comuns (Capítulo 12).
• Tratar as ações de um adversário como falhas aleatórias.
• FMEA sem interações; árvores de falhas sem as pessoas.
• Revisões que terminam com "erro humano" e retreinamento.

O Laboratório 11 supõe a independência entre a falha do gerador e a contaminação do combustível; o EX024 mostra como um tanque de combustível compartilhado quebra isso. O caminho do BMS é o segundo erro tornado explícito: 0,002 não é uma propriedade do BMS. O terceiro aparece se uma FMEA do gerador ignorar o operador que precisa dar a partida manualmente. Uma revisão que termina com "erro do engenheiro da manutenção predial; retreinar" é o quarto.

Exercícios — capítulo 28

EX055 — Restaure a porta E. Objetivo: ver o efeito de uma correção de engenharia. Entradas: Laboratório 11. Etapas: modele uma correção em que o BMS só consegue desligar as cargas críticas se também houver uma interrupção da rede (isto é, o caminho cibernético entra na porta E da rede como uma causa extra de falha da reserva). Calcule a nova probabilidade do evento de topo. Evidência esperada: código modificado e valor. Rubrica: 3 = falha da reserva = 1−(0,98)(0,995)(0,99)(0,998) ≈ 0,03658, topo ≈ 0,001829, com o comentário de que o caminho cibernético agora precisa de uma interrupção da rede coincidente; 2 = abordagem certa, deslize aritmético; 1 = estrutura inalterada; 0 = nada.

EX056 — Linhas de FMEA. Objetivo: aplicar a análise de baixo para cima. Entradas: a bomba dosadora de cloro da CW e o seu analisador de residual. Etapas: escreva quatro linhas de FMEA (componente, modo de falha, efeito, detecção, controle existente). Evidência esperada: tabela. Rubrica: 3 = modos realistas (bomba na vazão máxima, bomba para, analisador lê baixo, analisador congelado) com efeitos sobre a segurança da água e detecções críveis; 2 = três; 1 = vago; 0 = nada.

Síntese do capítulo

As árvores de falhas e a FMEA tornam explícitas as premissas sobre falhas, de cima para baixo e de baixo para cima. Acrescentar caminhos cibernéticos revela eventos únicos que contornam a redundância projetada; a resposta mais forte restaura a independência estrutural, em vez de ajustar uma estimativa. Quando as falhas acontecem, revise o sistema, e não a pessoa.