Capítulo 30 — Laboratório II

Mapa da aula

Aula 30 publicada. Mapa, exemplo, EX088.

flowchart TD
  N0["30.1 A linha de base"]
  N1["30.2 Lendo o resultado da frota"]
  N2["30.3 Priorizando"]
  N3["30.5 Reproduzindo e ampliando o laboratório"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX088"]

Desenho lógico

flowchart LR
  N0["30.1 A linha de base"]
  N1["30.2 Lendo o resultado da frota"]
  N2["30.3 Priorizando"]
  N3["30.5 Reproduzindo e ampliando o laboratório"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX088"]

[30.1 A linha de base]
    |
    v
[30.2 Lendo o resultado da frota]
    |
    v
[30.3 Priorizando]
    |
    v
[30.5 Reproduzindo e ampliando o laboratório]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX088]

Objetivos de aprendizagem

Você vai (1) avaliar uma frota IoT sintética contra provisões selecionadas da ETSI EN 303 645; (2) relatar as lacunas por dispositivo e da frota inteira; (3) relacionar as provisões com as atividades do fabricante do NIST IR 8259; e (4) priorizar a remediação.

30.1 A linha de base

A ETSI EN 303 645 V2.1.1 fixa 13 provisões de cibersegurança para IoT de consumo, mais provisões de proteção de dados. Este laboratório verifica quatro: 5.1 (nenhuma senha padrão universal), 5.2 (implementar um meio de gerenciar relatos de vulnerabilidades), 5.3 (manter o software atualizado) e 5.5 (comunicar-se com segurança). O NIST IR 8259 cobre um terreno parecido pelo lado do processo do fabricante — por exemplo, planejar atualizações e comunicar-se com os clientes.

"""Lab 30: score a synthetic IoT meter fleet against selected ETSI EN 303 645 provisions."""
fleet = {"MTR-A": {"unique_pw": True, "vuln_policy": True, "update": True, "tls": True},
         "MTR-B": {"unique_pw": False, "vuln_policy": True, "update": True, "tls": True},
         "MTR-C": {"unique_pw": True, "vuln_policy": False, "update": False, "tls": False}}
PROV = {"unique_pw": "5.1 no universal default passwords", "vuln_policy": "5.2 vulnerability disclosure",
        "update": "5.3 software updatable", "tls": "5.5 secure communication"}
for dev, f in fleet.items():
    miss = [PROV[k] for k, v in f.items() if not v]
    print(f"{dev}: {4-len(miss)}/4 met; missing: {miss or 'none'}")
print("fleet-wide gaps:", sorted({k for f in fleet.values() for k, v in f.items() if not v}))

Execute com python3 lab_fleet.py. Saída verificada:

MTR-A: 4/4 met; missing: none
MTR-B: 3/4 met; missing: ['5.1 no universal default passwords']
MTR-C: 1/4 met; missing: ['5.2 vulnerability disclosure', '5.3 software updatable', '5.5 secure communication']
fleet-wide gaps: ['tls', 'unique_pw', 'update', 'vuln_policy']

Os três modelos de medidor do laboratório respondem a um pequeno questionário sobre essas quatro provisões; o script relata quais cada um atende e o que falta à frota.

30.2 Lendo o resultado da frota

O MTR-A atende às quatro. O MTR-B falha apenas na 5.1 — corrigível forçando credenciais únicas na instalação. O MTR-C falha em três provisões: nenhuma política de divulgação, nenhum mecanismo de atualização e nenhuma comunicação segura. A lista de lacunas da frota inteira contém as quatro provisões, o que parece alarmante, mas é causado por apenas dois modelos; relate as duas visões.

A visão por dispositivo diz a Maya o que corrigir em cada modelo de medidor, enquanto a visão da frota diz ao gestor da LDHP quais provisões faltam em algum ponto do parque. Ler apenas a lista da frota sugeriria quatro problemas distintos em todos os medidores, quando o MTR-A está limpo e três das quatro lacunas estão só no MTR-C.

30.3 Priorizando

A severidade depende da consequência e da facilidade de correção. A falta de capacidade de atualização do MTR-C é estrutural — ele não pode receber patches —, então o planejamento da substituição começa agora. A senha padrão do MTR-B é o vetor clássico do Mirai (Capítulo 20) e é urgente, mas barata. A tabela de remediação de Maya segue essa ordem. O MTR-B é corrigido em duas semanas, na próxima visita de leitura dos medidores. O MTR-C recebe controles compensatórios imediatamente, isolamento atrás do gateway com o TLS terminado ali, e uma substituição programada para dentro de 12 meses, porque a 5.3 não pode ser atendida por nenhuma mudança de configuração. O MTR-A não precisa de nada agora, mas é verificado de novo sempre que o seu firmware muda, já que um resultado aprovado descreve uma única versão.

30.4 Limites da avaliação por lista de verificação

"Atende à 5.3", neste laboratório, é um booleano vindo de um questionário. Uma avaliação real verifica evidências: o mecanismo de atualização verifica assinaturas, e as atualizações são de fato publicadas? Para os medidores da LDHP, isso significa pedir a cada fornecedor evidências, e não respostas. Para o "atende à 5.3" do MTR-A, significa um pacote de atualização assinado e a data da última atualização publicada. Para a 5.1, significa uma restauração de fábrica que ainda produza uma senha única. Para a 5.5, significa a versão do TLS e o tratamento de certificados observados na bancada. Só as afirmações do MTR-A precisariam ser verificadas dessa forma primeiro, porque as suas quatro respostas "sim" são as que hoje sustentam uma decisão de não fazer nada.

Exemplo resolvido (LDHP sintética)

Tabela de remediação de Maya: MTR-B — redefinir senhas únicas na próxima visita de leitura dos medidores, 2 semanas. MTR-C — isolar atrás do gateway com terminação TLS como controle compensatório para a 5.5, pedir o contato de divulgação do fornecedor, programar a substituição para dentro de 12 meses porque a 5.3 não pode ser atendida. MTR-A — nenhuma ação, verificar de novo quando o firmware mudar.

Caso sintético — Lakeside District Heating Plant. Os modelos de dispositivos e as respostas são inventados.

30.5 Reproduzindo e ampliando o laboratório

Mude o dicionário de um dispositivo por vez e rode de novo, registrando a saída ao lado da edição. Se dois estudantes obtiverem resultados diferentes a partir dos mesmos dicionários, compare as versões do Python e o arquivo exato; o script é determinístico e nunca deveria divergir. Uma primeira edição útil é pôr o unique_pw do MTR-B como verdadeiro e confirmar que a sua linha passa a 4/4, enquanto a lista de lacunas da frota inteira perde o unique_pw e mantém as três lacunas do MTR-C; uma segunda é dar ao MTR-C uma política de divulgação e verificar que só a 5.2 some da sua lista de faltantes. Se a lista da frota inteira não mudar como você previu, leia a agregação do script antes de confiar na sua edição.

Erros e limites

A ETSI EN 303 645 se destina a dispositivos de consumo; medidores distritais podem estar sujeitos a outros regimes. As quatro provisões verificadas são um subconjunto.

Exercícios

• EX088 — Acrescentando uma provisão. Acrescente "secure_storage", mapeada para a 5.4, com MTR-A True, MTR-B True e MTR-C False. O que o MTR-C imprime agora?
  Mostrar critérios de avaliação

  Rubrica: 3 = percebe o 4 fixo no código (imprime 0/4), corrige-o e obtém 1/5 com quatro provisões faltando; 2 = um dos dois; 1 = diz 1/4; 0 = nada.
• EX089 — Por que as lacunas da frota inteira enganam. Explique por que "lacunas da frota inteira: as quatro" poderia enganar um gestor.
  Mostrar critérios de avaliação

  Rubrica: 3 = dois modelos as causam; a visão por dispositivo mostra a maioria dos problemas no MTR-C; 2 = parcial; 1 = vago; 0 = nada.
• EX090 — Evidência para a 5.3. Que evidência você pediria a um fornecedor para aceitar "software atualizável"?
  Mostrar critérios de avaliação

  Rubrica: 3 = mecanismo de atualização assinado, histórico de atualizações publicado/período de suporte, teste de atualização em bancada; 2 = dois; 1 = o fornecedor diz que sim; 0 = nada.

Síntese

Avaliações de linha de base são úteis quando relatadas por dispositivo e por frota, sustentadas por evidências e transformadas num plano de remediação datado.