Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Comment le Security as code relève les nouveaux défis du DevSecOps

octobre 2021 par Cindy Blake, Senior Product Marketing Manager & Security Specialist, GitLab

Le Security as code est un des moteurs de l’évolution actuelle de la sécurité des applications. Il va de pair avec le développement moderne de logiciels et l’essor de l’Infrastructure as code (IaC), mais il aide également les organisations axées sur l’innovation à mieux aborder et gérer le plus grand défi de sécurité observé depuis une génération.

La méthodologie DevOps a réussi à briser les silos entre le développement et les opérations, et le cloud permet aux développeurs de coder plus rapidement. L’infrastructure nécessaire pour héberger le code dans le cloud peut être configurée facilement. Cependant, cette étape de configuration est souvent source d’erreurs et de vulnérabilités en matière de sécurité. Pour éliminer les étapes manuelles et améliorer la cohérence et la sécurité des logiciels, ces configurations sont désormais codifiées sous forme d’Infrastructure as code.

L’IaC assure la mise à l’échelle, la rapidité, la cohérence, la visibilité et la traçabilité des modifications apportées à chaque configuration. Le problème est que les équipes DevOps et de sécurité de l’entreprise doivent actionner un grand nombre de leviers différents. Les paramètres de configuration étant intégrés dans différents services de cloud, conteneurs, orchestrateurs et outils de création et de déploiement de logiciels, il est souvent difficile pour les équipes de développement et de sécurité de garantir une configuration globale correcte.

Grâce à l’automatisation, ces différentes politiques peuvent être configurées de manière centralisée et appliquées de manière cohérente à tous les projets. Cette innovation élimine la dépendance à l’égard de la prise de décision individuelle (et son potentiel d’erreur évident) mais, ce faisant, elle crée une cible centralisée pour quiconque souhaite injecter des configurations malveillantes. C’est là que se situe le danger.

La configuration peut être automatisée ; elle est reproductible et conforme aux normes, mais elle peut au contraire être un fouillis d’éléments uniques créés sans réelle compréhension de l’impact des choix effectués. Dans tous les cas, la sécurité doit être assurée pour le matériel, les applications et l’infrastructure dont dépendent les applications aux stades du développement, du déploiement et de l’utilisation. Avec des paramètres codifiés sous forme d’IaC, ce code doit être traité avec la même rigueur que le code des applications.

Ici, le catalyseur est l’automatisation et la possibilité de réduire le délai de déploiement des logiciels.

L’IaC automatisée est par nature quasi instantanée. Vos équipes peuvent désormais mettre en production l’infrastructure et le code en une seule étape. Mais si le code n’est pas sécurisé, les vulnérabilités peuvent être déployées avec lui sans qu’il soit possible de tester l’intégrité de la configuration. Il est donc nécessaire d’automatiser les contrôles de sécurité et de les intégrer dans les processus d’assemblage et de déploiement des logiciels, plutôt que de les considérer comme des efforts distincts qui doivent être gérés par des équipes de sécurité distinctes. Au bout du compte, l’IaC engendre le Security as code.

IaC : une nouvelle façon de penser la sécurité des logiciels

L’attaque de Solarwinds a incité les cadres, les professionnels de la sécurité et les développeurs du monde entier à s’arrêter et à repenser la sécurité des software factories de leur organisation. L’attaque a mis en évidence une incapacité manifeste à protéger le processus de cycle de développement logiciel.

Avec cet exploit, les hackers ont déployé un code malveillant dans le logiciel de gestion et de surveillance informatique Solarwinds Orion utilisé par des milliers d’entreprises et agences gouvernementales dans le monde entier. SolarWinds a alors envoyé involontairement à ses clients des mises à jour logicielles qui contenaient le code piraté. Injecté au cours du processus de développement de l’application Orion, le code a effectivement ouvert une brèche dans les systèmes informatiques des clients de SolarWinds, permettant un accès malveillant.

En Europe, les défis sont similaires et de plus en plus fréquents. Une étude sur le contexte des attaques publiée cette semaine par l’Agence européenne chargée de la sécurité des réseaux et de l’information (ENISA) prévoit qu’il y aura quatre fois plus d’attaques sur les chaînes d’approvisionnement en 2021 que l’année dernière.

Les attaques les plus dommageables ont tendance à s’appuyer sur le laisser-aller interne vis-à-vis des mesures de sécurité (correctifs qui ne sont pas appliqués, mots de passe qui ne sont pas changés régulièrement) à l’aide de procédés efficaces qui existent depuis des années. Selon la couverture médiatique de l’incident, l’administrateur de Solarwinds utilisait un mot de passe unique qui n’était jamais inchangé. Le passage à des processus automatisés peut garantir une rotation régulière des mots de passe, tandis que la détection des secrets peut rechercher rigoureusement les mots de passe codés en dur, particulièrement fréquents avec les API qui relient différentes applications entre elles.

Suite à l’attaque de SolarWinds, suivie de celle, tout aussi médiatisée, des oléoducs de Colonial Pipeline, le président Biden a publié un décret sur la cybersécurité. Tous les membres de la communauté logicielle devraient en prendre note, car cette intervention pourrait susciter un nouveau degré d’effort en matière de gouvernance, de testing et de sécurité qui ne s’est pas vu depuis la planification du passage à l’an 2000 — où chaque application fut inspectée pour voir comment elle gérait les variables de date et où beaucoup durent être ré-architecturées. Ce nouvel accent mis sur la sécurisation de la chaîne d’approvisionnement des logiciels promet un niveau d’introspection similaire.

Comment planifier la gouvernance et le testing de sécurité ?

Heureusement, les organisations peuvent suivre certaines étapes clés qui, par conséquent, accéléreraient le délai de livraison des logiciels.

Pour ce faire, il faudra penser et détailler les processus et les politiques pour chaque étape. Quand les politiques sont définies, une série de nouvelles questions doivent être prises en compte. Par exemple, comment le code source est-il testé ? Pour chaque application ? Quelles sont les exceptions ? Qui autorise les exceptions ? Les conteneurs sont-ils testés ? Quand ? Par qui ? Qui a accès à la software factory ? Qu’est-ce qui peut y être modifié ?

Il convient de répartir les efforts et les ressources en matière de sécurité logicielle en trois domaines principaux :

1. Fournir un code plus sûr ? le code créé doit être testé pour identifier et éliminer les risques de vulnérabilité. Les politiques relatives aux analyses à utiliser et à l’étendue du portefeuille d’applications doivent être définies. L’idéal étant d’exécuter plusieurs types d’analyses, aux stades de la validation du code et de la fusion avec la branche principale. Il convient d’envisager des outils qui intègrent toutes ces analyses afin d’éviter de devoir gérer l’intégration d’une chaîne d’outils complexe. Ensuite, il faut définir des politiques visant les actions nécessaires en cas de vulnérabilités identifiées.

2. Sécuriser l’infrastructure environnante de l’application ? rechercher les erreurs de configuration et surveiller les changements imprévus. Considérer les éléments suivants :

1. Les conteneurs - leurs composants ?
2. Les orchestrateurs (p.ex. Kubernetes) - configurés pour déterminer comment, où et quand les conteneurs s’exécutent, définir quelles applications peuvent communiquer avec quelles autres applications, spécifier les ressources de calcul et de stockage que chaque application est autorisée à consommer.
3. Les services de cloud - environnements hébergeant les machines virtuelles et les conteneurs.
4. Les IaC (configurations codées) telles que les API, les paquets, les charts Helm, Terraform, etc. Les applications monolithiques étant de plus en plus souvent divisées en microservices, l’authentification et l’autorisation prennent une toute nouvelle dimension – et impliquent une plus grande utilisation des API. Vous devez les tester et, idéalement, capturer, stocker et visualiser tous les appels d’API en vue de l’audit de votre organisation.

3. Sécuriser la software factory elle-même - sécuriser la software factory elle-même contre toute intervention malveillante. Le pipeline CI est essentiellement votre chaîne de montage de logiciels, il est donc fondamental d’en gérer l’accès, que ce soit par des humains, des machines ou des API.

L’application des principes Zero Trust doit être étendue à ce domaine. Cette approche consiste notamment à garantir un accès de moindre privilège à la chaîne d’outils DevOps et à l’infrastructure de l’application. En outre, un inventaire des éléments d’infrastructure tels que les registres, les gestionnaires de paquets, etc. doit être dressé et les différents niveaux d’accès autorisés doivent être évalués. La gestion des accès doit tenir compte de cette nouvelle portée plus large.

Un pipeline CI/CD automatisé présente l’avantage d’appliquer de manière systématique des contrôles de conformité classiques supplémentaires tels que la séparation des tâches, les autorisations de fusion, etc. Ces capacités permettront à leur tour de simplifier les audits de sécurité internes.

Le Security as code peut accélérer le DevSecOps

Les applications logicielles modernes nécessitent les dernières méthodes en matière de sécurité des applications au-delà du simple shift left. À mesure que les cycles de développement s’accélèrent, le Security as code devient primordial. Ce changement s’accompagne d’avantages supplémentaires que les méthodes traditionnelles plus cloisonnées ne pourraient offrir : rapidité, visibilité des risques, contrôle. Les stratégies de Security as code permettent aux organisations de se préparer dès maintenant à cette évolution de la sécurité des applications en intégrant véritablement la sécurité dans leur software factory de bout en bout.


Voir les articles précédents

    

Voir les articles suivants