Avaliação do risco cibernético de produtos: por que razão a maioria das análises de segurança é aparentemente correta, mas, na prática, inútil?

Na esmagadora maioria das empresas tecnológicas, o processo conhecido como avaliação do risco cibernético já existe. Normalmente assume a forma de uma tabela extensa, uma matriz complexa ou uma folha de cálculo dominada por valores “low”, “medium” e “high”. Este documento inclui uma longa lista de ameaças genéricas, descrições curtas de potenciais vulnerabilidades e um conjunto de medidas de controlo padrão. Do ponto de vista formal, está tudo certo: o documento está completo, assinado pela administração e devidamente arquivado.

O problema é que, na prática de engenharia, este documento não muda absolutamente nada.

Não influencia a arquitetura do equipamento em desenvolvimento. Não condiciona a decisão sobre a forma de disponibilizar atualizações. Não altera o modelo de suporte pós-venda nem revê as relações com os fornecedores de componentes. É um documento correto do ponto de vista do compliance, mas totalmente indiferente para a cibersegurança dos produtos no mundo real. No entanto, isto não se deve a falta de competências nas equipas de engenharia ou de security. É um problema de um ponto de partida fundamentalmente errado.

A maioria das análises de risco tradicionais começa com a pergunta: “Que ameaças podem ocorrer?”. Entretanto, a nova abordagem regulatória da União Europeia – claramente visível em atos como o Cyber Resilience Act (CRA), nas diretivas médicas (MDR) ou no novo regulamento de máquinas 2023/1230 – impõe uma perspetiva completamente diferente. Ela começa com a pergunta:

Em que condições de utilização o produto pode tornar-se um portador de risco para o utilizador, o sistema ou o mercado — e se o fabricante é capaz de controlar esse risco ao longo de todo o seu ciclo de vida?

Trata-se de uma mudança fundamental de paradigma. A avaliação do risco cibernético no contexto do produto não é apenas mais uma análise de ameaças à infraestrutura de TI. Também não é um teste de intrusão nem uma aplicação mecânica das orientações da norma ISO 27001. É uma análise aprofundada da capacidade do próprio produto, bem como do seu fabricante, para manter a segurança ao longo do tempo, num ambiente operacional real.

Vulnerabilidade técnica vs. risco do produto — a distinção na cibersegurança

Para que a avaliação de risco deixe de ser apenas uma tabela burocrática e passe a ser uma ferramenta de decisão para a engenharia, temos de separar com precisão dois conceitos que, no mercado, são frequentemente confundidos. Tenhamos presente: vulnerabilidade não é o mesmo que risco do produto.

• Vulnerabilidade técnica é um erro concreto e identificável no software, na configuração de hardware ou no próprio projeto. Pode ser uma validação incorreta de dados, uma biblioteca de programação desatualizada ou uma falha no mecanismo de autenticação. Estes erros são registados em bases como o sistema CVE (Common Vulnerabilities and Exposures). Ainda assim, continua a ser uma avaliação exclusivamente ao nível técnico.
• Risco do produto só surge no momento em que a vulnerabilidade referida (ou até a sua ausência temporária) é colocada nas duras realidades de utilização.

Esse contexto inclui um conjunto de variáveis: o ambiente de trabalho (rede aberta ou isolada), a forma de integração com outros sistemas, os comportamentos dos utilizadores, a disponibilidade de atualizações de segurança (o chamado patch management) e a capacidade organizacional do fabricante para responder a incidentes.

Um produto pode não ter quaisquer vulnerabilidades conhecidas no dia do lançamento e, ainda assim, gerar risco crítico se o seu criador não tiver processos de suporte a longo prazo. Compreender esta diferença organiza todo o trabalho de engenharia. É precisamente nisto que assenta a abordagem baseada no risco (risk-based approach). As medidas de segurança têm de ser proporcionais a cenários de abuso previsíveis, e não a uma lista abstrata encontrada na internet.

O paradoxo das proteções: quando a proteção aumenta o risco em IT e OT

No desenho da cibersegurança, assume-se muitas vezes que adicionar um novo “cadeado” reduz sempre o risco. A prática mostra que, por vezes, acontece exatamente o contrário. Uma medida implementada sem compreender o contexto cria novos vetores de ameaça.

1. Autenticação forte em ambiente industrial (OT)

Imaginemos a implementação de autenticação multifator (MFA) numa máquina industrial. Do ponto de vista de IT, é um passo exemplar; no entanto, a cibersegurança na automação industrial é uma realidade completamente diferente. Num ambiente fabril, o equipamento funciona 24/7 e as intervenções de assistência decorrem sob pressão de tempo. Quando a rede falha, o técnico não consegue autorizar o token online. A produção para. O resultado? Um cliente frustrado desativa este mecanismo de forma permanente, contornando totalmente a proteção. A medida que deveria proteger gerou um enorme risco operacional.

2. Atualizações automáticas em dispositivos médicos (IoMT)

A correção rápida de vulnerabilidades reduz a exposição a ataques — no mundo de IT isso é o padrão. No entanto, no universo dos dispositivos médicos, uma atualização forçada durante um procedimento pode alterar o comportamento do sistema ou interromper a comunicação com a rede hospitalar. Neste caso, uma proteção tecnológica cria um risco clínico e regulatório crítico (violação da certificação MDR).

3. Fecho de interfaces em equipamentos de consumo (IoT)

O fabricante remove fisicamente do dispositivo de casa inteligente as portas locais de diagnóstico para dificultar o acesso de hackers. Na prática, os serviços autorizados passam a diagnosticar avarias através de interfaces instáveis, contornando a encriptação, e utilizadores avançados instalam em massa software modificado (custom firmware). O resultado é a perda total de controlo do próprio ecossistema por parte do fabricante.

Uma análise de risco cibernético a sério pergunta: “Como vão mudar a estabilidade, a usabilidade e a segurança de todo o ecossistema após a introdução deste mecanismo específico?”.

Os 5 erros mais comuns na análise de risco de produtos tecnológicos

Ao avaliarem processos em empresas que colocam no mercado eletrónica e software, especialistas em cibersegurança observam padrões recorrentes.

1. Copiar o modelo corporativo de IT para o mundo dos produtos. Um produto não é um centro de dados. Funciona num ambiente desconhecido, muitas vezes offline, configurado por leigos. Aplicar ferramentas de IT à análise do produto acaba por ignorar problemas-chave: o ciclo de vida do dispositivo e a inexistência de atualizações forçadas.
2. Analisar ameaças abstratas em vez de cenários reais. Preencher uma tabela com frases como “acesso não autorizado” é analiticamente inútil. A análise tem de assentar em factos concretos: Quem? Por que interface? Com que objetivo? Com que impacto?
3. Ignorar o ciclo de vida do produto (End-of-Life). A análise de risco costuma focar-se no momento do lançamento. Entretanto, o risco aumenta com o tempo — bibliotecas open-source envelhecem e fornecedores de componentes terminam o suporte. Sem considerar o modelo de manutenção, a análise é enganadora.
4. Isolamento em relação à equipa de projeto (R&D). Tratar a avaliação de risco como uma checklist antes da auditoria é um caminho direto para o desastre. Os resultados têm de voltar aos engenheiros como requisitos arquiteturais vinculativos (Secure by Design).
5. Fetichização da tecnologia em detrimento dos procedimentos. As empresas investem fortunas em criptografia avançada, mas não sabem quem, dentro da organização, é responsável por lançar uma correção de segurança (patch) após a comunicação de uma vulnerabilidade por um investigador (Vulnerability Disclosure Program).

Como realizar uma análise em conformidade com o Cyber Resilience Act? 7 passos de engenharia

A avaliação de risco cibernético tem de deixar de ser um fardo burocrático. Abaixo encontra-se um modelo operacional de mercado, alinhado com a abordagem da UE (incluindo, entre outros, os requisitos do CRA).

1. Defina os limites do produto. O produto não é apenas hardware. Inclui também a aplicação móvel, a cloud, servidores OTA e interfaces API.
2. Descreva a realidade dura do ambiente de utilização. Não descreva um ambiente de laboratório. Responda a perguntas sobre a conectividade real à internet, as competências dos utilizadores e as possibilidades de acesso físico ao dispositivo.
3. Identifique cenários de abuso (Threat Modeling). Rejeite listas genéricas. Recorra a métodos e ferramentas de engenharia para estimativa de risco comprovados, para se focar em vetores de ataque precisos e ajustados ao seu setor.
4. Quantifique consequências não financeiras. Avalie o risco de paragem de produção, ameaça à saúde ou incumprimento de obrigações regulatórias.
5. Coloque a questão do controlo. Enquanto fabricante, consegue prevenir, detetar e reagir rapidamente ao cenário de abuso identificado?
6. Conceba mecanismos de proteção proporcionais. Decisões sobre encriptação ou segmentação de rede têm de resultar diretamente das respostas dadas nos passos anteriores.
7. Conceba o processo de manutenção (Lifecycle). Documente a política de disponibilização de patches de segurança, o período de suporte e os canais de comunicação com o cliente.

Resumo: O que deve resultar de uma avaliação de risco rigorosa?

O resultado final de uma avaliação de risco de cibersegurança do produto bem feita nunca deveria ser um poema denso de texto para o auditor. Deste trabalho têm de sair artefactos tangíveis: um mapa claro dos limites do sistema, decisões arquiteturais vinculativas em R&D, um orçamento aprovado para a política de atualizações e um rasto de auditoria coerente que comprove a conformidade com as diretivas da UE.

Uma organização tecnologicamente madura já não pergunta: “Estamos 100% seguros?”. Em vez disso, pergunta: “Onde, exatamente, estamos expostos e conseguimos gerir isso ao longo do tempo?”.

O seu produto está preparado para as novas regulamentações?

A segurança é um processo, não um certificado pontual. Se não quer que a avaliação de riscos na sua empresa seja apenas “papelada”, vale a pena agir de forma proativa. Veja como preparar, na prática, o seu produto para o Cyber Resilience Act (CRA) em 2026-2027, antes de surgirem as normas harmonizadas oficiais.