DevOps & sécurité : quatre mesures pour une alliance parfaite

Le DevOps est parfaitement adapté pour délivrer des applications performantes, qui peuvent être rapidement disponibles et mises à jour par la suite. Pourtant, il fait courir de nouveaux risques de sécurité pour les accès à privilèges.

Traditionnellement, les équipes de sécurité pouvaient mettre en place des « portes » (gates) dans le processus de développement pour vérifier que l'application satisfaisait aux exigences de sécurité avant d'être délivrée aux utilisateurs. Mais avec l'approche CI/CD (intégration continue / distribution continue), ces portes ne correspondent plus au modèle de déploiement habituel et les équipes de sécurité doivent repenser leurs processus.

Pour suivre ce rythme soutenu, tout en respectant les principales exigences de sécurité des accès à privilèges, les organisations peuvent s'appuyer sur quatre approches stratégiques :

Les équipes de sécurité doivent s'efforcer d'automatiser autant que possible les tests d'applications, en utilisant une combinaison de scripts personnalisés et d'outils. Cela permet d'identifier rapidement les vulnérabilités et les codes malveillants au sein des applications, un avantage particulièrement appréciable lorsque l'on travaille à la vitesse des équipes DevOps.

Le département IT peut aussi s'assurer que les applications récupèrent correctement les secrets à partir d'un coffre-fort centralisé et chiffré, et que les mots de passe ne sont pas enregistrés dans des logs d'activités.

Un test automatisé révélant un problème donne aux équipes de sécurité de nouveaux arguments pour guider et inciter les développeurs à respecter les exigences fondamentales de cybersécurité. Par exemple, une approche « break the build » oblige les développeurs à résoudre les problèmes de sécurité dès leur code et, tant que ce n'est pas fait, ils ne seront pas en mesure de soumettre leur travail.

En outre, l'évaluation du risque devient alors partie intégrante du processus de développement : si le risque dépasse un seuil prédéterminé, le « building » - soit le fait de rassembler des codes sources en une application - est automatiquement interrompu.
Plus largement, les équipes IT doivent vérifier la sécurité dès le début du processus de développement, afin d'atténuer les risques au maximum.

Les organisations doivent garder en tête que les attaquants font preuve de créativité et de persévérance. Pour surprendre ces cybercriminels de plus en plus chevronnés et stopper les attaques avant qu'elles n'aient des répercussions sur leurs activités, les entreprises doivent donc penser comme un attaquant.

Pour ce faire, il convient de combiner des tests automatisés statiques et dynamiques, ainsi que des tentatives manuelles d'intrusion ; les équipes de sécurité doivent alors se pencher à la fois sur l'application et sur les outils utilisés pour la déployer.

Des exercices réguliers par une Red Team - soit une équipe extérieure simulant une attaque - s'avèrent également pertinents pour déceler les vulnérabilités, identifier les domaines à améliorer et formuler des recommandations en fonction des risques.

Il s'agit d'inviter des professionnels de la sécurité et des hackers éthiques ou « white-hats » à trouver des problèmes de sécurité - s'il y en a - et d'octroyer une récompense aux personnes qui en ont trouvé et les ont signalés de façon confidentielle. Le suivi des résultats apporte des preuves concrètes des vulnérabilités et de leur coût financier pour l'entreprise.

Avant de lancer un programme de « bug bounty », il est important d'établir un accord d'exploitation officiel entre l'entreprise et ses participants, dans lequel il est précisé que ces derniers ne causeront aucun tort à l'entreprise. À cette fin, il importe de veiller à ce que l'équipe de direction comprenne la nature du programme et les règles établies, pour maintenir la transparence tout au long du processus.

L'adoption des environnements DevOps invite les équipes de sécurité à sortir des sentiers battus et à mettre en place des processus pour détecter et identifier les risques. Cela suppose d'utiliser des tests d'intrusion, des exercices « Red Teams », des programmes de « bug bounty » et d'autres approches créatives pour trouver et résoudre les vulnérabilités, avant que les attaquants ne le fassent.

Autre point important, la collaboration : les responsables de la sécurité doivent continuer de travailler avec les développeurs et leur rappeler que la cyberprotection est une responsabilité partagée.

Jérôme Colleu, Pre-sales engineer - CyberArk.