Capítulo 11 — Redes e protocolos | Engenharia 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 11 publicada. Mapa, exemplo, EX022.

flowchart TD
  N0["11.1 As camadas e o que elas prometem"]
  N1["11.2 Protocolos industriais"]
  N2["11.3 Latência, jitter e varredura cíclica polling"]
  N3["11.4 Zonas, condutos e listas de permissões"]
  N4["11.6 Atividade prática: Laboratório 5"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX022"]

Desenho lógico

flowchart LR
  N0["11.1 As camadas e o que elas prometem"]
  N1["11.2 Protocolos industriais"]
  N2["11.3 Latência, jitter e varredura cíclica polling"]
  N3["11.4 Zonas, condutos e listas de permissões"]
  N4["11.6 Atividade prática: Laboratório 5"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]

[11.1 As camadas e o que elas prometem]
    |
    v
[11.2 Protocolos industriais]
    |
    v
[11.3 Latência, jitter e varredura cíclica polling]
    |
    v
[11.4 Zonas, condutos e listas de permissões]
    |
    v
[11.6 Atividade prática: Laboratório 5]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX022]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) explicar o modelo em camadas e os papéis de Ethernet, IP, TCP, UDP e dos protocolos de aplicação; (2) descrever protocolos industriais (Modbus/TCP, DNP3, IEC 60870-5-104, OPC UA) e quais propriedades de segurança cada um oferece ou não oferece; (3) montar um orçamento de latência para a telemetria; e (4) expressar a segmentação como zonas e condutos e conferir os fluxos observados contra ela. Ele se apoia nos capítulos 3 e 4 e prepara os capítulos 18 (arquitetura de segurança) e 26 (alternativas de arquitetura).

11.1 As camadas e o que elas prometem

As redes são construídas em camadas: física e de enlace (quadros Ethernet num segmento), de rede (pacotes IP roteados entre segmentos), de transporte (o TCP, com fluxos de bytes confiáveis e ordenados; o UDP, com datagramas sem garantia de entrega — o TCP é especificado na RFC 9293) e de aplicação (o protocolo que carrega o significado). Cada camada promete algo limitado. O TCP garante ordem e retransmissão, não autenticidade. O IP roteia, mas endereços de origem podem ser forjados em muitas redes. As propriedades de segurança precisam ser acrescentadas deliberadamente, em geral com TLS (RFC 8446), IPsec ou autenticação na camada de aplicação.

11.2 Protocolos industriais

Os protocolos industriais clássicos foram projetados para redes seriais fechadas. O Modbus/TCP (porta 502) transporta códigos de função, como leitura e escrita de registradores, sem autenticação; qualquer um que alcance a porta 502 pode emitir escritas. O DNP3 é amplamente usado em água e eletricidade; sua extensão Secure Authentication acrescenta autenticação por desafio e resposta para comandos críticos, mas não está implantada universalmente. O IEC 60870-5-104 é comum nos sistemas elétricos europeus, com extensões de segurança definidas na IEC 62351. O OPC UA foi projetado com modos de segurança que oferecem assinatura e cifração, mas eles precisam ser configurados — "None" é uma política válida. A lição é consistente: capacidade do protocolo não é implantação. Verifique o que está configurado.

11.3 Latência, jitter e varredura cíclica (polling)

A telemetria costuma ser consultada ciclicamente: o mestre SCADA interroga cada RTU por vez. A latência de ponta a ponta, de um evento físico até a tela de um operador, é a soma da atualização do sensor, da varredura da RTU, da ida e volta no enlace, da espera pela consulta do mestre, do processamento e da atualização da tela. O jitter é a variação da latência. Escreva um orçamento, meça cada elemento e compare o total com o requisito; o Capítulo 36 acrescenta as filas. O orçamento da LRWA no Laboratório 5 soma a varredura da RTU, a ida e volta na LTE, a espera pela consulta e a atualização da tela para chegar a um segundo, contra um requisito de 1,5 segundo, mas a espera pela consulta é o elemento que mais varia, e o EX022 mostra como ela domina o pior caso.

11.4 Zonas, condutos e listas de permissões

A segmentação divide uma rede em zonas com requisitos de segurança semelhantes e controla os condutos entre elas. Esse vocabulário vem da série ISA/IEC 62443. Uma política de conduto é uma lista de permissões (allowlist): zona de origem, zona de destino, protocolo e porta específicos, e todo o resto negado. Verificar não é ler a configuração do firewall; é conferir os fluxos observados contra a política pretendida, porque as configurações derivam e caminhos não documentados (o modem de acesso remoto de um fornecedor, um laptop com duas interfaces de rede) contornam os firewalls. A revisão de fluxos da LRWA, abaixo, mostra por quê.

11.5 Exemplo resolvido: revisão de fluxos da LRWA (sintético)

A LRWA define as zonas: enterprise (corporativa), dmz, control (servidores SCADA), field (RTUs) e eng (estações de engenharia). Os condutos pretendidos estão listados no Laboratório 5. Uma semana de registros de fluxo mostra três violações: um host corporativo falando Modbus diretamente com uma RTU de campo (um script de relatório esquecido que contorna a DMZ), uma estação de engenharia abrindo SSH diretamente para uma RTU em vez de passar pelo jump host da zona de controle, e um servidor SCADA fazendo consultas DNS a um resolvedor público. Cada uma é uma constatação com um dono: remover o script e servir seus dados a partir do historiador da DMZ; encaminhar o acesso de engenharia pelo jump host; apontar o DNS do SCADA para um resolvedor interno, ou para nenhum.

11.6 Atividade prática: Laboratório 5

# Lab 5 - check observed flows against a zone-conduit allowlist (synthetic, offline)
RULES = [  # (src_zone, dst_zone, protocol, port)
    ("control", "field", "tcp", 502), ("control", "dmz", "tcp", 443), ("dmz", "enterprise", "tcp", 443),
    ("eng", "control", "tcp", 22), ("field", "control", "udp", 20000)]
ZONE = {"10.1.0.": "control", "10.2.0.": "field", "10.3.0.": "dmz", "10.4.0.": "enterprise", "10.5.0.": "eng"}
def zone(ip): return next((z for p, z in ZONE.items() if ip.startswith(p)), "unknown")
FLOWS = [("10.1.0.5", "10.2.0.31", "tcp", 502), ("10.4.0.77", "10.2.0.31", "tcp", 502),
         ("10.2.0.31", "10.1.0.5", "udp", 20000), ("10.3.0.9", "10.4.0.20", "tcp", 443),
         ("10.5.0.12", "10.2.0.33", "tcp", 22), ("10.1.0.5", "8.8.8.8", "udp", 53),
         ("10.1.0.6", "10.3.0.9", "tcp", 443)]
for s, d, p, port in FLOWS:
    ok = (zone(s), zone(d), p, port) in RULES
    print(f"{s:>10} {zone(s):>10} -> {d:<10} {zone(d):<10} {p}/{port:<5} {'allowed' if ok else 'VIOLATION'}")
budget = {"rtu_scan": 120, "lte_rtt": 180, "scada_poll_wait": 500, "operator_view": 200}
print("end-to-end latency budget ms:", sum(budget.values()), "vs requirement 1500")

Saída esperada:

  10.1.0.5    control -> 10.2.0.31  field      tcp/502   allowed
 10.4.0.77 enterprise -> 10.2.0.31  field      tcp/502   VIOLATION
 10.2.0.31      field -> 10.1.0.5   control    udp/20000 allowed
  10.3.0.9        dmz -> 10.4.0.20  enterprise tcp/443   allowed
 10.5.0.12        eng -> 10.2.0.33  field      tcp/22    VIOLATION
  10.1.0.5    control -> 8.8.8.8    unknown    udp/53    VIOLATION
  10.1.0.6    control -> 10.3.0.9   dmz        tcp/443   allowed
end-to-end latency budget ms: 1000 vs requirement 1500

Três dos sete fluxos são violações, e cada uma corresponde a uma constatação do exemplo resolvido: o script de relatório corporativo falando Modbus com uma RTU de campo, a estação de engenharia abrindo SSH diretamente para uma RTU em vez de passar pelo jump host, e um servidor SCADA consultando um resolvedor DNS público. A linha do orçamento de latência mostra um total de um segundo contra o requisito de 1,5 segundo, mas esse valor usa valores típicos, então trate-o como ponto de partida para a análise de pior caso do EX022, e não como evidência de que R7 foi atendido.

11.7 Erros comuns e limites

Igualar a cifração numa camada à proteção de ponta a ponta.
Supor que a segurança opcional de um protocolo industrial está habilitada.
Verificar a segmentação apenas lendo configurações.
Orçamentos de latência com médias em vez de piores casos.
Listas de permissões por host em vez de por função, que se tornam impossíveis de manter.

A revisão de fluxos da LRWA ilustra diretamente o terceiro erro: a configuração do firewall parecia correta, mas uma semana de registros de fluxo mostrou três violações. Ler as configurações não teria encontrado nenhuma delas. Listas de permissões escritas por host também teriam exigido edições constantes à medida que as RTUs fossem acrescentadas.

Exercícios — capítulo 11

EX021 — Estenda a verificação da política. Objetivo: encontrar violações por função. Entradas: Laboratório 5. Passos: (1) acrescente um fluxo de 10.2.0.31 para 10.4.0.77 em TCP/445; (2) acrescente uma regra para que a estação de engenharia só alcance as RTUs por um jump host na zona de controle, e modele os dois saltos; (3) execute de novo e relate. Evidência esperada: mudanças no código e saída. Rubrica: 3 = nova violação detectada, modelo de dois saltos correto, nenhuma regra enfraquece a proteção do campo; 2 = um problema; 1 = não executado; 0 = nada.

EX022 — Latência contra o requisito. Objetivo: orçar a latência de pior caso. Entradas: varredura da RTU de 120 ms, ida e volta na LTE de 180 ms típicos / 900 ms no percentil 99, espera pela consulta de até um ciclo completo de 1,3 s (Laboratório 13), atualização da tela do operador de 200 ms; requisito: 95% dos alarmes na tela em até 1,5 s e todos em até 5 s. Passos: calcule os totais típico e de pior caso; julgue as duas cláusulas; proponha uma mudança de projeto. Evidência esperada: tabela. Rubrica: 3 = somas corretas, espera pela consulta reconhecida como dominante, mudança proposta (relato por exceção ou alarmes não solicitados); 2 = uma soma errada; 1 = apenas o típico; 0 = nada.

Síntese do capítulo

Cada camada de rede promete algo estreito; a autenticidade precisa ser acrescentada. Os protocolos industriais variam em capacidade de segurança, e capacidade não é configuração. Orce a latência com piores casos. Expresse a segmentação como zonas e condutos com listas de permissões e verifique-a contra os fluxos observados, e não contra as configurações pretendidas.