Exemplo STRIDE: um gateway industrial
Sytance · Atualizado
A STRIDE utiliza seis categorias de ameaças para analisar como um sistema pode ser atacado. O gateway industrial fictício apresentado abaixo ilustra um cenário por categoria, com um controlo proposto e um critério de ensaio. Estes exemplos descrevem ataques possíveis e ensaios planeados.
O gateway e os respetivos limites de confiança
Um operador utiliza um browser para chamar a API de gestão do gateway. A API lê e escreve num repositório de configuração local. Um controlador local envia dados operacionais para o gateway, que reencaminha telemetria para um serviço remoto. Um serviço de atualização separado fornece pacotes de firmware.
Neste exemplo, as ligações de gestão e telemetria utilizam TLS. A autenticação da interface do controlador e o mecanismo de confiança da atualização continuam a ser questões de conceção por resolver. A localização numa rede local não estabelece, por si só, a identidade nem a autoridade do emissor.
- Browser → API de gestão: sessões, pedidos de estado e alterações de configuração.
- API de gestão → repositório de configuração: definições armazenadas e acesso a segredos.
- Controlador local → gateway: entrada operacional proveniente da rede do local.
- Gateway → serviço de telemetria: identidade do dispositivo e dados de telemetria.
- Serviço de atualização → gateway: metadados do pacote e conteúdo do firmware.
Falsificação da identidade na interface do controlador
Um atacante na rede do local envia mensagens que alegam provir do controlador local. Se o gateway confiar apenas num endereço de origem, dados operacionais falsificados podem entrar no fluxo de telemetria.
Controlo proposto: estabelecer uma identidade do dispositivo e verificá-la antes de aceitar mensagens. Se o controlador não suportar autenticação, avalie outras formas de proteger a interface e os ataques que continuam a ser possíveis. Um segmento de rede, por si só, não prova a origem da mensagem.
Critério de verificação: as mensagens de uma identidade de teste não reconhecida são rejeitadas, enquanto as mensagens do controlador aprovado continuam a funcionar. Registe a rejeição e confirme que o valor falsificado não chegou ao serviço de telemetria.
Adulteração do firmware antes da instalação
Um atacante substitui um pacote obtido através de um ponto de distribuição comprometido. A cifragem do transporte até esse ponto não provaria que o pacote foi autorizado pelo fabricante.
Controlo proposto: verificar a assinatura do pacote face a uma âncora de confiança autorizada antes da instalação. Vincule a verificação aos bytes a instalar e ao produto permitido. Decida separadamente como tratar versões antigas assinadas e chaves de assinatura revogadas.
Critério de verificação: um pacote alterado e um pacote assinado com uma chave não fidedigna são rejeitados antes da instalação. Após a rejeição, o gateway tem de permanecer no estado operacional ou de recuperação especificado.
Alterações de configuração sem rastreabilidade
Um operador autorizado altera o destino da telemetria, mas o registo não contém a identidade individual nem o resultado. A equipa não consegue atribuir a alteração de forma fiável nem distinguir uma escrita bem-sucedida de um pedido rejeitado.
Controlo proposto: registar a identidade autenticada, a ação, o alvo, a hora e o resultado. Proteja o acesso aos registos e defina o comportamento quando o armazenamento estiver cheio. Evite incluir palavras-passe ou tokens de acesso no registo.
Critério de verificação: uma alteração controlada produz o registo correspondente, um utilizador não autorizado não o consegue editar e o comportamento de auditoria quando o armazenamento está cheio corresponde à política documentada.
Segredos expostos através da leitura da configuração
Um endpoint de estado devolve o objeto de configuração completo, incluindo a credencial de telemetria. Um utilizador autorizado a consultar o estado recebe informações de que não necessita para desempenhar a sua função.
Controlo proposto: devolver uma resposta adequada à finalidade, omitindo os campos secretos, e aplicar permissões às leituras da configuração. A cifragem em trânsito não elimina o problema de uma resposta com dados excessivos.
Critério de verificação: inspecione as respostas de cada função suportada e confirme que os valores secretos não aparecem nas respostas, nos erros nem nos registos.
O processamento de entradas esgota os recursos do gateway
Um emissor envia mensagens do controlador demasiado grandes ou repetidas. O processamento sintático e o armazenamento em memória consomem recursos de que o gateway também necessita para a gestão e a telemetria.
Controlo proposto: limite o tamanho das mensagens e das filas, valide as entradas antes de operações dispendiosas e isole o processamento crítico. Defina os limites com base na capacidade medida e no comportamento exigido ao produto em condições de sobrecarga.
Critério de verificação: num ambiente de ensaio autorizado, exercite os casos de sobrecarga acordados e observe a memória, a profundidade das filas, a disponibilidade do serviço e a recuperação. Os limites de aceitação decorrem dos requisitos deste produto; não se presume uma taxa universal.
Um utilizador só de leitura acede a uma operação de escrita
Um utilizador consegue iniciar sessão e consultar o estado. Chama diretamente uma API de escrita da configuração, contornando a interface. Se a API verificar apenas a autenticação, o utilizador obtém uma capacidade reservada aos administradores.
Controlo proposto: aplique no servidor permissões relativas à ação e ao recurso em todas as vias de escrita. Mantenha a mesma regra para pedidos normais, operações em lote e endpoints de manutenção.
Critério de verificação: os pedidos diretos de escrita de uma conta só de leitura falham e a configuração armazenada permanece inalterada. Repita com uma conta autorizada para verificar se a operação prevista continua a ser bem-sucedida.
Cobertura e riscos remanescentes
As seis categorias seguem as definições STRIDE da Microsoft. Os cenários de ataque e os controlos dependem da arquitetura do gateway descrita acima.
Um produto real pode ter vários cenários de ataque numa categoria, e um ataque pode enquadrar-se em várias categorias. Se o produto as incluir, a análise também tem de abranger interfaces de fabrico, manutenção e recuperação.
Após implementar e testar um controlo, avalie os ataques que continuam a ser possíveis face aos critérios de risco acordados. A decisão resultante aplica-se à versão do produto analisada.