Capítulo 24 — Infraestrutura crítica e segurança setorial: controles | 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 24 publicada. Mapa, exemplo, EX047.

flowchart TD
  N0["24.1 Frameworks como organizadores"]
  N1["24.2 Tipos de controle"]
  N2["24.3 Mapeamento e lacunas"]
  N3["24.4 Restrições da TO"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX047"]

Desenho lógico

flowchart LR
  N0["24.1 Frameworks como organizadores"]
  N1["24.2 Tipos de controle"]
  N2["24.3 Mapeamento e lacunas"]
  N3["24.4 Restrições da TO"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX047"]

[24.1 Frameworks como organizadores]
    |
    v
[24.2 Tipos de controle]
    |
    v
[24.3 Mapeamento e lacunas]
    |
    v
[24.4 Restrições da TO]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX047]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) usar um framework — o NIST CSF 2.0, o CAF do Reino Unido ou metas setoriais — para organizar os controles; (2) classificar os controles por tipo (preventivo, detectivo, corretivo) e natureza (técnico, procedimental, físico, de engenharia); (3) mapear os controles aos cenários e às técnicas que eles tratam e encontrar lacunas; e (4) escolher controles adequados às restrições da TO. O capítulo se apoia nos Capítulos 16 e 23 e prepara o Laboratório I (Capítulo 25) e o Capítulo 27 (verificação).

24.1 Frameworks como organizadores

Um framework organiza os resultados para que nada grande seja esquecido. O Cybersecurity Framework 2.0 do NIST agrupa os resultados em seis funções: Govern, Identify, Protect, Detect, Respond e Recover (governar, identificar, proteger, detectar, responder e recuperar) (NIST CSF 2.0). O CAF do Reino Unido expressa resultados e indicadores de boas práticas para os operadores de serviços essenciais (NCSC CAF). Também existem metas específicas de setor — por exemplo, as metas de desempenho em cibersegurança para a saúde do Department of Health and Human Services dos EUA (HHS HPH CPGs). Os catálogos detalhados de controles, como o NIST SP 800-53, listam controles específicos (SP 800-53 Rev. 5). Os frameworks dizem quais resultados alcançar; eles não dizem qual risco importa mais para o seu serviço — isso vem do Capítulo 23.

24.2 Tipos de controle

Os controles preventivos impedem um evento (allowlist, autenticação, um limite por fiação). Os controles detectivos o percebem (monitoramento, verificações de integridade, alarmes). Os controles corretivos ou de recuperação restauram o serviço (backups, procedimentos manuais, equipamentos sobressalentes). Quanto à natureza, os controles são técnicos, procedimentais (aprovação por duas pessoas, gestão de mudanças), físicos (armários trancados, chaves físicas) ou de engenharia (projetos que tornam impossível um estado danoso, como uma bomba dimensionada para não conseguir dosar demais). Na TO, os controles de engenharia e físicos costumam ser os mais confiáveis, porque continuam funcionando quando os computadores são comprometidos.

24.3 Mapeamento e lacunas

Um controle só tem valor contra alguma coisa. Construa um mapeamento dos cenários (ou das técnicas catalogadas, por exemplo do ATT&CK for ICS) para os controles, com cada controle marcado como preventivo, detectivo ou corretivo. As lacunas aparecem como cenários só com controles detectivos (você vai saber, mas não vai impedir), sem controle corretivo (você não consegue se recuperar) ou cobertos apenas por controles que compartilham um ponto único de falha (o modo comum do Capítulo 16). O mapeamento também expõe os controles órfãos, que não tratam nada da sua lista — candidatos a revisão.

24.4 Restrições da TO

Alguns controles padrão na TI são arriscados ou impossíveis na TO: agentes de endpoint que consomem os recursos do controlador, aplicação automática de patches, varredura ativa, bloqueio de conta numa IHM de operador durante uma emergência (bloquear o operador pode ser mais perigoso que o atacante). As alternativas incluem o monitoramento passivo da rede, a allowlist de aplicações em estações de trabalho estáveis, diodos de dados só de leitura para fluxos de mão única, chaves físicas para os modos de programação e controles procedimentais ligados ao livro de turno do operador.

O mapa do BMS do CVH os aplica: monitoramento passivo da VLAN do BMS em vez de agentes no controlador, e um intertravamento de vazão mínima por fiação para a ventilação do centro cirúrgico, em vez de depender de bloqueio ou de patches.

24.5 Exemplo resolvido: mapa de controles do BMS do CVH (sintético)

Este caso é sintético.

Tabela da aula; deslize para ver todas as colunas →

Cenário	Preventivo	Detectivo	Corretivo	Lacuna
Comprometimento remoto do BMS pela rede corporativa	Allowlist no firewall para o servidor do BMS; MFA para a administração do BMS	Monitoramento passivo da VLAN do BMS	Controle manual local das unidades de tratamento de ar	Nenhuma óbvia; verificar o exercício de controle manual
Alteração maliciosa ou equivocada dos setpoints de ventilação do centro cirúrgico	Direitos de alteração baseados em papéis	Alarme de trocas de ar fora da faixa	O plantão da manutenção predial restaura os setpoints	Nenhum limite independente: acrescentar um intertravamento de vazão mínima por fiação
Notebook de fornecedor no controlador do BMS	Armários trancados; acompanhamento do fornecedor	—	Restaurar a configuração do controlador a partir do backup	Sem detecção; backup da configuração não testado

O mapa transforma um vago "o BMS é um risco" em duas ações específicas: um intertravamento de engenharia e uma restauração de configuração testada.

24.6 Erros comuns e limites

Tratar o preenchimento de um framework como redução de risco.
Contar controles em vez de mapeá-los aos cenários.
Depender só da detecção para consequências que precisam de prevenção.
Importar controles de TI para a TO sem considerar a segurança operacional.

O mapa do BMS do CVH evita cada um: não conta controles, mapeia-os a três cenários, acrescenta um intertravamento de engenharia onde só havia detecção e rejeita controles de TI como a aplicação automática de patches no controlador do BMS. Uma nota de framework de "Protect: implementado" não teria dito nada ao hospital sobre a vazão de ar do centro cirúrgico.

Exercícios — capítulo 24

EX047 — Classifique os controles. Objetivo: usar tipo e natureza. Entradas: backups offline; aprovação de pagamentos por duas pessoas; analisador de cloro na saída que fecha uma válvula; alerta do SIEM sobre novas contas de administrador; chave física para a programação do PLC. Etapas: classifique cada um por tipo e natureza. Evidência esperada: tabela. Rubrica: 3 = backups corretivo/técnico; aprovação por duas pessoas preventivo/procedimental; disparo do analisador preventivo (limita a consequência)/de engenharia; alerta do SIEM detectivo/técnico; chave física preventivo/físico; 2 = um erro; 1 = dois erros; 0 = nada.

EX048 — Encontre a lacuna. Objetivo: mapear e julgar. Entradas: a tabela do CVH. Etapas: acrescente um cenário (ransomware no servidor do BMS) com controles em cada coluna e depois nomeie a melhoria isolada mais valiosa e justifique-a. Evidência esperada: linha e justificativa. Rubrica: 3 = controles plausíveis, incluindo restauração testada e controle manual local; melhoria justificada pela consequência; 2 = linha sem justificativa; 1 = linha incompleta; 0 = nada.

Síntese do capítulo

Os frameworks organizam os resultados; a análise de risco decide as prioridades; os mapeamentos ligam os controles aos cenários que eles tratam e revelam as lacunas. Prefira combinações de prevenção, detecção e recuperação e, na TO, favoreça os controles de engenharia e físicos, que continuam funcionando quando os computadores não funcionam.