Salut InfoSec, que faites-vous pour protéger votre équipe DevOps ?

DevOps, applications sans serveur et conteneurs ne sont que quelques exemples des dernières avancées technologiques à la disposition des développeurs. Pour les équipes de développement, cela signifie un délai de mise sur le marché plus court, notamment pour les équipes agiles. Dès lors, comment les équipes de sécurité opérationnelle s'y prennent-elles pour garantir que la sécurité suive le rythme de ce développement rapide ? La plupart tentent d'intégrer un ingénieur sécurité au sein de leurs équipes de développement, ce qui constitue un excellent premier pas. Cependant, il existe de nombreux niveaux de protection à mettre en place pour garantir la sécurité de votre organisation, au-delà du simple code source.

Le DevOps, ou DevSecOps, représente un grand pas en avant, mais son adoption (et sa mise en œuvre) reste difficile pour de nombreuses organisations. Même après la mise en place du DevSecOps, des problèmes majeurs subsistent et chaque équipe de sécurité doit en être consciente.

Quelle que soit la taille de l'organisation — d'une petite start-up technologique à une multinationale —, un déploiement rapide est essentiel pour conserver un avantage concurrentiel. La sécurité doit garantir à votre équipe de développement les droits nécessaires à l'exécution de ses tâches. Développeurs et équipes de sécurité doivent pouvoir installer les outils, bibliothèques, etc., en fonction de leurs besoins.

Vous avez entendu parler de NPM compromis n'est-ce pas ? Qu'en est-il de Arch Linux? PythonQuelles mesures de sécurité avez-vous mises en place au sein de votre organisation pour détecter et prévenir ce type d'incident ?

Surveillez tous les environnements

Les équipes de sécurité doivent gérer quotidiennement une multitude de problèmes, allant des compromissions des packages tiers en amont à leurs systèmes de production. Mais qu'en est-il des environnements de déploiement ? Des environnements de test ? Les surveillez-vous aussi attentivement que la production ? Vous devriez.

Dans de nombreuses situations (mais ce n'est pas forcément une bonne pratique), un environnement de développement ou d'assurance qualité est une réplique d'un environnement fonctionnel (comme la production). Cela signifie que cet environnement peut-être production Données dont vos équipes de sécurité doivent avoir connaissance. Ces environnements de développement doivent appliquer des contrôles de sécurité identiques ou similaires à ceux de leurs environnements de production et doivent être surveillés (et consignés) comme tout système de production.

Vous pouvez ajouter de nombreux autres contrôles, mais l'essentiel est de vous assurer que votre équipe surveille avec précision ces environnements et a une visibilité sur toutes les modifications apportées à chaque environnement.

Si vos environnements de développement ou d'assurance qualité regorgent de données hors production, il existe néanmoins des risques dont vous devez être conscients.

Clés, jetons, CI/CD, oh là là !

Vos développeurs ont-ils accès à vos environnements de compilation et de déploiement CI/CD (intégration continue et livraison continue) ? Ont-ils accès à des environnements de développement, que ce soit en local ou sur AWS/Azure/GCP/etc. ?

Si vous avez répondu oui, vous devez impérativement surveiller de près l'activité de vos développeurs (en particulier sur leur système local) ! Il suffit de visiter un site malveillant ou de se laisser piéger par un courriel d'hameçonnage pour vous mettre en grand danger.

Si vos développeurs accèdent à des ressources cloud, ils utilisent généralement des identifiants ou des clés d'accès/secrètes pour y accéder. Devinez où ils sont stockés ? Eh oui, sur leur système local. Voici une liste rapide des emplacements où chercher :

Interface de ligne de commande AWS : ls ~/.aws ~/.aws/credentials ~/.aws/config Interface de ligne de commande Azure : $HOME/.azure (*nix et macOS) %USERPROFILE%\.azure (Windows)

Si les identifiants de connexion sur les machines de vos développeurs sont compromis, les conséquences pourraient être désastreuses pour votre organisation. Un acteur malveillant peut modifier vos environnements CI/CD et altérer votre code source sans jamais être détecté dans les binaires compilés ou les bibliothèques.

De plus, vous devez empêcher les développeurs d'inclure accidentellement des secrets dans les dépôts. Il existe plusieurs façons de détecter cela, mais l'une d'elles consiste à utiliser git-secrets d'AWS.

Assurez-vous que votre équipe de sécurité comprenne où sont conservés les secrets, comment ils sont utilisés et quelles sont les conséquences d'un défaut de surveillance ou d'alerte en cas d'utilisation abusive potentielle de ces identifiants.

conteneurisation

À mesure que les organisations migrent vers les conteneurs, le serverless et l'infrastructure en tant que code, les équipes de sécurité informatique doivent collaborer avec les équipes de développement pour mettre en place un dépôt de conteneurs interne, surveillé en permanence par l'équipe de sécurité. Si un nouveau package ou une nouvelle bibliothèque est nécessaire, assurez-vous qu'un ingénieur en sécurité (de votre équipe de développement) examine le code avant son intégration à la branche principale. De plus, vous devriez mettre en œuvre une analyse automatisée de vos dépôts afin d'identifier les éventuelles données sensibles présentes dans les commits et les bibliothèques tierces vulnérables importées ou utilisées dans votre produit.

Équipe de développement + sécurité

Imaginez que vous faites partie d'une équipe de développement et qu'une personne d'un autre service vienne vous dire que votre travail est nul et qu'il y a des failles de sécurité partout. Comment réagiriez-vous ? Probablement pas très bien, surtout si vous pensez que votre code est plutôt bon !

Ce type d'interaction avec les équipes de développement est fréquent et nous devons repenser notre approche. C'est pourquoi nous devons intégrer des ingénieurs en sécurité à nos équipes de développement. Cet ingénieur doit être capable d'identifier les problèmes de sécurité, de créer des tickets d'incident et de les résoudre. Cette personne clé combine les compétences de développeur et de spécialiste en sécurité au sein de l'équipe de développement.

Imaginez maintenant recevoir un retour de votre collègue. La réaction du reste de l'équipe de développement serait plus compréhensive et une communication directe serait établie, permettant notamment de tisser une relation durable entre les développeurs et l'équipe de sécurité. À mesure que votre collègue se sentira en confiance, les autres développeurs hésiteront à lui confier davantage de travail. Pensez-vous donc qu'ils prendront leur temps ou qu'ils s'arrêteront pour réfléchir à leur implémentation ? J'en suis convaincu.

De plus, cet ingénieur en sécurité devrait être impliqué dans les discussions avec le chef de produit/responsable produit et l'architecte dès les premières étapes, car il est de facto le responsable de la sécurité et devrait participer aux décisions de conception initiales susceptibles d'avoir un impact sur la manière dont votre produit gère la sécurité (pensez à l'authentification, aux secrets partagés, aux communications, etc.).

Conclure

Tous les professionnels de la sécurité sont surchargés. Les alertes sont trop nombreuses et les journées trop courtes. Même s'il est impossible de répondre à chaque alerte, les membres de l'équipe du centre des opérations de sécurité (SOC) doivent comprendre la mission de leur organisation, l'emplacement de leurs actifs critiques et les menaces à surveiller dans un paysage en constante évolution. En collaborant avec les équipes de développement, nous pouvons contribuer à protéger nos organisations respectives et intégrer la sécurité à notre cycle de développement.