Capítulo 29 — Infraestrutura crítica e segurança setorial: operações | Graduação Segurança de infraestrutura crítica e setores

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 29 publicada. Mapa, exemplo, EX057.

flowchart TD
  N0["29.1 O que as operações de segurança fazem"]
  N1["29.2 Resposta a incidentes na TO"]
  N2["29.3 Medir as operações"]
  N3["29.5 Uma etapa de playbook sintético"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX057"]

Desenho lógico

flowchart LR
  N0["29.1 O que as operações de segurança fazem"]
  N1["29.2 Resposta a incidentes na TO"]
  N2["29.3 Medir as operações"]
  N3["29.5 Uma etapa de playbook sintético"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]

[29.1 O que as operações de segurança fazem]
    |
    v
[29.2 Resposta a incidentes na TO]
    |
    v
[29.3 Medir as operações]
    |
    v
[29.5 Uma etapa de playbook sintético]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX057]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) descrever as operações de segurança de um operador de serviço crítico — monitoramento, triagem, escalonamento, gestão de mudanças e de vulnerabilidades; (2) adaptar a resposta a incidentes à tecnologia operacional, em que manter o processo seguro vem primeiro; (3) medir o desempenho operacional com o tempo para detectar e o tempo para recuperar, usando medianas e percentis; e (4) escrever uma etapa de playbook que respeite tanto a segurança quanto as operações. O capítulo se apoia nos Capítulos 12, 15, 24, 27 e 28 e prepara o Laboratório II (Capítulo 30).

29.1 O que as operações de segurança fazem

No dia a dia, uma função de operações de segurança monitora (logs, tráfego de rede, alertas), faz a triagem (isto é real? quão grave?), escalona (para quem, com que rapidez), coordena as mudanças (nenhuma mudança surpresa nos sistemas de TO) e gerencia as vulnerabilidades (Capítulos 5, 9, 11). Para um operador de serviço crítico, a característica definidora é a parceria com as operações: a equipe da sala de controle, os engenheiros e os clínicos sabem como é o normal para o processo e são donos das decisões que o afetam. Operações de segurança que não conversam com a sala de controle vão interpretar mal os alertas e, pior, tomar ações que prejudicam o serviço.

29.2 Resposta a incidentes na TO

As recomendações de resposta a incidentes do NIST, revisadas em 2025, situam a resposta dentro da gestão geral de riscos de cibersegurança e das funções do CSF 2.0 (SP 800-61 Rev. 3). Na TO, a ordem das prioridades muda: primeiro manter o processo seguro (o que pode significar passar ao controle manual ou local), depois conter (isolar os segmentos de TI ou TO afetados sem cortar o que o processo precisa), depois investigar e recuperar. Desconectar um servidor comprometido é um reflexo na TI; na TO, o operador precisa primeiro saber o que esse servidor faz — tirar o historiador é inofensivo, tirar o único servidor SCADA pode cegar os operadores durante uma tempestade. A evidência também precisa ser preservada: imagens das estações de engenharia, configurações dos controladores, capturas de rede e o livro do operador. Os playbooks são acordados com antecedência com as operações, a safety e, onde dados pessoais puderem estar envolvidos, a proteção de dados (Capítulo 14).

29.3 Medir as operações

As medidas comuns são o tempo para detectar (TTD: da primeira atividade maliciosa ou com defeito até a detecção) e o tempo para recuperar (TTR: da detecção até o serviço restabelecido). As suas distribuições são assimétricas (Capítulo 12): a maioria dos incidentes é tratada rapidamente; alguns levam dias. Reporte a mediana, o 90º percentil e o tamanho da amostra, e examine os valores atípicos individualmente — é na cauda longa que estão as lições. Cuidado com os incentivos: uma meta de TTD pode estimular registrar com generosidade a hora da "detecção".

Os 15 registros do Laboratório 12 mostram por quê: média de 27,2 horas, mediana de 4.

Examine individualmente a detecção de 240 horas; foi um uso indevido lento de credenciais.

29.4 Exemplo resolvido e Laboratório 12 (sintético)

Este caso é sintético. Os membros da CRP reuniram 15 registros de incidentes sanitizados dos últimos dois anos.

# Lab 12 - time to detect and recover: mean, median and percentiles from synthetic tickets (offline)
import statistics as st
TTD_H = [0.5, 1, 1, 2, 2, 3, 3, 4, 6, 8, 12, 20, 36, 70, 240]   # hours from first malicious activity to detection
TTR_H = [2, 3, 3, 4, 5, 5, 6, 8, 8, 10, 12, 16, 24, 48, 96]
for name, xs in (("time to detect", TTD_H), ("time to recover", TTR_H)):
    q = st.quantiles(xs, n=10, method="inclusive")
    print(f"{name}: n={len(xs)} mean={st.mean(xs):.1f} median={st.median(xs):.1f} p90={q[8]:.1f} max={max(xs)}")
print("mean TTD without the 240 h outlier:", round(st.mean(TTD_H[:-1]), 1))

Saída esperada:

time to detect: n=15 mean=27.2 median=4.0 p90=56.4 max=240
time to recover: n=15 mean=16.7 median=8.0 p90=38.4 max=96
mean TTD without the 240 h outlier: 12.0

O tempo médio para detectar (27,2 h) não descreve nenhum incidente real: metade foi detectada em até 4 horas, e um levou dez dias. Remover esse único registro corta a média em mais da metade. O relatório útil diz: "mediana de 4 h, 90º percentil de cerca de 56 h, n = 15; o caso de 240 horas foi um uso indevido lento de credenciais encontrado durante uma revisão de acessos" — e então pergunta por que o monitoramento o deixou escapar. Percentis sobre 15 registros são aproximados; o método de cálculo deve ser declarado (aqui, o método "inclusive" do statistics.quantiles do Python).

29.5 Uma etapa de playbook (sintético)

Playbook da CPN, etapa 3 — suspeita de comprometimento de uma estação de engenharia: (1) O analista de segurança informa o supervisor da sala de controle; o supervisor confirma que nenhuma operação de manobra depende da estação neste momento. (2) O supervisor autoriza o isolamento; o analista isola a porta de rede da estação, deixando-a ligada (para preservar a memória). (3) Um engenheiro confere as configurações dos controladores que a estação poderia ter alterado, comparando com o último backup sabidamente bom. (4) O analista registra os horários, as decisões e quem autorizou no log do incidente. Cada etapa nomeia quem decide e por que a ordem importa.

Se um engenheiro da CPN estivesse no meio de uma manobra de carga em torno da Substation North a partir daquela estação, tirar a sua porta de rede deixaria a operação pela metade, com a sala de controle sem saber quais disjuntores tinham se movido.

29.6 Erros comuns e limites

Equipes de segurança agindo na TO sem a autorização das operações.
Desligar a energia ou apagar sistemas antes de preservar a evidência.
Reportar tempos médios para dados assimétricos.
Playbooks que existem só nos sistemas que o incidente desativou.

O playbook da CPN evita os dois primeiros ao fazer o supervisor autorizar o isolamento e ao deixar a estação ligada. O Laboratório 12 mostra o terceiro. O quarto é o motivo de os membros da CRP manterem cópias impressas dos playbooks em cada sala de controle, já que um incidente pode desativar o sistema de documentos que os guarda.

Exercícios — capítulo 29

EX057 — Reporte a cauda. Objetivo: resumir dados assimétricos com honestidade. Entradas: Laboratório 12. Etapas: escreva um resumo de 100 palavras para o conselho da CRP sobre o TTD e o TTR, incluindo o tamanho da amostra, uma limitação e uma pergunta sobre o caso mais longo. Evidência esperada: o resumo. Rubrica: 3 = medianas e p90 com n, distorção da média apontada, limitação (pequena, sanitizada, tempos de detecção autodeclarados), pergunta incisiva; 2 = números sem ressalva; 1 = só as médias; 0 = nada.

EX058 — Contenção segura. Objetivo: ordenar as ações na resposta em TO. Entradas: ransomware detectado no servidor do historiador da CW na zona de controle; os servidores SCADA parecem não afetados. Etapas: escreva as cinco primeiras ações em ordem, com quem decide cada uma. Evidência esperada: lista ordenada. Rubrica: 3 = confirmar o estado do processo com as operações; preparar a operação manual/local; isolar o historiador da zona de controle com a aprovação das operações; preservar a evidência; conferir o SCADA e os controladores contra o estado sabidamente bom, com os papéis nomeados; 2 = sensato, mas fora de ordem ou sem papéis; 1 = o "desligar tudo" ao estilo da TI; 0 = nada.

Síntese do capítulo

Nos serviços críticos, as operações de segurança trabalham lado a lado com as operações: primeiro manter o processo seguro, conter sem cegar os operadores, preservar a evidência e recuperar. Meça com medianas, percentis e tamanhos de amostra, e investigue os valores atípicos que as médias escondem.