Catégories
conférences

C&ESAR 2016 – J3


Telecom-ParisTech – Cyber-physical protections for IoT

(Le mr parle d’attaques cyber pour des attaques logicielles, je vous fait la traduction hein 😉 ). Petite comparaison entre attaques logicielles type mĂ©mory leak avec les side channel classifiĂ©e par l’orateur comme « passive », et les attaques « actives » avec cotĂ© logiciel le « stack smashing », et cotĂ© physique l’injection de faute. Pour les attaques physiques, l’Ă©quilibrage est un moyen d’empĂȘcher l’exploitation de side-channels. Ou encore des rotations de clefs ou de la gĂ©nĂ©ration de bruit Ă  l’aide de code exĂ©cutĂ© uniquement pour gĂ©nĂ©rer du bruit EM. CotĂ© injections de faute, la redondance peut servir. Retour cotĂ© sĂ©curitĂ©s logicielles anti-exploitation: DEP, ASLR, FatPointer.
Pour se protĂ©ger contre les attaques logicielles, l’orateur propose deux protections, l’une avec une instruction spĂ©ciale REV qui exĂ©cute des basic-bloc chiffrĂ©s (ça fait penser Ă  SGX). L’autre qui viens protĂ©ger les addresses de retour nommĂ© PCX (PC=program counter). SCALL: Pour dĂ©tecter le ROP/JOP et autre call oriented programming, l’orateur propose d’intĂ©grer au processeur une « shadow stack » que le processeur utilisera pour contrĂŽler l’intĂ©griter de la pile. HCODE: Pour protĂ©ger l’intĂ©gritĂ© des basic block, l’orateur propose de stocker un hash des basic block dans l’ELF du programme et de faire vĂ©rifier par le CPU au runtime la validitĂ© de ce hash pour chaque basic bloc. Cette technique de contrĂŽle d’intĂ©gritĂ© des basic block Ă  l’avantage de protĂ©ger contre certaines injections de faute. (Une bonne prĂ©sentation avec des idĂ©es intĂ©ressantes qui rejoint la problĂ©matique d’adaptation des SoC aux besoins de sĂ©curitĂ© Ă©voquĂ© prĂ©cĂ©dement ). L’ensemble des propositions Ă  Ă©tĂ© implĂ©mentĂ©e sur FPGA.

HP – SĂ©curisation d’objets connectĂ©s sur le rĂ©seau

Il faut distinguer un objet connectĂ© isolĂ© d’une flotte. En effet, un paquet envoyĂ©e Ă  un objet connectĂ© est difficile Ă  identifiĂ© comme lĂ©gitime ou non. Lorsque ce mĂȘme paquet est comparĂ© Ă  ce qui est envoyĂ© au reste de la flotte, il est plus facile de l’identifier. CotĂ© sĂ©curisation Ă  la volĂ©e, il est trĂšs difficile de reconfigurer/patcher/sĂ©curisĂ© un object connectĂ© si ça n’a pas Ă©tĂ© pensĂ© dans les fonctionnalitĂ©s de l’objet. A partir de ces constats, l’orateur propose de dĂ©porter les fonctions de sĂ©curitĂ© sur la pĂ©riphĂ©rie de l’objet, cad sa passerelle d’interconnexion (ou gateway/hub/box). L’orateur prĂ©sente un DSL pour gĂ©nĂ©rer des rĂšgles de protection pĂ©rimĂ©triques (=firewall) adaptĂ©s aux capacitĂ©s des applications prĂ©sentes dans la flotte d’IoT et dans les gateway (FP7 SECURED et ses sources).

Le projet SHIELD quand Ă  lui, utilise les techniques d’analyse de donnĂ©s &machine learning pour identifier les attaques. Une fois l’attaque dĂ©tectĂ©, le rĂ©seau est re-configurĂ© Ă  la voilĂ©e Ă  coup de SDN/SDS pour rĂ©tablir la sĂ©curitĂ© de l’ensemble. (une prĂ©sentation de haut niveau avec un fond technique et pas de marketing, c’est aprĂ©ciable).

CNIL – Vie privĂ©e & Objets connectĂ©s

L’informatique doit ĂȘtre au service des citoyens. La CNIL Ă  pour mission de faire respecter tout les aspect de la loi Informatique & LibertĂ©s. En amont du dĂ©ploiement d’un systĂšme, la CNIL peut effectuer une analyse au regard des traitements effectuĂ©s et des guidelines issue des rĂ©fĂ©rentiels de sĂ©curitĂ©. Cette analyse fait l’objet d’une dĂ©cision argumentĂ©e et accompagnĂ© de conseils pour la mise en oeuvre du systĂšme. Lors de contrĂŽles Ă  posteriori, c’est plutĂŽt des sanctions qui tombent. Les donnĂ©es Ă  caractĂšre personnel sont nombreuses avec une gradation dans la sensibilitĂ© de ces derniĂšres. La CNIL Ă  aussi une mission de veille sur l’impact des nouvelles technologies sur la vie privĂ©e. CookieViz,

Le rĂšglement EuropĂ©en sur la vie privĂ©e apporte un bouleversement du modĂšle actuel. Pour les personnes, chaque citoyen Ă  un Droit Ă  l’oubli, ainsi que le droit Ă  la portabilitĂ© de ses donnĂ©es. Elle introduit la possibilitĂ© d’un recours collectif Ă  ce sujet. Pour les entreprises, les formalitĂ©s sont allĂ©gĂ©s, mais leur responsabilitĂ© est bien plus grande. Chaque traitement doit faire l’objet d’une Ă©tude d’impact sur la vie privĂ©e des utilisateurs. Et la solution doit ĂȘtre Privacy by design et Privacy by default.

Retour sur les objets connectĂ©s: ces objets collectent des donnĂ©es de diverse natures, proches & personnelles pour les capteurs e-santĂ©, ou au contraire environnementaux ou Ă©loignĂ©s comme la domotique ou les smart-city/smart-car. La collecte des donnĂ©es doit avoir une finalitĂ© explicite (on ne garde pas les donnĂ©es sans en dĂ©finir l’usage). La CNIL travaille avec les constructeur pour leur fournir des « packs de conformité » et des guides pour diffuser les bonnes pratiques et simplifier les formalitĂ©s pour les professionnels. DiffĂ©rents scĂ©narii sont envisagĂ©s. In->In les donnĂ©es sont rĂ©-utilisĂ© dans l’environnement de l’utilisateur. In->Out ou les donnĂ©es sont transmises dans le cloud. et enfin In->Out->In ou les donnĂ©es sont traitĂ©s dans le cloud et re-descendus. ForcĂ©ment, si ça sort de la sphĂšre privĂ©e, il faut se conformer Ă  la loi.

L’IoT prĂ©sente des risques trĂšs proches Ă  ceux du BigData. Le G29 Ă  publiĂ© un avis Ă  ce sujet.

Table Ronde – IoT & SĂ©curitĂ©

Labellisation et IoT: soit on est sur des labellisation fortes pour des objets haut de gamme type CSPN, soit des labellisation « dĂ©claratives » façon label rouge, et restera toujours ceux qui ne font rien cotĂ©. La sĂ©curitĂ© des IoT ne sera pas portĂ© par les experts seuls, parce-que ces experts sont trop rares pour ĂȘtre en capacitĂ© de former l’ensemble des dĂ©veloppeurs. Il faut donc appuyer le dĂ©veloppeur par des outils et des frameworks qui permettent aux IoT d’ĂȘtre secure by design. On ne peut pas rattraper toutes les erreurs accumulĂ©s lors d’une Ă©valuation, il faut que cette compĂ©tence et cette implication sĂ©curitĂ© doit descendre jusqu’au dev. Il faut aussi que les crĂ©ateurs de plateformes doivent sandboxer les applications car on ne sait jamais quel est le niveau de compĂ©tences en sĂ©curitĂ© Ă  priori.

SĂ©curiser les objets en eux-mĂȘme, c’est plutĂŽt complexe. par contre en les intĂ©grant dans une architecture de sĂ©curitĂ© qui permet de les dĂ©fendre. le cloisonnement est une approche traditionnelle dans la SSI qui permet d’y appliquer des politiques de sĂ©curitĂ© et de limiter l’impact d’une compromission. C’est un peu le diviser pour mieux rĂ©gner.

Analyser la sĂ©curitĂ© de l’IoT dans son contexte Ă  plus de sens qu’une analyse limitĂ©e Ă  l’objet en lui mĂȘme. Une voiture n’est pas un IoT comme les autres, puisqu’il s’agit plus d’un SI roulant avec ses problĂ©matiques de mises Ă  jour qui imposent une interconnexion ponctuelle. Les vĂ©hicules avant n’avaient pas de notion d’identitĂ©, on identifiait surtout le vĂ©hicule, mais va Ă©merger sous peu une notion d’identitĂ© du conducteur pour diffĂ©rencier entre l’usager, le garagiste et le constructeur et d’adapter ses capacitĂ©s d’action sur le SI-vĂ©hicule.

La gestion d’une flotte d’IoT fait rappel aux problĂ©matiques des tĂ©lĂ©phones mobiles, mais dans des dimensions plus grandes avec des capacitĂ©s plus faibles. Il s’agit donc d’une problĂ©matique ouverte dont les premiers cas sont visibles dans la gestion des flottes de vĂ©hicules Ă©quipĂ©s de dispositifs de suivis GPS. Ce type d’Ă©quipement apporte des problĂšmes de privacy pour les salariĂ©s. Il n’y a pas de solution universelle pour la vie privĂ©e, il faut que les informations collectĂ©s soient proportionnĂ©s par rapport aux finalitĂ©s de traitement. Ces informations personnelles peuvent ĂȘtre filtrĂ©s et limitĂ©s au minimum nĂ©cessaire pour le fonctionnement du service associĂ©.

Le dĂ©fi des objets connectĂ©s en entreprise et de leur acceptation au sein de l’entreprise est loin d’ĂȘtre rĂ©solu, mais le cloisonnement est la piste de rĂ©ponse. il faut savoir poser des limites.

Discours de Cloture

l’Amiral Coustillere Ă  sous sa responsabilitĂ© l’ensemble des facettes de la sĂ©curitĂ© informatique qui concernent les forces armĂ©s. Dans un espace de plus en plus en contact du numĂ©rique, le ministĂšre de la dĂ©fense, conscient de ces enjeux investis massivement et recrute massivement pour y rĂ©pondre. une grande partie de ces investissement concernent la rĂ©gion Bretagne dans la dynamique du pĂŽle d’excellence cyber. Face Ă  un « ennemi » numĂ©rique, il faut savoir reprendre l’initiative et ĂȘtre mobile. En matiĂšre numĂ©rique, cela se traduit par l’innovation dans le domaine numĂ©rique. Cette innovation doit ĂȘtre alimentĂ©s par des savoir faire rĂ©gionaux dont la vocation est de rayonner au niveau europĂ©en et international. Des botnets « surprise » comme miraĂŻ font Ă©voluer les rĂ©flexions stratĂ©giques pour la dĂ©fense notamment la rĂ©silience des rĂ©seaux face aux attaques DDoS massives, tout comme l’usage des rĂ©seaux sociaux par les organisations terroriste pour la diffusion de sa propagande. Ces rĂ©seaux sociaux sont un facteur d’influence qui Ă  un impact sur la vie politique comme la vie militaire. L’internet et l’informatique c’est des surprises tout les 6 mois, une matiĂšre vivante qu’il faut suivre quotidien, et il faut savoir ĂȘtre flexible pour s’adapter Ă  l’adversaire et Ă©viter l’effet « ligne maginot ».
ForcĂ©ment la rĂ©ponse Ă  ces dĂ©fis dĂ©pend de ressources humaines consĂ©quentes et compĂ©tentes. Ces ressources Ă©mergent et Ă©voluent dans de petites structures innovantes qu’il faut prĂ©server et nourrir. Le ministĂšre de la dĂ©fense peut ĂȘtre une Ă©tape de carriĂšre intĂ©ressante en SSI.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *