Si on en croit le dernier rapport Hype Cycle for Emerging Technologies, l'Internet des Objets (IoT) n'a pas encore atteint le pic des espérances exagérées (Peak of Inflated Expectations) et ne parviendra pas au plateau de productivité (Plateau of Productivity) avant cinq à dix ans.
Et pourtant, il fait déjà parler de lui de manière positive. Cela va d'histoires amusantes, comme le fait d'essayer pendant 11 heures de faire bouillir l'eau du thé, à des nouvelles plus inquiétantes, comme cette cyberattaque record par déni de service distribué (DDoS, Distributed Denial of Service) contre le site Web du journaliste Brian Krebs en passant par l’attaque - aussi record - contre Dyn (fournisseur d'une infrastructure de services DNS essentielle au fonctionnement d'Internet) qui s'est traduite par une panne géante de la toile sur la côte Est des États-Unis, ou encore, plus récemment, l'attaque contre les routeurs ADSL domestiques qui a privé près d'un million d'Allemands de connexion Internet. Le dénominateur commun de ces cyberattaques ? Des terminaux vulnérables connectés à Internet et dans le collimateur du botnet Mirai ou de ses variantes.
Si les publicités diffusées en fin d’année sont un indice de ce qu’ont été les cadeaux offerts à Noël, on peut deviner qu’un grand nombre de dispositifs connectés se sont bien retrouvés au pied du sapin. Nous pouvons aussi en déduire, sans trop nous avancer, que les logiciels dont ces nouveaux gadgets sont équipés ne sont pas moins vulnérables. C'est la menace fantôme de l'IoT. Face à tous ces appareils photo vulnérables à SQLi, à ces DVR avec mot de passe par défaut non modifiable, à ces systèmes de sécurité domestique piratables à loisir dont le firmware ne peut être mis à niveau, et à ces routeurs dont la configuration peut être modifiée sans authentification avec une connexion non chiffrée, la question est de savoir ce qui peut être fait.
Face à la menace imminente d'attaques plus importantes et désastreuses, nous pourrions nous tourner vers le néo-luddisme, et renoncer aux technologies ou nous employer activement à les détruire. Certes, la menace serait neutralisée, mais cette « solution » est tout aussi irréalisable que le pronostic est irréaliste. Nous pourrions également émettre cette hypothèse tout aussi utopique selon laquelle nous allons tout d'un coup nous surpasser en programmation, faisant disparaître comme par magie toutes ces failles. Voici donc quelques conseils concrets qui vous seront utiles quelque soit votre métier.
Vous êtes responsable produits ou gestionnaire de programmes ?
Inspirez-vous de Benjamin Franklin : « Il vaut mieux créer un code pour prévenir plutôt que pour guérir », une position peu téméraire, mais qui constitue un excellent point de départ. Vous devez intégrer la sécurité et son cycle de vie dans la conception de vos produits. Cela peut faire peur, mais c'est en fait plus facile (et, encore mieux, plus économique) qu'il n'y paraît. Vous êtes sceptique ? Lisez les excellentes recommandations de John Overbaugh de chez InfoSecure.io sur le cycle de vie du développement sécurisé (SDLC) avec un budget dérisoire. En matière de coûts, gardez ce point à l'esprit : modifier techniquement et conceptuellement un produit en dernière phase d'un projet parce que l'audit de sécurité réalisé lors de la validation de son cycle de vie n'était pas bon vous coûtera moins cher que de revoir la conception et la création d'un produit après sa commercialisation.
Vous êtes développeur ou ingénieur informatique ?
Un mauvais chiffrement ne vaut guère mieux que l'absence de chiffrement. Essayez les défis du site Cryptopals (Cryptopals Crypto Challenges). Mettez à profit ces huit exercices pour affiner votre compréhension de la cryptographie logicielle, en particulier l'identification, l'exploitation et la prévention des failles du chiffrement. Apprenez à effectuer des tests d'intrusion, car vous pouvez être sûr que la « Red Team » de quelqu'un s'attaquera à votre logiciel. Alors, autant prendre les devants. En étant conscient de la manière dont les attaques contre les applications se produisent, vous apprendrez à éviter les erreurs les plus courantes et rédigerez un code plus sécurisé.
Vous êtes architecte, ingénieur ou opérateur réseau ou sécurité ?
Il est grand temps de vous préoccuper des « MANRS ». Oui, c'est naturel de vouloir bien faire pendant les fêtes de fin d'année, mais les normes communément adoptées d'Internet Society en matière de sécurité du routage (MANRS, Mutually Agreed Norms for Routing Security) fournissent un cadre simple qui permet au « I » de « IoT » de se tenir bien droit tout au long de l'année. Les recommandations MANRS mettent en avant quatre actions et tout responsable de réseau se doit d'accomplir la seconde : prévenir tout trafic d'adresses IP provenant de sources usurpées. L'impact des cyberattaques DDoS qui se sont produites en 2016 aurait facilement pu être limité si le trafic issu des adresses usurpées avait été relégué en marge d'Internet. Si, en guise de bonne résolution pour la nouvelle année, vous voulez vous impliquer davantage, envisagez sérieusement de segmenter le réseau. Les dispositifs IoT vulnérables constituent des cibles parfaites et sont des tremplins vers les autres segments de votre infrastructure. Si segmenter le réseau n'est pas une mince affaire, c'est votre meilleure parade contre les dispositifs IoT faciles à pirater.