Gardez un œil sur les menaces avec un monitoring de la sécurité

1. Introduction

La sécurité est encore bien souvent le parent pauvre (et oublié) des systèmes d'information : pour les devs elle ralentit le développement et les déploiements en production, et pour les ops elle amène un niveau supplémentaire de complexité pour lequel ils n'ont pas été formés. Et le DevSecOps et le shift left de la sécurité n'est pas pour rassurer ni les devs, ni les ops qui ont tout simplement l'impression qu'on se débarrasse de ce fardeau sur leurs épaules.

La sécurité a toujours été ce parent pauvre, et tout le monde aimait se bercer de cette illusion que derrière un pare-feu on se trouvait dans une « zone de confiance » (trusted zone) où la sécurité n'avait plus lieu d'être...

C'était sans compter sur le cloud (qui a fait son arrivée en 2006), les microservices (qui ont fait leur apparition vers 2014) et la conteneurisation (vers 2013 sous sa forme actuelle). Parce que des piles logicielles de plus en plus complexes sont désormais déployées sur des infrastructures non moins complexes et exposées publiquement sur Internet, le nombre de cyberattaques s'est multiplié de façon exponentielle (qu'elles soient l’œuvre de vrais hackers ou de simples script-kiddies).

Bref, la sécurité est aujourd'hui un sujet qu'il est difficile d'ignorer.

2. Qu'est-ce que la sécurité ?

Mais qu'est-ce qui vous vient à l'esprit quand on parle de sécurité ? J'imagine que ce sont les mots pare-feu et TLS qui reviennent le plus souvent. Si ça n'était que ça, ce serait réglé depuis longtemps. La sécurité n'est pas un sujet simple qui pourrait facilement être résumé en un article tant les méthodologies et les outils sont nombreux et variés. Dans cet article, nous allons nous concentrer sur les outils de sécurité, et plus spécifiquement sur les outils de monitoring de la sécurité, par opposition aux outils de prévention (dont les pare-feux et TLS font partie). Cependant, vous me pardonnerez si parfois j'entre dans la zone grise, car la distinction n'est pas toujours aussi claire qu'elle n'y paraît.

Donc, plutôt que de répondre à la question « qu'est-ce que la sécurité », voyons ensemble ce qu'on peut observer au niveau de la sécurité. Tout d'abord, nous avons tout ce qui concerne la sécurité des applications (Application Security ou AppSec), qui est sans doute le domaine le plus vaste. Depuis l'écriture du code jusqu'à son exécution sur une machine en production, il y a plus à analyser qu'on ne pourrait se l'imaginer. Ensuite, il y a ce qu'on pourrait appeler l’administration de la posture de sécurité cloud (je sais, ça sonne toujours bizarrement en français, Cloud Security Posture Management ou CSPM). Plus généralement, ici ce qui nous préoccupe ce sont les configurations de l'infrastructure (et plus spécifiquement les mauvaises configurations). Et enfin, l'analyse des logs et des événements, mieux connue sous le nom de SIEM (Security Information and Event Management).

3. AppSec

AppSec, pour Application Security, est l'ensemble des processus qu'on peut mettre en place pour s'assurer que le code que l'on déploie est sûr, et qu'il ne créera pas de problème en production. Mais qu'est-ce que j'entends par « problème en production » ? Je parle de CVE, ou Common Vulnerabilities and Exposures. Si on regarde l'évolution du nombre de CVE ces 10 dernières années, on ne peut que se rendre à l'évidence : il est en constante augmentation [1].

J'ai aussi dit précédemment que c'était le domaine le plus vaste, mais c'est aussi le domaine des devs (le fameux SDLC, mais cette fois non pas pour Software Development Life Cycle, mais pour Secure Development Life Cycle) ; oui, le shift left encore une fois. Mais attention, parler de shift left ne signifie pas faire endosser la responsabilité de la sécurité par les développeurs. Bien sûr, quand on génère du code il y a toujours des bonnes pratiques de sécurité à respecter, et les devs doivent y être formés, mais au-delà de cela, cela signifie avant tout d'être en mesure d'identifier les vulnérabilités le plus tôt possible (donc à l'écriture du code par exemple). La raison en est simple : au plus tôt la vulnérabilité est identifiée, le moins d'efforts cela demandera pour y remédier. Par ailleurs, tout le monde y gagne, car il n'y a rien de pire que de s'entendre dire qu'une version de l'application ne sera pas déployée en production parce qu'elle présente des vulnérabilités (quand elles arrivent à être identifiées par une équipe dédiée) et qu'il faut revenir sur un code écrit il y a plusieurs semaines de cela... Je pense qu'une équipe de devs ne se sentira jamais aussi bien qu'en ayant la possibilité d'adopter le Continuous Deployment (CD), et d'expédier de nouvelles fonctionnalités en production 2-3 fois par jour ! Mais ça demande de la discipline, et de bons outils.

Ces outils en question, que vous connaissez peut-être même déjà, au moins partiellement, peuvent être rangés en 3 catégories :

• Static Application Security Testing (SAST), Software Composition Analysis (SCA) inclus ;
• Dynamic Application Security Testing (DAST) ;
• Interactive Application Security Testing (IAST).

Je ne parlerai pas ici des Runtime Application Self-Protection (RASP) qui font plus partie des outils de prévention que de monitoring.

3.1 SDLC

Qu'est-ce que le Secure Development Life Cycle (autrement appelé SDL ou S-SDL par Microsoft) ?

• Durant la première phase, Design et Threat Modeling (modélisation des menaces), le but est d'identifier ce qui pourrait mal se passer avec le design de la solution, et comment y remédier ;
• La deuxième phase est celle du développement. Durant cette phase, le Threat Modeling est toujours d'actualité, grâce aux méthodes agiles, par opposition à un développement en Waterfall qui aurait considéré avoir identifié toutes les menaces durant la phase de design. Mais ici, on parle aussi de bonnes pratiques de développement pour la sécurité de l'application (chaque langage a les siennes, mais il en existe aussi de plus génériques, comme comment développer une API qui soit sécurisée). Enfin, durant le développement, nous retrouvons l'analyse statique et l'analyse de composition du software sur lesquelles nous allons revenir dans un instant ;
• La 3ème phase est celle du testing, où tout ce qui concerne la sécurité est validé (threat modeling, dynamic testing et sécurité du runtime) ;
• Et finalement, le déploiement est la 4ème et dernière phase pendant laquelle des campagnes de pentesting et/ou du bug bounty peuvent prendre place.

Vous vous demandez peut-être si tout ceci en vaut bien la peine, car après tout ça prend du temps et freine inévitablement l'implémentation de nouvelles fonctionnalités. Mais connaissez-vous OWASP [2] ? OWASP jusqu'à il y a peu signifiait Open Web Applications Security Project, mais le nom a maintenant changé en Open Worldwide Applications Security Project. OWASP publie régulièrement le top 10 des risques de sécurité liés aux applications. Pourquoi soudainement avoir changé de nom ? Parce qu'aujourd'hui ça va bien plus loin que le Web. Il y a toujours les applications web, bien sûr, mais également les API, les applications mobiles, le machine learning, l'IoT, le serverless et j'en passe. Mais pourquoi est-ce que je vous parle de OWASP ? Pour vous prouver que les risques liés à un développement non conforme aux règles de sécurité non seulement existent, mais qu'ils sont plus que souvent exploités. Et que les personnes à même de les exploiter sont légion !

3.2 SAST

Mais plongeons-nous dans les outils qui sont à notre disposition pour y remédier. Commençons par les tests statiques de sécurité des applications (Static Application Security Testing). Ces tests ont déjà une longue vie derrière eux ; ils consistent à lire le code, à trouver des erreurs et à les rapporter à l'utilisateur. Ces tests peuvent tourner au moment du build de l'application, au niveau du commit de code, ou même dans votre IDE.

Il y a une multitude de SAST open source à votre disposition, mais pour le bien de ma démonstration, je vais utiliser Gosec [3] en ligne de commandes. Comme j'ai l'habitude d'écrire assez régulièrement des petites applications backend pour démontrer telle ou telle fonctionnalité d'un produit, j'ai pléthore de code à ma disposition. Mais le code que j'utilise n'a pas d'importance (l'application s'appelle bingo), c'est le résultat que l'outil me donne qui compte :

Gosec a détecté deux risques potentiels. Pour chacun d'eux, j'ai un niveau de confiance (il y a bien évidemment des faux positifs), une sévérité (les découvertes sont d'ailleurs rangées par sévérité), la ligne de code qui pose problème, ainsi qu'une explication du problème.

Les limites de l'outil sont bien illustrées par ce court exemple : mon application utilise math/rand au lieu de crypto/rand pour générer un nombre aléatoire, et Gosec rapporte ce problème comme ayant une sévérité élevée, ce qui n'est bien évidemment pas le cas ici, puisque le nombre généré est juste un entier entre 0 et 9 (un nombre que l'utilisateur doit deviner dans l'application). L'outil n'a pas pris en compte le contexte et me retourne donc un faux positif. Cependant, si ce genre d'outils a l'habitude de retourner un grand nombre de faux positifs (et personne n'aime recevoir de warnings de ce genre), ils valent vraiment la peine d'être utilisés pour les quelques problèmes qu'ils ne manqueront pas de découvrir dans votre code.

3.3 DAST

Le Dynamic Application Security Testing est un outil qui permet d'envoyer à une application toutes sortes de données bizarroïdes pour voir comment elle réagit. Si la réponse de l'application est celle attendue, c'est que tout va bien, sinon c'est qu'il y a un problème. Ce type d'outil permet d'identifier différents types d'injections (SQL, script...), mais aussi du cross-site scripting (XSS), et bien plus encore.

Contrairement aux SAST, les DAST n'ont pas besoin d'avoir accès au code de l'application. Par contre, ils ont besoin d'avoir accès à une instance de l'application. Ce qui signifie que ça arrive plus vers la fin du cycle de développement que pendant le développement lui-même.

Pour les points négatifs, les DAST sont compliqués à configurer et ne garantissent pas une couverture complète des différents points d'entrée de l'application. Par ailleurs, ces tests peuvent prendre un certain temps à s'exécuter.

La figure 2 est une capture d'écran de OWASP ZAP [4]. ZAP contient un moteur DAST (fuzz plus précisément, mais le fuzzy testing et DAST sont relativement similaires). En regardant les différents tests, on peut retrouver tout ce qui est XSS et injections.

Pour ceux qui ne seraient pas familiarisés avec ce qu'est une injection, voici deux exemples.

Une injection SQL se produit généralement lorsque vous demandez à un utilisateur un input, comme son nom d'utilisateur, mais au lieu d'un nom, l'utilisateur vous fournit une instruction SQL que vous exécutez involontairement sur votre base de données :

La requête SQL ci-dessus est valide et renverra toutes les lignes de la table Users, car OR 1=1 est toujours vrai (cet exemple vient de W3Schools [5]).

Un autre exemple d'injection de commande serait de placer un eval dans l'input d'une application python, vous permettant ainsi d'exécuter n'importe quelle commande avec les privilèges de l'utilisateur l'exécutant (encore bien trop souvent root).

Donc même s'il présente quelques inconvénients, le DAST est un outil précieux pour tester vos applications.

3.4 IAST

L'Interactive Application Security Testing tout comme le DAST, nécessite une instance de votre application. Mais contrairement au DAST, ce n'est pas du blackbox monitoring : avec un IAST, le code doit être instrumenté avec certaines bibliothèques pour vous aider à identifier des vulnérabilités. Tout comme avec le fuzzy testing, le IAST vous aide à capturer XSS et injections.

Comme il s'agit d'une bibliothèque, bien évidemment votre langage de programmation doit être supporté, mais si vous êtes assez chanceux pour ça, alors il vous sera d'une grande utilité, car il produit beaucoup moins de faux positifs qu'un SAST, parce qu'il bénéficie du contexte de l'application au runtime.

Malheureusement, c'est un outil qui n'a pas une grosse présence en open source, et n'est que rarement gratuit, et ce n'est pas mon rôle de vous recommander tel ou tel autre fournisseur. Quoi qu'il en soit OWASP garde une liste de ces outils à jour, et je ne peux que vous recommander d'aller faire un tour sur leur page [6].

3.5 Récapitulatif

En guise de récapitulatif, voici un tableau vous permettant de mieux comparer ces différents outils :

Cependant, ce n'est pas parce que je vous offre ici un comparatif qu'il faut choisir l'un ou l'autre, et un SAST va facilement de pair avec un DAST ou un IAST.

3.6 SCA

Mais je ne vous ai pas encore parlé du SCA, ou Software Composition Analysis qui est un outil dont il vaut mieux ne pas se passer de nos jours. L'open source a depuis longtemps fait ses preuves, et qui pourrait contester aujourd'hui le temps inestimable qu'il nous fait gagner dans le développement d'applications, que celles-ci soient elles-mêmes open source ou non. J'ai besoin d'effectuer cette fonction très complexe dans mon code (comme la gestion de la pile HTTP ou SSL), alors allons voir s'il n'y a pas une bibliothèque open source capable de m'aider dans ce cas précis ; et, plus souvent que le contraire, elle existe.

Mais qu'est-ce que ça implique ? En important une bibliothèque open source dans votre code, vous utilisez le code de quelqu'un d'autre (façon de parler). Même si vous respectez toutes les bonnes pratiques pour avoir un code sécurisé, et aussi tous les bons outils, rien ne vous garantit que le code que vous avez importé est lui aussi sûr. Et les vulnérabilités sont aussi fréquentes dans l'open source qu'elles le sont ailleurs !

Le SCA vous permet d'identifier ces bibliothèques, et en les comparant à une base de données de vulnérabilités connues pour ces bibliothèques, est en mesure de détecter les CVE qui les impactent.

Par ailleurs, il est bon de lancer régulièrement ces tests, car tous les jours de nouvelles CVE sont découvertes, et une bibliothèque qui ne présentait pas de risque la veille peut avoir besoin d'être mise à jour aujourd'hui.

Cerise sur le gâteau, même si cette fois ça ne touche pas à la sécurité, un SCA vous permet aussi de valider que les licences de ces bibliothèques correspondent à vos besoins (un point à ne pas négliger quand on développe un produit à des fins commerciales).

Cependant, tout comme les IAST, l'offre open source se fait relativement rare, et pour une raison toute simple : il faut avoir accès à des bases de données de CVE, et toutes (loin s'en faut) ne sont pas open source. Vous pouvez néanmoins trouver quelques outils gratuits, comme les vulnerability scanners qui sont utilisés pour scanner les différentes couches qui composent les images d'un conteneur [7].

4. CSPM

Mais assez parlé d'AppSec ! Je vous propose encore un autre acronyme : CSPM pour Cloud Security Posture Management. Mais même le nom ne nous dit pas exactement de quoi il retourne.

Un peu plus tôt j'ai parlé de l'adoption de l'open source, la même chose est certainement vraie pour le cloud. Si tout le monde n'a pas entièrement basculé dans le cloud, il n'est pas non plus rare de voir des déploiements hybrides. Ce qui est plus rare de nos jours, c'est de n'avoir absolument rien dans le cloud. Le cloud est un outil pratique et facile quand on doit prototyper une solution, mais lorsqu'il s'agit d'y faire tourner sa production, même s'il demeure toujours aussi pratique, sa complexité évolue de façon exponentielle ! Et malheureusement, la moindre mauvaise configuration (un bucket s3 accessible publiquement, un security group un peu trop laxiste) peut entraîner rapidement des fuites de données. D'ailleurs, plus que les CVE, les mauvaises configurations sont responsables de la plupart des brèches de sécurité [8]. Avouez que ça donne à réfléchir !

Dès lors, comment savoir si mes configurations sont bonnes ou mauvaises ? Sur quelles règles s'appuyer ? Par chance, ces règles sont bien documentées, et peut-être connaissez-vous déjà certains frameworks de conformité comme ISO 27001, SOC-2 et autres. Parce que ces règles doivent pouvoir être auditées, elles ont nécessairement besoin d'être documentées.

Mais sans entrer plus avant dans les frameworks de conformité, un excellent point de départ pour s'assurer que l'on suit les bonnes pratiques de sécurité pour nos configurations est le CIS Benchmark. En vous rendant sur leur site [9], vous pouvez télécharger un PDF avec toutes les recommandations dont vous avez besoin, et la manière de les mettre en œuvre.

Par exemple, si nous jetons un œil au CIS Benchmark pour Docker, une des premières recommandations est d'avoir une partition séparée pour /var/lib/docker. Le CIS Benchmark nous informe ensuite de la raison pour laquelle c'est recommandé : parce que Docker stocke ses fichiers à cet emplacement, images de conteneurs y compris. Il est donc possible de remplir rapidement un disque si l'on n'y prend pas garde, et ainsi rendre Docker, mais aussi la machine, instables. En créant un point de montage pour /var/lib/docker, on s'assure de protéger la machine dans le cas où Docker remplirait sa partition. Mais la recommandation ne s'arrête pas là, et c'est justement le point où je veux en venir : le CIS Benchmark nous donne ensuite le moyen d'auditer cette recommandation.

La commande grep '/var/lib/docker\s' /proc/mounts doit retourner les détails de la partition pour ce point de montage.

La commande mountpoint -- "$(docker info -f '{{ .DockerRootDir }}')" vous dit si le répertoire est un point de montage.

Dans la mesure où cette configuration peut être auditée, alors nous ne sommes qu'à un pas de la monitorer. Il nous suffit d'avoir un simple script shell à lancer sur toutes les machines qui ont Docker installé et qui retourne vrai ou faux si la configuration est mise en place ou non. En résumé, CSPM n'est rien de plus que cela. Maintenant vous vous doutez que ce n'est pas aussi simple : vous avez probablement un nombre conséquent de ressources à analyser sur des centaines de critères différents. Qui plus est, les recommandations évoluent au fil du temps. J'ai pris le CIS Benchmark Docker v1.6.0, mais il y a eu d'autres versions avant celle-là, et il y en aura encore d'autres après.

Heureusement, la plupart des éditeurs nous donnent les moyens de réaliser un benchmark de leurs produits. Continuons notre audit de Docker, cette fois en utilisant docker-bench-security [10] :

J'ai tronqué l'output, mais cela devrait vous donner un bon aperçu de ce que l'outil est capable de faire. C'est plus simple que d'écrire le script soi-même ! Cependant ça reste manuel et pas très centralisé. La mauvaise nouvelle, c'est que je ne connais pas d'outil de CSPM gratuit vous permettant de monitorer la conformité de vos différents operating systems, cloud providers, Docker, Kubernetes et j'en passe. Jetez tout de même un œil à Magpie [11] qui a fait l'annonce de son CSPM open source à la conférence BlackHat en août 2021.

5. Cloud SIEM

Dernier outil de ma liste, dernier acronyme SIEM. SIEM signifie Security Information and Event Management. Encore une fois, le nom n'est guère plus explicite de l'acronyme, mais encore une fois il s'agit de cloud. Quand vous utilisez un cloud provider, celui-ci produit régulièrement des logs et des événements. Si vous voulez vous assurer que rien de fâcheux n'arrive à votre plateforme, alors bien évidemment vous vous devez d'auditer ces logs et ces événements régulièrement. Mais dès lors vous faites face à deux challenges :

• Le nombre de logs et d'évènements produits quotidiennement par ces plateformes est colossal.
• En quoi consiste un incident de sécurité ? Ou en d'autres termes, est-ce qu'il existe un framework pour auditer ces logs ?

Pour le premier challenge, évidemment la seule réponse que l'on puisse apporter c'est qu'il faut automatiser l'audit. Quant au deuxième, la bonne nouvelle c'est que oui, il existe un jeu de règles pour réaliser cet audit, et cerise sur le gâteau, certaines sont open source ! La mauvaise nouvelle cependant, c'est que seul le jeu de règle est open source, pour les utiliser il vous faudra un backend de logs centralisé (comme OpenSearch par exemple, pour n'en citer qu'un).

L'ensemble des règles se trouve dans le repository GitHub de Sigma [12]. Elles peuvent être converties et importées pour votre propre backend (quel que soit ce backend d'ailleurs, car elles constituent aujourd'hui une sorte de standard). Une fois ces règles importées, il suffit qu'elles soient exécutées sur votre stream de logs et d'évènements pour émettre des signaux vous permettant d'identifier des activités suspectes. Pour ne donner qu'un exemple, une règle pourrait être le voyage impossible : un même utilisateur essayant de se connecter en l'espace de très peu de temps depuis des endroits différents (Los Angeles, Paris et Pékin).

Si le SIEM est un must have pour l'audit des journaux de votre cloud provider, il est cependant bon de savoir que ces règles sont open source et relativement simples à écrire. À partir de là vous pouvez aisément étendre ce jeu de règles à à peu près tout, y compris vos propres applications (write once, run everywhere) !

Conclusion

Voici qui nous amène doucement vers la fin de cet article. Un voyage au travers de ce qu'il est possible de monitorer au niveau de la sécurité, que ce soit du point de vue de vos applications (AppSec) ou de votre infrastructure (CSPM et SIEM). Ce qu'il est important de retenir, c'est que la sécurité ne dépend plus (d'ailleurs ça n'a jamais été le cas) d'une équipe de sécurité capable de sécuriser vos déploiements avec un bouton magique. À chaque étape de la chaîne, nous avons notre rôle à jouer. Par ailleurs, si vous vous plaignez du shift left de la sécurité, et que ça vous fait perdre du temps lors du déploiement de nouvelles fonctionnalités, mon ami vous êtes dans l'erreur (ou le déni), car c'est tout le contraire. Non seulement vous allez participer à rendre l'ensemble plus sûr, mais vous allez aussi y gagner du temps : une nouvelle fonctionnalité n'est jamais déployée sans que la sécurité n'en soit validée. Si cet audit arrive en bout de chaîne et que c'est la responsabilité d'une seule équipe qui ne dispose pas de tous les éléments dont vous disposez (comme le code source de l'application, mais bien aussi la compréhension de ce code source), ça peut prendre des lustres (si vous avez de la chance), si pour le moins la release ne vous est pas tout simplement retournée parce qu'elle présente des failles de sécurité...

Bien sûr, dans le domaine de la sécurité il n'est jamais simple de trouver des outils open source (et si possible gratuits). Cependant, cela ne devrait jamais constituer un frein à l'adoption, car le coût d'un outil n'est rien à côté du coût, pour une entreprise, d'une brèche de sécurité et d'une fuite de données. Au mieux cela coûte quelques millions, au pire l'entreprise ne s'en relève pas. C'est comme refuser de prendre une assurance en se disant que ce genre de choses n'arrivent qu'aux autres. Croisez bien fort les doigts si c'est votre cas.

Dans tous les cas j'espère que ce voyage aura été instructif, et que pour le moins il vous aura donné un meilleur aperçu de ce qu'il est possible de faire dans ce domaine.

Références

[1] Le nombre de CVE est en augmentation croissante : https://www.cvedetails.com/browse-by-date.php

[2] Le site officiel de OWASP : https://owasp.org/

[3] Le repository de Gosec pour les développeurs Go : https://github.com/securego/gosec

[4] OWASP ZAP, un outil de DAST très complet : https://www.zaproxy.org/

[5] Exemple d'injection SQL fourni par W3School : https://www.w3schools.com/sql/sql_injection.asp

[6] La liste compilée d'outils de sécurité fournie par OWASP :
https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

[7] Trivy, le scanner de vulnérabilités d'AquaSec : https://github.com/aquasecurity/trivy

[8] Un article très intéressant sur les brèches de sécurité dues à de mauvaises configurations :
https://securityaffairs.co/wordpress/117305/security/cloud-misconfiguration-risks.html

[9] Le site officiel de CIS Benhmark : https://www.cisecurity.org/cis-benchmarks

[10] Le repository GitHub de docker-bench-security : https://github.com/docker/docker-bench-security

[11] Le repository GitHub de Magppie : https://github.com/openraven/magpie

[12] Le repository GitHub de Sigma : https://github.com/SigmaHQ/sigma