Capítulo 31 — Infraestrutura crítica e segurança setorial: casos avançados

Mapa da aula

Aula 31 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["31.1 Além da manchete"]
  N1["31.2 Cadeias de suprimentos"]
  N2["31.3 Um quadro de comparação"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["31.1 Além da manchete"]
  N1["31.2 Cadeias de suprimentos"]
  N2["31.3 Um quadro de comparação"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> Q["EX061"]

[31.1 Além da manchete]
    |
    v
[31.2 Cadeias de suprimentos]
    |
    v
[31.3 Um quadro de comparação]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) analisar casos em que o dano veio pelo processo físico, pelos sistemas de safety ou por fornecedores compartilhados, e não pelo roubo de dados; (2) comparar casos de forma sistemática por causa, caminho, consequência, detecção e recuperação; (3) raciocinar sobre o risco da cadeia de suprimentos e de concentração entre setores; e (4) extrair lições defensáveis e delimitadas para um operador. O capítulo se apoia no Capítulo 20 e nos Capítulos 21–30 e prepara o projeto comparativo (Capítulo 34).

31.1 Além da manchete

A análise avançada de casos não pergunta "o que aconteceu?", e sim "qual premissa falhou, e essa premissa está presente aqui?" Três famílias de casos ilustram premissas de que os serviços críticos dependem.

Manipulação do processo projetada para ficar escondida. A análise de Langner sobre o Stuxnet descreve um malware que manipulava controladores industriais que acionavam centrífugas enquanto apresentava aos operadores valores de aparência normal (Langner, 2011). Premissa que falhou: o que o operador vê é o que o processo faz. Lição transferível: caminhos de medição independentes para as variáveis críticas e limites físicos que não dependam do controlador.

Ataques à camada de safety. A análise do TRITON/HatMan descreve um malware que tinha como alvo um controlador de sistema instrumentado de segurança (CISA MAR-17-352-01). Premissa que falhou: o sistema de safety é independente das redes que um atacante consegue alcançar. Lição: impor fisicamente os modos de programação do SIS (chaves físicas), separar as redes do SIS e tratar as estações de engenharia do SIS como os ativos mais sensíveis.

Falha de dependência compartilhada. A atualização de segurança defeituosa de julho de 2024, que derrubou cerca de 8,5 milhões de dispositivos Windows (Microsoft, 2024), e a parada preventiva de 2021 depois de um ransomware na rede de TI de uma empresa de oleodutos (CISA AA21-131A) mostram o dano chegando pelas dependências, e não pelo sistema de controle. Premissa que falhou: o nosso risco é limitado pelos nossos próprios sistemas. Lição: mapear a concentração (muitos serviços dependendo de um produto, fornecedor ou região de nuvem), escalonar as atualizações e planejar uma operação degradada que não precise da TI de negócio.

31.2 Cadeias de suprimentos

Todo operador roda software e hardware construídos por outros, muitas vezes por meio de longas cadeias de componentes. As medidas públicas incluem as listas de materiais de software, que listam os componentes (CISA SBOM), frameworks para a integridade do build como o SLSA (SLSA), práticas de desenvolvimento seguro para fornecedores (NIST SSDF, SP 800-218) e expectativas de "seguro por concepção" sobre os fabricantes (CISA Secure by Design). No bacharelado, as alavancas do operador são sobretudo contratuais e arquiteturais: exigir SBOMs e divulgação de vulnerabilidades, testar as atualizações antes da implantação, escalonar a distribuição, manter a capacidade de reverter e evitar que a falha de um único fornecedor pare várias funções críticas ao mesmo tempo.

31.3 Um quadro de comparação

Tabela da aula; deslize para ver todas as colunas →

Leia primeiro a linha "Premissa que falhou"; ela é a parte transferível. Cada controle genérico trata essa premissa, e não a técnica específica.

31.4 Exemplo resolvido: concentração em Calder (sintético)

Este caso é sintético. A CRP faz um levantamento entre os seus membros: o CVH, o CEDC e a Calder Mutual usam todos o mesmo produto de segurança de endpoints, configurado para atualizações automáticas; o CEDC e a CT usam a mesma região de nuvem para CAD/escalas; a CW e a CPN usam o mesmo integrador de TO, com acesso remoto a ambas. Eventos únicos que poderiam atingir vários setores de uma vez: uma atualização de endpoint defeituosa (hospital, despacho e banco simultaneamente); uma interrupção da região de nuvem (despacho e transporte); um comprometimento do integrador (água e energia). Recomendações: escalonar as atualizações de endpoint (um pequeno grupo canário primeiro, os consoles críticos de despacho por último); confirmar que a contingência com papel e rádio do CEDC não precisa da nuvem; exigir aprovação por sessão e credenciais separadas para o integrador em cada operador e incluí-lo no exercício conjunto. O ponto não é que esses fornecedores sejam ruins; é que o risco do condado é compartilhado e precisa ser analisado em conjunto.

31.5 Erros comuns e limites

• Tirar lições de detalhes vívidos, mas sem fonte.
• Tratar operações estatais direcionadas como a ameaça típica para todo operador.
• Ignorar falhas acidentais de dependências compartilhadas porque não há adversário envolvido.
• Ensinar técnicas em vez de premissas que falharam.

O exemplo da concentração em Calder evita esses erros: não usa nenhum detalhe de técnica, trata uma atualização acidental de endpoint com a mesma seriedade que um comprometimento do integrador e não supõe um agente estatal. Repetir afirmações sem fonte sobre a origem do Stuxnet seria o primeiro erro.

O quarto erro transformaria uma lição do TRITON numa descrição de como alcançar um controlador de safety.

Exercícios — capítulo 31

EX061 — Encontre a premissa. Objetivo: abstrair um caso. Entradas: o caso da Ucrânia em 2015 (Capítulo 20). Etapas: declare duas premissas que falharam e uma premissa que se manteve e ajudou na recuperação, com apoio da fonte. Evidência esperada: três premissas. Rubrica: 3 = por exemplo, o acesso remoto/as estações dos operadores eram confiáveis (falhou), as centrais de atendimento continuariam acessíveis (falhou), a operação manual era possível (se manteve), cada uma ligada ao alerta da CISA; 2 = duas; 1 = uma; 0 = nada.

EX062 — Mapa de concentração. Objetivo: identificar dependências compartilhadas. Entradas: o levantamento de concentração de Calder no exemplo resolvido deste capítulo. Etapas: desenhe um mapa bipartido (fornecedores ↔ operadores), marque o fornecedor com o maior alcance e proponha uma medida por fornecedor. Evidência esperada: mapa e medidas. Rubrica: 3 = o produto de endpoint alcança três operadores em três setores (o maior), medidas específicas (atualizações escalonadas, independência da contingência, controles sobre o integrador); 2 = mapa sem medidas; 1 = lista; 0 = nada.

Síntese do capítulo

Os casos avançados ensinam por meio das premissas que falharam: o que os operadores veem é real, os sistemas de safety são independentes, o risco é limitado pelos nossos próprios sistemas. Compare os casos por causa, caminho, consequência e premissa; gerencie o risco da cadeia de suprimentos e de concentração em conjunto entre os operadores; e transforme as lições em controles genéricos, e não em conhecimento de técnicas.