"Chef, temos uma brecha na segurança!"
- Bem, pelo menos algo está seguro conosco ...Olá Habr!
Nos comentários
do post anterior sobre o InoThings ++, eles expressaram a opinião de que na Internet das Coisas há uma área mais importante para discussão do que a intervenção do governo - essa é a área de garantir a segurança do dispositivo. De todos os pontos de vista.
Posso argumentar aqui com apenas uma coisa - que uma discussão sobre questões de segurança deve ser realizada em um formato de mesa redonda; por esse motivo, deixaremos a mesa redonda como está, com base na necessidade (ou desnecessária) de padrões nacionais e, em geral, na interferência do governo na indústria, mas falaremos sobre segurança separadamente.
Por que a segurança geralmente é considerada na IoT como algo separado e específico, diferente da segurança nos sistemas de TI clássicos?
Sim, em geral, porque os sistemas de IoT são semelhantes aos clássicos apenas por parte do usuário que vê belas fotos na tela do monitor ou controla uma lâmpada de um smartphone - mas por dentro, em um nível baixo, elas são completamente diferentes.
E, infelizmente, ainda engolimos muitas vezes autores de produtos que não entendem as diferenças de abordagem e problemas.
A “Internet das coisas” é, antes de tudo, uma história sobre dispositivos acessíveis, baratos, compactos, econômicos e, portanto, extremamente massivos, conectados a redes de dados locais ou globais.
O que isso significa na prática?
• Geralmente uma
conexão sem fio . Nos fios em que confiamos, é claro, apenas os fios são caros; aqueles que fizeram uma casa inteligente com fio entendem que isso significa uma grande reforma com a colocação de baixa tensão em todos os cantos. E se o fio não puder ser colocado?
Na verdade, o rápido desenvolvimento da IoT começou com o advento de conexões sem fio baratas, econômicas e de longo alcance - de Wi-Fi doméstico e BLE a LoRaWAN, Sigfox, NB-IoT e assim por diante. Conexões que permitiam saturar um determinado espaço com sensores sem se preocupar com a potência e a conexão.
No entanto, o rádio não é apenas conveniência, mas também uma maldição. Se, para se conectar ao fio, os vizinhos precisam abrir as fechaduras da sua porta, eles não apenas “ouvem” sua casa sem fio quase sempre, mas também podem atolá-la ou até mesmo falsificá-la.
• Como regra,
modos de operação extremamente
econômicos do canal de rádio - um dispositivo sem uma fonte de alimentação constante deve ser protegido por uma bateria. Salvar no canal de rádio resulta no fato de que a atualização do firmware do dispositivo por via aérea é impossível ou não faz sentido, porque um episódio da atualização consome dezenas de por cento da bateria disponível.
Consequentemente, a qualidade inicial do código e dos protocolos adquire um significado extremamente alto - se um buraco fatal for descoberto neles, o fabricante, é claro, poderá fazer upload de um novo arquivo em seu site, mas não fará sentido nele.
• Normalmente,
processadores de baixa potência e
baixa potência . Atualmente, um sensor IoT típico é construído em processadores da classe STM32L0 para o STM32L4 mais novo e, simplesmente devido a limitações de memória e poder de processamento (além do canal de rádio, veja acima), pode não gerar autorização complicada, autenticação e outros esquemas de proteção . Além disso, baixa energia também pode significar a falta de memória “extra” necessária para atualizar o firmware pelo ar - o canal de rádio não confiável significa a incapacidade de rolar o firmware diretamente em um flash “ativo” e pode não haver memória para salvá-lo em uma área separada com a reescrita subsequente do firmware em funcionamento .
E sobre tudo isso, a massa e a onipresença abrem suas asas - o que, na prática, significa que o proprietário não tem controle efetivo sobre o acesso aos dispositivos.
Quando você tinha quatro dispositivos Wi-Fi em sua casa - um roteador, um laptop e dois smartphones - o problema de perdê-los não era muito grave, porque nenhum deles era um incidente arremessável.
Quando você tem três ou quatro dúzias de lâmpadas inteligentes, interruptores, sensores de temperatura e o diabo em sua casa, o que mais - você provavelmente enviará outra lâmpada queimada ou apenas uma lâmpada velha para o lixo, sem nem pensar que continua armazenando a chave com segurança no flash da sua rede wifi.
Além disso, se não estamos falando sobre a escala do apartamento, mas sobre o local da cabana, o hotel ou a fábrica - você nem controla o acesso aos dispositivos IoT. Qualquer pessoa pode desaparafusar a lâmpada, drenar as chaves de acesso e parafusá-la em meia hora - e você nem perceberá.
Os dispositivos podem ser clonados. Você pode ler chaves e certificados de dispositivos. O firmware modificado pode ser carregado nos dispositivos.
A questão aqui não é que tudo isso não poderia ser feito com um roteador Wi-Fi - é possível, é claro. A questão é a transição da quantidade para a qualidade: com o prometido aumento exponencial no número de dispositivos de IoT, esses ataques se tornam significativos e realizáveis. De fato, a história das câmeras IP é repetida - embora existissem poucas, ninguém sequer pensou que câmeras com o mesmo buraco no firmware seriam suficientes para fazer sentido escrever um script que as coletasse em uma botnet gigante que poderia inundar o GitHub com Twitter
Como terminou -
todos vocês sabem .
Na segurança clássica das informações, acredita-se que, se um invasor obtém acesso físico completo ao dispositivo protegido - bem, em geral, esse não é o fim, mas tudo está ruim. Na IoT, nesse contexto, "tudo está ruim" - esse não é o resultado de ações maliciosas de alguém, mas o estado permanente e inicial do sistema.
O problema de segurança na IoT não é o problema de amanhã. Este é um problema hoje. Se você não resolver, amanhã não será um problema, mas um desastre.
No InoThings ++, sem dúvida, queremos falar sobre isso também - e como deixar claro para o desenvolvedor que a IoT traz modelos de ameaças completamente novos e sobre o que fazer.
Vou apresentar alguns relatórios.
Um relatório introdutório sobre os problemas de proteção dos dispositivos IoT e as novas ameaças específicas à IoT, com uma análise da legislação russa e das recomendações que já foram emitidas - ainda não como requisitos - de organizações estrangeiras, incluindo
NIST ,
ENISA ,
IIC e
outras (links sob os nomes não apenas links, mas também os documentos relevantes - eu realmente recomendo a leitura deles, se você tiver algo a ver com o desenvolvimento de dispositivos IoT).
Este relatório é simplesmente essencial para integradores e desenvolvedores que entraram recentemente no mercado de IoT e ainda não perceberam totalmente as possíveis conseqüências disso. Não há escolha - essas são coisas que você simplesmente não pode saber sobre a existência e, se não a entender hoje, amanhã poderá acabar para você e sua empresa como um desastre para o qual você simplesmente não terá tempo para se preparar.
Não é de todo um relatório técnico, mas também importante - que agora estamos vivendo um momento feliz, em que todo fabricante pode sussurrar em seus dispositivos o que seu coração deseja, e não haverá nada para ele.
Mais precisamente, sobre o fato de que esse tempo terminará em breve - a necessidade de mudanças legislativas relacionadas à IoT e dispositivos inteligentes em geral amadureceu, e o setor ainda receberá seu GDPR aqui.
O primeiro (necessário, mas não suficiente) passo para a segurança dos sistemas de IoT é escrever um código confiável. Uma maneira de aumentar sua confiabilidade é obedecer aos padrões desenvolvidos em indústrias décadas mais antigas que a IoT - por exemplo, o padrão de qualidade de código MISRA C “automotivo”.
Obviamente, a conformidade com o MISRA C e o uso de analisadores de código estático não garantem confiabilidade absoluta - no entanto, você pode economizar um número razoavelmente grande de erros, começando com negligência banal, copiar e colar e erros de digitação. Infelizmente, a prática de escrever código confiável ainda é muito difundida entre os programadores incorporados - e espero que Philip inspire pelo menos alguns dos participantes da conferência a tentar implementar essas práticas em seus trabalhos.
Outra maneira de aumentar a confiabilidade do código é, em vez de incentivar o disparo com as próprias pernas e outras seleções naturais de idiomas do tipo C, mudar para idiomas que foram originalmente concebidos como mais confiáveis e que não permitem que você cometa muitos erros (agora escrevo com toda a responsabilidade, como pessoa, ontem às duas à noite, capturando um evento de estouro de pilha que ocorreu em momentos aleatórios, às vezes após dezenas de minutos de operação ativa do firmware).
No entanto, quão brilhantes são as perspectivas, são tão vagas e o presente dessas linguagens - por exemplo, Rust, o principal candidato para o papel do futuro padrão no campo do software embarcado, para a maioria dos programadores profissionais pertence à categoria “eu ouvi, é legal, mas o que tenho agora?”. Isso é especialmente facilitado pela curva tradicional de hype, pela qual a Rust viaja - ela subiu ao topo, sendo abertamente despreparada para uso prático sério, após o qual muitos desenvolvedores simplesmente pararam de monitorar seu destino futuro.
Então, de fato, no relatório, Eugene dirá qual é o destino atual do Rust, por que ele já pode ser considerado como uma linguagem de trabalho e quantos quilômetros de terminações nervosas custarão para você usá-lo aqui e agora.
E, finalmente, um relatório puramente prático - sobre o que é necessário para garantir a confiança em seus dispositivos, se você já os tiver instalado em algumas centenas de peças e, ao mesmo tempo, saiba com certeza que a qualquer momento pelo menos várias dezenas estão nos armários, que você esqueceu de trancar e no qual alguém possa entrar a qualquer momento, mescle o firmware e preencha-o com algo parecido com o mesmo dispositivo, mas não o seu, mas ele.
Além disso, não basta controlar esses dispositivos - eles devem ser implantados primeiro, o que, do ponto de vista da autenticação, também pode ser uma tarefa não trivial.
InoThings ++ 2019
Portanto, todos esses relatórios - assim como muitos outros - podem ser ouvidos na conferência InoThings ++, e o que é especialmente valioso não é apenas ouvir, mas terminar seus discursos e levá-los à margem para continuar a conversa. Na verdade, é isso que torna uma visita animada a conferências de tecnologia valiosa - observando a gravação de uma apresentação ou um álbum em uma apresentação de slides meio ano depois, você não pode se levantar e pedir mais detalhes naquele momento, levar o orador a uma xícara de café para falar com mais detalhes sobre seus projetos e assim por diante e assim por diante.
Portanto venha.
Atualmente, os ingressos
custam 15 mil rublos e, acredite, para uma conferência desse nível e com esses palestrantes - isso é muito modesto.
