"Chef, nous avons un trou de sécurité!"
- Eh bien, au moins quelque chose est en sécurité avec nous ...Bonjour, Habr!
Dans les commentaires
du précédent article sur InoThings ++, ils ont exprimé l'opinion que sur l'Internet des objets, il y a un domaine de discussion plus important que l'intervention du gouvernement - c'est le domaine de la sécurité des appareils. De tous les points de vue.
Je peux argumenter ici avec une seule chose - qu'une discussion sur les questions de sécurité devrait se tenir sous forme de table ronde; pour cette raison, nous quitterons la table ronde telle quelle, sur la nécessité (ou l'inutilité) des normes nationales et, en général, l'ingérence du gouvernement dans l'industrie, mais nous parlerons de la sécurité séparément.
Pourquoi la sécurité est-elle généralement considérée dans l'IoT comme quelque chose de séparé et de spécifique, contrairement à la sécurité dans les systèmes informatiques classiques?
Oui, en général, car les systèmes IoT ne sont similaires aux systèmes classiques que de la part de l'utilisateur qui voit de belles images sur l'écran du moniteur ou contrôle une ampoule à partir d'un smartphone - mais à l'intérieur, à un niveau bas, ils sont complètement, complètement différents.
Et, malheureusement, nous déglutissons encore de nombreuses fois avec des auteurs de produits qui ne comprennent pas les différences d'approche et les problèmes.
L '«Internet des objets» est avant tout une histoire d'appareils abordables, bon marché, compacts, économiques et donc extrêmement massifs connectés à des réseaux de données locaux ou mondiaux.
Qu'est-ce que cela signifie dans la pratique?
• Généralement une
connexion sans fil . Dans le fil, nous avons confiance, bien sûr, seul le fil est cher; ceux qui ont fait une maison intelligente filaire comprennent que cela signifie une révision majeure avec la pose de basse tension dans tous les coins. Et si le fil ne peut pas être posé du tout?
En fait, le développement rapide de l'IoT a commencé avec l'avènement de connexions sans fil bon marché, économiques et à longue portée - du Wi-Fi domestique et du BLE à LoRaWAN, Sigfox, NB-IoT, etc. Connexions qui ont permis de saturer un certain espace avec des capteurs sans se soucier de leur puissance et de leur connexion.
Cependant, la radio n'est pas seulement une commodité, mais aussi une malédiction. Si, pour se connecter au fil, les voisins doivent ouvrir les serrures de votre porte, ils non seulement «entendent» presque toujours votre maison sans fil, mais ils peuvent également la bloquer ou même la simuler.
• En règle générale,
les modes de fonctionnement extrêmement
économiques du canal radio - un appareil sans alimentation constante doit être protégé par une batterie. Économiser sur la chaîne radio entraîne le fait que la mise à jour du micrologiciel de l'appareil par voie aérienne est soit impossible, soit dénuée de sens du fait qu'un épisode de la mise à jour consomme des dizaines de pour cent de la batterie disponible.
En conséquence, la qualité initiale du code et des protocoles acquiert une importance extrêmement élevée - si un trou fatal y est découvert, le fabricant sera bien sûr en mesure de télécharger un nouveau fichier sur son site Web, mais cela n'aura aucun sens.
• Généralement,
processeurs basse consommation et
basse consommation . De nos jours, un capteur IoT typique est construit sur des processeurs de la classe du STM32L0 au plus jeune STM32L4, et simplement en raison des limitations de la mémoire et de la puissance de traitement (ainsi que du canal radio, voir ci-dessus) peut ne pas tirer des autorisations complexes, une authentification et d'autres schémas de protection . De plus, une faible puissance peut également signifier le manque de mémoire «supplémentaire» nécessaire pour la mise à jour du micrologiciel par voie hertzienne - le canal radio peu fiable signifie l'impossibilité de faire rouler le micrologiciel directement dans un flash «en direct», et il peut ne pas y avoir de mémoire pour le sauvegarder dans une zone distincte avec une réécriture ultérieure du micrologiciel de travail .
Et sur tout cela, la masse et l'ubiquité déploient leurs ailes - ce qui signifie en pratique que le propriétaire n'a aucun contrôle effectif sur l'accès aux appareils.
Lorsque vous aviez quatre appareils Wi-Fi dans votre maison - un routeur, un ordinateur portable et deux smartphones - le problème de les perdre n'était pas très aigu, car aucun d'entre eux n'était un incident jetable.
Lorsque vous avez trois ou quatre douzaines d'ampoules intelligentes, interrupteurs, capteurs de température et le diable dans votre maison quoi d'autre - vous enverrez très probablement une autre ampoule grillée ou juste une vieille ampoule à la poubelle sans même penser qu'elle continue de stocker de manière fiable la clé dans votre flash depuis votre réseau wifi.
De plus, si nous ne parlons pas de l'échelle de l'appartement, mais du site du chalet, de l'hôtel ou de l'usine - vous ne contrôlez même pas l'accès aux appareils IoT. N'importe qui peut dévisser votre ampoule, en vider les clés d'accès et la revisser en une demi-heure - et vous ne le remarquerez même pas.
Les appareils peuvent être clonés. Vous pouvez lire les clés et les certificats des appareils. Le micrologiciel modifié peut être téléchargé sur les appareils.
La question ici n'est pas que tout cela ne puisse pas être fait avec un routeur Wi-Fi - c'est possible, bien sûr. Le problème est le passage de la quantité à la qualité: avec l'augmentation exponentielle promise du nombre d'appareils IoT, ces attaques deviennent significatives et réalisables. En fait, l'histoire avec les caméras IP se répète - alors qu'il y en avait peu, personne ne pensait même que les caméras avec le même trou dans le firmware suffiraient pour écrire un script qui les recueille dans un botnet géant qui pourrait inonder GitHub avec Twitter
Comment cela s'est terminé -
vous le savez tous .
Dans la sécurité classique de l'information, on pense que si un attaquant a un accès physique complet à l'appareil protégé - eh bien, en général, ce n'est pas la fin, mais tout va mal. Dans l'IoT dans ce contexte, «tout est mauvais» - ce n'est pas le résultat d'actes malveillants de quelqu'un, mais l'état permanent et initial du système.
Le problème de sécurité dans l'IoT n'est pas le problème de demain. C'est un problème aujourd'hui. Si vous ne le résolvez pas, demain ce ne sera pas un problème, mais un désastre.
Chez InoThings ++, entre autres choses, sans aucun doute, nous voulons en parler aussi - et comment faire comprendre au développeur que l'IoT apporte des modèles de menace complètement nouveaux, et parler de ce qu'il faut faire à ce sujet.
Je vais présenter quelques rapports.
Un rapport introductif sur les problèmes de protection des dispositifs IoT et les nouvelles menaces spécifiques à l'IoT, avec une analyse de la législation russe et des recommandations qui ont déjà été émises - pour l'instant non obligatoires - par des organisations étrangères, dont le
NIST , l'
ENISA , l'
IIC et d'
autres (liens sous les noms pas seulement des liens, mais des documents pertinents - je recommande vraiment, vraiment de les lire si vous avez quelque chose à voir avec le développement de dispositifs IoT).
Ce rapport est tout simplement un incontournable pour les intégrateurs et les développeurs qui sont récemment entrés sur le marché de l'IoT et n'ont pas encore pleinement compris les conséquences possibles de cela. Il n'y a pas de choix ici - ce sont des choses que vous ne pouvez tout simplement pas ignorer sur l'existence, et si vous ne le comprenez pas aujourd'hui, demain cela pourrait se terminer en désastre pour vous et votre entreprise, pour lequel vous n'aurez tout simplement pas le temps de vous préparer.
Ce n'est pas du tout un rapport technique, mais aussi un rapport important - que nous vivons maintenant à une époque heureuse, où chaque fabricant peut chuchoter dans ses appareils ce que son cœur désire, et il n'y aura rien pour lui.
Plus précisément, sur le fait que cette période se terminera bientôt - la nécessité de modifications législatives liées à l'IoT et aux appareils intelligents en général est arrivée à maturité, et l'industrie recevra toujours son RGPD ici.
La première étape (nécessaire, mais non suffisante) de la sécurité des systèmes IoT consiste à écrire du code fiable. Une façon d'augmenter sa fiabilité est de se conformer aux normes développées dans des industries qui sont des décennies plus anciennes que l'IoT - par exemple, la norme de qualité du code MISRA C «automobile».
La conformité avec MISRA C et l'utilisation d'analyseurs de code statiques seuls, bien sûr, ne vous garantissent pas une fiabilité absolue - cependant, cela peut vous éviter un nombre assez important d'erreurs, à commencer par une négligence banale, un copier-coller et des fautes de frappe. Malheureusement, la pratique d'écrire du code fiable est très mal répartie parmi les programmeurs intégrés - et j'espère que Philip inspirera au moins certains des participants à la conférence à essayer de mettre en œuvre ces pratiques dans leur travail.
Une autre façon d'augmenter la fiabilité du code est au lieu d'encourager le tir sur vos propres jambes et d'autres sélections naturelles de langages de type C, passez à des langues qui ont été conçues à l'origine comme plus fiables et ne vous permettent pas de faire beaucoup d'erreurs (j'écris maintenant avec toute la responsabilité, en tant que personne, hier à deux heures la nuit, capture d'un événement de débordement de pile qui s'est produit à des moments aléatoires, parfois après des dizaines de minutes de fonctionnement actif du micrologiciel).
Cependant, à quel point les perspectives sont brillantes, elles sont tout aussi vagues et le présent de ces langages - par exemple, Rust, le principal candidat pour le rôle de la future norme dans le domaine des logiciels embarqués, pour la plupart des programmeurs pratiquants appartient à la catégorie `` J'ai entendu, c'est cool, mais pourquoi ai-je maintenant? ''. Cela est particulièrement facilité par la courbe de battage médiatique traditionnelle, le long de laquelle rouille Rust - elle a atteint son sommet, n'étant ouvertement pas préparée à une utilisation pratique sérieuse, après quoi de nombreux développeurs ont simplement cessé de surveiller son futur destin.
Donc, en fait, dans le rapport, Eugene vous dira quel est le sort actuel de Rust, pourquoi il peut déjà être considéré comme une langue de travail et combien de kilomètres de terminaisons nerveuses il vous en coûtera pour l'utiliser ici et maintenant.
Et enfin, un rapport purement pratique - sur ce qu'il faut pour garantir la confiance dans vos appareils, si vous les avez déjà installés quelques centaines de pièces, et en même temps, assurez-vous qu'à tout moment au moins plusieurs dizaines d'entre elles sont dans les armoires, que vous avez oublié de verrouiller et dans lequel à tout moment n'importe qui peut entrer, fusionner le firmware et le remplir avec quelque chose comme le même appareil, mais pas le vôtre, mais lui.
De plus, il ne suffit pas de contrôler ces appareils - ils doivent d'abord être déployés, ce qui, du point de vue de l'authentification, peut également être une tâche plutôt banale.
InoThings ++ 2019
Ainsi, tous ces rapports - ainsi que de nombreux autres - peuvent être entendus lors de la conférence InoThings ++, et ce qui est particulièrement précieux n'est pas seulement d'entendre, mais de mettre fin à leurs discours et de les prendre sur la touche pour poursuivre la conversation. En fait, c'est ce qui rend une visite animée à des conférences technologiques précieuse - en regardant un enregistrement d'une performance ou d'un album sur un diaporama six mois plus tard, vous ne pouvez pas vous lever et demander plus de détails à ce moment-là, emmener le haut-parleur dans une tasse de café pour parler plus en détail de ses projets, et et ainsi de suite.
Venez donc. Les billets
coûtent actuellement 15 mille roubles , et croyez-moi, pour une conférence de ce niveau et avec de tels orateurs - c'est très modeste.
