Nesta postagem, aprofunde-se em detalhes relacionados especificamente à estrutura de atualização de software over-the-air (OTA) em um ambiente corporativo.

Dispositivos inteligentes são cada vez mais usados ​​em uma ampla variedade de aplicações, de sistemas domésticos inteligentes a controles industriais. O mercado de Internet das Coisas deverá crescer para mais de US $ 1,5 trilhão até 2025. Cada vez mais dispositivos estão incluindo funcionalidades acessíveis pela rede, mas infelizmente muitos deles não tomam as medidas de segurança adequadas. Atores mal-intencionados podem se infiltrar em dispositivos mal protegidos e coletá-los no que é chamado de "botnet". Os efeitos desses botnets podem ser dramáticos, às vezes resultando em interrupções em escala global. Ataques de ransomware estão se tornando comuns. Mesmo os dispositivos conectados que parecem inofensivos, como tanques de peixes, podem ser usados ​​como vetores para ataques caros.

Para responder às ameaças, os designers devem fornecer a capacidade dos sistemas implantados remotamente de receber atualizações de software, que, se mal implementadas, podem fornecer outro vetor para ataques. Nesta postagem, discutiremos algumas considerações de segurança e privacidade para dispositivos conectados e nos aprofundaremos em detalhes específicos relacionados à estrutura de atualização de software over-the-air (OTA) em um ambiente corporativo. Começamos revisando alguns princípios gerais de segurança que devem fazer parte do design de qualquer sistema. Em seguida, examinaremos as considerações para a estrutura de atualização em si, incluindo decisões de design que devem ser feitas com antecedência para evitar o retrofit da camada do sistema. Em seguida, detalharemos as necessidades de segurança do sistema operacional do dispositivo de destino. Finalmente,

Princípios gerais de segurança

A segurança é um processo e uma mentalidade. Não existe um interruptor mágico que possamos alternar para tornar um sistema seguro. É importante ficar vigilante, revisando as falhas de segurança existentes e adaptando-se ao seu fluxo de trabalho para contabilizá-las. Novas classes de ataques aparecem aparentemente todos os dias e as equipes de engenharia devem se preparar para isso a fim de permanecerem seguras. Os chapéus brancos precisam acertar todas as vezes, enquanto os chapéus pretos precisam acertar apenas uma vez. Você precisa identificar quais recursos são dignos de proteção. É improvável que um banco de dados de leituras do tempo contenha informações proprietárias, ao passo que um banco de dados de clientes certamente contém. Você desejará adaptar a segurança para corresponder à gravidade de uma violação. O objetivo da maioria dos dispositivos de segurança é aumentar o custo de um ataque ou reduzir o valor de qualquer violação bem-sucedida.

É importante perceber que o sistema de atualização OTA geralmente se preocupa apenas com ataques e vulnerabilidades potenciais ao próprio processo de atualização. Ele não oferece nenhuma proteção contra ataques que ocorreram fora da alteração da atualização. Para esses tipos de ataques, você precisa contar com outros componentes fornecidos pelo seu sistema operacional. 

Uma consideração geral de segurança extremamente importante é o princípio do menor privilégio. Isso afirma que os componentes do seu sistema devem ter o acesso mínimo necessário para realizar as funções exigidas. Isso ajuda a limitar os danos que podem ser causados ​​quando um determinado componente é violado.

Outras coisas a considerar ao projetar seu sistema, mas não diretamente relacionadas às atualizações OTA são:

Sistemas de controle de acesso (como SELinux ou SMACK )

Modo de segurança

Armazenamento somente leitura

Hardware de segurança

Considerações de segurança para uma estrutura de atualização

Além dos princípios gerais de segurança que qualquer dispositivo em rede deve seguir, as estruturas de atualização OTA têm algumas preocupações específicas. Essas preocupações afetam três partes do seu processo de atualização:

lado do servidor, onde as atualizações são armazenadas e implantadas

lado do cliente, o dispositivo que recebe a atualização e o software em execução no dispositivo que implementa as atualizações OTA

ferramentas, os certificados, chaves e outras ferramentas que garantem a segurança do processo.

Lado do servidor

Uma das primeiras decisões ao projetar o lado do servidor de sua estrutura de atualização é onde você hospedará o sistema. É possível hospedá-lo em servidores de sua propriedade, mas é preciso levar em consideração a segurança física deles. Quem deve ter acesso? Como isso é controlado e, mais importante, revogado? Que outra segurança existe? Existem câmeras de segurança adequadas e outras medidas? Todos nós já vimos filmes ou programas de TV em que os personagens vestem um uniforme e carregam uma prancheta (ou, mais provavelmente, um tablet) e simplesmente passam pela recepção de segurança de um edifício. Obter acesso físico a esses sistemas pode facilmente contornar muitos dos outros mecanismos de segurança que temos em vigor.

Devido à complexidade de gerenciar seus próprios servidores físicos, cada vez mais projetos estão usando provedores de nuvem para terceirizar esses problemas. Fornecedores como Amazon , Google e Microsoft fornecem sistemas robustos com gerenciamento remoto completo que devem ser considerados para a configuração do seu servidor, a menos que você já tenha experiência e infraestrutura física no local. Construir seus componentes de servidor usando sistemas de contêiner, como Docker oferecem grande flexibilidade na escolha do fornecedor de nuvem e permitem a possibilidade de migrar entre eles, caso seja necessário. A maior vantagem de usar esses provedores é que eles lidam com todas as necessidades de segurança física, permitindo que você se concentre em seus aplicativos. Você normalmente ainda é responsável pela segurança digital de seus nós de computação em nuvem, mas os provedores geralmente fornecem padrões sãos, o que pode acelerar seu desenvolvimento significativamente. Cuidado especial deve ser tomado com os ativos que estão armazenados na nuvem. Houve muitos vazamentos de dados devido a permissões inadequadas em dados armazenados na nuvem. Esses problemas não são problemas com armazenamento em nuvem, mas sim com escolhas específicas de implementação inadequadas.

Qualquer estrutura de atualização exigirá comunicação entre os dispositivos clientes e o servidor. Para garantir a privacidade dos dados, isso será feito por meio de uma conexão criptografada. Protocolos como HTTPS e MQTT são frequentemente usados ​​aqui e cada um tem seus próprios requisitos específicos. As conexões HTTPS e MQTT podem ser criptografadas com TLS . É importante usar chaves TLS devidamente assinadas e atestadas por uma autoridade de certificação (CA) conhecida. Isso permite que dispositivos clientes verifiquem a identidade do servidor sem a necessidade de chaves de verificação específicas no dispositivo. Isso também significa que as chaves do servidor podem ser atualizadas sem modificação no cliente, pois as autoridades de certificação estarão cientes das mudanças.

O gerenciamento de usuários no servidor é outra área de preocupação que deve ser abordada no início de seu projeto. As credenciais de login armazenadas por seu servidor devem ser salgadas e criptografadas adequadamente . Isso fornece boa proteção, mesmo quando os usuários reutilizam senhas em sites. Atribua funções a usuários individuais (isto é, Role Based Access Control ou RBAC) em vez de permissões individuais para limitar o acesso aos recursos de uma maneira previsível e auditável. Mas seu sistema deve ser capaz de revogar permissões específicas ou remover o acesso de um usuário inteiramente para minimizar o dano potencial que pode ocorrer em grandes frotas de dispositivos.

As estruturas de atualização precisarão aceitar conexões não solicitadas de dispositivos implantados em campo. É comum que os dispositivos sejam embalados e colocados em uma prateleira por um longo tempo antes de serem ligados e conectados pela primeira vez. Identificar dispositivos válidos e, mais importante, ignorar tentativas de conexão inválidas são dois dos recursos mais importantes do servidor em uma estrutura de atualização. Cada dispositivo deve ter um identificador exclusivo, como um número de série, que deve ser emparelhado com uma chave criptograficamente segura. As melhores práticas da indústria para comprimentos de chave e seleção de algoritmo ajudarão a proteger contra ataques de força bruta. A equipe de desenvolvimento também deve monitorar os relatórios de segurança em busca de novos pontos fracos que possam ser descobertos em algoritmos específicos para que possam se ajustar de acordo.

Todo software não trivial tem bugs e sua estrutura de atualização exigirá atualizações contínuas ao longo da vida de seu projeto. Com um pacote bem conservado, as atualizações serão planejadas e fáceis de aplicar. Isso também permite adicionar funcionalidade que pode fornecer maior valor para o seu caso de uso. Sua estrutura de atualização provavelmente terá dependências de outros pacotes, como bibliotecas fornecidas por terceiros. A equipe de engenharia da estrutura de atualização deve monitorar o desenvolvimento de quaisquer dependências e garantir que as correções de bug para esses componentes sejam rapidamente incorporadas ao produto.

Por fim, considere quais registros e relatórios estão disponíveis em sua estrutura de atualização. Isso é crucial para questões de segurança, bem como para o bom funcionamento do seu sistema. É fácil obter os relatórios de que você precisa sem ficar sobrecarregado por grandes quantidades de informações irrelevantes? Você pode obter relatórios automáticos? Existem prioridades e escalonamentos para problemas de segurança e outras preocupações operacionais?

Ao decidir sobre uma arquitetura de registro, tome cuidado especial para que as informações contidas nos registros não causem mais problemas. Os registros podem conter informações confidenciais e devem ser criptografados se mantidos no dispositivo ou completamente removidos após serem transmitidos para fora do dispositivo.

Cliente

Conforme discutido acima, o canal de comunicação entre os dispositivos e o servidor deve ser criptografado. Os protocolos padrão da indústria, como TLS, devem ser usados ​​junto com os certificados assinados pela CA usados ​​em seu servidor. Isso garante que o dispositivo pode validar que está se comunicando com o servidor esperado e remove a ameaça de ataques man-in-the-middle. Um outro nível de segurança pode ser alcançado usando um sistema TLS mútuo. Isso permite que o servidor verifique os dispositivos usando um mecanismo semelhante.

Dado que os dispositivos clientes são frequentemente implantados em ambientes de rede hostis com pouco controle da segurança física disponível para os fornecedores de dispositivos, o uso de chaves de segurança baseadas em hardware deve ser fortemente considerado. Esses dispositivos fornecem segurança mais forte para as chaves do que simplesmente armazená-los como arquivos no sistema de arquivos de destino. Se os malfeitores podem acessar fisicamente os dispositivos, os sistemas de arquivos geralmente são facilmente acessíveis. O uso de chaves de hardware fornece outro nível de segurança para ajudar a garantir que as chaves não sejam comprometidas.

As cargas úteis de atualização devem usar assinaturas criptográficas. A abordagem mais forte para isso é usar criptografia de chave pública, que permitirá que você não apenas verifique se a imagem baixada não foi modificada, mas também se é autêntica. O software cliente pode validar a carga útil independentemente da verificação do canal de comunicação, o que separa as verificações da carga útil da infraestrutura. Efetivamente, isso garante que, mesmo se seu servidor for violado, permitindo o download de payloads falsificados, eles nunca serão instalados, pois a verificação de assinatura falhará. Mecanismos de chave pública / privada padrão da indústria devem ser suportados.

Quanto às implicações de segurança do próprio processo de atualização, é vital que o sistema suporte reversões automáticas. Isso garante que os problemas que ocorrem durante o próprio processo de atualização, como perda de energia ou perda de conectividade, não resultem em uma frota de dispositivos bloqueada. Após cada implantação, a estrutura de atualização deve verificar se ainda é capaz de se comunicar com o servidor para garantir que futuras atualizações possam ser instaladas. A estrutura também deve fornecer um mecanismo para permitir que os designers de sistema criem suas próprias verificações de integridade pós-instalação, focando em seu aplicativo exclusivo e adaptado para verificar os recursos que são importantes para verificar antes de considerar uma atualização concluída.

Ferramental

Qualquer sistema que usa certificados digitais e chaves criptográficas precisa de um mecanismo para substituir esses arquivos ao longo do tempo. Quer seja feito periodicamente por precaução ou como resultado de uma violação específica, é prática recomendada que sua estrutura de atualização ofereça suporte a isso. Normalmente, isso exigirá uma atualização em duas etapas. A primeira atualização usará as chaves antigas, mas adicionará as novas chaves e se autenticará novamente com a estrutura usando-as. A segunda atualização removerá as chaves antigas.

Dependendo das necessidades de segurança de seu aplicativo e, particularmente, da tolerância ao risco que sua equipe tem para proteger suas chaves privadas, você pode querer considerar o uso de sistemas com intervalo de ar para aplicar assinaturas digitais às imagens do sistema. São sistemas que não estão ligados a nenhuma rede mas que possuem as ferramentas necessárias para assinar as imagens. As chaves privadas nunca precisam sair deste sistema, então o risco de vazá-las é muito baixo. Isso requer um mecanismo como discos rígidos externos para transportar as imagens de e para o sistema de assinatura, de forma que o risco não seja completamente eliminado, mas seja bastante reduzido.

Integrar uma estrutura de atualização de software OTA em seu produto

Para implantar com êxito um design com uma estrutura de atualização automática OTA, há várias coisas que você precisa considerar. O nível de formalidade em seus processos e design dependerá de vários fatores, incluindo o tamanho de sua frota de dispositivos, o custo para resgatar dispositivos bloqueados e o público-alvo. Se seus usuários são mais práticos (ou seja, fabricantes), então é apropriado ter um sistema mais manual. No entanto, se você planeja implantar uma frota de milhares ou dezenas de milhares de dispositivos, você desejará o máximo de automação possível; confiar que os usuários finais executem etapas complicadas de atualização de firmware é uma receita para dispositivos desatualizados.

O desenvolvimento de software moderno depende fortemente de ferramentas de automação de compilação. Os builds são executados automaticamente em cada commit ou, pelo menos, em uma base programada. Os sistemas que gerenciam essas compilações, conhecidos como sistemas de integração / entrega contínua (CI / CD), têm ferramentas para ajudar a automatizar a implantação de novas compilações com base na fase de desenvolvimento e podem ser prontamente adaptados ao seu fluxo de trabalho de desenvolvimento. Por exemplo, seus builds noturnos de “desenvolvimento” podem ser carregados automaticamente para o servidor OTA e implantados em um grupo de dispositivos específicos. Isso garante que sua equipe de controle de qualidade esteja pronta para começar todas as manhãs com as imagens mais recentes para teste. Da mesma forma, seus builds de “produção” podem ser carregados e preparados para implantação automática em toda a sua frota de dispositivos, mantendo facilmente seus dispositivos em campo atualizados.

Ao projetar o software para um dispositivo embutido conectado (como dispositivos IoT), geralmente você tem uma imagem master de ouro contendo os bits de software que são comuns a todos os dispositivos. Esta imagem provavelmente está programada no dispositivo na fabricação, mas também pode ser feita como uma etapa de pós-fabricação se uma imagem específica da fabricação for usada para o diagnóstico de burn-in. Além dos bits golden-master, seu sistema provavelmente precisará de alguns detalhes exclusivos para cada placa. Isso pode consistir em certificados de segurança, números de série ou quaisquer outros dados que variam de um dispositivo para outro. Muitos mecanismos podem ser usados ​​para preencher os dados exclusivos de seus dispositivos, mas você precisa se planejar para isso. Esses dados geralmente são necessários em outro local do sistema. Por exemplo, Pode ser necessário carregar certificados de identificação de dispositivo no software do servidor para que ele reconheça e aceite automaticamente os dispositivos quando eles se conectarem pela primeira vez. O manuseio adequado desses dados específicos do dispositivo é fundamental para manter a segurança do sistema como um todo.

O uso de uma estrutura de atualização OTA projetada corretamente não deve introduzir problemas de segurança significativos em seu design. As considerações de segurança discutidas acima devem minimizar o impacto da adição dessa funcionalidade. No entanto, observe que adicionar software sempre aumenta sua superfície de ataque, portanto, é crucial que você monitore o desenvolvimento da estrutura de atualização para garantir que está incluindo alterações nesse sistema, bem como em seu próprio software. Todo software tem bugs, mas se você incluir uma estrutura de atualização com capacidade OTA bem mantida em seu projeto, terá a capacidade de responder a problemas sem ter que recorrer a recalls caros ou atualizações manuais pelos usuários finais.

Empacotando

Discutimos muitas considerações para a estrutura de atualização de software OTA e segurança geral do sistema. Esperamos que esteja claro que a segurança é uma preocupação contínua, exigindo vigilância e a capacidade de se adaptar às ameaças em constante mudança. Você não pode estar totalmente seguro e, como tal, considere como responderá quando for violado. Os clientes recompensam a transparência e punem o sigilo, portanto, revele o máximo que puder sobre uma violação, sem reduzir sua capacidade de responder a ameaças futuras.

A atualização do software é geralmente a primeira etapa para tratar das questões de segurança, e o próprio sistema de atualização precisa de uma mentalidade de segurança. Usar as melhores práticas do setor, como criptografia de chave pública / privada, é um requisito mínimo. Seja implementando seu próprio software ou usando uma estrutura de atualização de terceiros, certifique-se de usar um software bem mantido que é atualizado regularmente para resolver problemas e ameaças recém-descobertos. Se o sistema de código aberto que você está usando não tem commits por vários anos, recomendamos fortemente que você continue procurando por algo com uma comunidade de desenvolvimento ativa.

Como nota final, não atrase as discussões sobre segurança até o final da fase de design. Isso precisa fazer parte do seu pensamento desde o início do seu projeto. Nem todos os membros de sua equipe serão especialistas em segurança, mas é importante ter uma mentalidade de segurança em sua organização. Os custos para a sua organização podem ser graves se o seu produto for violado, especialmente se o público considerar que você é negligente.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.