Capítulo 21 — Segurança de TO, IoT e sistemas ciberfísicos: requisitos

Mapa da aula

Aula 21 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["21.1 Fontes"]
  N1["21.2 Três famílias"]
  N2["21.3 Critérios de aceitação"]
  N3["Nota prática"]
  N4["21.1b MoSCoW sob segurança física"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["21.1 Fontes"]
  N1["21.2 Três famílias"]
  N2["21.3 Critérios de aceitação"]
  N3["Nota prática"]
  N4["21.1b MoSCoW sob segurança física"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]

[21.1 Fontes]
    |
    v
[21.2 Três famílias]
    |
    v
[21.3 Critérios de aceitação]
    |
    v
[Nota prática]
    |
    v
[21.1b MoSCoW sob segurança física]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) levantar requisitos com a segurança de processo, a operação e a segurança da informação; (2) separar requisitos funcionais, de segurança física e de medição; (3) escrever critérios de aceitação que um testador possa executar sobre dados de teste sintéticos.

21.1 Fontes

A segurança de processo quer camadas de proteção independentes. A operação quer visualização sem parada. A segurança da informação quer condutos com negação por padrão. As entrevistas de levantamento produzem declarações com "deverá" marcadas pela fonte. Os conflitos (visualização por conveniência versus isolamento do SIS) são registrados, não disfarçados.

Na ABP, Lena entrevistou separadamente o engenheiro de segurança de processo, os líderes de turno, os engenheiros de controle e a equipe de rede de TI, e depois levou os conflitos a uma reunião conjunta. O conflito mais claro foi a regra de visualização remota FW-12, que a operação valorizava e a segurança de processo não podia aceitar. Ele foi registrado com as duas posições, e a solução, a visualização pela réplica na DMZ, virou um requisito com dono.

21.2 Três famílias

Funcional: "O monitor serial deverá decodificar Modbus RTU no tronco A e emitir decisões de permitir/negar." Segurança física: "Se o arquivo da lista de permissões não carregar, o monitor deverá falhar de forma fechada (descartar todo o tráfego não essencial, ou alarmar e exigir ação humana, conforme o projeto)." Medição: "O CNHP deverá relatar a cobertura planejada versus observada das técnicas do ATT&CK for ICS, com denominadores." Os requisitos de segurança física vencem os empates.

Lena marca cada requisito do CNHP com a sua família, para que as revisões possam conferir se os de segurança física são testados primeiro. Os empates são resolvidos por escrito.

21.3 Critérios de aceitação

Cada requisito tem um Dado/Quando/Então sobre dados sintéticos. Exemplo: Dada a negação do L2 para o L1-SIS, Quando a alcançabilidade roda a partir do L4, Então o L1-SIS não está no conjunto alcançável. Critérios que exijam uma escrita na planta em operação são rejeitados na revisão.

Caso sintético — Ashford Batch Plant. O requisito de segurança física S-1, "falhar de forma fechada se faltar a lista de permissões", reprovou no seu teste de aceitação quando um caminho com erro de digitação retornou PASS. A correção foi publicada antes de qualquer janela na planta.

Os critérios são revistos com o dono do requisito. Cada critério é um teste.

21.4 Erros e limites

As partes interessadas inventam requisitos no meio da janela; estacione-os num backlog com um ticket AUTH, não altere às pressas monitores de produção durante um lote.

Quando alguém pede uma nova regra no monitor durante um lote, Lena a registra no backlog com um ticket de autorização e a avalia depois da janela. Mudar um monitor de produção no meio de um lote arrisca uma parada ou um defeito de falha aberta que ninguém testou. O item do backlog nomeia quem pediu, por que e quando será revisto, para que o pedido não se perca e quem o levantou veja que foi tratado.

Nota prática

Os testes de aceitação do CNHP levam o id do requisito no nome e reprovam a integração contínua quando pulados, de modo que um requisito do monitor sem teste aparece na build. Requisitos Must órfãos são testados ou formalmente adiados, com um dono executivo.

21.1b MoSCoW sob segurança física

A priorização Must/Should/Could ainda põe todos os requisitos de segurança física em Must. Um Could que enfraquece um Must (negação opcional de códigos de escrita) é reclassificado ou rejeitado. Gerentes de produto não derrotam no voto a falha fechada. Os campos de log também levam o id do requisito (req=S-1), para que um evento de negação possa ser rastreado até o requisito que ele impõe.

Na ABP, o S-1 e o R-12 são ambos itens Must, e nenhuma decisão de produto pode rebaixá-los. Um pedido para tornar opcionais, por conveniência, as negações de códigos de escrita foi rejeitado com base nisso, e a rejeição é registrada com o requisito que teria enfraquecido.

Exercícios

• EX061 — Levantamento. Escreva um requisito funcional e um de segurança física com "deverá" a partir de "o escritório não pode alcançar o SIS". Rubrica: 3 = ambos testáveis; 2 = um; 1 = vago; 0 = nada.
• EX062 — Aceitação. Dado/Quando/Então para a falha fechada com a lista de permissões ausente. Rubrica: 3 = completo, com negação/alarme esperados; 2 = parcial; 1 = ideia; 0 = nada.
• EX063 — Conflito. Visualização do L4 para o L2 por conveniência versus zoneamento — registre o conflito e a regra escolhida. Rubrica: 3 = conflito nomeado + regra com a segurança primeiro, via DMZ; 2 = só a regra; 1 = escolhe a conveniência; 0 = nada.

Síntese

Os requisitos do CNHP vêm dos operadores e engenheiros da planta, se dividem em famílias e são entregues com testes de aceitação sobre dados de teste sintéticos da planta.