L’Internet des Objets (non sécurisés) : la menace fantôme de l’année 2017

842

L’Internet des Objets (non sécurisés) : la menace fantôme de l’année 2017

James Plouffe, Architecte en chef chez MobileIron
D’après le dernier rapport Hype Cycle for Emerging Technologies, l’IoT n’a pas encore atteint le pic des espérances exagérées (Peak of Inflated Expectations) et n’atteindre pas le plateau de productivité (Plateau of Productivity) d’ici cinq ans à dix ans minimum. Et pourtant, il fait déjà parler de lui de manière positive. Cela va d’histoires assez comiques, comme le fait d’essayer pendant 11 heures de faire bouillir l’eau du thé, à des choses plus affolantes, 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  supposer  qu’un grand nombre de dispositifs connectés se sont bien retrouvés au pied du sapin.  Nous pouvons également en déduire, sans trop nous avancer, que les logiciels dont ces nouveaux gadgets sont équipés ne sont pas moins vulnérables. On parle de menace fantôme de l’Internet des Objets.

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.

Devant la menace imminente d’attaques plus importantes et catastrophiques, il serait possible de se 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.

Si vous êtes reponsables produits ou gestionnaires de programmes : Vous pouvez vous inspirer 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 ? Prenez en compte 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.

Si vous êtes ingénieur informatique ou développeur :  Un mauvais chiffrement est tout aussi mauvais 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é.

Si vous êtes opérateur réseau/sécurité, architecte ou ingénieur :  Il faut se 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.

James Plouffe est architecte en chef chez MobileIron et consultant technique pour la célèbre série Mr. Robot qui s’inspire directement de l’œuvre de Charles Dickens, ainsi que d’autres auteurs. Il possède une bouilloire électrique, mais non connectée.