Capítulo 20 — Infraestrutura crítica e segurança setorial: contexto de engenharia

Capítulo 20 — Infraestrutura crítica e segurança setorial: contexto de engenharia

Mapa da aula

Aula 20 publicada. Mapa, exemplo, EX039.

flowchart TD
  N0["20.1 O que torna uma infraestrutura crítica"]
  N1["20.2 Setores como sistemas de engenharia"]
  N2["20.3 Interdependência"]
  N3["20.4 Aprender com incidentes documentados"]
  N4["20.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX039"]

Desenho lógico

flowchart LR
  N0["20.1 O que torna uma infraestrutura crítica"]
  N1["20.2 Setores como sistemas de engenharia"]
  N2["20.3 Interdependência"]
  N3["20.4 Aprender com incidentes documentados"]
  N4["20.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX039"]

[20.1 O que torna uma infraestrutura crítica]
    |
    v
[20.2 Setores como sistemas de engenharia]
    |
    v
[20.3 Interdependência]
    |
    v
[20.4 Aprender com incidentes documentados]
    |
    v
[20.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX039]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) descrever como a infraestrutura crítica é definida e organizada em setores, e o panorama regulatório dentro do qual os engenheiros trabalham; (2) caracterizar os setores por seus processos físicos, unidades de consequência e tecnologia; (3) descrever as interdependências entre setores; e (4) aprender com incidentes documentados no nível que suas fontes públicas sustentam. É a ponte entre os fundamentos (capítulos 1–19) e os capítulos da área (21–50).

20.1 O que torna uma infraestrutura "crítica"

Os governos designam como críticos os ativos, sistemas e redes cuja incapacitação prejudicaria gravemente a segurança, a economia, a saúde pública ou a segurança das pessoas. Os Estados Unidos identificam dezesseis setores de infraestrutura crítica e, mais recentemente, um conjunto de National Critical Functions que atravessam as organizações. A Diretiva NIS2 (2022/2555) da União Europeia estabelece obrigações de cibersegurança para entidades essenciais e importantes, e a Diretiva CER (2022/2557) trata da resiliência das entidades críticas de forma mais ampla. As regras setoriais acrescentam detalhes: as normas NERC CIP para os sistemas elétricos de grande porte da América do Norte, os requisitos de avaliação de riscos do America's Water Infrastructure Act de 2018 para os sistemas comunitários de água dos EUA, o DORA (2022/2554) para as finanças da UE e as HHS Healthcare and Public Health Cybersecurity Performance Goals. Essas regras mudam; cite a versão e a data e verifique de novo.

20.2 Setores como sistemas de engenharia

Cada setor tem um processo físico ou de serviço, uma unidade de consequência e uma tecnologia característica.

A tabela é uma simplificação para orientação de engenharia; cada linha é uma carreira.

20.3 Interdependência

Rinaldi, Peerenboom and Kelly (2001) classificam as interdependências como físicas, cibernéticas, geográficas e lógicas. A água precisa de eletricidade para o bombeamento; a recomposição da eletricidade precisa de comunicações; os hospitais precisam de água, energia e comunicações; quase tudo precisa de hora precisa. A interdependência transforma falhas locais em regionais e fornecedores compartilhados em causas comuns. A atualização defeituosa da CrowdStrike, em julho de 2024, que a Microsoft estimou ter afetado cerca de 8,5 milhões de dispositivos Windows (Microsoft, 2024), não foi um ataque, mas interrompeu de uma só vez companhias aéreas, hospitais e outros serviços por meio de uma dependência de software compartilhada.

20.4 Aprender com incidentes documentados

Os relatórios públicos de incidentes são valiosos e parciais. Use-os no nível de suas fontes. O incidente da Colonial Pipeline, em 2021, envolveu ransomware na TI de negócios; a empresa paralisou as operações do oleoduto por precaução — um lembrete de que a dependência das operações em relação a sistemas de TI (faturamento, programação) pode interromper o serviço físico sem nenhum comprometimento da TO. O ataque de 2015 à rede elétrica ucraniana usou acesso remoto para operar disjuntores e danificou as capacidades de recuperação. O surto do WannaCry em 2017 interrompeu serviços do NHS na Inglaterra. Cada um tem detalhes documentados e questões em aberto; onde os relatos iniciais foram revistos, como em Oldsmar, cite ambos.

20.5 Exemplo resolvido: situando a LRWA no contexto (sintético)

A LRWA é uma concessionária de água que tem um hospital entre seus clientes críticos. Sua unidade de consequência são pessoas-hora sem água segura, ponderadas para usuários vulneráveis; a reservação própria do St Brenna's dá cerca de quatro horas de folga. Suas interdependências: eletricidade (bombeamento, tratamento), comunicações (telemetria LTE), fornecimento de produtos químicos (cloro) e tempo (correlação de logs). Supõe-se que seu contexto regulatório inclua um dever de avaliação de riscos e resiliência semelhante ao do AWIA. O escopo do TMRP é definido por esses elementos: o programa não é "proteger o SCADA", e sim "manter a água segura chegando às pessoas sob condições adversas plausíveis, incluindo ataques".

20.6 Atividade prática

Escolha um setor que não seja o de água. Apenas a partir de fontes públicas, construa a linha dele na §20.2 com mais detalhes: três unidades de consequência, três tecnologias típicas, duas regulações principais com versão e data, e um incidente documentado com sua fonte. Mantenha o perfil no nível de suas fontes. Para cada regulação, dê a versão, a data em que você a consultou e as entidades que ela abrange. Para o incidente, diga apenas o que o relatório citado diz e anote qualquer revisão posterior, como no caso de Oldsmar. Depois compare a unidade de consequência do seu setor com as pessoas-hora sem água segura da LRWA e anote uma interdependência que seu setor compartilha com a água, como eletricidade, comunicações ou tempo.

20.7 Erros comuns e limites

• Tratar a "infraestrutura crítica" como uma categoria de tecnologia, e não como uma categoria de consequência.
• Regulações citadas sem versão ou data.
• Narrativas de incidentes repetidas além do que as fontes sustentam.
• Ignorar as dependências de TI das operações físicas.
• Pensar num único setor num mundo interdependente.

O próprio contexto da LRWA mostra por que isso importa. Sua condição de crítica vem do St Brenna's e de seus outros clientes, não da tecnologia que ela opera. Suas operações dependem de eletricidade, LTE, fornecimento de cloro e hora precisa, então analisar a água isoladamente deixaria passar a dependência oculta do alimentador encontrada antes. Qualquer dever regulatório em que ela se apoie precisa ser citado com versão e data.

Exercícios — capítulo 20

EX039 — Perfil setorial. Objetivo: traçar o perfil de um setor a partir de fontes públicas. Entradas: §20.6. Passos: produza o perfil com citações. Evidência esperada: uma página. Rubrica: 3 = exato, citado, unidades de consequência mensuráveis, incidente descrito dentro de suas fontes; 2 = uma afirmação sem citação; 1 = genérico; 0 = nada.

EX040 — Dependência compartilhada. Objetivo: raciocinar sobre causas comuns entre setores. Entradas: a interrupção da CrowdStrike de julho de 2024, como descrita pela Microsoft. Passos: explique em 200 palavras por que uma atualização de software não maliciosa produziu uma interrupção em vários setores, qual propriedade de engenharia ela revela e uma prática de projeto que limita eventos assim. Evidência esperada: texto. Rubrica: 3 = dependência compartilhada/causa comum, componente privilegiado com atualização automática, implantação em etapas ou diversidade como prática, afirmações dentro das fontes; 2 = prática genérica; 1 = chama de ataque; 0 = nada.

Síntese do capítulo

A infraestrutura crítica é definida pela consequência. Os setores diferem em processo, unidades de consequência e tecnologia, mas compartilham a interdependência de energia, comunicações, tempo e fornecedores comuns. Trabalhe dentro das regulações por versão e data, aprenda com os incidentes apenas até onde suas fontes vão e defina todo programa de segurança pelo serviço e pelas pessoas que ele protege.

Continue estudando — capítulo 20 de 50

← Capítulo 19 · Índice de capítulos do curso · Capítulo 21 →

Siga para a próxima lição escrita.