Introduction

Nous avons vu un certain nombre d’outils et de pratiques à mettre en œuvre au sein des pipelines CI/CD, sur les hôtes de nos conteneurs, sur les images Docker ainsi que sur les fichiers Kubernetes. De même, les différentes technologies liées au chiffrement ont été abordées et détaillées. Cependant, il convient de s’arrêter, sur ce chapitre, sur la sécurisation du développement en lui-même.

En effet, le DevSecOps se concentre principalement sur le « Shift Left », ou le fait de gérer la sécurité au plus tôt dans le cycle de développement du logiciel (SDLC). Nous allons donc voir les différentes étapes à respecter et les bonnes pratiques pour intégrer la sécurité à chaque étape, mais également une fois que le service est déployé. Il est essentiel de garder une vue d’ensemble sur l’état de santé de notre infrastructure et de nos services, car la sécurité ne s’arrête pas uniquement au développement à proprement parler.

Application de la sécurité au SDLC (Software Development Life Cycle)

1. SDLC et méthodologie

Le SDLC correspond à une méthodologie à appliquer lors du développement logiciel. Un peu comme ce que vous pouvez retrouver pour la gestion de projets IT avec les méthodes agile, ITIL ou DevOps, le SDLC propose un certain nombre d’étapes clés pour assurer la fiabilité, la qualité et l’adéquation du développement avec les besoins des utilisateurs.

Le nombre d’étapes peut varier en fonction des documents que vous trouvez sur Internet ou dans les revues dédiées au développement.

a. Planification & recueil des besoins

À ce niveau, les développeurs les plus expérimentés (ou certains chefs de projets) vont être en charge de récupérer l’ensemble des besoins auprès des différentes parties prenantes (ou stakeholders en anglais). L’objectif est ensuite de planifier les autres étapes du SDLC de manière plus fine grâce aux besoins récupérés.

Au moment du recueil des besoins, il convient de reformuler auprès des stakeholders les éléments récupérés, afin de s’assurer que le ou les produit(s) à développer correspondent bien à ce qui est attendu.

Il n’existe rien de pire pour une équipe que de se lancer dans un processus de développement long et difficile pour ensuite devoir tout recommencer car le produit terminé ne correspond pas aux besoins réels des clients.

L’équipe cherche ensuite à évaluer les risques associés, mais également les critères de succès pour chaque élément. Cela permet d’obtenir une image globale du projet, la plus précise...

SSDLC (Secure Software Development Life Cycle)

1. Mise en œuvre du Threat Modeling

a. Déployer le Threat Modeling en entreprise

En français, il est question de « modélisation des menaces ». Il s’agit de réaliser une activité avec l’ensemble des stakeholders techniques et non techniques afin d’identifier, de mesurer, d’évaluer et de réfléchir à des contre-mesures concernant les menaces potentielles auxquelles le(s) produit(s) pourrai(en)t être confronté(s).

En général, les équipes dessinent un schéma avec l’ensemble des éléments principaux puis mettent en lumière les failles, les menaces et les surfaces d’attaque potentielles.

Il existe un Threat Modeling Manifesto, disponible à l’adresse https://www.threatmodelingmanifesto.org/, qui reprend les questions principales qu’il est nécessaire de se poser, que l’on pourrait traduire de la manière suivante :

Sur quoi sommes-nous en train de travailler ?
Qu’est-ce qui pourrait mal se passer ?
Qu’allons-nous faire à propos de cela ?
Avons-nous effectué un travail suffisamment bon ?

Ce Manifest nous invite à suivre les valeurs suivantes lors de la réalisation de ce Threat Modeling :

Approche systémique
Créativité
Pluralité des points de vue
Utilisation d’outils facilitant l’exécution des différentes tâches
Application pratique plutôt que théorique

En résumant l’ensemble des informations disponibles à ce sujet, cinq grands périmètres d’actions sont à prendre en considération lors de la réalisation du Threat Modeling.

Intégrer l’ensemble des parties prenantes, afin d’obtenir...

TOP 10 de l’OWASP

1. Introduction au TOP 10 de l’OWASP

L’OWASP (Open Web Application Security Project) s’occupe de présenter régulièrement des ressources, à disposition des professionnels de l’informatique, correspondant à la sécurité des applications web. Tous les documents proposés, ainsi que les liens et les ressources, sont complètement gratuits. Cette organisation a créé un certain nombre de projets, de Frameworks, de listes, de bonnes pratiques, pour que tout le monde puisse améliorer la sécurité des applications web.

Parmi les projets les plus connus de l’OWASP, vous pouvez retrouver le TOP 10. Il s’agit d’une analyse des attaques les plus courantes dont sont victimes les applications web. Cette liste est mise à jour assez régulièrement et, au moment de l’écriture de cet ouvrage, la dernière liste est celle de 2021.

A01:2021 - Broken Access Control : cette catégorie est montée tout en haut du podium à cause de la multiplication des tentatives d’authentification frauduleuses, qui ont explosé ces dernières années. Vous y retrouvez la plupart des notions liées à l’authentification et à la gestion des mots de passe (cf. section Authentication and Password Management), dont nous avons déjà parlé dans ce chapitre.

A02:2021 - Cryptographic Failures : à la deuxième place du classement figurent les notions autour de la cryptographie et du chiffrement. Cette catégorie met l’accent sur les problèmes d’exposition de données sensibles et de compromission des systèmes liés à des chiffrements insuffisants ou inadaptés.

A03:2021 - Injection : cette catégorie fait référence, bien entendu...

Gestion des évènements de votre infrastructure

Dans une infrastructure, quasiment tous les équipements, les services, et les applications émettent de nombreux logs. Il s’agit d’un ensemble de notifications datées marquant un évènement particulier.

Aujourd’hui, il est devenu indispensable de gérer de manière efficace les différents messages émis par les « assets » de vos architectures.

1. Mettre en place un système de centralisation des logs

En général, les logs sont stockés dans des fichiers locaux sur les machines qui les ont émis. Par exemple, sur les systèmes Ubuntu, les évènements relatifs aux services d’un système Linux sont stockés dans le fichier /var/log/syslog, qui se remplit au fur et à mesure que ces logs sont générés.

Voici un exemple du contenu d’un fichier /var/log/syslog :

Nov 25 15:55:11 k8s-controller systemd[907650]: Reached target 
Basic System. 
Nov 25 15:55:11 k8s-controller systemd[907650]: Reached target 
Main User Target. 
Nov 25 15:55:11 k8s-controller systemd[907650]: Startup finished 
in 106ms. 
Nov 25 15:55:11 k8s-controller systemd[1]: Started User Manager 
for UID 1558258428. 
Nov 25 15:59:23 k8s-controller snapd[3978112]: autorefresh.go:540: 
auto-refresh: all snaps are up-to-date 
Nov 25 16:07:59 k8s-controller systemd[1]: 
run-containerd-runc-k8s.io-4f4629c4d38f6bae8749242dca58054b7ecc0aae1
31530567426a337f117f6c7-runc.p3mxPV.mount: Deactivated successfully. 
Nov 25 16:17:01 k8s-controller CRON[916109]: (root) CMD (   cd / 
&& run-parts --report /etc/cron.hourly)

Or ils contiennent des informations essentielles au fonctionnement des différents systèmes et services, mais également des attaques informatiques...

Supervision de la stack applicative avec Prometheus et Grafana

1. Supervision et métriques

Nous avons déjà parlé de nombreuses fois de supervision ou de monitoring. Cela permet aux différentes équipes (Dev, Ops, Sécurité, Business...) de suivre l’état de santé des différents éléments de l’infrastructure.

Même si à première vue, cela ne semble pas être du ressort de la sécurité, souvenez-vous que la disponibilité fait partie intégrante du CIA. Il est donc indispensable de s’assurer de la bonne disponibilité des différents services et applications auprès des utilisateurs finaux. En allant plus loin, il convient également de vérifier que les performances de ces éléments soient suffisantes pour assurer un service de bonne qualité.

En plus des services et des applications, la supervision permet de surveiller les composants matériels, les serveurs, les équipements réseau, les bases de données, les baies de stockage, etc. L’idée est d’avoir une vue d’ensemble et d’être alerté en cas de défaillances de certains éléments de l’infrastructure.

Avec la supervision, il devient aussi possible de faire des analyses de tendance à court, moyen et long termes. Vous pouvez ainsi déterminer si le nombre d’utilisateurs augmente et à quel rythme. Il devient possible de vérifier si l’utilisation d’une base de données est en augmentation et s’il est nécessaire d’en créer de nouveaux replicas. De même, vous pouvez mesurer le taux de panne de vos systèmes et de vos applications, si les performances de vos services sont meilleures ou moins bonnes à la suite d’une...

Conclusion

Dans ce chapitre nous avons abordé plusieurs points essentiels. Tout d’abord, nous avons vu comment le SDLC permet de définir un cadre pour les activités de développement avec les principales étapes à respecter. Il est ensuite possible, en utilisant le Threat Modeling et la production de Secure Coding Checklist, d’intégrer la sécurité au cœur du SDLC pour en faire du SSDLC.

Vous avez pu voir différents challenges de pentesting autour des trois premières catégories du TOP 10 de l’OWASP, avec le Broken Access Control, les Cryptographic Failure, et les injections. Gardez en mémoire la manière dont vous avez résolu ces challenges pour mieux comprendre comment pense un hacker et ce qu’il va essayer en premier lieu comme techniques pour tenter d’attaquer votre infrastructure.

Grâce à Prometheus et Grafana, vous voyez qu’il est aisé de garder un œil sur l’état de santé des différents éléments de l’infrastructure, qu’ils correspondent à du système, du réseau, des services ou des applications. Gardez en tête qu’une infrastructure inviolable n’existe pas, mais qu’il est plus important d’avoir une vision complète des différents assets que l’on opère, plutôt que de se concentrer uniquement sur la défense périmétrique en mettant toute son énergie dans la configuration et l’administration des firewalls.

Sécurité du développement et bonnes pratiques