A serialização de “O Futuro da Segurança de Redes Veiculares” está dividida em três partes: “superior, intermediário e inferior”. Artigo anterior: O Futuro da Segurança da Rede Veicular (Parte 1): Análise de Ameaças, Avaliação de Riscos e Projeto de Segurança , Análise de Vulnerabilidade no Desenvolvimento de Veículos Então, neste artigo, analisaremos os pontos-chave da implementação da codificação de segurança no desenvolvimento de veículos, testes de segurança e medidas de segurança na fase de fabricação.
5. Pontos-chave para implementar codificação segura no desenvolvimento de veículos
De acordo com a avaliação de ameaças e riscos na fase de conceito, o design de segurança na fase de desenvolvimento, a análise de vulnerabilidade e os documentos de design gerados pelas atividades de implementação de medidas, examinam a "codificação segura" que deve ser executada na fase de implementação de software .
Codificação segura refere-se a "escrever programas robustos contra ataques cibernéticos". No final do Capítulo 4 da "Parte 1" desta série de tópicos , discutimos "vulnerabilidades na fase de design" e "vulnerabilidades na fase de implementação", e a codificação segura é uma medida para resolver "vulnerabilidades na fase de implementação" .
Esta é a atividade mais específica no “nível de software” na “fase de desenvolvimento do produto”, que é um dos sete elementos da ISO/SAE 21434 mostrados na Figura 1 do Capítulo 1 do Tópico “Parte Um” .
A importância da codificação segura
A razão pela qual a codificação segura é tão importante é que mesmo que você tome medidas contra um “bug na fase de design”, um “bug na fase de implementação” devido à codificação segura incompleta pode causar sérios danos. Vulnerabilidades como buffer overflows e injeções de SQL, por exemplo, podem levar à execução não intencional de código por terceiros, que são exemplos típicos de “vulnerabilidades na implementação”.
Além disso, para bugs no software como um todo, “vulnerabilidades que ocorrem na fase de implementação” são relatadas mais do que “vulnerabilidades que ocorrem na fase de design”, o que também é importante do ponto de vista do “número” de bugs.
Tarefas específicas para codificação segura
A Figura 10 lista o trabalho específico de codificação segura. Antes de prosseguir com o trabalho de codificação, deve-se traçar um plano geral de acordo com as características do projeto (como importância das informações e funções do produto, custo, prazo de entrega, etc.).
Figura 10: Operações específicas de codificação segura
*1 Revisão por pares: Um método de garantia de qualidade no qual pessoas com funções e ocupações iguais (ou semelhantes) verificam os resultados para melhoria.
※2 Cerca de 300 regras do CERT-C/C++ são estipuladas.
*3 MISTRA-C/C++: Uma diretriz de codificação para a linguagem C/C++ criada para fins de segurança funcional automotiva.
Desafios e soluções de codificação segura
Muitas organizações usam algumas ferramentas de análise estática para verificar a estabilidade do programa no nível do código-fonte, mas um grande desafio é "muitos problemas detectados para serem resolvidos" e "é difícil julgar se a ferramenta é falso positivo".
Para resolver este problema, o desenvolvimento geral de software tende a responder de acordo com a importância (como Crítica/Alta ou Moderada/Baixa) mostrada pelas ferramentas de análise estática. Por exemplo, sempre que possível, execute correções ou análises de risco em problemas Críticos/Altos e depois aceite o risco, sem detecção de erros em problemas Moderados/Baixos.
Na indústria automotiva, por outro lado, podem ocorrer danos potencialmente fatais mesmo para problemas considerados de baixa importância pelas ferramentas de análise estática, se os problemas detectados pelas ferramentas de análise estática não forem corrigidos, por isso é difícil determinar automaticamente contramedidas com base sobre importância e coisas do gênero.
Então, no desenvolvimento de software automotivo, como resolver isso?
Nossa solução para nossos clientes é “resolver todos os problemas detectados pela ferramenta”, portanto “considerar ações para lidar com todos os problemas”. Aqui, “resposta” significa “julgamento como falsa detecção” ou “correção”.
O foco está em “manter o máximo possível de código vulnerável” e “planejar para lidar com problemas detectados pelas ferramentas”.
Para o efeito, as medidas específicas são as seguintes:
• Implementar educação de codificação segura
• Execute ferramentas de análise estática no início da fase de desenvolvimento
• Automatize ferramentas de análise estática, incluindo a incorporação de ferramentas de análise estática em ferramentas de CI*4
*4 Ferramenta CI (Integração Contínua): Uma ferramenta para construção contínua de código-fonte (processo de criação de arquivos executáveis e pacotes de distribuição) e testes. Ao combinar ferramentas de análise estática com ferramentas como Jenkins que possuem compilações automatizadas, é possível realizar análises estáticas enquanto automatiza compilações.
6. Testes de segurança no desenvolvimento de veículos
Este capítulo descreve o "Teste de Segurança", que é uma medida da fase de teste para veículos/produtos de bordo implementados.
Teste de segurança por objetivo
Os testes de segurança incluem principalmente dois conceitos de diagnóstico de vulnerabilidades e testes de penetração.
Diagnóstico de vulnerabilidade
Conforme mencionado no capítulo anterior, o trabalho de segurança é realizado na fase de conceito, fase de desenvolvimento e fase de implementação, cada fase realiza análises de ameaças e, com base nesses resultados da análise, são realizados o projeto de segurança e a codificação de segurança. Dessa forma, um diagnóstico de vulnerabilidade é um teste que determina se uma medida de ameaça potencial em um processo upstream está funcionando corretamente conforme o esperado. Devido a estas propriedades, o diagnóstico de vulnerabilidade pode criar uma lista de verificação, etc., uma vez que pré-identifica a ameaça assumida e as suas contramedidas e fornece alguma explicação para a sua abrangência.
teste de penetração
O teste de penetração é um teste para determinar o objetivo do ataque e conduzir um ataque (avaliação) para atingir o objetivo.
O teste de penetração não requer abrangência, seu objetivo é descobrir se é possível atingir o objetivo de “executar código arbitrário em uma ECU (Unidade de Controle Eletrônico) específica”, caso contrário, até que ponto atingirá o objetivo, e o que não consegue atingir o objetivo qual é o motivo. Como o teste de penetração é conduzido independentemente dos vários esforços no processo upstream, ele pode efetivamente revelar ameaças que não foram pensadas no processo upstream, ou seja, omissões no processo upstream. Em outras palavras, todo item de teste realizado em testes de penetração também pode ser um item de diagnóstico de vulnerabilidade.
Isso significa avaliar do ponto de vista de um invasor, assim como os invasores globais fazem tudo para atingir seus objetivos, independentemente das medidas de segurança da empresa fabricante.
Conforme mostrado na Figura 11, as ideias de diagnóstico de vulnerabilidade e teste de penetração são diferentes, nenhuma contém a outra. É inviável em termos de custos realizar testes de segurança completos em todos os produtos, por isso é muito importante escolher quais projetos realizar. Dependendo do modelo do produto, diferenças funcionais em relação a modelos semelhantes, etc.
Figura 11: Visão geral dos diagnósticos de vulnerabilidade e testes de penetração
Perspectiva de teste de segurança para cada sujeito de teste
Tanto o diagnóstico de vulnerabilidade quanto o teste de penetração incluem testes de hardware e testes de software.
Teste de segurança de hardware
Existem vários níveis de teste de hardware, um deles é o teste de interfaces externas padrão fornecidas pelo produto. Por exemplo, portas Ethernet (portas LAN), interfaces de rede (como Wi-Fi e Bluetooth), interfaces de dispositivos externos (como portas USB), entradas de mídia (como CD/DVD) e botões no gabinete. Essas interfaces são as padrão que os usuários podem usar e são as mais fáceis de testar, pois são descritas em manuais, etc., mas sem conhecer as especificações internas podem levar a testes inúteis e, portanto, são muito difíceis de testar com eficácia.
O próximo projeto possível é desmontar o gabinete e fazer estudo e análise da placa de circuito impresso interna. Por exemplo, os tipos e utilizações dos diversos chips utilizados, se há serigrafia e conteúdo, se existe uma porta de depuração e verificação e análise dos vestígios dos pinos utilizados antes de sair da fábrica, etc.
Tal investigação e análise são benéficas para a presunção de especificações do produto.Além disso, se for possível descobrir e identificar portas de depuração, etc., o que é um grande risco por si só, e for possível obter informações internas para os desenvolvedores, será ajuda Realize testes de acompanhamento. Além disso, se essas análises identificarem chips que armazenam capacidades de comunicação, poderá ser testado se o firmware pode ser extraído desses chips e se o firmware extraído pode ser analisado.
Teste de segurança de software
Existem vários níveis de teste de software versus teste de hardware. O teste mais básico envolve o uso da interface do usuário (IU) apresentada ao usuário para garantir que os recursos de segurança sejam ignorados ou que ações que representem um risco à segurança sejam executadas. Além disso, se for fornecida uma interface para a rede, é possível verificar se serviços indesejados foram iniciados, se o software em execução possui vulnerabilidades conhecidas e, em caso afirmativo, realizar um ataque real e confirmar se um ataque pode ser executado. .
Se os testes externos forem realizados sem o conhecimento das especificações internas desses testes, isso poderá levar a testes cegos, dificultando o teste eficaz. Portanto, pode ser necessário analisar o firmware extraído durante o teste de hardware para determinar as especificações internas e depois testar o software. A Figura 12 fornece exemplos de testes de hardware e software.
Figura 12: Exemplo de teste de hardware e software
O lugar dos testes de segurança em todo o ciclo de vida do desenvolvimento de segurança
Se esses testes são realizados como diagnósticos de vulnerabilidade ou testes de penetração depende da extensão da ameaça envolvida no processo upstream, da extensão da ameaça assumida e da extensão e forma de ação tomada. Em outras palavras, os diagnósticos de vulnerabilidade são realizados para confirmar a adequação das contramedidas contra ameaças previstas na engenharia upstream, enquanto os testes de penetração são realizados para confirmar a adequação e eficácia das suposições originais.
Portanto, os testes de segurança não devem ser revistos em termos de políticas de implementação e conteúdo apenas durante a fase de testes, mas devem ser formulados de acordo com os esforços de todo o processo de desenvolvimento.
7. Medidas de segurança na fase de fabricação
Nosso foco está em atividades de segurança em design, implementação, testes e desenvolvimento de produtos. Este capítulo não discute a segurança do produto em si, mas sim as atividades de segurança necessárias para completar as fases de produção necessárias para o produto.
A necessidade de atividades de segurança na fase de fabricação
Até agora, o malware e outros compromissos de segurança persistiram, apesar das fábricas utilizarem a sua própria rede e instalações de sistema de controlo. Além disso, nos últimos anos, a Internet das Coisas, como fábricas inteligentes, desenvolveu-se e vários dispositivos estão conectados à rede de fábricas. Além disso, os próprios sistemas utilizam cada vez mais sistemas operacionais e aplicativos de uso geral. Essas mudanças no ambiente levam a maiores riscos de segurança, como ser alvo de malware.
Além disso, à medida que os veículos se conectam à rede, a aplicação da tecnologia de criptografia é ampliada, como criptografia de comunicação e autenticação de mensagens. Como resultado, cada vez mais unidades de controle eletrônico (ECUs) devem armazenar chaves de criptografia em seu interior, que desempenham um papel importante na tecnologia de criptografia. A fábrica deve controlar rigorosamente esta chave de criptografia e garantir que ela não possa ser vazada ou adulterada em todos os momentos.
Além disso, é tão importante quanto a ISO/SAE 21434, uma norma internacional, e espera-se que se torne lei no futuro." Projeto de Recomendação sobre Segurança Cibernética da Força-Tarefa de Segurança Cibernética e Over-the-air questões da UNECE WP.29 GRVA" está em desenvolvimento A implementação de um CSMS*1 é necessária ao longo de todo o ciclo de vida de um produto, incluindo a fase de fabricação, por isso será necessário realizar atividades de segurança nas fábricas de acordo com as leis e padrões internacionais no futuro.
Portanto, devido a vários aspectos, como a IoT das fábricas, o desenvolvimento das funções dos veículos, as leis e os padrões internacionais, há uma necessidade crescente de atividades de segurança na fase de fabricação.
*1 CSMS (Sistema de Gerenciamento de Segurança Cibernética): Um sistema de gerenciamento de segurança para automação industrial e sistemas de controle.
Quais medidas de segurança são exigidas em cada instalação de uma fábrica
Até agora, as instalações de produção da fábrica raramente estão ligadas a redes externas, o que pode fazer com que algumas medidas de segurança não sejam implementadas. Se esses dispositivos estiverem conectados diretamente a redes externas, os dispositivos de produção menos seguros serão o alvo. Como toda a rede está exposta a riscos de segurança, cada instalação e rede de produção exige medidas de segurança.
Contudo, o esforço e o custo seriam significativos se todos os equipamentos fossem colocados de forma segura no mesmo nível. Portanto, um gerenciamento de segurança eficaz é alcançado isolando redes, controlando conexões entre redes usando firewalls, etc., e implementando medidas de segurança necessárias para cada instalação (ver Figura 13).
Figura 13: Exemplo de controle de acesso crítico ao sistema
Os sistemas de gerenciamento de chaves de criptografia exigem medidas mais rigorosas
Dados chamados chaves de criptografia são usados para criptografia de comunicação, autenticação de mensagens, etc. (veja a Figura 14). Uma vez que a chave de criptografia seja obtida ilegalmente por um invasor, isso levará à quebra da comunicação criptografada e à personificação do veículo, portanto, um gerenciamento rigoroso, como o armazenamento seguro, deve ser realizado nos equipamentos e veículos de produção.
Como se presume que cada modelo ou veículo utiliza uma chave de criptografia diferente, é necessário um sistema de gerenciamento para vincular e gerenciar a chave de criptografia ao veículo ou dispositivo e gravar a chave de criptografia no dispositivo. Como mencionado anteriormente, uma vez que a chave de criptografia seja vazada, isso afetará seriamente o veículo, portanto, o sistema que lida com a chave de criptografia deve garantir uma maior força de segurança do que o equipamento de produção comum.
Exemplos de medidas de segurança para sistemas de gerenciamento de chaves
• Melhorias na segurança física, incluindo gerenciamento de sala de servidores
•Controle de acesso aprimorado ao sistema usando autenticação multifator, etc.
• Gerenciamento de chave de criptografia HSM*2
• Monitoramento de syslog aprimorado relacionado ao gerenciamento de chaves
Portanto, os sistemas de gerenciamento de chaves exigem proteções de segurança mais fortes. Num ambiente onde os sistemas existentes e os sistemas de gestão de chaves estão misturados na mesma rede, se não estiverem todos configurados para o mesmo nível de segurança, um ataque ao sistema menos seguro comprometerá a gestão de chaves no mesmo sistema de rede. Portanto, o isolamento de rede e o controle de acesso mencionados acima devem ser implementados para garantir que cada sistema tenha uma configuração de segurança adequada.
*2 HSM (Módulo de Segurança de Hardware): Hardware seguro usado para armazenar dados importantes, como chaves de criptografia em data centers, etc.
Figura 14: Visão geral do processo de criptografia
Para obter mais conteúdo, preste atenção em "O futuro da segurança da rede veicular (Parte 2): Medidas de segurança e requisitos de proteção de segurança após a entrega",