 Bonjour et bienvenue à la dernière parole. C'est la troisième parole de SIPA. Nous nous concentrons sur la sécurité de la SIPA et comment nous implementons les recommandations de sécurité de la SIPA. Je suis avec Angers Ronderiboukour et je suis Mathieu Dupré. Nous sommes tous venus de la même compagnie, Savoir Fairly Nukes. Savoir Fairly Nukes est une compagnie d'expert sur l'open source et nous assistons à une compagnie industrielle. Nous avons utilisé l'open source software. Nous sommes invités à la SIPA depuis le début et nous sommes tous les maintenance et contributaires de la SIPA. Le projet de SIPA est un jouet d'appareil. Il doit être utilisé dans une subvention de puissance électrique. L'objectif est de remplacer la machine physique par virtue de la machine virtuale pour gagner la flexibilité. Mais le retour est maintenant... Le point de vue de l'appareil. Donc, nous devons renforcer la sécurité de l'appareil. Pour faire ça, nous cherchons des recommandations de sécurité de la SIPA. Nous voulons que notre guide de la SIPA soit implémentairement orientée. Il y a beaucoup de guides qui sont plus à l'aile de l'oeuvre. Nous voulons donc une guide implémentairement orientée, mais pas de distribution spécifique. Nous voulons aussi une distribution hygothique. Parce que la SIPA utilise la distribution de la SIPA et la distribution de l'optimisme. Nous voulons que le guide soit libre et puissant. Nous voulons aussi couvrir tous les subjectifs de la SIPA, des réseaux, des systèmes d'adoling, des corneaux d'androïne, etc. Pour l'introduction de la SIPA, c'est la SIPA, qui vient de l'agence de la SIPA, qui est la SIPA. Donc, cette guide s'accusera de toutes les requises que Mathieu m'a dit. Nous ne voulons pas aller à toutes les requises, parce que c'est un peu grand, mais c'est seulement 100 pages, donc je vous encourage à regarder le document et ça vous donnera une bonne idée sur comment sécuriser vos devices Linux. Mais aujourd'hui, nous allons montrer la structure et les principaux principaux qui sont présents. Donc, le document s'instructe à quatre niveaux de sécurité qui vont être targetés à différents systèmes. Donc, vous avez le minimum de sécurité, qui est dans la rède ici. Il va s'appliquer à d'autres devices Linux, donc ça peut être un custom IoT gizmos, qui n'est pas vraiment critique, à des niveaux de sécurité très hauts, comme la SIPA, qui vient d'une structure critique, qui est l'électricité. Donc, pour la SIPA, pour exemple, nous devons rencontrer tous les requises de toutes les quatre niveaux. Et nous allons aussi se couvrir, donc le guide couvre beaucoup de problèmes, qui sont très complets, et qui garantissent la sécurité sur votre whole device Linux. Donc, il parle de la fragmentation de compilations, de la partition et de la permission de la file systémique, la configuration de kernel, ainsi que la configuration de l'utilisation, comment les services doivent être isolés ou sondés, la taille de votre image et ce que vous installez ou pas. Et, bien sûr, l'isolation des réseaux et les dégâts. Donc, ici c'est ce qu'un récrément semble. Donc, d'abord, vous avez un paragraphe, qui est ici sur le top, qui introduira le récrément et vous donnez des principes sur pourquoi ce sera nécessaire. Ensuite, vous avez le récrément actuel. Donc, ici, nous avons le numéro 57. Vous le voyez dans les squares, les niveaux de sécurité, cela s'applique aussi. Donc, ici, c'est un récrément important parce que cela targettera aucun dégâts sur le niveau intermédiaire de sécurité. Et donc, comme vous pouvez le voir, cela nous dit que les commandes pseudo doivent seulement être autorisées pour les utilisateurs qui sont partie des groupes pseudo. Parce que c'est un récrément simple, et c'est l'un des cas de showcase de l'ANCE BP28. Vous avez aussi une implementation proposée, qui est ici, montée par la permission de la binary pseudo. Donc, la plupart de ces récréments peuvent être facilement testés par les commandes pseudo. Donc, nous faisons cela en CPAS par Koukina. Et cela produisit un récrément test qui tourne des tasques très simples et les connecte à les récréments sur l'ANCE BP28. Et parce que CPAS peut tourner dans d'autres pays, nous voulons les tests pour être facilement liés avec d'autres récréments d'autres gouvernements et d'agences cyber. Donc, nous avons développé un outil d'accompagnement qui produise une matrice de complétation et cela va lier notre test de CPAS à des récréments Linux d'autres guidelines. Donc, vous voyez que certains de ces récréments sont récréments, mais c'était dans l'arrivée de développement, maintenant que ils devraient tous être en gris, bien sûr. Donc, nous regardons quelques différents types de récréments. Donc, bien sûr, je ne serai pas allé dans tous ces récréments. Donc, encore une fois, vous pouvez lire les récréments. Donc, certains récréments seront assez facilement implementés et testés. C'est généralement les récréments qui viennent avec des suggestions directes à l'implementation. Donc, nous avons ici les récréments sur le YAMA module. Le YAMA module est un module canel qui va oublier l'utilisation de Ptrace. Donc, Ptrace, comme vous le savez, est un système qui permet d'améliorer un processus d'un autre processus, donc, il peut imaginer ses souvenirs, par exemple, ainsi que ses récréments de l'utilisation même. Mais cela ferait le principe d'isolation entre les processus. Donc, nous voulons déterminer cela. Donc, cela a été fait par la sécurité de la YAMA module et la configurée. Donc, ici, les récréments nous donnent ce que nous devons mettre sur la ligne de commande de la colonne et les paramètres de la CCTL pour passer à la module d'améliorer ce récrément. Donc, parce que nous avons une implementation, c'est une suggestion, on peut facilement l'implementer mais aussi l'améliorer très facilement. Certaines récréments vont require un peu plus de pensée. Par exemple, ceci, qui est le premier récrément, est pour minimiser vos services. Donc, pour être sécurisé, vous voulez limiter la surface de l'attaque. Et pour faire cela, vous devez réinstaller chaque package qui n'est pas strictement récrément par votre application. Et comme vous pouvez voir, ce récrément s'applique à tous les niveaux de sécurité. Donc, cela devrait vraiment être fait sur tous vos devices que vous avez développés. Et donc, c'est facile de comprendre mais pour l'implementer, vous devez vraiment penser sur ce que sont mes services essentiels et critiques et remettre tout autrement. Donc, l'implementation ici n'est, bien sûr, pas donné. Mais, quand vous avez fait ce travail de sélectionner les packages minimales, vous pouvez facilement faire un test qui va garantir que vous vérifiez votre récrément. Donc, par exemple, si vous êtes en train de faire une distribution de débit vous pouvez vérifier par l'IPT qu'un autre package a été installé. Et puis, vous pouvez avoir un test de régression et si un autre développeur dans le futur ajoute un nouveau package, vous devez être notifié que ce n'est pas partie de l'image minimale. Donc, vous devez penser si c'est nécessaire ou pas. Et enfin, quelques récréments seront vraiment très importants. C'est-à-dire qu'il n'y a pas d'implementation dans les principes. Ils n'ont pas d'implementation et c'est aussi très difficile à tester. Donc, ici, on a un de les plus importants principes qui est la défense de la définition. Donc, il nous dit que nous devons utiliser l'authentication quand nécessaire pour des opérations critiques. Il nous dit aussi que nous devons logiser les événements et les systèmes d'alerte et aussi que les partitions et les services de la définition. Donc, bien sûr, c'est très étrange. Donc, vous pouvez faire beaucoup de tests pour vérifier partiellement que vous compliquez avec ces récréments. Mais l'idée, ici, c'est vraiment de mettre le réveil et le mindset de sécurité sur les devises Linux. Donc, bien sûr, vous ne voulez pas faire ce qu'on présente sur le droit ici. Donc, c'est l'usule d'Ibiya Noriocto ou quelque configuration sur Linux. Donc, tout se tourne en route. Pour les services system d'alerte, si vous ne spécifiez pas votre utiliseur, ça se tourne en route. Donc, bien sûr, ce n'est pas isolé. On peut aussi essayer de penser pourquoi est-ce important que quelque chose ne se tourne en route? Par exemple, dans un dévice embêté, on a souvent une application qui a accès à tout le data sensibilisé parce que, souvent, les dévices embêtés ont juste un task. Pourquoi serait-il même important que mon application s'occupe du data sensibilisé? Et, vous devez réunir en route parce que, pour exemple, cela permettrait d'améliorer l'application pour aussi, pour exemple, manipuler les partitions ou les systèmes updates. Donc, un attaqueur pourrait facilement impliquer une backdoor dans votre système. Donc, une vulnérabilité qui s'occupe maintenant pourrait devenir une vulnérabilité mais, vous devez minimiser les features et les privilèges de toutes vos applications. Vous devez isoler et participer l'application dans le C-Path. Nous voyons de la virtualisation. Donc, chaque application s'occupe dans une vm donc, cela nous aide à greatly réduire la contamination de les bridges de la sécurité. Vous devez aussi couper toutes vos configurations pour enlever toutes les features de la sécurité et, bien sûr, augmenter toutes les événements et, bien sûr, augmenter comme régulièrement possible. Donc, Mathieu sur le hardening. Oui. Nous voyons comment nous on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on on C'est ce que l'on peut modifier. Dans la part de l'Octobre, vous pouvez voir que vous pouvez modifier tout. Et dans la partie de l'Octobre, nous pouvons seulement modifier la configuration. Dans Yellow, c'est ce que l'on a fait par la part de l'Octobre. Pour illustrer cela, c'est un exemple de la construction de l'Octobre. En Yellow, nous avons fait notre configuration de l'Octobre sur l'Octobre. Nous avons répliqué la configuration de l'Octobre en l'Octobre. En Libyen, nous avons gardé la configuration de l'Octobre sur l'Octobre. Nous avons aussi gardé notre propre fragment, qui va évoluer la configuration de l'Octobre. En fin de la configuration, nous avons fait une configuration identique de l'Octobre et de l'Octobre. Nous allons voir d'autres recommandations. C'est la façon dont nous minimisons la configuration de l'Octobre sur l'Octobre. Depuis les différences de la philosophie, nous pouvons, en Yellow, configurer un peu plus la configuration de l'Octobre sur l'Octobre. Parce qu'en Libyen, nous pouvons seulement sélectionner l'Octobre sur l'Octobre. Mais nous ne pouvons pas éditer la dépendance. Dans l'Octobre, nous pouvons modifier la configuration pendant le temps. Et nous pouvons sélectionner la dépendance de l'Octobre. Pour l'enregistrement de l'Octobre, nous allons vérifier l'installation de l'Octobre. C'est une recommandation pour downloader la page HTTP. C'est ce que l'Octobre a fait en Libyen. Comme vous pouvez le voir, il y a beaucoup de dépendances de l'Octobre. Par exemple, l'LDP ou l'SAISL. Nous ne devons pas l'enregistrer sur l'Octobre, mais nous ne pouvons pas l'enregistrer. En l'Octobre, l'Octobre permet d'améliorer la configuration de l'Octobre. Pour l'instant, il y a un package config pour l'LDP. Si nous ne pouvons pas l'enregistrer sur l'Octobre, l'Octobre ne va pas être compagnie avec le support de l'LDP et la dépendance ne va pas être en SAISL. Il y a aussi l'Estra OEConf, qui peut être utilisé pour changer tous les paramètres passés au command de l'Octobre. Il peut aussi être utilisé pour compilier un package, qui n'est que l'option de l'Octobre. L'autre main-point, ce que l'on peut faire entre l'Octobre et l'Octobre, c'est la configuration de l'Octobre. En octobre, la configuration de l'Octobre est faite par l'Octobre, la team de l'Octobre. Nous avons utilisé ça. Nous pouvons changer le paramètre de l'Octobre dans l'autre paramètre de l'Octobre, mais nous ne pouvons pas éditer la configuration. La seule partie de l'Octobre n'est que dans le paramètre de l'Octobre. Dans l'Octobre, nous pouvons définir notre propre configuration de l'Octobre, donc nous pouvons appliquer tous les paramètres de l'Octobre, et la plupart des paramètres de l'Octobre sont dans la configuration. Nous avons encore un paramètre de l'Octobre et de l'Octobre, qui est un paramètre de l'Octobre, un paramètre de l'Octobre, comme il est fait avec l'Octobre. Pour nous aider, dans la configuration, nous avons utilisé l'Octobre de l'Octobre 28, mais nous avons aussi réalisé la protection de l'Octobre de l'Octobre. Un exemple pratique, c'est comment la configuration de l'Octobre de l'Octobre de l'Octobre de l'Octobre de l'Octobre de l'Octobre C'est une recommandation d'attendre l'Octobre de l'Octobre pour réduire l'Octobre et ne pas appeler l'Octobre de l'Octobre de l'Octobre Nous pouvons utiliser l'Octobre de l'Octobre avec le paramètre de l'Octobre de l'Octobre mais sur l'Octobre de l'Octobre, nous avons juste utilisé toutes les features de l'Octobre parce qu'on n'a pas besoin de l'Octobre. Maintenant, nous allons parler de monitorer la sécurité de l'Octobre de l'Octobre dans le long terme, et la plupart de ces tests sont faits en temps de billet. Donc, comme nous l'avons vu, il y a deux principales de distribution de Linux et d'autres de l'Octobre qui sont compilés de sources comme Yocto et d'autres de l'Octobre qui font des packages préviles comme Dibian. Donc, sur Dibian, l'Octobre de l'Octobre de l'Octobre compilera la sécurité de l'Octobre pour vous régulièrement pendant que vous êtes sur le branch mais vous devez être sûrs d'appeler toutes ces updates très souvent, sinon vous vous accumulez des vulnérabilités publiques qui ont été fixées à l'extrême. Alors que dans Yocto, vous devez rébuilder votre image et, bien sûr, vous avez les mêmes mécaniques pour garder les updates avec la version de la communauté donc cela se passe dans les layers, donc vous voulez d'appeler vos layers de source comme souvent possible et rédeployer votre version avec les updates. Alors, bien sûr, les updates sont très importants en gardant un système Linux Donc, avec Yocto, nous avons plus de responsabilités qui viennent de la flexibilité et nous devons garder le tract de toutes les packages de la CVE donc cela est fait par la CVE check BB class et cela nous donnera un file qui contient pour chaque package que nous avons installée les connaissances de la CVE et si nous sommes affectés par elles ou pas. Donc, ceci est fait par la CVE et avec CPAS nous générons un file de metadata avec chaque build et on vérifie que nous n'avons pas de CVE qu'on a trouvé. Donc, pour Yocto parce que nous sommes aussi les mêmes responsables pour la compilation nous avons aussi besoin de vérifier que la compilation a été faible. Donc, vous devez être sûr que les outils comme GCC ont une compilation de sécurité comme les stack canaries, par exemple donc les stack canaries sont un mécanisme basé qui protège les outils de Buford et nous permet de détecter et il y a beaucoup d'autres flags qui sont illustrés ici dans ce slide. Donc, si vous utilisez une distribution d'AGB c'est vous pouvez relier sur les maintenance pour avoir fait la compilation d'AGB enabled. Donc, grâce aux maintenance d'AGB si il n'y a aucun dans le sable. Mais si vous êtes Yocto vous devez probablement avoir des patchs de BBAPM ou peut-être vous reliez sur les layers de communauté qui ne sont pas partie de la course donc vous voulez vraiment vérifier que les flags de compilation de sécurité étaient correctement utilisés dans vos récipes. Par exemple, si une récipe ou une rédefine les flags LD ou quelque chose certains de ces flags ne peuvent ne les faire dans la binary de compilation donc c'est pourquoi nous avons choisi d'adresser ce test. C'est notre classe custom qui s'appelle Check Harden Compilation vous pouvez le trouver sur la repository Github et c'est pour chaque package pour les files de binary with binary analysis tools it will check if we properly had the security flags enabled. So we base this class on a on a CheckSec script that was available on Github as well the link is down below the slide. We have the same mechanism for the kernel configuration so of course most of our configuration was hardened through reading the MCBP28 which gives many recommendations on what you should enable or not enable in your kernel configuration so we have specific tests for that which are written in cookinia once again but we also do some tests at build time through a script that was also available on Github, Kconfig, Harden Check and it will run just a few more tests on our kernel configuration and give us a bit more guidance as to what should be enabled or not. So once again I really encourage you to have a look at the full document and CBP28 there are links to it in our presentation you will find it in French as well as in English it really I hope you understood that it was really Linux distribution agnostic it will apply to mostly all embedded Linux distribution and it will really guide you through the steps to secure your device even though some principles may be a bit more challenging to approach and will require you to really design the architecture of your product in a secure way so feel free also to contact us directly you have our emails in the slides and also you can have a look at the CPath Github repositories to see how we implemented the tests and also how we did the implementation of those requirements it's all done for Dibyan and Yocto so it should give you a good idea on how you can start securing your devices so with that I'll thank you and we have the time for a few questions I think. Thank you. You mentioned that you're using a CVE tracker from Yocto so how do you post-process them? I mean the kernel has like un test so what are you doing with them? We just generate the report of course we have to check if we are unpacked by the CVE and how do you document that? Do you have a workflow for that? Not yet. Thank you for your very interesting talk what I haven't heard is whether you try it and what your experiences are using the no recommendations setting from Yocto project So are you speaking about the security guide from the Yocto project? When calling so there is also runtime recommendations in recipes and you can also at the bitbake decide whether you want to have the recommendations installed or not and personally I made the experience that it does not typically it does not end well when you don't install the recommendations because it's getting very thin so I was wondering why that was not mentioned maybe because you also made bad experience I'm not sure about which recommendations you are speaking is it the package recommendation that comes with every package or is it another feature? It's a variable I think that controls whether you install the R-recommend packages Matieu may know if we have that enabled or not In my experience things should work the R-recommends variable usually if the maintainers of the recipes have done their job well the package should run without them it just enables more features so in theory you really want to disable that in the case if you want to have a minimized image unless of course you need the features so my recommendation will be to disable the recommendations and fix what's wrong ok thank you some of the requirements said should some said it is recommended and some said it is a must purpose is a like a different level of requirement that should be clarified I guess at the beginning of the document which should explain exactly the exact meaning of should, must and so forth so I'll guide you to the document it should tell you exactly when is a must applied and when should be applied do you have plans to extend BuildRoot for maybe people using BuildRoot ? because we choose Yocto because it is more easy to extend our rules in Yocto by doing our own meta layer and this is what we have done with MetaCipath basically yeah yeah I'll add that all the things we presented today related to Yocto will apply to BuildRoot because you are in the same environment where you are responsible for building the packages and ensuring that they are built in a secure way so as we've seen you want to disable the configurations you don't want and you also want to harden the configuration so so even I think you should have a look at our tests for Yocto and most of them should also be doable through BuildRoot even the time checks should be doable on BuildRoot as well Question over here Do you have any plans on going beyond the standard and checking for other kernel options introduced by special kernel patches like GR security or if there is other security hardening patches for the kernel No, we do not apply yet but if we want to add it is possible I think one of the main reasons we could go for that is if another government wants to be deployed of course we'll probably have to support that but yeah the MCBP28 is one recommendation and of course you can go beyond that as we've shown we also have some other recommendations that are already part of the project but it should be as secure as possible so it can be vast to secure your Linux device but the MCBP28 gives us a good first start let's say Thank you for your presentation there is any automatic tool or mechanism that can check if a running system is aligned with these requirements defined by this normative Yeah, actually compliance matrix you briefly show that was briefly showed runs at runtime so you can run it anytime to ensure the MCBP288 requirement so you can see if someone did malicious things you can also rerun in the C pass context we have un cible to set up some of the rules so you can rerun un cible and see if it did reapply so that they were broken but of course the only test here that we spoke about that won't be available at runtime are all the build checks and it's only we only defaulted to build time checks because we couldn't do it at runtime There's a question in the front For the other guidelines that she used from other countries do you also list them in the documentation for comparison sake For the moment we only implement the BP28 but it is possible to easily implement other guidelines because all things we applied are one guideline and other are very similar all tests are agnostic we defend just an ID for file matrix we match the recommendation and the test ID so if you want to implement another guideline you just have to create the matrix and implement what is missing Again thanks for this presentation very useful I have one question regarding the recent screen about it is it includes also recommendation for other platform because now it's mentioned x86 ARM and other also included already it check from different recommendation here on but there is another and yes it check the version because whichever version but there is some rules we can fail but you still want for instance here it is a recommendation to disable config modules but there is a lot of reasons to keep the module on your platform we have to keep it because there is some module we can build a load later tpdk any other questions then thank you very much