Capítulo 37 — Infraestrutura crítica e segurança setorial: operações

Mapa da aula

Aula 37 publicada. Mapa, exemplo, EX074.

flowchart TD
  N0["37.1 Operações de segurança em TO"]
  N1["37.2 Playbooks"]
  N2["37.3 Gestão de mudanças, acessos e vulnerabilidades"]
  N3["37.4 Aprender sem culpa"]
  N4["37.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX074"]

Desenho lógico

flowchart LR
  N0["37.1 Operações de segurança em TO"]
  N1["37.2 Playbooks"]
  N2["37.3 Gestão de mudanças, acessos e vulnerabilidades"]
  N3["37.4 Aprender sem culpa"]
  N4["37.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX074"]

[37.1 Operações de segurança em TO]
    |
    v
[37.2 Playbooks]
    |
    v
[37.3 Gestão de mudanças, acessos e vulnerabilidades]
    |
    v
[37.4 Aprender sem culpa]
    |
    v
[37.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX074]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) projetar as operações de segurança para TO — monitoramento, triagem, escalonamento, coordenação com as operações do processo; (2) escrever procedimentos operacionais e playbooks que os operadores consigam executar sob estresse; (3) gerenciar mudanças, acessos e vulnerabilidades nas operações diárias; e (4) aprender com incidentes e quase acidentes sem atribuir culpa. Ele se apoia nos capítulos 18, 29 e 34 e prepara os capítulos 38 e 47.

37.1 Operações de segurança em TO

O monitoramento de segurança de TO observa o tráfego de rede, os logs e os dados do processo em busca de sinais de uso indevido. A triagem em TO difere da de TI: a primeira pergunta não é "isto é malicioso?", mas "o processo está seguro?". Os caminhos de escalonamento, portanto, vão até a sala de controle e o gerente de operações de plantão, além da equipe de segurança. Muitas concessionárias não têm uma equipe de segurança 24/7; a sala de controle tem pessoal 24/7 e precisa conseguir agir sobre os alarmes de segurança com playbooks claros, escalonando para especialistas de segurança de sobreaviso.

37.2 Playbooks

Um playbook é um procedimento curto e testado para uma situação específica: gatilho, ações imediatas de segurança operacional, informações a coletar, decisões e quem as toma, comunicações e retorno à normalidade. Escreva para um operador cansado às 03:00: passos numerados, pontos de decisão claros, números de telefone, nada de jargão. Teste cada playbook em exercícios e atualize-o depois de cada uso. Orientações de tratamento de incidentes como a NIST SP 800-61 Rev. 3 fornecem a estrutura geral; os playbooks de TO acrescentam passos de segurança do processo. O playbook da LRWA para uma mudança inesperada de setpoint é escrito segundo esse padrão.

37.3 Gestão de mudanças, acessos e vulnerabilidades

As operações diárias mantêm o sistema no estado projetado: gestão de mudanças (nenhuma mudança de configuração sem aprovação e registro); gestão de acessos (admissões, transferências, desligamentos; sessões de fornecedores aprovadas a cada uso); gestão de vulnerabilidades (acompanhar alertas como os ICS advisories da CISA, avaliar a aplicabilidade, planejar a correção, Capítulo 12). A deriva — mudanças não documentadas que se acumulam — é o modo mais comum de um sistema bem projetado se tornar inseguro. Na LRWA, o script de relatório corporativo esquecido, encontrado na revisão de fluxos, é um exemplo de deriva, e o controle de mudanças em cada conduto é o modo como o TMRP impede que esses caminhos reapareçam.

37.4 Aprender sem culpa

Incidentes e quase acidentes são evidências sobre o sistema. Reason (2000) contrastou a abordagem da pessoa (culpar indivíduos) com a abordagem do sistema (defesas, barreiras e condições latentes), argumentando que a segunda é mais eficaz. As revisões pós-ação perguntam o que aconteceu, por que aquilo fazia sentido para as pessoas envolvidas no momento, quais defesas funcionaram ou falharam e o que vai mudar. A culpa suprime o relato, e quase acidentes não relatados são lições perdidas. Na LRWA, o técnico que conectou um laptop à rede da PS3 no EX074 é tratado desse modo: a revisão pergunta por que o jump host parecia lento demais e o que tornou o atalho possível.

37.5 Exemplo resolvido: playbook "mudança inesperada de setpoint" (sintético)

Gatilho: o SCADA mostra uma mudança de setpoint em qualquer estação que não corresponde a uma ação de operador nos últimos 5 minutos, ou um gateway registra falhas repetidas de MAC. Ações imediatas de segurança operacional: (1) confira os valores do processo da estação com as medições independentes; (2) se estiverem fora da faixa normal, restaure localmente o setpoint anterior ou passe para o manual local por meio do técnico de plantão; (3) não desligue a telemetria remota. Coletar: estação, horário, valores antigo/novo, trecho do log do gateway, log do operador. Decidir: o gerente de plantão decide se desativa as escritas remotas em toda a frota (chave de configuração dos gateways). Comunicar: segurança de sobreaviso em até 30 minutos; contato com o hospital se a PS3/PS4 forem afetadas. Retorno à normalidade: as escritas remotas só são reativadas depois que a segurança de sobreaviso concordar.

37.6 Atividade prática

Execute o playbook num exercício de mesa com uma sequência roteirizada de injeções (primeiro uma única mudança de setpoint, depois falhas de MAC numa segunda estação, depois um telefonema do hospital sobre pressão baixa). Registre os tempos de decisão e as ambiguidades e revise o playbook. Execute as injeções em ordem e anote o horário de cada decisão. Observe em especial se a equipe mantém a telemetria remota funcionando, como o playbook exige, e se o gerente de plantão decide sobre a desativação das escritas remotas em toda a frota antes que chegue o telefonema do hospital. Registre cada ponto em que alguém perguntou o que o playbook queria dizer. Depois do exercício, reescreva esses passos e agende uma segunda execução para conferir as revisões.

37.7 Erros comuns e limites

• Alarmes de segurança encaminhados a uma equipe que não está de serviço quando eles disparam.
• Playbooks escritos para especialistas, nunca testados.
• Gestão de mudanças contornada "temporariamente".
• Revisões pós-ação que terminam com "erro do operador".

O projeto do playbook da LRWA responde a esses erros: os alarmes de segurança chegam à sala de controle, que tem pessoal a todo momento, e a segurança de sobreaviso é chamada em até 30 minutos. O playbook é testado em exercícios de mesa, e o controle de mudanças não tem exceções temporárias. As revisões pós-ação na LRWA buscam condições latentes, como um jump host lento, em vez de terminar com erro do operador.

Exercícios — capítulo 37

EX073 — Revisão do playbook. Objetivo: melhorar um playbook. Entradas: §37.5. Passos: identifique três fraquezas (p. ex., limiares ambíguos, contatos ausentes, padrão inseguro) e reescreva os passos afetados. Evidência esperada: passos revisados. Rubrica: 3 = fraquezas substantivas corrigidas com passos executáveis; 2 = mudanças cosméticas; 1 = apenas crítica; 0 = nada.

EX074 — Revisão de quase acidente. Objetivo: conduzir uma revisão sem culpa. Entradas: um técnico conectou um laptop à rede de controle da PS3 para baixar logs, contornando o jump host; o laptop não tinha sido verificado. Nenhum incidente se seguiu. Passos: escreva uma revisão de uma página: o que aconteceu, por que fazia sentido, defesas que falharam, mudanças no sistema. Evidência esperada: revisão. Rubrica: 3 = explica a racionalidade local (jump host lento, prazo), identifica condições latentes (sem segurança de porta, sem caminho fácil para os logs), propõe mudanças no sistema; 2 = alguma culpa; 1 = "treinar de novo o técnico"; 0 = nada.

Síntese do capítulo

As operações de segurança de TO começam pela segurança do processo e encaminham o escalonamento pela sala de controle. Os playbooks precisam ser curtos, testados e executáveis sob estresse. A gestão diária de mudanças, acessos e vulnerabilidades mantém o sistema como projetado, e o aprendizado sem culpa com incidentes e quase acidentes melhora as defesas.