Conectividade adiciona capacidade operacional e também dependências. Um requisito de segurança precisa indicar o ativo protegido, a ameaça considerada, a capacidade esperada e como essa capacidade será testada e mantida.
Mapeie ativos, fluxos e fronteiras de confiança.
Documente controladores, gateways, redes, operadoras, APIs, plataforma, identidades, estações de operação, aplicativos, integrações e serviços de suporte. Para cada fluxo, registre origem, destino, protocolo, autenticação, dados, criticidade e comportamento em falha.
Separe comandos de leitura, administração e manutenção. A arquitetura também deve mostrar dependências externas, ambientes, segregação e caminhos de contingência.
Dispositivos e configurações precisam de identidade.
Cada componente deve ser reconhecível de forma consistente, com inventário, versão, estado e vínculo ao ativo de campo. Defina como credenciais são provisionadas, trocadas, revogadas e recuperadas, evitando segredos compartilhados sem controle.
Configurações relevantes precisam de autorização, validação, histórico e possibilidade de restauração segura. Valores padrão, interfaces de manutenção e modos de fábrica devem fazer parte da análise.
Proteja dados e limite interfaces.
Classifique telemetria, comandos, localização, dados operacionais e registros de usuários. Defina proteção em trânsito e armazenamento, gestão de chaves, retenção, exportação e descarte. O projeto deve deixar claro quem controla e quem processa cada conjunto.
Privilégios devem ser mínimos e separados por função. Autenticação, autorização, sessões, bloqueios, revisão de acesso e trilha de auditoria precisam ser verificáveis. Interfaces desnecessárias devem permanecer desativadas ou inacessíveis.
Atualização segura é parte do produto.
Defina origem, assinatura ou mecanismo equivalente de verificação, transporte, autorização, janela, rollback, compatibilidade, inventário de versões e tratamento de falhas. Atualizações precisam preservar disponibilidade e permitir identificar o que foi aplicado a cada componente.
O fornecedor deve informar período de suporte, processo de vulnerabilidades, comunicação de correções e condições de fim de vida. Um equipamento sem caminho de atualização transfere risco para toda a operação.
Logs, alertas e contingência precisam ser exercitados.
Registre autenticações, alterações administrativas, comandos relevantes, falhas, atualizações e eventos de segurança com relógio e identidade coerentes. Defina retenção, proteção, acesso e integração com a rotina de incidentes.
Planeje indisponibilidade de comunicação, plataforma, credenciais ou fornecedor. Determine quais funções locais permanecem, como a operação manual ocorre, quem decide e como o retorno é reconciliado.
A capacidade não técnica também importa.
Documentação, canal de contato, divulgação de vulnerabilidades, educação, atualizações e suporte ao longo do ciclo de vida complementam os recursos do dispositivo. Contratos e procedimentos devem preservar acesso aos dados, exportação, continuidade e encerramento organizado.
Usar uma referência do NIST como checklist não certifica o sistema nem demonstra conformidade. A arquitetura real precisa ser avaliada e testada segundo o risco do projeto.
Converta segurança em uma matriz de teste.
| Capacidade | Evidência | Teste |
|---|---|---|
| Identificação | Inventário e identidade por componente | Conciliar campo, plataforma e versão |
| Configuração | Perfis, permissões e histórico | Alterar, negar e restaurar |
| Proteção de dados | Arquitetura e gestão de chaves | Inspecionar fluxos e acessos |
| Acesso lógico | Interfaces e controles habilitados | Validar privilégio mínimo |
| Atualização | Pacote, verificação e rollback | Executar cenário controlado |
| Estado de segurança | Logs, alertas e inventário | Gerar, detectar e investigar |
Integre a matriz ao termo de referência e ao plano de aceite. Veja também a visão de telegestão para iluminação pública.
Referências públicas consultadas.
O checklist foi estruturado a partir da série NIST IR 8259 e do catálogo de capacidades de cibersegurança para IoT do NIST. A revisão 1 do NIST IR 8259, publicada em 2026, reforça atividades de segurança ao longo do desenvolvimento e suporte do produto.