## Capítulo 5 — Infraestrutura crítica e segurança setorial: alternativas de projeto ### Mapa da aula Aula 05 publicada. Mapa, exemplo, EX021. ```mermaid flowchart TD N0["5.1 Partir da consequência"] N1["5.2 Princípios que geram alternativas"] N2["5.3 Projetos como grafos"] N3["5.4 Projetos como sistemas operáveis"] N4["5.6 Atividade prática: caminhos e pontos de estrangu"] N5["5.7 Escolher e registrar"] N6["Síntese do capítulo"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 N6 --> EX["Exemplo resolvido"] EX --> Q["Exercício EX021"] ``` ### Desenho lógico ```mermaid flowchart LR N0["5.1 Partir da consequência"] N1["5.2 Princípios que geram alternativas"] N2["5.3 Projetos como grafos"] N3["5.4 Projetos como sistemas operáveis"] N4["5.6 Atividade prática: caminhos e pontos de estrangu"] N5["5.7 Escolher e registrar"] N6["Síntese do capítulo"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"] ``` ```text [5.1 Partir da consequência] | v [5.2 Princípios que geram alternativas] | v [5.3 Projetos como grafos] | v [5.4 Projetos como sistemas operáveis] | v [5.6 Atividade prática: caminhos e pontos de estrangu] | v [5.7 Escolher e registrar] | v [Síntese do capítulo] | v [Exemplo resolvido] --> [Exercício EX021] ``` ### Objetivos de aprendizagem e conexão Ao final deste capítulo, você deverá ser capaz de: 1. Gerar alternativas de arquitetura genuinamente diferentes para um problema de segurança num serviço essencial, partindo das consequências, e não dos produtos. 2. Representar as alternativas como grafos de caminhos permitidos e compará-las pelos caminhos, pelos pontos de estrangulamento e pelas barreiras em cada caminho. 3. Avaliar cada alternativa como um sistema operável: os modos de falha dos próprios controles de segurança, o acesso de emergência (break-glass), a manutenibilidade e a força de trabalho que precisa operá-la. 4. Combinar as evidências de segurança, operabilidade e custo numa recomendação, usando os métodos de decisão dos Capítulos 1 e 4. 5. Registrar a escolha num registro de decisão de arquitetura. O Capítulo 4 quantificou o risco; este capítulo mostra onde as escolhas de projeto o mudam. O Capítulo 6 testa, então, se um projeto escolhido funciona como alegado. ### 5.1 Partir da consequência As revisões de arquitetura muitas vezes partem de um produto ("devemos comprar um diodo de dados?") ou de um padrão ("precisamos de zero trust"). Um especialista parte da **consequência a ser evitada** e volta até os caminhos digitais que poderiam causá-la. A engenharia orientada pela consequência e informada pelo cibernético (CCE), desenvolvida no Idaho National Laboratory, formaliza isso: identificar as funções cuja falha seria intolerável, mapear os sistemas e as dependências que poderiam causá-la e escolher mitigações de engenharia — inclusive não digitais, como limites mecânicos — que eliminem ou limitem a consequência ([INL, CCE](https://inl.gov/national-security/cce/); [Bochman e Freeman, 2021](https://www.routledge.com/Countering-Cyber-Sabotage-Introducing-Consequence-Driven-Cyber-Informed-Engineering-CCE/Bochman-Freeman/p/book/9780367673710)). Para a estação de Hollin da Merrow Water, a consequência intolerável é uma dose insegura de cloro chegando aos clientes; a pergunta de projeto é como o acesso remoto ao controlador de dosagem deve funcionar, se é que deve existir. A mitigação não digital merece o primeiro lugar no conjunto de opções. Uma bomba dosadora dimensionada de modo que fisicamente não consiga exceder uma dose segura, ou um analisador independente que desarma a dosagem num limite rígido, limita a consequência aconteça o que acontecer com a rede. Os controles digitais são então escolhidos para reduzir a frequência das tentativas contra o que resta. ### 5.2 Princípios que geram alternativas Os princípios clássicos de projeto ainda geram boas alternativas: economia de mecanismo, padrões à prova de falhas (fail-safe defaults), mediação completa e menor privilégio ([Saltzer e Schroeder, 1975](https://doi.org/10.1109/PROC.1975.9939)). A IEC 62443 os aplica aos sistemas de controle por meio de **zonas** (grupos de ativos com requisitos de segurança comuns) e **conduítes** (a comunicação controlada entre as zonas) ([visão geral da ISA](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)). A arquitetura zero trust desloca a aplicação das regras da localização na rede para decisões por sessão sobre identidade, dispositivo e contexto ([NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)). A engenharia de ciber-resiliência acrescenta técnicas — segmentação, não persistência, diversidade, redundância, integridade comprovada — voltadas a operar através do comprometimento, e não apenas a evitá-lo ([NIST SP 800-160 Vol. 2 Rev. 1](https://doi.org/10.6028/NIST.SP.800-160v2r1)). Cada princípio aponta para um projeto diferente; usar vários deliberadamente produz alternativas que diferem em natureza. ### 5.3 Projetos como grafos Uma representação simples e poderosa: os nós são sistemas, as arestas direcionadas são conexões permitidas e cada aresta carrega a barreira que um intruso precisa vencer para usá-la. Três medidas comparam então os projetos: - **Número de caminhos** desde os pontos de entrada plausíveis até o ativo que carrega a consequência. Menos é melhor, mas apenas junto com a medida seguinte. - **Menor conjunto de pontos de estrangulamento** — o menor número de nós cuja remoção (ou defesa perfeita) corta todos os caminhos. Um único ponto de estrangulamento forte é mais fácil de defender, monitorar e evidenciar do que vários fracos; é também um ponto único de falha para as operações legítimas (§5.4). - **Força das barreiras ao longo de cada caminho** — um caminho cujas arestas depois da entrada inicial não têm barreira ("none") permite que um único ponto de apoio vire controle. O grafo deve incluir os **caminhos inesperados** que os ambientes reais contêm: conexões do historiador, links de backup, modems de fornecedores, agentes de monitoramento em nuvem. Muitas fraquezas de arquitetura não estão no projeto pretendido, mas no caminho que alguém acrescentou depois por conveniência. A análise de grafos não prova a segurança; ela torna os pressupostos explícitos e contáveis. ### 5.4 Projetos como sistemas operáveis Um projeto seguro no papel pode fracassar na operação. Para cada alternativa, pergunte: 1. **O que acontece quando o controle de segurança falha?** Se o intermediador de acesso estiver fora do ar durante uma emergência noturna, como um engenheiro chega ao controlador? Um caminho de **acesso de emergência (break-glass)** — credenciais lacradas, presença física, uma rota de emergência registrada e alarmada — precisa existir e ser testado, ou os operadores construirão o seu próprio. 2. **Quem o opera?** Um projeto que exige competências que a organização não tem, ou um fornecedor que ela não consegue responsabilizar, vai se degradar. 3. **Como ele é alterado?** Toda exceção a uma regra é uma nova aresta no grafo; projetos que tornam fácil o trabalho legítimo reduzem a pressão por exceções. 4. **Quanto ele custa ao longo da vida?** Licenças, pessoal, testes, renovações. 5. **O que ele faz com o monitoramento?** Fluxos de dados unidirecionais podem proteger uma rede de controle e ainda permitir que o negócio veja os dados do processo; eles também limitam o diagnóstico remoto. ### 5.5 Exemplo resolvido: três projetos de acesso remoto em Hollin (sintético) A Merrow Water tem três projetos candidatos para o acesso remoto à rede de controle de Hollin: - **D1 VPN plana** — o arranjo atual: a VPN de fornecedores e funcionários cai diretamente na rede de controle; o historiador é alcançável a partir da rede corporativa. - **D2 VPN mais jump host** — MFA na VPN; todo acesso interativo passa por um jump host endurecido; o historiador é transferido para uma DMZ. - **D3 acesso intermediado com historiador unidirecional** — acesso remoto apenas por meio de um intermediador de acesso que exige MFA e aprovação por sessão, com sessões gravadas e limitadas no tempo, chegando a uma única estação de engenharia; o historiador se replica para a DMZ por um link unidirecional; a chave seletora do controlador de dosagem é deixada em RUN, o que (neste controlador sintético) bloqueia o download de programas. Dois pontos de entrada são modelados: a internet e um e-mail de phishing que chega a um PC corporativo. ### 5.6 Atividade prática: caminhos e pontos de estrangulamento ```python # Lab 5 - comparing three remote-access architectures as graphs (offline, standard library only) # Synthetic: paths from the internet to the dosing PLC at Merrow Water's Hollin works under three designs. # An edge is a permitted connection; its label is what an intruder must defeat to use it. from itertools import combinations DESIGNS = { "D1 flat VPN": { "internet": [("vpn", "password")], "vpn": [("hmi", "none"), ("eng-ws", "none"), ("historian", "none")], "corp-pc": [("vpn", "none"), ("historian", "password")], "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "historian": [("hmi", "none")], "email": [("corp-pc", "user click")], "plc": []}, "D2 VPN + jump host": { "internet": [("vpn", "MFA")], "vpn": [("jump", "password")], "corp-pc": [("jump", "password"), ("historian-dmz", "password")], "jump": [("hmi", "password"), ("eng-ws", "password")], "historian-dmz": [("historian", "none")], "historian": [("hmi", "none")], "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "email": [("corp-pc", "user click")], "plc": []}, "D3 brokered access + one-way historian": { "internet": [("broker", "MFA + per-session approval")], "broker": [("eng-ws", "recorded session, time-boxed")], "corp-pc": [("broker", "MFA + per-session approval")], "historian": [("historian-dmz", "one-way")], # data leaves OT only; nothing flows back "eng-ws": [("plc", "PLC key switch in RUN blocks writes")], "hmi": [("plc", "none")], "email": [("corp-pc", "user click")], "historian-dmz": [], "plc": []}, } ENTRY, TARGET = ["internet", "email"], "plc" def paths(g, node, seen): if node == TARGET: yield [node]; return for nxt, _ in g.get(node, []): if nxt not in seen: for rest in paths(g, nxt, seen | {nxt}): yield [node] + rest def reachable(g, removed): stack = [e for e in ENTRY if e not in removed]; seen = set(stack) while stack: n = stack.pop() for nxt, _ in g.get(n, []): if nxt not in seen and nxt not in removed: seen.add(nxt); stack.append(nxt) return TARGET in seen for name, g in DESIGNS.items(): ps = [p for e in ENTRY for p in paths(g, e, {e})] inner = sorted({n for n in g if n not in ENTRY + [TARGET]}) cut = next(c for k in range(1, len(inner) + 1) for c in combinations(inner, k) if not reachable(g, set(c))) free = [p for p in ps if all(lbl == "none" for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b and a not in ENTRY)] print(f"{name}: {len(ps)} paths; smallest chokepoint set {list(cut)}; " f"paths with no barrier after the first hop: {len(free)}") for p in ps: bars = [lbl for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b] print(" ", " -> ".join(p), "|", ", ".join(bars)) ``` Saída esperada: ```text D1 flat VPN: 7 paths; smallest chokepoint set ['corp-pc', 'vpn']; paths with no barrier after the first hop: 6 internet -> vpn -> hmi -> plc | password, none, none internet -> vpn -> eng-ws -> plc | password, none, none internet -> vpn -> historian -> hmi -> plc | password, none, none, none email -> corp-pc -> vpn -> hmi -> plc | user click, none, none, none email -> corp-pc -> vpn -> eng-ws -> plc | user click, none, none, none email -> corp-pc -> vpn -> historian -> hmi -> plc | user click, none, none, none, none email -> corp-pc -> historian -> hmi -> plc | user click, password, none, none D2 VPN + jump host: 5 paths; smallest chokepoint set ['corp-pc', 'jump']; paths with no barrier after the first hop: 0 internet -> vpn -> jump -> hmi -> plc | MFA, password, password, none internet -> vpn -> jump -> eng-ws -> plc | MFA, password, password, none email -> corp-pc -> jump -> hmi -> plc | user click, password, password, none email -> corp-pc -> jump -> eng-ws -> plc | user click, password, password, none email -> corp-pc -> historian-dmz -> historian -> hmi -> plc | user click, password, none, none, none D3 brokered access + one-way historian: 2 paths; smallest chokepoint set ['broker']; paths with no barrier after the first hop: 0 internet -> broker -> eng-ws -> plc | MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes email -> corp-pc -> broker -> eng-ws -> plc | user click, MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes ``` **Interpretação.** O D1 tem sete caminhos; em seis deles, nada fica entre o primeiro ponto de apoio e o controlador. Seu menor conjunto de pontos de estrangulamento tem dois nós. O D2 elimina todos os caminhos sem barreira e acrescenta MFA, mas o grafo expõe uma falha que o documento de projeto não mencionava: o caminho `corp-pc → historian-dmz → historian → hmi → plc`. Transferir o historiador para uma DMZ e deixar uma conexão *da DMZ para dentro* do historiador da zona de controle recria uma rota que contorna o jump host. É exatamente o tipo de aresta de conveniência contra o qual a §5.3 advertiu; o EX021 a corrige. O D3 tem dois caminhos, ambos passando por um único ponto de estrangulamento (o intermediador), e cada um atravessa várias barreiras fortes. Do ponto de vista da segurança, o D3 é claramente o melhor. Do ponto de vista da operabilidade, o ponto de estrangulamento único do D3 é também sua fraqueza. Se o intermediador ou seu provedor de identidade falhar durante uma emergência, não existe nenhum caminho remoto; o projeto precisa, portanto, de uma rota de acesso de emergência testada, que é ela mesma uma nova aresta a modelar e proteger. A barreira da chave seletora só é real se os procedimentos operacionais mantiverem as chaves em RUN e se uma visita ao local for aceitável para as mudanças de programa. Uma recomendação completa acrescentaria isso ao custo e ao grafo. ### 5.7 Escolher e registrar Reúna as evidências com os métodos do Capítulo 1: uma tabela de cenários para cada projeto (incidentes evitados, custos operacionais de um acesso mais lento, cenários de indisponibilidade do intermediador) e a verificação distributiva do Capítulo 4 (algum projeto torna os locais remotos mais difíceis de atender?). Depois, escreva um **registro de decisão de arquitetura (ADR)**: o contexto, a consequência tratada, as alternativas consideradas com seus grafos, a decisão, as consequências (incluindo riscos novos, como a dependência do intermediador), o projeto do acesso de emergência, as evidências que mostrarão que o projeto está funcionando (Capítulo 6) e um gatilho de revisão. Um ADR é um registro de decisão (§1.8) especializado para projetos; seu valor é que o próximo engenheiro que quiser acrescentar uma aresta conveniente possa ver por que ela não estava lá. ### 5.8 Erros comuns e limites - Partir de um produto ou de um slogan, e não da consequência. - Omitir as mitigações não digitais que limitam a consequência de uma vez. - Desenhar o projeto pretendido e deixar de ver os caminhos acrescentados depois. - Contar controles em vez de examinar as barreiras ao longo de cada caminho. - Celebrar um ponto de estrangulamento único sem projetar para a sua falha. - Ignorar quem vai operar o projeto e como as exceções serão tratadas. - Não escrever nenhum registro de decisão, de modo que a próxima mudança desfaça o projeto em silêncio. Os grafos são tão completos quanto o inventário por trás deles, e os rótulos das barreiras são julgamentos de força, não medições. Use-os para comparar projetos e expor pressupostos e, depois, teste o projeto escolhido (Capítulo 6). ### Exercícios — capítulo 5 **EX021 — Corrija o D2.** *Objetivo:* eliminar um caminho não pretendido e reavaliar. *Insumos:* Laboratório 5. *Restrições:* mudar apenas os links do historiador no D2, de modo que os dados fluam num único sentido, do historiador da zona de controle para a cópia na DMZ, como no D3. *Passos:* (1) editar e reexecutar; (2) relatar os caminhos e o menor conjunto de pontos de estrangulamento do D2; (3) comparar o D2 corrigido com o D3 em duas frases. *Evidência esperada:* edição, saída e comparação. *Rubrica:* 3 = edição correta, o D2 agora com quatro caminhos e ponto de estrangulamento `jump`, a comparação aponta os saltos do D2 protegidos apenas por senha, em contraste com a aprovação por sessão e a gravação do D3; 2 = números certos, comparação rasa; 1 = não executado; 0 = nada. **EX022 — Uma nova aresta.** *Objetivo:* avaliar uma proposta de conveniência. *Insumos:* D3; a Corvane propõe um agente de monitoramento em nuvem na estação de engenharia que mantém uma conexão de saída com a nuvem da Corvane "para diagnóstico". *Restrições:* modelá-lo como uma aresta `internet → eng-ws` com a barreira "vendor cloud account". *Passos:* (1) acrescentar a aresta e reexecutar; (2) relatar os caminhos e os pontos de estrangulamento; (3) propor uma alternativa que atenda à necessidade de diagnóstico. *Evidência esperada:* saída e proposta. *Rubrica:* 3 = reconhece que o conjunto de pontos de estrangulamento muda porque um caminho agora contorna o intermediador, propõe uma alternativa (por exemplo, diagnóstico exportado pelo historiador unidirecional, ou o agente num host da DMZ), declara o risco residual; 2 = saída certa, alternativa fraca; 1 = aceita a aresta como segura por ser apenas de saída; 0 = nada. **EX023 — Projeto do acesso de emergência.** *Objetivo:* projetar para a falha do ponto de estrangulamento. *Insumos:* D3. *Restrições:* precisa funcionar quando o intermediador e o provedor de identidade estiverem fora do ar; não pode se tornar um caminho de rotina. *Passos:* (1) projetar a rota de acesso de emergência; (2) acrescentá-la ao grafo; (3) especificar os alarmes, os registros e a frequência de testes. *Evidência esperada:* projeto e lista de caminhos atualizada. *Rubrica:* 3 = rota física ou com credenciais lacradas, com alarmes e revisão depois do uso, modelada como uma aresta com sua barreira, testada segundo um cronograma; 2 = sem testes; 1 = senha permanente compartilhada; 0 = nada. **EX024 — Escolha com evidências.** *Objetivo:* combinar segurança e operabilidade. *Insumos:* D1, D2 corrigido e D3 com acesso de emergência; custos anuais sintéticos de £20 mil, £70 mil e £110 mil; seu julgamento das perdas por cenário no formato do Capítulo 1. *Restrições:* pelo menos três cenários, incluindo a indisponibilidade do intermediador durante uma emergência. *Passos:* (1) montar a tabela; (2) aplicar o VE e o arrependimento minimax; (3) declarar o limiar que mudaria a sua recomendação. *Evidência esperada:* tabela e recomendação. *Rubrica:* 3 = cenários plausíveis e que incluem as desvantagens operacionais do D3, as duas regras aplicadas corretamente, limiar explícito; 2 = só uma regra; 1 = apenas segurança; 0 = nada. **EX025 — Registro de decisão de arquitetura.** *Objetivo:* registrar a escolha de projeto. *Insumos:* sua recomendação do EX024. *Restrições:* uma página; todos os elementos da §5.7. *Passos:* escrever o ADR. *Evidência esperada:* ADR. *Rubrica:* 3 = contexto que parte da consequência, alternativas com evidências dos grafos, riscos novos e acesso de emergência, evidências de verificação e gatilho de revisão; 2 = falta um elemento; 1 = descrição de produto; 0 = nada. ### Síntese do capítulo Projete a partir da consequência, de trás para a frente, e coloque os limites não digitais em primeiro lugar. Use princípios estabelecidos — menor privilégio, mediação completa, zonas e conduítes, decisões por sessão, técnicas de resiliência — para gerar alternativas que diferem em natureza. Represente os projetos como grafos de caminhos permitidos e compare caminhos, pontos de estrangulamento e barreiras, incluindo as arestas de conveniência que os ambientes reais acumulam. Avalie cada projeto como um sistema operável, projetando para a falha de seus próprios controles. Escolha com os métodos de decisão dos capítulos anteriores e registre a escolha num ADR, para que ela sobreviva ao próximo pedido de mudança. ### Continue estudando — capítulo 05 de 12 [← Capítulo 04](#ch-04) · [Índice de capítulos do curso](../SUBJECTS.md) · [Capítulo 06 →](#ch-06) Siga para a próxima lição escrita. ## Worked answers **EX021 — Corrija o D2.** Tornar o historiador unidirecional para fora da zona de controle deixa o D2 com quatro caminhos e um único ponto de estrangulamento, `jump`. Em comparação com o D3: o D2 ainda depende de saltos protegidos por senha depois do MFA; o D3 acrescenta a aprovação por sessão e a gravação. O D3 continua mais forte em segurança; o D2 corrigido é uma melhoria clara em relação ao D2. **EX022 — Uma nova aresta.** Acrescentar `internet → eng-ws` com a barreira "vendor cloud account" dá ao D3 três caminhos e move o ponto de estrangulamento para `eng-ws`, contornando o intermediador. Alternativa: exportar o diagnóstico pelo historiador unidirecional para um host da DMZ que o fornecedor possa ver, ou um agente do fornecedor apenas nesse host da DMZ. Risco residual: mau uso do canal de saída — monitorar e usar lista de permissões. **EX023 — Projeto do acesso de emergência.** Presença física com um envelope de credenciais lacrado, ou uma conta local de emergência alarmada e revisada depois de cada uso; testada trimestralmente; modelada como uma aresta com barreira forte e detecção. Nunca uma senha permanente compartilhada. **EX024 — Escolha com evidências.** Uma tabela de nota máxima inclui comprometimento de TO, ransomware, indisponibilidade do fornecedor, indisponibilidade do intermediador durante uma emergência e ano tranquilo; aplica o VE e o arrependimento minimax; declara um limiar (por exemplo, probabilidade de indisponibilidade do intermediador acima de X% → preferir o D2 corrigido). Os números podem variar; é a estrutura que recebe o crédito. **EX025 — Registro de decisão de arquitetura.** Contexto: a consequência da dose insegura. Alternativas com as evidências de caminhos e de pontos de estrangulamento. Decisão (declare a sua). Consequências, incluindo a dependência do intermediador. Acesso de emergência. Evidências de verificação (Capítulo 6). Gatilho de revisão (por exemplo, a proposta de um agente do fornecedor).