Capítulo 29 — Segurança de TO, IoT e sistemas ciberfísicos: operações

Mapa da aula

Aula 29 publicada. Mapa, exemplo, EX085.

flowchart TD
  N0["29.1 Monitoramento em que os operadores confiam"]
  N1["29.2 Passos do playbook"]
  N2["29.3 Patches nas janelas"]
  N3["29.4 Exercícios de mesa"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX085"]

Desenho lógico

flowchart LR
  N0["29.1 Monitoramento em que os operadores confiam"]
  N1["29.2 Passos do playbook"]
  N2["29.3 Patches nas janelas"]
  N3["29.4 Exercícios de mesa"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[29.1 Monitoramento em que os operadores confiam]
    |
    v
[29.2 Passos do playbook]
    |
    v
[29.3 Patches nas janelas]
    |
    v
[29.4 Exercícios de mesa]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX085]

Objetivos de aprendizagem

Você vai (1) projetar um fluxo de monitoramento de segurança de TO com os operadores no circuito; (2) escrever um passo de playbook de resposta a incidentes que respeite a segurança do processo; (3) planejar a aplicação de patches dentro das janelas de manutenção; e (4) conduzir um exercício de mesa.

29.1 Monitoramento em que os operadores confiam

O monitoramento passivo de rede no switch de controle da LDHP constrói uma linha de base de quem fala com quem. Os alertas — um novo host falando Modbus, uma escrita de uma origem inesperada, um download de firmware — vão para um analista de segurança, que liga para o líder de turno antes que alguém toque na planta. O NIST SP 800-82r3 enfatiza que a resposta a incidentes em TO precisa ser coordenada com a operação, porque as próprias ações de contenção podem causar uma perturbação no processo. Na LDHP, o alerta do exercício de mesa deste capítulo, uma escrita Modbus no registrador 100 feita por 10.20.4.17 na VLAN do escritório, é exatamente o caso de "origem inesperada".

29.2 Passos do playbook

Bons passos de playbook de TO nomeiam quem decide e qual é o estado seguro. "Isolar o PLC-H da rede" é perigoso se os operadores perderem a HMI. Melhor: "O líder de turno decide se passa a caldeira para controle manual local; só então o analista bloqueia a origem suspeita no firewall." O exercício de mesa deste capítulo seguiu essa ordem: o analista ligou para o líder de turno às 02:12, o operador restabeleceu o setpoint de ida de 30 °C para 90 °C às 02:15, e o líder de turno aprovou o bloqueio de 10.20.4.17 no firewall às 02:18. O bloqueio veio depois de o processo estar seguro, e não antes, e depois de uma pessoa identificada tê-lo decidido.

29.3 Patches nas janelas

A LDHP tem uma janela de manutenção mensal de quatro horas. Os patches são testados numa HMI de bancada, classificados por risco (exposição × consequência) e aplicados em ordem até a janela encher; o resto é adiado com um chamado datado e controles compensatórios. O IEC TR 62443-2-3 trata da gestão de patches em ambientes de IACS. Num mês com uma correção de firmware do PLC-H, uma atualização do Windows da HMI-1 e um patch do gateway, a classificação só põe o PLC-H em primeiro lugar se a correção tratar de um caminho exposto; caso contrário, a HMI-1, que guarda as contas nominais dos operadores e está voltada para a EWS-1 e para o jump host, pode vir primeiro. O que for adiado recebe um chamado datado e os controles compensatórios do Capítulo 24.

29.4 Exercícios de mesa

Um exercício de mesa ensaia um cenário no papel: quem é chamado, o que é decidido, que informação está faltando. Ele revela lacunas sem arriscar o processo. O exercício de mesa da LDHP começou a partir de um alerta às 02:10 numa noite de janeiro: uma escrita Modbus no registrador 100 do PLC-H feita por 10.20.4.17 na VLAN do escritório. O analista ligou para o líder de turno às 02:12, o operador confirmou que o setpoint de ida tinha mudado para 30 °C e restabeleceu 90 °C às 02:15, e o líder de turno aprovou o bloqueio do endereço às 02:18, depois do que começou a coleta de evidências. A lacuna encontrada foi banal e importante: ninguém tinha o telefone noturno do administrador do firewall. Um incidente real teria encontrado a mesma lacuna com menos tempo para corrigi-la.

Caso sintético — Lakeside District Heating Plant. Os horários, os endereços e a lacuna são inventados.

Erros e limites

Os playbooks apodrecem à medida que as equipes e as redes mudam; revise-os depois de cada exercício. O bloqueio automático em TO deve ser excepcional e combinado de antemão.

Exercícios

• EX085 — Reescrevendo um passo de playbook perigoso. Reescreva de forma segura "Desligue o servidor SCADA imediatamente".
  Mostrar critérios de avaliação

  Rubrica: 3 = quem decide, primeiro o estado seguro do processo, depois a contenção; 2 = parcial; 1 = inalterado; 0 = nada.
• EX086 — Preenchendo uma janela. Os patches precisam de 1,5 h (risco 9), 2 h (risco 6), 1 h (risco 8) e 1 h (risco 3) numa janela de 4 h. Quais entram?
  Mostrar critérios de avaliação

  Rubrica: 3 = riscos 9, 8 e 3 (3,5 h), com o patch de risco 6 adiado num chamado datado; 2 = conjunto certo, sem registro do adiamento; 1 = estoura a janela; 0 = nada.
• EX087 — Corrigindo a lacuna do exercício de mesa. Proponha uma correção para o telefone que faltava e como testá-la.
  Mostrar critérios de avaliação

  Rubrica: 3 = escala de plantão no playbook mais uma ligação de teste no próximo exercício; 2 = um; 1 = vago; 0 = nada.

Síntese

A segurança das operações de TO mantém os operadores no comando do processo, aplica patches por risco dentro das janelas e ensaia até que as lacunas sejam encontradas no papel, e não às 2 da manhã.