## Capítulo 30 — Laboratório II ### Mapa da aula Aula 30 publicada. Mapa, exemplo, EX088. ```mermaid 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 ```mermaid 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"] ``` ```text [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. ```python """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: ```text 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? *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. *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"? *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. ### Continue estudando — capítulo 30 de 40 [← Capítulo 29](#ch-29) · [Índice de capítulos do curso](../SUBJECTS.md) · [Capítulo 31 →](#ch-31) Siga para a próxima lição escrita. ## Worked answers **EX088.** O laço usa `4-len(miss)`, então imprimiria `MTR-C: 0/4 met`, a menos que o 4 seja trocado; depois de trocá-lo por `len(f)-len(miss)`, o MTR-C imprime 1/5 met, com 5.2, 5.3, 5.4 e 5.5 faltando. Perceber o 4 fixo no código faz parte da resposta. **EX089.** Todas as provisões aparecem como lacunas da frota, mas o MTR-A passa em todas e o MTR-B falha em apenas uma; o gestor poderia financiar a substituição da frota inteira quando o problema real está concentrado no MTR-C, mais uma redefinição de senha barata para o MTR-B. **EX090.** Uma descrição de como as atualizações são assinadas criptograficamente e verificadas no dispositivo, o histórico de atualizações publicado pelo fornecedor e o período de suporte declarado, e uma demonstração em bancada aplicando uma atualização e rejeitando uma adulterada.