Capítulo 13 — Infraestrutura crítica e segurança setorial: cenários de risco
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["13.1 Cenários, e não categorias"]
N1["13.2 A consequência primeiro"]
N2["13.3 Controles existentes e risco residual"]
N3["13.4 Dos cenários ao trabalho"]
N4["13.6 Atividade prática: ordenação de cenários"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["13.1 Cenários, e não categorias"]
N1["13.2 A consequência primeiro"]
N2["13.3 Controles existentes e risco residual"]
N3["13.4 Dos cenários ao trabalho"]
N4["13.6 Atividade prática: ordenação de cenários"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]
[13.1 Cenários, e não categorias]
|
v
[13.2 A consequência primeiro]
|
v
[13.3 Controles existentes e risco residual]
|
v
[13.4 Dos cenários ao trabalho]
|
v
[13.6 Atividade prática: ordenação de cenários]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- escrever um cenário de risco como uma história específica: causa, caminho, ativo afetado, consequência para as pessoas e controles existentes;
- atribuir faixas de consequência e de probabilidade com motivos declarados, medindo a consequência em pessoas e tempo;
- ordenar os cenários com a consequência primeiro quando a safety está envolvida, e explicar por que o produto probabilidade × consequência pode enganar;
- transformar os principais cenários em trabalho de implementação com responsáveis.
A avaliação de riscos pode ser feita em muitas profundidades; o guia do NIST descreve um processo completo para organizações (NIST SP 800-30 Rev. 1). Este capítulo ensina a versão do implementador: escrever cenários precisos o bastante para que um tecnólogo consiga construir, testar e monitorar os controles que eles implicam.
13.1 Cenários, e não categorias
"Ransomware" é uma categoria. Um cenário é: "Um ransomware entregue por um e-mail de phishing cifra o HIST-01; os dados das estações ainda chegam ao relay, que os armazena em buffer; os operadores perdem as telas de tendências e os relatórios semanais de conformidade até que o historiador seja restaurado." Um bom cenário nomeia a causa, o caminho, o ativo afetado, a consequência para as pessoas e para o serviço, e os controles existentes. Ele pode então ser testado ("o relay realmente armazena em buffer? por quanto tempo?") e monitorado.
O R2 passa no teste: credencial de fornecedor roubada, acesso remoto do fornecedor, setpoint de dosagem da PS-07, mudança de cloro na água que se bebe.
13.2 A consequência primeiro
A consequência descreve o que acontece às pessoas: quantas, por quanto tempo e se alguém poderia ser prejudicado. Uma faixa simples usa pessoas × horas de interrupção, com qualquer efeito crível de safety posto na faixa mais alta, quaisquer que sejam os números. A probabilidade é uma faixa de julgamento (de 1 a 5), informada pela exposição, pelas ameaças conhecidas e pelo histórico. Escreva o motivo de cada faixa; uma faixa sem motivo não pode ser contestada.
Muitos registros ordenam pelo produto probabilidade × consequência. O produto é conveniente e perigoso: trata um incômodo frequente e uma catástrofe rara como iguais se os produtos coincidirem, e deixa um problema visto com frequência, mas recuperável, passar à frente de um cenário de safety. Onde a safety é possível, ordene primeiro pela consequência e depois pela probabilidade dentro da faixa; use o produto, se usar, apenas dentro de uma faixa de consequência. Os métodos orientados por consequências desenvolvidos para a infraestrutura crítica adotam a mesma visão: partir dos desfechos que não podem acontecer (INL CCE).
13.3 Controles existentes e risco residual
Para cada cenário, registre os controles que já o reduzem e se eles foram testados (Capítulo 23). Um controle não testado é uma esperança, e não deveria baixar muito a faixa. O risco residual — o que sobra depois dos controles — precisa de um dono que o tenha aceitado, identificado pelo nome do papel, com uma data de revisão.
Para o R1, o ransomware no historiador, o controle-chave é o armazenamento em buffer dos dados das estações pelo relay enquanto o HIST-01 está fora. Até que esse buffer tenha sido testado parando o historiador de propósito e conferindo quantas horas o relay retém, ele é uma esperança, e a faixa baixa do R1 se apoia nele. O dono do risco residual do R1 seria a operação de Água, porque os relatórios de conformidade são dela.
13.4 Dos cenários ao trabalho
O valor do registro está no trabalho que ele produz. Para cada um dos principais cenários, liste as tarefas de implementação que reduziriam a consequência ou a probabilidade, e o monitoramento que o detectaria em andamento. Um registro que não produz tarefas é um documento; um que produz tarefas com responsáveis é um plano.
Para o R3, o enchimento do disco do relay, o trabalho é concreto: descobrir o que mantém os dados do RLY-01 além de 30 dias, definir um alerta de disco antes do alarme de 85 % e testar o comportamento do buffer quando o disco está cheio. Para o R2, são os controles da conta do fornecedor e o alerta fora de banda de cloro que aparecem como cartões de controle no Capítulo 18.
13.5 Exemplo resolvido: seis cenários de Fallowmere (sintético)
O Laboratório 13 ordena seis cenários. Dois carregam uma marca de safety — uma credencial de fornecedor roubada usada para mudar o setpoint de dosagem da PS-07 (R2), e uma interrupção do gateway clínico que impede as atualizações da biblioteca de medicamentos das bombas de infusão (R4) — e vão para a faixa de consequência 5. Ordenados com a consequência primeiro, R2 e R4 lideram, seguidos pelo enchimento do disco do relay (R3) e pela interrupção da operadora (R6). Ordenados pelo produto, R3 (16) e R6 (12) passam à frente dos dois cenários de safety (10 cada). A ordenação pelo produto mandaria o esforço do próximo trimestre para a capacidade de disco — útil, mas não onde o dano às pessoas é possível.
Note também o R1, o ransomware no historiador, no fim da lista, com consequência 1. Isso reflete o projeto: a telemetria e o controle continuam sem o historiador. Não é um motivo para ignorar o R1 — os relatórios de conformidade e as investigações dependem do historiador —, mas um motivo para confiar na propriedade de projeto do Capítulo 8, se o buffer do relay tiver sido testado.
O R2 merece uma nota. O LANTERN não transporta comandos, então o caminho do R2 não passa pelo LANTERN. Ele passa pelo acesso remoto do fornecedor ao sistema de controle. O registro de riscos de um tecnólogo deve incluir cenários que o serviço não causa, mas precisa detectar ou apoiar: a telemetria do LANTERN é como os operadores notariam uma mudança inesperada na dosagem.
13.6 Atividade prática: ordenação de cenários
Laboratório 13 (salve como lab13.py, execute com python3 lab13.py):
# Lab 13 - a small risk-scenario register ranked by consequence first (offline, standard library only)
# Synthetic: Fallowmere scenarios. Likelihood band 1-5 (judgement), consequence in service units.
scenarios = [ # id, scenario, likelihood band, people affected, hours of disruption, safety flag
("R1", "Ransomware encrypts historian; station data still reaches relay", 3, 0, 0, False),
("R2", "Stolen vendor credential used to change PS-07 dosing setpoint", 2, 41000, 24, True),
("R3", "Relay disk fills; telemetry dropped for remote stations", 4, 41000, 6, False),
("R4", "Clinical gateway outage stops infusion-pump library updates", 2, 300, 72, True),
("R5", "Depot kiosk defaced", 4, 0, 2, False),
("R6", "Upstream carrier outage isolates 6 stations", 3, 18000, 8, False),
]
def consequence_band(people, hours, safety):
ph = people * hours
band = 1 if ph == 0 else 2 if ph < 10_000 else 3 if ph < 100_000 else 4 if ph < 1_000_000 else 5
return 5 if safety else band # any credible safety effect goes to the top band
rows = []
for sid, text, lik, people, hours, safety in scenarios:
c = consequence_band(people, hours, safety)
rows.append((c, lik, sid, text, c * lik))
print("ranked by consequence, then likelihood:")
for c, lik, sid, text, prod in sorted(rows, key=lambda r: (-r[0], -r[1])):
print(f" {sid} C{c} L{lik} CxL={prod:>2} {text}")
print("ranked by CxL product only:")
print(" " + " ".join(sid for c, lik, sid, text, prod in sorted(rows, key=lambda r: -r[4])))
Saída esperada (Python 3.13.5):
ranked by consequence, then likelihood:
R2 C5 L2 CxL=10 Stolen vendor credential used to change PS-07 dosing setpoint
R4 C5 L2 CxL=10 Clinical gateway outage stops infusion-pump library updates
R3 C4 L4 CxL=16 Relay disk fills; telemetry dropped for remote stations
R6 C4 L3 CxL=12 Upstream carrier outage isolates 6 stations
R5 C1 L4 CxL= 4 Depot kiosk defaced
R1 C1 L3 CxL= 3 Ransomware encrypts historian; station data still reaches relay
ranked by CxL product only:
R3 R6 R2 R4 R5 R1
Execute-o e compare as duas ordenações. Com a consequência primeiro, R2 e R4 lideram porque ambos carregam a marca de safety na faixa 5. Pelo produto, R3 com 16 e R6 com 12 os ultrapassam, e o R1 fica no fim de qualquer forma. Depois mude uma entrada que você considere incerta, como a probabilidade do R2, e veja se isso põe o R2 abaixo do R3. Se a ordenação com a consequência primeiro sobreviver à sua mudança e a ordenação pelo produto não, esse é o argumento a pôr diante de quem distribui o trabalho do próximo trimestre.
13.7 Erros comuns e limites
- Escrever categorias em vez de cenários.
- Faixas sem motivos.
- Ordenar pelo produto quando a safety está envolvida.
- Baixar a probabilidade por causa de controles que nunca foram testados.
- Risco residual sem dono.
- Deixar de fora cenários externos ao seu sistema que o seu sistema precisa detectar.
As faixas são julgamentos. O seu valor está em tornar o raciocínio explícito e comparável, e não em medir o risco com precisão.
O Laboratório 13 mostra o terceiro erro: ordenar pelo produto põe a capacidade de disco acima da dosagem de cloro.
Deixar de fora o R2 porque o LANTERN não transporta comandos seria o sexto erro: a telemetria do LANTERN é como os operadores notam uma mudança inesperada na dosagem.
Exercícios — capítulo 13
EX037 — Escreva dois cenários. Objetivo: escrever cenários testáveis. Entradas: o projeto do LANTERN dos Capítulos 2 e 8. Restrições: cada um precisa nomear causa, caminho, ativo, consequência (pessoas e tempo) e controles existentes. Etapas: escreva um cenário sobre a operadora BayTel e um sobre o host de salto da FSTS. Evidência esperada: dois cenários de 80–120 palavras. Rubrica: 3 = específicos, testáveis, consequências em pessoas e tempo, controles nomeados com a situação de teste; 2 = um elemento vago; 1 = categorias; 0 = nada.
EX038 — Produto versus consequência. Objetivo: explicar uma escolha de ordenação a um gestor. Entradas: a saída do Laboratório 13. Restrições: 150 palavras; sem jargão. Etapas: explique por que R2 e R4 devem ser tratados antes do R3, embora o R3 tenha nota maior pelo produto, e do que o R3 ainda precisa. Evidência esperada: parágrafo. Rubrica: 3 = argumento claro sobre o possível dano às pessoas, a irrecuperabilidade e a falha do produto em pesar tudo igualmente; reconhece que o R3 ainda precisa de ação de capacidade (Capítulo 1) e é barato de corrigir; 2 = argumento parcial; 1 = apenas "safety primeiro"; 0 = nada.
EX039 — Do cenário ao trabalho. Objetivo: produzir tarefas de implementação. Entradas: R2 (credencial de fornecedor usada para mudar um setpoint de dosagem). Restrições: tarefas que a FSTS ou a Água conseguem entregar; cada uma com responsável e evidência de conclusão. Etapas: liste três tarefas de prevenção ou redução e duas de detecção. Evidência esperada: tabela. Rubrica: 3 = por exemplo, acesso de fornecedor limitado no tempo com MFA (Capítulo 7), registro das sessões, limites de setpoint no CLP projetados pela Água, alerta de telemetria para mudança de cloro/dosagem fora de uma janela aprovada, e comparação dos valores de setpoint com uma linha de base aprovada; responsáveis e evidências nomeados; 2 = tarefas genéricas; 1 = menos de três; 0 = nada.
Síntese do capítulo
Escreva os riscos como cenários específicos — causa, caminho, ativo, consequência e controles —, para que possam ser testados e monitorados. Meça a consequência em pessoas e tempo, ponha os efeitos críveis de safety no topo e ordene com a consequência primeiro; o produto probabilidade × consequência pode deixar incômodos passarem à frente do dano. Dê um dono ao risco residual, inclua os cenários que o seu serviço precisa detectar e transforme o registro em tarefas.
Continue estudando — capítulo 13 de 30
← Capítulo 12 · Índice de capítulos do curso · Capítulo 14 →
Siga para a próxima lição escrita.