Modelagem de Ameaças

Modelagem de ameaças cobre o comportamento relevante à segurança de um sistema e não substitui teste de invasão, análise de código ou gestão de vulnerabilidades. O primeiro passo é delimitar o que entra no modelo. Em uma casa inteligente, o escopo pode incluir aplicativo móvel, conta cloud, hub local, broker MQTT, câmeras, fechaduras, VLAN IoT, roteador e APIs de terceiros. Ativos são dados e capacidades que precisam de proteção: chaves privadas, vídeo, histórico de presença, comandos de abertura, credenciais, disponibilidade de automações e integridade de firmware. Em seguida são desenhados fluxos de dados e fronteiras de confiança. Uma fronteira aparece quando dados cruzam entre componentes com níveis de confiança diferentes, por exemplo Internet e reverse proxy, VLAN IoT e rede de gestão, aplicativo e API cloud, hub e dispositivo por Zigbee, ou usuário convidado e painel administrativo. Cada fluxo registra protocolo, direção, autenticação, criptografia, formato e persistência. Diagramas de fluxo de dados ajudam porque tornam explícitos processos, armazenamentos, entidades externas e canais. O modelo precisa incluir fluxos de atualização, suporte remoto, recuperação de senha e telemetria, não apenas o caminho principal. Um inventário com versões, portas e dependências evita abstração excessiva. O objetivo não é desenhar cada fio do circuito, mas capturar decisões de segurança. A consequência prática é encontrar, ainda no projeto, que uma câmera pode falar diretamente com a Internet ou que uma fechadura depende de um token cloud sem alternativa local. Corrigir no diagrama custa menos do que depois da instalação.

STRIDE é uma técnica amplamente usada para organizar ameaças em seis classes: spoofing de identidade, tampering de dados, repudiation, information disclosure, denial of service e elevation of privilege. Cada componente e fluxo pode ser examinado. Um broker MQTT sem certificado de cliente pode permitir spoofing. Um webhook sem HMAC pode sofrer tampering. Logs sem identidade e tempo confiável dificultam repudiation. Uma câmera exposta ou backup sem cifra causa information disclosure. Jamming de 2,4 GHz, exaustão de conexões e queda cloud são denial of service. Uma API que permite ao usuário comum alterar ACL é elevation of privilege. A classificação não é uma lista decorativa; cada ameaça deve virar cenário concreto com pré-condição, ação, ativo afetado, impacto e controle. Árvores de ataque aprofundam objetivos como “abrir a porta sem autorização” em caminhos alternativos: roubar credencial, clonar token, explorar API, comprometer hub, abusar de suporte remoto ou atacar fisicamente o atuador. Casos de abuso complementam requisitos funcionais. O modelo precisa considerar atacante remoto, vizinho com alcance de rádio, visitante na LAN, técnico autorizado, fornecedor comprometido e malware no telefone. A capacidade varia. Uma ameaça plausível recebe prioridade por probabilidade, impacto e exposição. Métodos quantitativos podem usar DREAD ou matrizes, mas números sem evidência criam falsa precisão. É mais útil registrar justificativas e condições. A modelagem deve incluir falhas acidentais que afetam segurança, como relógio incorreto invalidando certificados ou restauração de backup reintroduzindo chave revogada.

Uma ameaça só é tratada quando a mitigação é específica, atribuída e verificável. “Usar criptografia” é insuficiente. Um requisito melhor afirma: “o aplicativo deve validar TLS 1.3 ou 1.2, cadeia X.509 e hostname; o gateway deve usar certificado individual e mTLS; chaves privadas devem permanecer em TPM; a renovação deve ocorrer antes de 80% da validade”. Para spoofing, controles incluem MFA, certificados por dispositivo, secure boot e atestação. Para tampering, assinatura de firmware, HMAC, AEAD e validação de esquema. Para disclosure, minimização, criptografia em trânsito e repouso, segregação e retenção curta. Para DoS, rate limiting, filas limitadas, operação local e watchdog. Para privilégio, RBAC/ABAC, menor privilégio, separação de contas e revisão. Cada controle recebe status: planejado, implementado, testado, aceito como risco ou transferido. Risco residual é documentado. Testes são vinculados. Um requisito de webhook vira teste de assinatura inválida, timestamp fora de 5 minutos e replay. Um requisito de atualização vira teste de imagem não assinada, rollback e chave revogada. A equipe também registra ameaças não mitigadas e prazo. Aceitar risco é decisão do responsável, não silêncio. Em automação residencial, a segurança física exige análise de estados degradados. Se a cloud cai, a fechadura continua permitindo saída e chave mecânica. Se o hub falha, alarmes locais não devem desaparecer sem indicação. A modelagem deve evitar um controle digital criar risco de vida.

O modelo não é documento feito uma vez. Mudanças de firmware, novo protocolo, integração com assistente de voz, acesso remoto, nova API ou migração cloud alteram. Revisões devem ocorrer em marcos de arquitetura, antes de release, após incidente e quando dependência crítica muda. Um repositório versiona diagramas, ameaças, decisões e testes. O histórico explica por que uma porta está fechada ou por que o dispositivo não aceita comando cloud direto. Ferramentas como Microsoft Threat Modeling Tool, OWASP Threat Dragon, diagrams.net e templates podem apoiar, mas não pensam pelo time. A principal limitação é incompletude. Se o diagrama omite o servidor de atualização, a ameaça de supply chain não aparece. Se assume que a LAN é confiável, ignora dispositivo IoT comprometido. Se o facilitador conhece apenas software, pode esquecer rádio, energia e acesso físico. Revisões multidisciplinares melhoram: desenvolvimento, redes, elétrica, privacidade, operação e produto. Modelagem também não prova ausência de vulnerabilidades. Ela direciona controles e testes. Red teaming e análise de código encontram falhas emergentes. O método deve evitar burocracia: priorizar caminhos críticos e decisões. Em uma residência pequena, uma sessão de 60–90 minutos com diagrama e principais cenários já produz valor, desde que gere ações. Em fabricante, o processo é contínuo e integrado ao SSDLC.