Pour gérer vos consentements :

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 :

1- Tests de code automatisés

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.

2- « Break the build »

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.

3 – Tests manuels et exercices « Red Team »

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.

4 – « Bug bounty »

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.

Recent Posts

Du ransomware au ransomware as a service : comment aller plus loin dans la lutte à l’heure de l’Intelligence artificielle

Si j'avais un seul souhait à formuler pour 2024, ce serait que l'on cesse d’appeler…

3 heures ago

Le défi de la cybersécurité des infrastructures critiques du secteur de l’énergie

La cybersécurité est un enjeu crucial pour le secteur de l'énergie et de manière générale…

2 jours ago

Les paquets de données : pilier fondamental de la cybersécurité

L'absence d'une analyse poussée des paquets de données peut avoir des conséquences désastreuses pour les…

6 jours ago

Les entreprises en quête de solutions face aux faiblesses du cloud

La convergence d'un cadre de Zero Trust et d'une collaboration renforcée entre les équipes de…

1 semaine ago

Dark Web et groupes de cybercriminels : décryptage

Il est assez compliqué de bloquer l’accès au Dark Web. Cependant, en bloquant l’installation du…

1 semaine ago

Allier le FinOps au GreenOps pour des dépenses Cloud plus écoresponsables

En adoptant la méthode FinOps, une entreprise s’assure une optimisation de ses investissements Cloud. En…

2 semaines ago