Capítulo 27 — Infraestrutura crítica e segurança setorial: projeto de controles
Mapa da aula
Aula 27 publicada. Mapa, exemplo, EX053.
flowchart TD
N0["27.1 Do cenário ao controle"]
N1["27.3 Camadas independentes"]
N2["27.4 Especificando os controles"]
N3["27.6 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX053"]
Desenho lógico
flowchart LR
N0["27.1 Do cenário ao controle"]
N1["27.3 Camadas independentes"]
N2["27.4 Especificando os controles"]
N3["27.6 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX053"]
[27.1 Do cenário ao controle]
|
v
[27.3 Camadas independentes]
|
v
[27.4 Especificando os controles]
|
v
[27.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX053]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) projetar controles que tratam de cenários específicos com desempenho definido; (2) combinar controles preventivos, detectivos e de recuperação numa defesa em profundidade cujas camadas falham de forma independente; (3) dar preferência a limites projetados, baseados na física, para as piores consequências; e (4) especificar cada controle de modo que ele possa ser verificado. Ele aplica os capítulos 15, 23 e 26 e prepara os capítulos 28 e 30.
27.1 Do cenário ao controle
Cada cenário do Capítulo 23 recebe controles em três pontos: prevenir o evento de ameaça, detectá-lo se a prevenção falhar, e limitar e recuperar-se das consequências. Exemplo — comandos de parada forjados para a PS3 e a PS4: prevenir com comandos autenticados (R1); detectar com alarmes para anomalias de comando e mudanças de estado inesperadas; limitar com a lógica local de religamento automático e o tanque do hospital; recuperar com os procedimentos manuais locais (R4). Cada um desses controles precisa então ser especificado e verificado, como mostra o restante do capítulo, antes que o cenário da parada forjada possa ser considerado coberto no dossiê.
27.2 Limites projetados primeiro
Para as piores consequências, os controles mais robustos não dependem de software algum: válvulas de alívio de pressão, batentes mecânicos, intertravamentos por fiação dedicada, bombas dosadoras de produtos químicos fisicamente dimensionadas para que não consigam superdosar no curso máximo. A engenharia informada pela cibersegurança (veja o CCE do INL) enfatiza esses controles porque eles se mantêm mesmo que todos os sistemas digitais sejam comprometidos. Eles não conseguem cobrir tudo — uma válvula de alívio mecânica não impede que uma bomba seja desligada —, mas limitam os piores casos. Para a bomba dosadora da LRWA, o limite de curso dimensionado pelos engenheiros de processo é um controle desse tipo.
27.3 Camadas independentes
A defesa em profundidade só funciona se as camadas falharem de forma independente. Liste as dependências de cada camada: se a autenticação, o monitoramento e o registro em log dependem todos dos servidores SCADA, um único comprometimento derrota os três. Coloque pelo menos uma camada de detecção fora dos sistemas que ela observa (monitoramento passivo da rede, um analisador independente) e mantenha os materiais de recuperação (backups off-line, procedimentos, chaves reservas) fora do alcance da ameaça da qual se está recuperando. O TMRP aplica isso colocando o alarme do analisador de cloro num registrador separado e mantendo os backups off-line longe dos servidores SCADA que eles restaurariam.
27.4 Especificando os controles
Uma especificação de controle declara: o(s) cenário(s) de que ele trata; sua função; o desempenho (detecção em até X, taxa de rejeição, tempo de restauração); as dependências; o modo de falha (à prova de falhas ou operacional em falha, e o que isso significa aqui); o dono; e o método de verificação. Sem desempenho e verificação, um controle é uma intenção. A especificação dos limites de setpoint no exemplo resolvido abaixo mostra todos os elementos: o cenário, os limites e o limite de passo, a regra de alarme, as dependências, a manutenção do último setpoint válido como modo de falha e o teste T3 como verificação. Seu dono é a equipe de engenharia de controle que configura o controlador de dosagem.
27.5 Exemplo resolvido: limites de setpoint (sintético)
Cenário: um setpoint forjado ou errôneo leva a bomba dosadora de cloro a superdosar. Controles: (1) projetado — curso da bomba dosadora limitado fisicamente, de modo que a dose máxima na vazão máxima fique abaixo de uma concentração nociva (dimensionado pelos engenheiros de processo); (2) preventivo — limites e limites de passo no lado do controlador (R3), implementados no controlador, não na IHM, para que um SCADA comprometido não consiga contorná-los; (3) detectivo — alarme do analisador de cloro independente (R9) num registrador separado; (4) recuperação — procedimento para isolar a linha de dosagem e lavá-la. Especificação de (2): rejeitar setpoints fora de 0,5–5,5 mg/L ou que mudem mais de 0,5 mg/L por comando, rejeitar valores não finitos, registrar em log toda rejeição, alarmar após três rejeições em 10 minutos; à prova de falhas = manter o último setpoint válido; verificado pelo teste T3, incluindo testes baseados em propriedades (Laboratório 11).
27.6 Atividade prática
Escreva especificações completas para dois controles do cenário de parada forjada da §27.1, incluindo desempenho, dependências, modo de falha e verificação. Escolha um controle preventivo, como os comandos autenticados, e um controle de recuperação, como a operação manual local na PS3 e na PS4. Para cada um, declare o desempenho que ele precisa alcançar, do que depende e o que acontece quando falha. A autenticação deve falhar fechada para os comandos; a operação manual local precisa funcionar sem o SCADA e sem a rede. Nomeie um dono pelo papel e um método de verificação, e depois verifique se os dois controles compartilham alguma dependência que permitiria a um único evento derrotar ambos.
27.7 Erros comuns e limites
- Controles sem critérios de desempenho.
- Limites impostos na IHM, e não no controlador.
- "Camadas" que compartilham dependências.
- Nenhum limite projetado para a pior consequência quando um é viável.
- Materiais de recuperação alcançáveis pelo mesmo atacante.
O exemplo da dosagem evita cada um: os limites ficam no controlador, o alarme do analisador usa um registrador separado, o limite de curso é projetado, e cada elemento tem uma meta de desempenho. Os limites também mantêm o último setpoint válido quando um comando é rejeitado, de modo que o modo de falha está declarado, e cada rejeição é registrada em log para a regra de alarme.
Exercícios — capítulo 27
EX053 — Auditoria de dependências das camadas. Objetivo: verificar a independência. Entradas: os quatro controles da §27.5 e sua implementação: limites do controlador no PLC de dosagem; analisador num registrador separado; registro em log via SCADA. Passos: liste as dependências de cada camada; identifique qualquer dependência compartilhada; proponha uma mudança. Evidência esperada: tabela e mudança. Rubrica: 3 = dependência compartilhada encontrada (registro e alarme das rejeições via SCADA), mudança proposta (log local mais caminho de alarme independente); 2 = sem mudança; 1 = apenas a lista; 0 = nada.
EX054 — O significado de à prova de falhas. Objetivo: definir modos de falha no contexto. Entradas: o gateway de telemetria autenticada na PS4. Passos: para a falha do gateway, defina o que significa à prova de falhas para (a) os comandos, (b) a telemetria, (c) o controle local, e justifique. Evidência esperada: três definições. Rubrica: 3 = os comandos falham fechados (rejeitados), a telemetria falha de forma visível (alarme no SCADA), o controle local continua automaticamente; 2 = uma mal definida; 1 = "à prova de falhas = desligar"; 0 = nada.
Síntese do capítulo
Projete controles por cenário, nos pontos de prevenção, detecção e recuperação. Coloque limites físicos projetados nas piores consequências, imponha os limites onde o atacante não consiga contorná-los, torne as camadas independentes e especifique, para cada controle, desempenho, dependências, modo de falha, dono e verificação.
Continue estudando — capítulo 27 de 50
← Capítulo 26 · Índice de capítulos do curso · Capítulo 28 →
Siga para a próxima lição escrita.