[ad_1]
Não estamos brincando quando falamos sobre carros como large information gerando centros de computação sobre rodas. Se você continuar Porta de vidro, há até uma pergunta na entrevista: “Quantas linhas de código um Tesla tem?”
Não tenho certeza, mas mesmo uma década atrás, os carros top class continham 100 unidades de controle eletrônico (ECUs) baseadas em microprocessadores, que executavam coletivamente mais de 100 milhões de linhas de código. Depois, há telemática, instrument de assistência ao motorista e sistema de infoentretenimento, para citar apenas alguns outros componentes que exigem código.
O que ecu sei é que como os carros digitais e Autônomo capacidades aumentarem, a integridade desse código será ainda mais importante — especialmente sua segurança.
Cada carro vem com muitos componentes, e cada um deles pode ter uma base de código diferente, que, se mal testada ou protegida, é vulnerável a insects, erros ou códigos maliciosos. Mas e se pudéssemos proteger os carros antes que eles saíssem do chão de fábrica?
Falei recentemente com Matt Wyckhouse, fundador e CEO da Estado finito, para descobrir como os fabricantes de automóveis protegem todo esse código. Ele também é dono de um Tesla, então investiu pessoalmente na segurança do carro.
É comum incluir segurança em todo o ciclo de vida do desenvolvimento. No entanto, o Estado Finito empurra a segurança “o mais à direita possível”. Isso garante que o código da compilação ultimate seja seguro, para garantir que nada mude entre o teste e o carro indo para seus clientes.
Quais são algumas das falhas de segurança mais comuns?
O código mal escrito é vulnerável a riscos de segurança ou atividades maliciosas. Esses milhões de linhas de código dentro dos microprocessadores de um carro têm sua própria origem. Por exemplo, o firmware do sistema incorporado, incluindo o firmware usado em veículos conectados, é composto por 80-95% de componentes de terceiros e de código aberto.
E, uma vez que você comece a usar instrument de outras partes que podem não compartilhar sua vigilância de segurança, o risco aumenta. Alguns exemplos comuns:
Vulnerabilidade do Log4J
Um exemplo da recente Vulnerabilidade do Log4j — uma vulnerabilidade de dia 0 na biblioteca de log baseada em Java do Apache Log4j.
O desenvolvedor important pode ter puxado o instrument Log4j como parte de sua prática de desenvolvimento. Ou pode ser encapsulado em um componente de terceiros, 4to ou quinta parte construído em Java que chega ao instrument ultimate.
Isso compromete a segurança de qualquer servidor automático usando a biblioteca. Os dados são coletados e armazenados em diferentes lugares ao longo do pace. Isso aumenta o risco de impacto no instrument do veículo.
Em janeiro, o pesquisador de segurança cibernética David Columbo ganhou entrada remota para mais de 25 Teslas devido a uma falha de segurança descoberta em instrument de terceiros usado pelos motoristas da Tesla.
Não lhe permitia ‘dirigir’ os carros. Mas ele podia trancar e destrancar janelas e portas, desativar os sistemas de segurança dos carros, buzinar e ligar e desligar os rádios dos carros.
Então, agora tenho controle remoto general de mais de 20 Teslas em 10 países e parece não haver maneira de encontrar os proprietários e denunciá-los…
— David Colombo (@david_colombo_) 10 de janeiro de 2022
O problema de segurança das credenciais codificadas
Outro exemplo é credenciais codificadas. É aqui que as senhas de texto simples e os dados secretos são colocados no código-fonte. Ele fornece um backdoor para teste e depuração de produtos.
Deixado no código ultimate, um invasor pode ler e modificar arquivos de configuração e alterar o acesso do usuário. Se a mesma senha estiver em uso como padrão em vários dispositivos, você terá um problema ainda maior.
Em 2019, credenciais codificadas deixadas no Aplicativo móvel MyCar possibilitou aos invasores acessar dados do consumidor e obter acesso físico não autorizado ao veículo de um alvo.
Então, como você protege o instrument contra vulnerabilidades e ataques?
O trabalho da Finite State começa na fase de teste, focando na cópia binária ultimate e nas compilações. Eles trabalham de trás para frente, automatizando a engenharia reversa de código, desmontando, descompilando e testando pontos fracos e vulnerabilidades. Em seguida, eles os compartilham com a equipe de segurança do cliente.
Wyckhouse explicou que o teste ultimate permite que eles vejam como um artefato de instrument mudou ao longo do pace:
E se houver uma mudança não intencional que não seja rastreável até uma ação da equipe de desenvolvimento, isso é um motivo para investigar mais.
Quando pensamos em cibersegurança e mobilidade realmente, estamos apenas começando. Mas, de acordo com Wyckhouse, as montadoras estão investindo continuamente em segurança, não apenas para cumprir padrões industriais mas também para obter vantagens competitivas e de reputação sobre os rivais que sofrem repetidamente com violações de segurança.
Ainda assim, não passa uma semana sem mais um relatório de um ataque ou uma vulnerabilidade encontrada por pesquisadores de chapéu branco. E à medida que a automação do carro aumenta, os riscos só aumentam.
[ad_2]
Fonte da Notícia
