Capítulo 10 — Infraestrutura crítica e segurança setorial: orientação

Capítulo 10 — Infraestrutura crítica e segurança setorial: orientação

Mapa da aula

Aula 10 publicada. Mapa, exemplo, EX028.

flowchart TD
  N0["10.1 O que torna um serviço crítico"]
  N1["10.2 Como os setores diferem"]
  N2["10.3 Dependências e interdependências"]
  N3["10.4 As obrigações do operador e a sua parte nelas"]
  N4["10.6 Atividade prática: tabela de consequências e pr"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX028"]

Desenho lógico

flowchart LR
  N0["10.1 O que torna um serviço crítico"]
  N1["10.2 Como os setores diferem"]
  N2["10.3 Dependências e interdependências"]
  N3["10.4 As obrigações do operador e a sua parte nelas"]
  N4["10.6 Atividade prática: tabela de consequências e pr"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX028"]

[10.1 O que torna um serviço crítico]
    |
    v
[10.2 Como os setores diferem]
    |
    v
[10.3 Dependências e interdependências]
    |
    v
[10.4 As obrigações do operador e a sua parte nelas]
    |
    v
[10.6 Atividade prática: tabela de consequências e pr]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX028]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você deve ser capaz de:

• explicar o que torna um serviço crítico: a consequência da sua perda para as pessoas, para outros serviços e para a sociedade;
• descrever como água, saúde, energia, transporte e finanças diferem no que protegem, na rapidez com que o dano chega e em quem os regula;
• identificar as dependências e interdependências que transformam uma falha local numa falha regional;
• situar o seu próprio trabalho como implementador dentro das obrigações que um operador carrega.

Os Capítulos 1–9 construíram habilidades gerais. Daqui em diante, o livro as aplica especificamente aos serviços críticos. Este capítulo é de orientação: o formato da área, o bastante para entender por que um tecnólogo da FSTS precisa pensar numa estação de bombeamento, num hospital e numa garagem de ônibus de formas diferentes, mesmo quando os servidores se parecem.

10.1 O que torna um serviço crítico

Um serviço é crítico quando a sua interrupção prejudicaria gravemente a saúde, a segurança, a proteção, a atividade econômica ou o funcionamento da sociedade. Os governos formalizam isso de formas diferentes. Os Estados Unidos descrevem National Critical Functions — funções tão vitais que a sua interrupção teria um efeito debilitante —, e não apenas listas de setores (CISA National Critical Functions). A Diretiva NIS2 da União Europeia estabelece obrigações de gestão de riscos de cibersegurança e de notificação para entidades em setores de alta criticidade (Diretiva (UE) 2022/2555), e a Diretiva CER trata da resiliência física e mais ampla das entidades críticas (Diretiva (UE) 2022/2557). Esses textos mudam; confira a versão atual e como a sua jurisdição a aplica. Este livro não dá aconselhamento jurídico.

Para um implementador, o significado prático é mais simples: a unidade de dano é pessoas e tempo, e não apenas registros de dados ou dinheiro. "41.000 pessoas sem informações confiáveis sobre a água por seis horas" é o tipo de afirmação que deve orientar as prioridades.

10.2 Como os setores diferem

As diferenças mudam as escolhas de implementação. Um patch no gateway das bombas de infusão de um hospital exige a aprovação da engenharia clínica; uma mudança de firewall numa estação de bombeamento pode exigir uma visita ao local e uma janela de interrupção; um quiosque da garagem em geral pode ser reconstruído no mesmo dia. Tratar todos com um único processo de mudanças de TI ou atrasa as mudanças seguras, ou apressa as perigosas.

10.3 Dependências e interdependências

Os serviços críticos dependem uns dos outros: a água precisa de eletricidade para as bombas e de telecomunicações para a telemetria; os hospitais precisam de água, eletricidade e telecomunicações; todos dependem de um pequeno número de fornecedores. O artigo clássico de Rinaldi e colegas classifica as interdependências como físicas, cibernéticas, geográficas e lógicas (Rinaldi, Peerenboom e Kelly, 2001). Na FSTS, a interdependência mais importante é organizacional: a mesma equipe pequena, o mesmo host de salto e os mesmos fornecedores atendem aos três operadores. Uma única conta de administrador da FSTS comprometida toca água, saúde e transporte ao mesmo tempo.

10.4 As obrigações do operador e a sua parte nelas

Os operadores de serviços essenciais costumam carregar obrigações de gerenciar o risco cibernético, notificar incidentes significativos dentro de prazos definidos, manter planos de continuidade e cooperar com as autoridades. Frameworks como o Cyber Assessment Framework do NCSC do Reino Unido expressam essas obrigações como resultados a alcançar (NCSC CAF); os Cross-Sector Cybersecurity Performance Goals da CISA oferecem uma linha de base de práticas (CISA CPGs). Um implementador raramente é dono dessas obrigações, mas produz a maior parte das evidências para elas: listas de ativos, revisões de acessos, logs, resultados de testes, linhas do tempo de incidentes. Se essas evidências estiverem atrasadas ou erradas, o relatório do operador estará atrasado ou errado.

10.5 Exemplo resolvido: uma falha, três clientes (sintético)

Às 02:10, um disco do host de salto da FSTS falha. A operação de Água perde a administração remota dos relays, mas mantém a telemetria (os relays continuam rodando). Os engenheiros clínicos do hospital não conseguem alcançar o gateway das bombas de infusão para carregar uma atualização da biblioteca de medicamentos programada para as 06:00. A garagem não consegue enviar uma mudança de horários para os quiosques. A mesma falha tem três consequências diferentes, com três prazos diferentes. O tecnólogo de plantão que reconhece isso liga primeiro para a Engenharia Clínica — porque a atualização das 06:00 tem uma finalidade de segurança do paciente —, embora a Água seja o maior cliente.

10.6 Atividade prática: tabela de consequências e prazos

Para cada cliente de Fallowmere, liste três sistemas operados pela FSTS. Para cada sistema, escreva: o que as pessoas perdem se ele parar, com que rapidez essa perda se torna danosa, quem decide sobre a ação de emergência e de qual outro sistema ele depende. Guarde esta tabela; o Capítulo 11 a transforma num inventário com dependências.

Para o Fallowmere Community Hospital, uma linha poderia ser: gateway das bombas de infusão; perda, as atualizações da biblioteca de medicamentos não podem ser carregadas; danosa em horas se uma atualização programada, como a das 06:00, for perdida; a Engenharia Clínica decide; depende do host de salto da FSTS. Essa linha é o motivo pelo qual a falha do host de salto no exemplo resolvido foi escalada ao hospital antes da Água.

10.7 Erros comuns e limites

• Tratar todo sistema operado por uma equipe de TI como tendo a mesma consequência.
• Medir o dano apenas em dados ou dinheiro.
• Ignorar pessoas, ferramentas e fornecedores compartilhados como dependências.
• Citar regulamentos de memória; o seu escopo e os seus prazos mudam e diferem entre jurisdições.
• Presumir que o implementador não tem parte nas obrigações do operador.

A falha do host de salto mostra juntos o primeiro e o terceiro erros: um único host compartilhado da FSTS teve três consequências, com três prazos.

Medir o dano apenas em dinheiro teria posto a Água em primeiro lugar naquela noite, por ser o maior cliente, e teria perdido a atualização da biblioteca de medicamentos das 06:00.

Exercícios — capítulo 10

EX028 — Consequência em pessoas e tempo. Objetivo: expressar o dano em unidades de serviço. Entradas: o cenário do Capítulo 10 ("Exemplo resolvido: uma falha, três clientes"). Restrições: apenas números sintéticos; declare as premissas. Etapas: para cada cliente, escreva uma frase da forma "N pessoas perdem X por T, o que se torna danoso depois de D porque…". Evidência esperada: três frases com premissas. Rubrica: 3 = três afirmações específicas, plausíveis e com premissas rotuladas, mostrando prazos diferentes, com o prazo de segurança do paciente do hospital identificado como o mais curto; 2 = uma genérica; 1 = todas em dinheiro; 0 = nada.

EX029 — Mapa de dependências compartilhadas. Objetivo: encontrar as interdependências criadas por um serviço compartilhado. Entradas: a FSTS opera um host de salto, um SIEM, um diretório de identidades e um sistema de backup para os três clientes; a Kell fornece as RTUs de água, a BayTel transporta a telemetria da água e a internet do hospital. Restrições: use os quatro tipos de Rinaldi. Etapas: (1) classifique cada dependência; (2) nomeie a falha única de efeito mais amplo; (3) proponha uma mudança para reduzi-la. Evidência esperada: tabela e parágrafo. Rubrica: 3 = sistemas compartilhados da FSTS como cibernéticos/lógicos, BayTel como operadora comum cibernética/física, pessoal como lógico; comprometimento do diretório de identidades ou do host de salto identificado como o mais amplo; uma mudança prática, como níveis privilegiados por cliente ou um segundo caminho de operadora para a telemetria; 2 = classificação fraca; 1 = só a lista; 0 = nada.

EX030 — As evidências que você deve. Objetivo: ligar o trabalho diário às obrigações do operador. Entradas: CISA CPGs ou NCSC CAF (escolha um; cite a versão que você leu). Restrições: três resultados ou metas. Etapas: para cada um, nomeie a evidência que um tecnólogo da FSTS produz para ele, com que frequência e onde ela é guardada. Evidência esperada: tabela com citação. Rubrica: 3 = três resultados/metas corretamente citados (por exemplo, inventário de ativos, MFA, coleta de logs), cada um com evidência específica e produzida com regularidade; 2 = evidência vaga; 1 = sem citação; 0 = nada.

Síntese do capítulo

Um serviço é crítico por causa do que a sua perda faz às pessoas, medido em pessoas e tempo. Os setores diferem no que protegem primeiro e na rapidez com que o dano chega, então a mesma falha técnica exige respostas diferentes. Serviços compartilhados como a FSTS criam interdependências por meio de pessoas, ferramentas e fornecedores. Os operadores carregam as obrigações legais; os implementadores produzem a maior parte das evidências que mostram que elas são cumpridas.

Continue estudando — capítulo 10 de 30

← Capítulo 09 · Índice de capítulos do curso · Capítulo 11 →

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