« Fuzzing dans l'Internet des objets » : différence entre les versions
| Ligne 30 : | Ligne 30 : | ||
== Fuzzing des systèmes embarqués == |
== Fuzzing des systèmes embarqués == |
||
Les systèmes embarqués sont de plus en plus présent dans notre vie quotidienne. Leurs interconnexions avec d’autres appareils proposant différents services en ligne en font des acteurs essentiels de l’Internet des Objets. Cependant, l’augmentation rapide du nombre d’appareils connectés s’accompagne d’un accroissement de |
Les systèmes embarqués sont de plus en plus présent dans notre vie quotidienne. Leurs interconnexions avec d’autres appareils proposant différents services en ligne en font des acteurs essentiels de l’Internet des Objets. Cependant, l’augmentation rapide du nombre d’appareils connectés s’accompagne d’un accroissement de la surface d’attaque, et les systèmes fortement contraints sont considérés comme particulièrement vulnérables. Le fuzzing est une technique très populaire pour découvrir des failles de sécurité, il peut être automatisé à grande échelle même avec une connaissance limité du système à tester, mais un traitement particulier est parfois requis lorsqu'il s'agit de l'appliquer aux systèmes embarqués.<ref name=":5" /> |
||
=== Dans le secteur industriel === |
=== Dans le secteur industriel === |
||
Les systèmes embarqués sont couramment utilisés dans les dispositifs de supervision industriels, mais la compatibilité des réseaux industriels avec Internet est une tendance récente qui les rend vulnérables aux cyber-attaques. Cette tendance entraîne donc un besoin croissant de tests de sécurité de ces réseaux. Grâce au fuzzing des implémentations de protocoles réseau industriels il est possible d’obtenir des informations sur la résilience des systèmes face aux nouvelles menaces en provenance d’Internet. Cependant, les outils de fuzzing traditionnels ne conviennent pas à ces systèmes complexes conçus pour fonctionner en vase clos, on voit donc apparaître de nouveaux outils de fuzzing spécialisés, dédiés par exemple au protocole [[Modbus|Modbus/TCP]]<ref>{{Article|langue=en-US|auteur1=|prénom1=Artemios G.|nom1=Voyiatzis|prénom2=Konstantinos|nom2=Katsigiannis|prénom3=Stavros|nom3=Koubias|titre=A Modbus/TCP Fuzzer for testing internetworked industrial systems|périodique=2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA)|date=2015|issn=|doi=10.1109/etfa.2015.7301400|lire en ligne=https://doi.org/10.1109/ETFA.2015.7301400|consulté le=2018-01-06|pages=}}</ref> |
Les systèmes embarqués sont couramment utilisés dans les dispositifs de supervision industriels, mais la compatibilité des réseaux industriels avec Internet est une tendance récente qui les rend vulnérables aux cyber-attaques. Cette tendance entraîne donc un besoin croissant de tests de sécurité de ces réseaux. Grâce au fuzzing des implémentations de protocoles réseau industriels il est possible d’obtenir des informations sur la résilience des systèmes face aux nouvelles menaces en provenance d’Internet. Cependant, les outils de fuzzing traditionnels ne conviennent pas à ces systèmes complexes conçus pour fonctionner en vase clos, on voit donc apparaître de nouveaux outils de fuzzing spécialisés, dédiés par exemple au protocole [[Modbus|Modbus/TCP]]<ref>{{Article|langue=en-US|auteur1=|prénom1=Artemios G.|nom1=Voyiatzis|prénom2=Konstantinos|nom2=Katsigiannis|prénom3=Stavros|nom3=Koubias|titre=A Modbus/TCP Fuzzer for testing internetworked industrial systems|périodique=2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA)|date=2015|issn=|doi=10.1109/etfa.2015.7301400|lire en ligne=https://doi.org/10.1109/ETFA.2015.7301400|consulté le=2018-01-06|pages=}}</ref>, aux spécifications [[OLE for Process Control|OPC]]<ref>{{Article|langue=|auteur1=|prénom1=Xiong|nom1=Qi|prénom2=Peng|nom2=Yong|prénom3=Zhonghua|nom3=Dai|prénom4=Shengwei|nom4=Yi|titre=OPC-MFuzzer: A Novel Multi-Layers Vulnerability Detection Tool for OPC Protocol Based on Fuzzing Technology|périodique=International Journal of Computer and Communication Engineering|volume=3|numéro=4|date=2014|issn=|doi=10.7763/ijcce.2014.v3.339|lire en ligne=http://www.ijcce.org/index.php?m=content&c=index&a=show&catid=42&id=400|consulté le=2018-01-06|pages=300–305}}</ref> ou encore aux systèmes de télégestion [[Système d'acquisition et de contrôle de données (SCADA)|SCADA]]<ref>{{Article|langue=en|prénom1=Rebecca|nom1=Shapiro|prénom2=Sergey|nom2=Bratus|prénom3=Edmond|nom3=Rogers|prénom4=Sean|nom4=Smith|titre=Identifying Vulnerabilities in SCADA Systems via Fuzz-Testing|périodique=Critical Infrastructure Protection V|série=IFIP Advances in Information and Communication Technology|éditeur=Springer, Berlin, Heidelberg|date=2011-03-23|isbn=9783642248634|doi=10.1007/978-3-642-24864-1_5|lire en ligne=https://link.springer.com/chapter/10.1007/978-3-642-24864-1_5|consulté le=2018-01-06|pages=57–72}}</ref>. |
||
=== Dans le secteur automobile === |
=== Dans le secteur automobile === |
||
Les automobiles modernes sont contrôlées par des dizaines d’ordinateurs coordonnés par un ou plusieurs bus de communication interne, et sont de plus en plus connectées avec l'extérieur. Ces évolution ont introduit de nouveaux risques potentiels |
Les automobiles modernes sont contrôlées par des dizaines d’ordinateurs coordonnés par un ou plusieurs bus de communication interne, et sont de plus en plus connectées avec l'extérieur. Ces évolution ont introduit de nouveaux risques potentiels. Par ailleurs la fragilité de ces systèmes est démontrée, on sait maintenant qu’il est possible de prendre le contrôle de certaines fonctions critiques d’un véhicule en infiltrant les [[Unité de commande électronique|unités de commandes électroniques]] (ECU).<ref name=":6">{{Article|prénom1=K.|nom1=Koscher|prénom2=A.|nom2=Czeskis|prénom3=F.|nom3=Roesner|prénom4=S.|nom4=Patel|titre=Experimental Security Analysis of a Modern Automobile|périodique=2010 IEEE Symposium on Security and Privacy|date=May 2010|doi=10.1109/SP.2010.34|lire en ligne=http://ieeexplore.ieee.org:80/document/5504804/?reload=true|consulté le=2018-01-06|pages=447–462}}</ref> Il n’est pas nécessaire de connaître finement les composants du véhicule, l’éventail de paquets CAN valides étant assez mince, un simple fuzzing de paquets générés aléatoirement puis envoyés sur un [[Bus de données CAN|bus CAN]] peut entraîner des dégâts significatifs. Le fuzzing permet également de découvrir les fonctions de contrôle des ECU afin de contrôler par exemple le moteur ou les freins.<ref name=":6" /> |
||
=== Défis spécifiques === |
=== Défis spécifiques === |
||
En comparaison des systèmes d’exploitation généralistes, le fuzzing des systèmes embarqués représente un défi particulier en raison de leur niveau de spécialisation élevé, de la diversité des dispositifs et de l’utilisation de protocoles propriétaires. Par ailleurs, la théorie et les outils du fuzzing actuels ont été conçus pour tester des programmes exécutés sur des systèmes généralistes et sont inadaptés aux systèmes embarqués.<ref>{{Lien web|langue=anglais|titre=What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices|url=http://www.eurecom.fr/fr/publication/5417/detail/what-you-corrupt-is-not-what-you-crash-challenges-in-fuzzing-embedded-devices|site=|date=|consulté le=}}</ref> |
En comparaison des systèmes d’exploitation généralistes, le fuzzing des systèmes embarqués représente un défi particulier en raison de leur niveau de spécialisation élevé, de la diversité des dispositifs et de l’utilisation de protocoles propriétaires. Par ailleurs, la théorie et les outils du fuzzing actuels ont été conçus pour tester des programmes exécutés sur des systèmes généralistes et sont inadaptés aux systèmes embarqués.<ref name=":5">{{Lien web|langue=anglais|titre=What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices|url=http://www.eurecom.fr/fr/publication/5417/detail/what-you-corrupt-is-not-what-you-crash-challenges-in-fuzzing-embedded-devices|site=|date=|consulté le=}}</ref> |
||
==== La détection d’erreurs ==== |
==== La détection d’erreurs ==== |
||
Version du 6 janvier 2018 à 16:25
Le Fuzzing dans l'Internet Of Thing
Fuzzing réseau de l'Internet Of Thing
Fuzzing des protocoles réseaux
Un programme de fuzzing, appelé plus communément un fuzzer permet de découvrir des failles de sécurité. La plupart de ces programmes sont utilisés notamment pour tester les protocoles réseaux.[1]
Les protocoles réseaux de l'IOT n'ont pas été spécialement conçus pour les objets connectés mais par exemple pour les communications en temps réel, ou l'asynchrone et sont encore jeunes, et peu testés, mais on été cependant adoptés par l'industrie de l'IOT. [2] Pour tester ces protocoles il existe des techniques telles que le fuzzing, en utilisant un fuzzer dédié à un protocole spécifique ou un framework plus générique. Les tests peuvent se faire selon différentes approches: entièrement automatisée ou en partie manuelle.[3] Fuzzer les protocoles réseaux de l'IOT consiste à envoyer des séquences de paquets réseaux et à analyser la façon dont l'objet connecté y répond: en renvoyant une exception, en crashant, en aillant un comportement inhabituel ou en gardant un comportement normal.L'envoi de ces paquets se fera en suivant des scénarios élaborés en amont[4] ou de façon plus globale et aléatoire afin de recueillir une première base de données statistiques.[1]
Les protocoles de l'IOT sont encore jeunes et dans l'industrie de l'IOT on peut voir des implémentations de protocoles qui ne respectent pas totalement les RFC ou qui sont peu testés. Pourtant la modification des systèmes IOT une fois sur le marché étant difficile, il est nécessaire de mettre en place des tests adaptés pour éviter les vulnérabilités. Sur environ 5 milliards de tests effectués en 2016, les objets issus de l'IOT résistent en moyenne moins longtemps au fuzzing que d'autres industries.[5]
Fuzzing des protocoles réseaux spécifiques à l'IOT
6LoWPAN
Low-power Wireless Personal Area Networks, conçu pour consommer peu d'énergie, les paquets transmis via ce protocole sont encodés, compressés, et les longs messages sont fragmentés en plusieurs plus courts. Fuzzer ce protocole nécessite donc un mécanisme de décompression et compression des paquets pour les analyser. Il est également nécessaire d'identifier les différents fragments d'un même message. Cela peut se faire grâce à des outils tels que scapy et des framework dédiés qui permettent d'accéder au message en représentation héxadécimale afin d'accéder aux différents champs qui le composent tels que la taille globale du message. La construction des paquets à injecter à l'objet connecté peut se faire grâce à des OS dédiés tels que Contiki qui permettent d'envoyer nativement des messages 6LoWPAN. Ces messages sont altérés pour suivre les scénarios de test, par exemple en changeant certains bits aux hasard, certains champs au hasard ou selon une fonction customisée.[4]
CoAP
Constrained Application Protocol, conçu au dessus d'UDP[2] il utilisé comme une sorte d'HTTP léger pour l'IOT[5]. Pour fuzzer ce protocole on envoie plusieurs requêtes construites pour analyser des comportements anormaux. Comme par exemple une requête GET ou POST avec des options adaptées aux scénarios de tests.[2]
Mbed TLS
Librairie de cryptographie pour l'IOT [6], le code source est disponible en open source[7] et est téléchargeable[8]. II est donc possible d'utiliser un fuzzer le tester de détecter des failles. Le groupe Gotham Digital Science a exemple une faille sur le déréférencement d'un pointeur null coté client qui a été corrigée par arm[9], grâce àau fuzzer American Fuzzing Loop développé par Michal Zalewski .[10]
Fuzzing dans le fog computing
Confidentialité des données
Le fog computing est la nouvelle génération de de cloud computing, il est composé d'objets connectés intelligents comme des capteurs reliés sans fil. Pour assurer la sécurité des données de ce type de réseau, on peut utiliser le fuzzing. Dans le fog computing chaque objet connecté a la capacité d'opérer des traitements. Et chaque objet peut communiquer avec un autre et transmettre des données. Afin d'éviter que les données puissent être interceptées chaque objet peut envoyer des données fuzzées selon une fréquence déterminée afin de générer du bruit. Un utilisateur malveillant ne pourra donc pas récupérer les données, alors que le récepteur légitime sera lui capable de les interpréter.[11]
Détection des comportements malveillants
Le fuzzing est également utilisé afin de construire des outils pour repérer les comportements anormaux lors de l'échange de données entre les objets connectés.En identifiant plusieurs paramètres comme le nombres de connections reçues, les auteurs des connections et le caractère sensible d'une donnée, il est possible d'établir un schéma de confiance et ainsi d'alerter en cas de comportements potentiellement malveillant.[12]
Fuzzing des systèmes embarqués
Les systèmes embarqués sont de plus en plus présent dans notre vie quotidienne. Leurs interconnexions avec d’autres appareils proposant différents services en ligne en font des acteurs essentiels de l’Internet des Objets. Cependant, l’augmentation rapide du nombre d’appareils connectés s’accompagne d’un accroissement de la surface d’attaque, et les systèmes fortement contraints sont considérés comme particulièrement vulnérables. Le fuzzing est une technique très populaire pour découvrir des failles de sécurité, il peut être automatisé à grande échelle même avec une connaissance limité du système à tester, mais un traitement particulier est parfois requis lorsqu'il s'agit de l'appliquer aux systèmes embarqués.[13]
Dans le secteur industriel
Les systèmes embarqués sont couramment utilisés dans les dispositifs de supervision industriels, mais la compatibilité des réseaux industriels avec Internet est une tendance récente qui les rend vulnérables aux cyber-attaques. Cette tendance entraîne donc un besoin croissant de tests de sécurité de ces réseaux. Grâce au fuzzing des implémentations de protocoles réseau industriels il est possible d’obtenir des informations sur la résilience des systèmes face aux nouvelles menaces en provenance d’Internet. Cependant, les outils de fuzzing traditionnels ne conviennent pas à ces systèmes complexes conçus pour fonctionner en vase clos, on voit donc apparaître de nouveaux outils de fuzzing spécialisés, dédiés par exemple au protocole Modbus/TCP[14], aux spécifications OPC[15] ou encore aux systèmes de télégestion SCADA[16].
Dans le secteur automobile
Les automobiles modernes sont contrôlées par des dizaines d’ordinateurs coordonnés par un ou plusieurs bus de communication interne, et sont de plus en plus connectées avec l'extérieur. Ces évolution ont introduit de nouveaux risques potentiels. Par ailleurs la fragilité de ces systèmes est démontrée, on sait maintenant qu’il est possible de prendre le contrôle de certaines fonctions critiques d’un véhicule en infiltrant les unités de commandes électroniques (ECU).[17] Il n’est pas nécessaire de connaître finement les composants du véhicule, l’éventail de paquets CAN valides étant assez mince, un simple fuzzing de paquets générés aléatoirement puis envoyés sur un bus CAN peut entraîner des dégâts significatifs. Le fuzzing permet également de découvrir les fonctions de contrôle des ECU afin de contrôler par exemple le moteur ou les freins.[17]
Défis spécifiques
En comparaison des systèmes d’exploitation généralistes, le fuzzing des systèmes embarqués représente un défi particulier en raison de leur niveau de spécialisation élevé, de la diversité des dispositifs et de l’utilisation de protocoles propriétaires. Par ailleurs, la théorie et les outils du fuzzing actuels ont été conçus pour tester des programmes exécutés sur des systèmes généralistes et sont inadaptés aux systèmes embarqués.[13]
La détection d’erreurs
La grande majorité des techniques de fuzzing s’appuie sur des erreurs observables, or la plupart des systèmes embarqués ne dispose pas de mécanismes de détection des erreurs, et même lorsque ces mécanismes existent, ils sont souvent incomplets ou ne produisent pas de messages d’erreurs. Une des techniques permettant de compenser ces lacunes consiste à vérifier continuellement l’activité du système afin de connaître les effets des tests de fuzzing sur le dispositif.
La performance et la scalabilité
Il est rarement possible de virtualiser entièrement un système embarqué, et se procurer un grand nombre d’appareils n’est souvent pas envisageable par manque de moyens, il est donc difficile de démarrer plusieurs instances du même logiciel pour paralléliser les tests. De plus, il est nécessaire de restaurer fréquemment l’état initial du dispositif pour préparer le test suivant, ce qui implique généralement un redémarrage complet de l’appareil et ralenti considérablement l’exécution des tests.
L’instrumentation
Le manque de visibilité sur le fonctionnement du système limite l’accès à des techniques de fuzzing sophistiquées. En effet, le plus souvent le code source des firmwares n’est pas disponible, et la diversité des cibles à tester complique grandement la recompilation. Une solution courante consiste à instrumenter le programme compilé, mais elle est rarement applicable pour cette catégorie de dispositifs. Ainsi, l’instrumentation statique ou dynamique des firmwares est souvent complexe, voir impossible.
Le fuzzing outil dans la standardisation de l'Internet Of Thing
Des process de standardisation à adapter
L'IOT est un secteur qui est encore jeune, évolue vite les technologies utilisée sont encore hétérogènes, il n'y a pas encore de réel standard établit notamment en terme de test et de sécurité. Le but étant dé pouvoir garantir une interopérabilité des composant sur le marché pour envoyer et recevoir des paquets et messages de manière sure et continuer à faire en sorte que cette industrie puisse rester compétitive et réactive sur le marché. Les standards et process de tests doivent donc innover par rapport aux process de standardisation classiques. Par exemple, le fait que le systême d'un objet connecté puisse être patché plusieurs fois après sa mise sur le marché est une contrainte qui doit être prise en compte.[18] En ce sens le fuzzing est une aide qui permet de tester y compris les comportements inconnus et inattendus et cette technique se fait de plus en plus une place dans les process de tests. Par exemple Microsoft intègre dans ses protocoles de tests une phase de fuzzing de ses logiciels avant leur mise sur le marché.[19]
Des standards en construction
Consciente de la nécessité du besoin de standardiser l'IOT et notamment les standard de sécurité de l'IOT qui a la particularité de grandir très vite, l'Europe à crée un programme de recherche Horizon 2020 pour soutenir la recherche et l'innovation.[20] Dans le cadre de ce programme un projet de standardisation de l'IOT, ARMOUR, a été lancé en Février 2016 entre cinq pays européens: France, Grêce, Portugal, Espagne et Italie avec un consortium de plusieurs laboratoires de recherche comme l'INRIA. Le but est de produire un cadre expérimental en apportant des solutions de tests et des standards à l'industrie de l'IOT. Ce programme doit fournir une boite à outils de tests, des méthodes de travail, et des proposition pour la mise en place et l'obtention de certifications de sécurité.[21]
Pour fournir cette boite à outils et ces Frameworks les chercheurs du programme ARMOUR s'appuient sur le fuzzing pour tester tous les comportements et plus précisément les plus incertains. Le fuzzing permet en effet de produits de nombreux tests à grande échelle.L'algorithme utilisé permet de tester de nombreux comportements tout en évitant les duplications, ce qui en fait un outils précieux dans les protocoles de tests.[18]
Références
- X. Han, Q. Wen et Z. Zhang, « A mutation-based fuzz testing approach for network protocol vulnerability detection », Proceedings of 2012 2nd International Conference on Computer Science and Network Technology, , p. 1018–1022 (DOI 10.1109/iccsnt.2012.6526099, lire en ligne, consulté le )
- « ThingPot: an interactive Internet-of-Things honeypot » (consulté le )
- Qixu Liu et Yuqing Zhang, « TFTP vulnerability finding technique based on fuzzing », Computer Communications, vol. 31, no 14, , p. 3420–3426 (DOI 10.1016/j.comcom.2008.05.041, lire en ligne, consulté le )
- A. Lahmadi, C. Brandin et O. Festor, « A Testing Framework for Discovering Vulnerabilities in 6LoWPAN Networks », 2012 IEEE 8th International Conference on Distributed Computing in Sensor Systems, , p. 335–340 (DOI 10.1109/dcoss.2012.48, lire en ligne, consulté le )
- « state-of-fuzzing-2017 », sur https://www.synopsys.com/, (consulté le )
- « Mbed IoT Platform | Mbed », sur Arm Mbed (consulté le )
- (en) « PolarSSL is dead, long live mbed TLS », Arm Community, (lire en ligne, consulté le )
- (en) ARM Limited, « SSL Library mbed TLS / PolarSSL », sur tls.mbed.org (consulté le )
- (en) « GDS - Blog - Fuzzing the mbed TLS Library », sur blog.gdssecurity.com (consulté le )
- « american fuzzy lop », sur lcamtuf.coredump.cx (consulté le )
- S. Kulkarni, S. Saha et R. Hockenbury, « Preserving privacy in sensor-fog networks », The 9th International Conference for Internet Technology and Secured Transactions (ICITST-2014), , p. 96–99 (DOI 10.1109/ICITST.2014.7038785, lire en ligne, consulté le )
- N. Tamani et Y. Ghamri-Doudane, « Towards a user privacy preservation system for IoT environments: a habit-based approach », 2016 IEEE International Conference on Fuzzy Systems (FUZZ-IEEE), , p. 2425–2432 (DOI 10.1109/FUZZ-IEEE.2016.7737997, lire en ligne, consulté le )
- (en) « What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices »
- (en-US) Artemios G. Voyiatzis, Konstantinos Katsigiannis et Stavros Koubias, « A Modbus/TCP Fuzzer for testing internetworked industrial systems », 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA), (DOI 10.1109/etfa.2015.7301400, lire en ligne, consulté le )
- Xiong Qi, Peng Yong, Zhonghua Dai et Shengwei Yi, « OPC-MFuzzer: A Novel Multi-Layers Vulnerability Detection Tool for OPC Protocol Based on Fuzzing Technology », International Journal of Computer and Communication Engineering, vol. 3, no 4, , p. 300–305 (DOI 10.7763/ijcce.2014.v3.339, lire en ligne, consulté le )
- (en) Rebecca Shapiro, Sergey Bratus, Edmond Rogers et Sean Smith, « Identifying Vulnerabilities in SCADA Systems via Fuzz-Testing », Critical Infrastructure Protection V, Springer, Berlin, Heidelberg, iFIP Advances in Information and Communication Technology, , p. 57–72 (ISBN 9783642248634, DOI 10.1007/978-3-642-24864-1_5, lire en ligne, consulté le )
- K. Koscher, A. Czeskis, F. Roesner et S. Patel, « Experimental Security Analysis of a Modern Automobile », 2010 IEEE Symposium on Security and Privacy, , p. 447–462 (DOI 10.1109/SP.2010.34, lire en ligne, consulté le )
- G. Baldini, A. Skarmeta, E. Fourneret et R. Neisse, « Security certification and labelling in Internet of Things », 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT), , p. 627–632 (DOI 10.1109/WF-IoT.2016.7845514, lire en ligne, consulté le )
- « Effectiveness of fuzz testing high-security applications A case study of the effectiveness of fuzz-testing applications with high security requirements », (consulté le )
- Horizon 2020, « Accueil - Horizon 2020 », sur www.horizon2020.gouv.fr (consulté le )
- (en-US) « Home - ARMOUR », sur ARMOUR (consulté le )
_____________________________________________________________________________________________________________________________________________________________________________
/backup des references des parties non abordées + plan (non figé)/ ref générales (à potentiellement virer)
- J. M. Mendel, « Type-2 Fuzzy Sets and Systems: An Overview [corrected reprint] », IEEE Computational Intelligence Magazine, vol. 2, no 2, , p. 20–29 (ISSN 1556-603X, DOI 10.1109/MCI.2007.357235, lire en ligne, consulté le )
- J. Engblom, « A review of reverse debugging », Proceedings of the 2012 System, Software, SoC and Silicon Debug Conference, , p. 1–6 (lire en ligne, consulté le )
- Radu-Emil Precup et Hans Hellendoorn, « A survey on industrial applications of fuzzy control », Computers in Industry, vol. 62, no 3, , p. 213–226 (DOI 10.1016/j.compind.2010.10.001, lire en ligne, consulté le )
- L. Piètre-Cambacédès et M. Bouissou, « Cross-fertilization between safety and security engineering », Reliability Engineering & System Safety, vol. 110, no Supplement C, , p. 110–126 (DOI 10.1016/j.ress.2012.09.011, lire en ligne, consulté le )
Le Fuzzing, outil de sécurisation
Sécurisation de l'objet connecté
- (en) Vincent ALIMI, Sylvain VERNOIS et Christophe ROSENBERGER, « Analysis of embedded applications by evolutionary fuzzing », HPCS, 21-25 juillet 2014 (DOI 10.1109/HPCSim.2014.6903734)
- Tewodros Legesse MUNEA, I. Luk KIM et Taeshik SHON, « Design and Implementation of Fuzzing Framework Based on IoT Applications », Wireless Personal Communications, vol. 93, no 2, , p. 365–382 (DOI 10.1007/s11277-016-3322-9, lire en ligne, consulté le )
- « securing-the-iot », (consulté le )
- A. M. Al-Kandari, S. A. Soliman et M. E. El-Hawary, « Fuzzy systems application to electric short-term load forecasting. I. Problem formulation », Large Engineering Systems Conference on Power Engineering, 2003, , p. 125–130 (DOI 10.1109/LESCPE.2003.1204691, lire en ligne, consulté le )
- G. Acampora et A. Vitiello, « Extending IEEE Std 1855 for designing Arduino #x2122;-based fuzzy systems », 2017 IEEE International Conference on Fuzzy Systems (FUZZ-IEEE), , p. 1–6 (DOI 10.1109/FUZZ-IEEE.2017.8015755, lire en ligne, consulté le )
- Kazukuni KOBARA, « Cyber Physical Security for Industrial Control Systems and IoT », IEICE TRANSACTIONS on Information and Systems, vol. E99-D, no 4, (ISSN 1745-1361 et 0916-8532, lire en ligne, consulté le )
- S. Ray, E. Peeters, M. M. Tehranipoor et S. Bhunia, « System-on-Chip Platform Security Assurance: Architecture and Validation », Proceedings of the IEEE, vol. PP, no 99, , p. 1–17 (ISSN 0018-9219, DOI 10.1109/JPROC.2017.2714641, lire en ligne, consulté le )
- Software Reliability Enhancement Center (SEC), Technology Headquarters, Information-technology Promotion Agency (IPA), « IoT Safety/Security Design Tutorial », Information-technology Promotion Agency, Japan (IPA), , p. 65 (lire en ligne)
- « Poster: IoTcube: An Automated Analysis Platform for Finding Security Vulnerabilities » (consulté le )
- W. Zhao, F. Xie, Y. Peng et Y. Gao, « Security Testing Methods and Techniques of Industrial Control Devices », 2013 Ninth International Conference on Intelligent Information Hiding and Multimedia Signal Processing, , p. 433–436 (DOI 10.1109/IIH-MSP.2013.114, lire en ligne, consulté le )
- Katsuhiro Takamatsu, « Efforts for Enhancing Security in Control Systems », Yokogawa Technical Report English Edition Vol.57, (lire en ligne)
- T. Miyachi et T. Yamada, « Current issues and challenges on cyber security for industrial automation and control systems », 2014 Proceedings of the SICE Annual Conference (SICE), , p. 821–826 (DOI 10.1109/SICE.2014.6935227, lire en ligne, consulté le )
- (en-US) « Embedded low power analog CMOS Fuzzy Logic Controller chip for industrial applications - IEEE Conference Publication », sur ieeexplore.ieee.org (consulté le )