Um veículo conectado é um computador distribuído, com interfaces ligadas à segurança, vida útil longa e software fornecido por diversas organizações. As regras europeias de homologação tornam cibersegurança e gestão de atualizações preocupações de todo o ciclo de vida, não apenas um trabalho de proteção do sistema multimídia. Veja como ligar o contexto regulatório à arquitetura, à entrega de software e à resposta em campo.
O Regulamento ONU nº 155 (R155) trata da cibersegurança veicular e do Cyber Security Management System (CSMS), ou sistema de gestão de cibersegurança do fabricante. O Regulamento ONU nº 156 (R156) trata de atualizações de software e do Software Update Management System (SUMS). Na UE, a cibersegurança veicular faz parte do regime de homologação pelo Regulamento (UE) 2019/2144. A Comissão Europeia informa que as regras pertinentes valem para novos tipos de veículo desde 2022 e para todos os veículos novos desde 7 de julho de 2024, com extensões de escopo para algumas categorias previstas posteriormente. Para uma decisão real de homologação, confira a legislação consolidada e a categoria aplicável.
A conclusão de engenharia é a cobertura do ciclo de vida. Os materiais da UNECE descrevem identificação, avaliação e tratamento de riscos, testes de segurança, monitoramento contínuo da frota, resposta a vulnerabilidades e dependências de fornecedores. Para atualizações, é preciso identificar versões de software e dados de integridade com confiança, controlar a implantação e manter registro do que mudou. Certificado ou documento de processo, sozinho, não protege a frota quando build e OTA não são rastreáveis.
Esboço para modelagem de ameaças. A arquitetura e a segmentação reais variam por fabricante e modelo.
Comece pelos ativos e pelo impacto à segurança; depois trace os caminhos de dados e controle. Qual interface consegue gravar em um segmento da rede? Uma conta no aplicativo pode iniciar um comando privilegiado? Quais papéis no backend podem selecionar veículos para uma campanha? O software de um fornecedor pode atravessar uma fronteira de gateway? O threat model deve ligar capacidade do atacante, função afetada, consequência plausível, controle mitigador e evidência de verificação. Nem todo recurso conectado tem a mesma criticidade de segurança.
R155 vai além de instalar um scanner de vulnerabilidades. O CSMS do fabricante precisa gerenciar riscos nas fases de desenvolvimento, produção e pós-produção, incluindo fornecedores, avaliações atualizadas, testes, monitoramento e resposta. Equipes de software podem tornar esses processos concretos por meio de registros ligados às versões entregues:
A evidência exata de homologação pertence ao fabricante e ao processo da autoridade aplicável. Para uma organização de software, evidências úteis incluem avaliações de risco ligadas a variantes liberadas, relatórios de teste, controles de interface com fornecedores, decisões sobre vulnerabilidades, resultados de campanhas e justificativas registradas quando um problema não pode ser corrigido imediatamente. Relacione os registros ao ID do build e à configuração do veículo, em vez de juntar PDFs desconexos apenas na época da auditoria.
Uma campanha começa com o motivo da mudança e a seleção precisa dos veículos compatíveis. O serviço precisa identificar configuração de software e hardware, publicar um manifesto autenticado, validar integridade e autenticidade do artefato, verificar pré-condições e coordenar uma implantação segura. A instalação requer regras de energia e estado do veículo, dependências ordenadas, reporte de falhas e estratégia de recuperação adequada à ECU. Uma transferência HTTP concluída não prova que a atualização ocorreu com sucesso e segurança.
Uma resposta a vulnerabilidade na frota precisa descobrir quais variantes contêm o componente, quais builds do fornecedor foram afetados, qual é a exposição, se há sinais de exploração e qual mitigação é segura. Mantenha inventário relacionando VIN, ou identificador veicular adequadamente protegido, a hardware, SBOM, firmware de ECU e campanha de atualização. Restrinja o acesso a essa associação e retenha apenas a telemetria necessária à segurança e operação.
Separe detecção de ação. Uma anomalia no backend deve ser validada contra versões conhecidas e condições de rede. Um comando remoto que altera o estado do veículo precisa de autorização e salvaguardas de segurança mais fortes que uma consulta de diagnóstico. Planeje uma escada de resposta: enriquecer evidências, limitar interface exposta, bloquear campanha, liberar correção, avisar proprietários ou concessionárias e escalar para serviço físico quando necessário.
| Caminho de ameaça | Controle de engenharia | Evidência operacional | Falha a evitar |
|---|---|---|---|
| Conta de aplicativo ou cloud comprometida | Acesso privilegiado resistente a phishing, tokens escopados e autenticação reforçada para ações críticas. | Decisão de autorização, evento da conta, trace do comando e teste de revogação. | Tratar login bem-sucedido como prova de que todo comando é seguro. |
| Componente vulnerável ou malicioso de fornecedor | Acordo de interface de segurança, inventário, proveniência, testes e canal para avisos de vulnerabilidade. | Mapa de versões do fornecedor, avaliação, responsável e mitigação. | Supor que certificado de fornecedor elimina o risco de integração. |
| Atualização forjada ou dirigida ao veículo errado | Manifesto e payload assinados, boot seguro, verificação de compatibilidade e aprovação da campanha. | Identidade do assinante, alvo, digest, estado de instalação e testes. | Usar criptografia de transporte como substituta de autenticidade do artefato. |
| Telemetria expõe dados de condutores | Limitação de finalidade, eventos mínimos, controle de acesso, retenção e revisão de privacidade. | Inventário de campos, logs de acesso e prazo de exclusão. | Coletar todos os logs do veículo para sempre “por garantia”. |
| Exploit descoberto após a venda | Recepção contínua, consulta de impacto na frota, opções de mitigação e campanha gradual. | Tempo de avaliação, população afetada, decisões e verificação de eficácia. | Fechar ticket sem provar que o risco em campo mudou. |
Sinais do veículo podem revelar localização, rotina, comportamento de direção ou outras informações pessoais. Monitoramento de segurança precisa ter finalidade definida e minimizar dados: colete eventos relevantes, não contexto bruto contínuo por padrão; separe identificadores do payload de diagnóstico quando viável; defina retenção e acesso; e registre consultas para incidentes. Ao mesmo tempo, uma exclusão agressiva não pode apagar evidências necessárias a uma investigação de segurança ou a um registro obrigatório. Resolva a tensão com classes de retenção documentadas e revisão jurídica controlada.
Eu ligaria a cadeia segura de software à operação da frota: atestados de origem e fornecedores alimentam o catálogo de releases; builds assinados relacionam firmware, hardware compatível e testes; a orquestração valida elegibilidade e política de rollout; o veículo devolve versões e eventos de saúde assinados; e um serviço de vulnerabilidades mapeia novos avisos para variantes afetadas. O painel mostraria progresso, grupos de falha, exposição e responsáveis sem transformar dados de cada condutor em feed de analytics irrestrito.
Depois, ensaiaria incidentes plausíveis: credenciais de campanha comprometidas, rotação de chave de assinatura, atualização defeituosa em uma pequena coorte, aviso de fornecedor, perda de conectividade durante a instalação e retirada de serviço de um componente vulnerável. Registre estados seguros esperados e verifique-os em bancada antes de qualquer implantação em estrada.
Segurança de veículos conectados é um problema de sistemas e ciclo de vida. R155 e R156 fornecem um regime de gestão e homologação; o trabalho de engenharia conecta riscos, garantia de fornecedores, build seguro, atualizações autenticadas, monitoramento com privacidade e resposta da frota a configurações rastreáveis. Um bom programa consegue responder não apenas “este componente está corrigido?”, mas “quais veículos foram afetados, o que é seguro fazer agora e como saberemos que a mitigação funcionou?”.
Nota editorial: Este artigo é uma visão geral de engenharia, não um checklist de homologação nem parecer jurídico. A aplicabilidade regulatória e a evidência exigida variam por categoria, data de homologação e jurisdição.