Capítulo 21 — Infraestrutura crítica e segurança setorial: requisitos

Mapa da aula

Aula 21 publicada. Mapa, exemplo, EX041.

flowchart TD
  N0["21.1 Fontes de requisitos"]
  N1["21.2 Requisitos para a operação degradada"]
  N2["21.3 Níveis de segurança e requisitos de componentes"]
  N3["21.4 Conflitos e negociação"]
  N4["21.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX041"]

Desenho lógico

flowchart LR
  N0["21.1 Fontes de requisitos"]
  N1["21.2 Requisitos para a operação degradada"]
  N2["21.3 Níveis de segurança e requisitos de componentes"]
  N3["21.4 Conflitos e negociação"]
  N4["21.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]

[21.1 Fontes de requisitos]
    |
    v
[21.2 Requisitos para a operação degradada]
    |
    v
[21.3 Níveis de segurança e requisitos de componentes]
    |
    v
[21.4 Conflitos e negociação]
    |
    v
[21.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX041]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) levantar requisitos de segurança e de resiliência a partir de consequências, partes interessadas, regulações e informações sobre ameaças; (2) escrever requisitos baseados em desempenho para a operação degradada, a recuperação e a segurança operacional, e não apenas para a proteção; (3) derivar requisitos de componentes a partir dos requisitos de sistema usando níveis de segurança; e (4) negociar explicitamente os conflitos entre requisitos. Ele aplica os capítulos 5 e 16 ao setor e prepara o Capítulo 22.

21.1 Fontes de requisitos

Os requisitos de segurança de infraestrutura vêm de cinco fontes, e um bom conjunto é rastreável a todas elas: consequências (o que nunca pode acontecer, e o que precisa ser restabelecido e com que rapidez); partes interessadas (operadores, clientes como hospitais, serviços de emergência, reguladores); regulações e normas (por exemplo, as avaliações de riscos do AWIA, o NERC CIP, as medidas de gestão de riscos da NIS2); informações sobre ameaças (capacidades de adversários documentadas em fontes como o MITRE ATT&CK for ICS e os avisos da CISA); e restrições (equipamentos legados, orçamento, equipe, certificação de segurança operacional).

21.2 Requisitos para a operação degradada

Um sistema que está ou "seguro" ou "comprometido" está mal especificado. Escreva requisitos para os estados intermediários: Durante a perda da rede de telemetria, cada estação de bombeamento deverá continuar em controle automático local, dentro de seus limites configurados, por pelo menos 72 h. Durante a suspeita de comprometimento dos servidores SCADA, os operadores deverão conseguir operar a PS3 e a PS4 em modo manual local, com procedimentos documentados e equipe, em até 1 h após a decisão. Após um incidente, a operação remota deverá ser restabelecida em até 8 h após a decisão de restabelecer, a partir de backups off-line verificados. São esses os requisitos que mantêm as pessoas abastecidas.

21.3 Níveis de segurança e requisitos de componentes

A IEC 62443-3-3 e a IEC 62443-4-2 expressam requisitos de sistema e de componentes em relação a níveis de segurança (SL 1–4), que refletem a capacidade do adversário a que se deve resistir, desde a violação casual ou acidental até o ataque sofisticado e com muitos recursos (visão geral da série ISA/IEC 62443). A avaliação de riscos para o projeto (IEC 62443-3-2, página do catálogo) divide o sistema em zonas e condutos e atribui um nível-alvo a cada um. Um nível-alvo se torna então requisitos concretos de componentes — por exemplo, autenticação de todos os usuários humanos, ou proteção da integridade das comunicações. O texto da norma não é de acesso livre; cite cláusulas apenas de uma cópia que você tenha obtido legalmente.

21.4 Conflitos e negociação

Os requisitos entram em conflito: acesso rápido do operador versus autenticação forte; correções frequentes versus disponibilidade; registro detalhado em log versus armazenamento em instalações remotas; suporte do fornecedor versus isolamento da rede. Não resolva conflitos em silêncio no projeto. Registre cada um, suas opções e a decisão com seu dono — geralmente a pessoa que é dona do risco operacional. O primeiro conflito registrado no TMRP é entre o modo manual local de R4 e a autenticação de R1, resolvido com uma chave seletora, um alarme e um log local. O dono é a área de operações, que assume o risco de um acesso manual mais lento.

21.5 Exemplo resolvido: conjunto de requisitos v1.0 do TMRP (sintético)

Tabela da aula; deslize para ver todas as colunas →

Conflito registrado: o modo manual local de R4 cria um caminho que contorna a autenticação de R1. Resolução: o modo manual exige uma chave seletora física no painel, é alarmado no SCADA e é registrado localmente.

21.6 Atividade prática

Escolha um estado degradado ainda não coberto (por exemplo, a perda do fornecedor de cloro por 7 dias) e escreva um requisito, sua fonte e o método de verificação. Escreva o requisito na mesma forma da tabela do TMRP: um identificador, uma única afirmação verificável, sua fonte e um método de verificação. Uma perda de sete dias no fornecimento de cloro, por exemplo, poderia levar a um estoque mínimo de produto químico na instalação, com uma inspeção, e a um procedimento para um fornecedor alternativo, testado por exercício. Verifique se seu requisito não entra em conflito com um existente e, se entrar, registre o conflito e quem deve decidi-lo.

21.7 Erros comuns e limites

• Requisitos apenas para a proteção, nenhum para a degradação e a recuperação.
• Níveis de segurança atribuídos sem uma avaliação de riscos documentada.
• Citar cláusulas de normas sem acesso ao texto.
• Conflitos resolvidos em silêncio por quem escreve o projeto.
• Requisitos que não podem ser verificados com os meios do programa.

O conjunto do TMRP evita o primeiro erro ao incluir R4, R5 e R6 para a operação degradada e a recuperação, e evita o quarto ao registrar abertamente o conflito do modo manual local. Todo requisito do conjunto pode ser verificado com a bancada, o ensaio ou a demonstração do próprio programa.

Exercícios — capítulo 21

EX041 — Requisitos de estado degradado. Objetivo: especificar o comportamento sob estresse. Entradas: LRWA, cenário "servidores SCADA cifrados por ransomware". Passos: escreva três requisitos cobrindo a continuidade do serviço, a detecção/contenção e a restauração, cada um com fonte e verificação. Evidência esperada: tabela. Rubrica: 3 = mensuráveis, cobrem as três fases, verificação realista; 2 = falta uma fase; 1 = apenas proteção; 0 = nada.

EX042 — Registro de conflito. Objetivo: documentar um conflito. Entradas: os operadores querem que a IHM fique conectada o turno inteiro; um novo requisito exige nova autenticação após 15 min de inatividade. Passos: escreva um registro de conflito com opções, resolução recomendada e dono. Evidência esperada: registro. Rubrica: 3 = as opções incluem controles compensatórios (controle de acesso físico à sala de controle, bloqueio apenas de visualização com nova autenticação rápida para ações de controle), dono nomeado pelo papel; 2 = sem dono; 1 = escolhe um lado sem opções; 0 = nada.

Síntese do capítulo

Derive os requisitos das consequências, das partes interessadas, das regulações, das ameaças e das restrições. Especifique a operação degradada e a recuperação com o mesmo cuidado que a proteção. Traduza os níveis de segurança-alvo em requisitos concretos de componentes por meio de uma avaliação de riscos documentada e registre cada conflito com opções, decisão e dono.