L’automatisation de la sécurité dans DevOps

Les environnements Cloud et les cycles DevOps nécessitent un niveau d’automatisation élevé. La sécurité doit s’adapter à ces environnements en tendant vers le plus d’automatisation possible de ses activités. C’est ce qui permet de rester agile en préservant un niveau acceptable des risques. La Cloud Security Alliance (qui propose les certifications individuelles CCSK et CCAK pour les professionnels de la sécurité dans le Cloud et aussi l’attestation STAR pour les fournisseurs) coordonne un groupe de travail qui produit des guides très complets. Ces aspects font partie du programme du CISSP (bien qu’abordés de manière très généraliste) et des certifications CCSP et CCSLP.

Le cycle DevSecOps

Le cycle DevSecOps comprend l’intégration de la sécurité dans les étapes suivantes :

  1. Conception et architecture.
  2. Développement.
  3. Intégration continue (« Continuous integration»).
  4. Déploiement continu (« Continous Delivery »).
  5. Supervision.

Les éléments déclencheurs

Les déclencheurs du pipeline de livraison (« delivery pipeline ») à l’origine d’une tâche automatique peuvent être une nouvelle caractéristique de l’application, un « pull », un « clone » ou un nouveau développement, une action d’intégration, la constitution d’un nouveau « package », une phase de test, la publication d’une image dans un répertoire ou l’instanciation d’un élément automatique d’infrastructure, « Infrastructure-as-a Code » que ce soit système ou réseau (SDN - Software Defined Network en environnement Cloud par exemple).

Exemples d’activités automatiques

Les tâches de sécurité automatisables qui peuvent être déclenchées comprennent :

  • Les outils d’analyse statique (SAST – Static Application Security Testing). On trouve plusieurs types d’outils. Par exemple certains outils scannent tout ou partie d’un code source et détecte des vulnérabilités potentielles. D’autres outils sont intégrés à l’environnement de développement et remontent en temps réels des alertes au développeur. Un bénéfice supplémentaire est de participer à la formation des développeurs qui peuvent acquérir plus de connaissances sur une faille qu’il ne connaissait pas grâce aux interfaces d’aide et aux tutoriels de ces outils (Pumascan par exemple). Enfin, d’autres programmes sont spécialisés sur la recherche automatique de secrets (clés privés, mots de passe, empreintes, clés de session…) stockées dans le code (Talisman par exemple).
  • Les outils d’analyse dynamique qui fonctionnent à partir du moment où l’on dispose d’un environnement d’exécution pour l’application. On trouve aussi les outils de type « fuzzing » qui détecte des failles potentielles de développement par l’injection de données mal formées.
  • Les scanners de vulnérabilités publiques.
  • Les outils de type IAST (interactive application security testing) pour réaliser des tests semi-automatisés sur des API par exemple.
  • Les outils de type RASP (Runtime Application Security Protection) intégrés à l’application en production et fonctionnant de manière similaire à un WAF (Web Application Firewall) .

Il faut néanmoins toujours garder en tête que les outils automatiques sont loin d’être efficaces à 100%. Par exemple, le NIST a réalisé une étude comparative sur une cible de 14 outils et a mis en évidence que plus de la moitié des vulnérabilités n’étaient détectées par aucun outil et que moins de 1% des vulnérabilités étaient trouvées par tous les outils.

Activités manuelles

Certaines activités ne sont pas automatisables. Il faut les mettre en œuvre d’un manière pragmatique et ciblée afin de conserver l’agilité des cycles CI/CD. Parmi ces activités figurent la modélisation de menaces, les revues de code et les tests d’intrusion.

  Pour en savoir plus sur les 20 meilleures formations sur la sécurité des systèmes d’information, téléchargez gratuitement notre livre blanc ci-dessous :

CISSP, CCSP, CCSK, CCAK, DevSecOps, SAST, DAST, RASP, IaaC