Adopter des impératifs de planification de développement sécurisé

Cet article définit les principaux impératifs d’intégration de la sécurité dans les pratiques de développement dans le cadre de la discipline Sécurité du développement.

Les organisations modernes s’appuient sur le développement rapide de logiciels pour offrir de l’innovation, répondre aux exigences de l’entreprise, maintenir un avantage concurrentiel et répondre aux besoins changeants de l’entreprise. Bien que DevOps active cette agilité, elle introduit également de nouveaux risques de sécurité en tant que code, infrastructure et processus de déploiement évoluent plus rapidement.

Pour adopter en toute sécurité les pratiques DevOps, les organisations doivent intégrer la sécurité à la stratégie de développement, aux flux de travail et aux processus de livraison, et adopter des pratiques DevSecOps qui sécurisent la livraison des applications tout au long du cycle de vie.

Résultats

L’adoption des impératifs de planification dans cet article permet aux organisations de :

• Réduisez l’introduction des faiblesses de sécurité dans les charges de travail de production.
• Améliorer la cohérence des décisions de préparation de la production.
• Réduisez les frictions entre le développement, la sécurité et les opérations.
• Améliorez la résilience des applications et de l’infrastructure de livraison.
• Maintenir la vitesse de l’innovation tout en gérant les risques opérationnels et de sécurité.

Reconnaître l’étendue de la sécurité du développement

La sécurité du développement s’applique à plus que le code d’application. Les organisations doivent définir les exigences de sécurité et les activités de tous les composants impliqués dans la conception, la création, le déploiement et l’exploitation des charges de travail.

Les organisations doivent prendre en compte les risques de sécurité :

• Logique d’application et services
• Déploiements d’automatisation de l’infrastructure/d’infrastructure en tant que code (IaC)
• Pipelines de build et de mise en production
• Configurations de déploiement et script opérationnel
• Environnements de développement et identités de service
• Dépendances tierces et composants de la chaîne d’approvisionnement

La reconnaissance de cette étendue complète permet aux organisations de définir des exigences de sécurité qui reflètent la façon dont les charges de travail modernes sont fournies, plutôt que de limiter la sécurité à la révision du code d’application en fin de cycle de vie.

Tenir compte des risques clés

Les organisations doivent inclure explicitement les risques suivants lors de la définition des exigences :

Ces risques informent directement les impératifs de planification définis dans cet article et doivent être traités par le biais de décisions de conception, de processus et de gouvernance.

Ces risques affectent les charges de travail d’application et l’infrastructure utilisée pour les générer et les exploiter.

Intégrer la sécurité dans la stratégie/cycle de vie

La sécurité doit être incorporée dans la stratégie de développement, non appliquée en tant que contrôle post-mise en production.

Les organisations doivent définir les exigences de sécurité en même temps que les exigences fonctionnelles et les aligner sur les éléments suivants :

• Stratégie de développement
• Planification architecturale
• Flux de travail de livraison
• Modèles de support opérationnel

Les résultats de sécurité sont des responsabilités partagées détenues par des rôles d’ingénierie et d’exploitation, prises en charge par les spécialistes de la sécurité.

La sécurité favorise l’innovation ; ce n’est pas un contrôle appliqué après la livraison.

Les organisations doivent adopter une approche de cycle de vie de développement sécurisé continu (SDL) qui inclut :

• Définition des exigences de sécurité dès le début de la conception.
• Alignement des exigences de sécurité avec l’architecture et l’implémentation.
• Intégration de la sécurité à l’automatisation de l’infrastructure.
• Exécution d’une validation de sécurité continue.
• Suivi des résultats de sécurité.
• Hiérarchisation de la correction.
• Application des résultats de sécurité aux décisions de préparation des mises en production afin que les problèmes de sécurité soient traités comme des bloqueurs de production si nécessaire.

La sécurité doit être évaluée et améliorée en permanence à mesure que les architectures d’application, les risques et les modèles de livraison évoluent.

Définir les critères de viabilité de production minimum

Les charges de travail doivent respecter les critères de viabilité minimale avant la mise en production. Ces critères définissent si une charge de travail est sécurisée, conforme et opérationnellement prête à être utilisée en production sur trois dimensions :

• Développement (développement) : les parties prenantes du développement définissent les exigences fonctionnelles minimales nécessaires pour répondre aux besoins de l’entreprise et à la valeur client/utilisateur.
• Sécurité (s) : les parties prenantes de la sécurité définissent les exigences minimales nécessaires pour respecter les obligations réglementaires, maintenir la posture de sécurité organisationnelle et prendre en charge la détection et la réponse des menaces actives.
• Opérations (ops) : les parties prenantes des opérations définissent des exigences minimales en matière de performances, de qualité et de prise en charge nécessaires pour que la charge de travail fonctionne de manière fiable dans les environnements de production.

Critères de viabilité de production :

• Vérifiez que les charges de travail sont sécurisées pour déployer et fonctionner dans des environnements de production.
• Servent d’éléments d’entrée pour les décisions de mise en production et doivent être appliqués de manière cohérente dans l’ensemble des flux de travail de développement.

Les critères de viabilité de production évoluent en fonction des modifications apportées à :

• Modèles de déploiement d’applications.
• Conditions de menace.
• Tolérance aux risques organisationnels.
• Exigences de conformité.

Intégrer la sécurité dans les flux de travail de développement

La sécurité doit être incorporée directement dans les processus de développement et de livraison. Les organisations doivent :

• Définissez les exigences de sécurité dans les flux de travail de développement.
• Intégrer les activités de sécurité dans :
  • Processus de conception
  • Générer des pipelines
  • Flux de travail de déploiement (CI/CD)
• Implémentez des mécanismes de validation de sécurité tels que :
  • Analyse du code
  • Validation de dépendances
  • Vérifications de configuration

Les résultats de sécurité doivent être traités de la même façon que les défauts de production et intégrés aux décisions de mise en production.

La validation de la sécurité doit se produire en continu par le biais de la remise, non seulement aux points de contrôle de mise en production.

Équilibrer et harmoniser les exigences

Les organisations doivent définir la façon dont les exigences de développement, de sécurité et d’exploitation sont équilibrées dans les décisions de livraison de logiciels. Les charges de travail de production doivent répondre aux exigences suivantes :

• Fonctionnalités métier.
• Résilience de sécurité.
• Vitesse de l’innovation.
• Fiabilité opérationnelle et performances.

Les organisations doivent définir des objectifs de livraison partagés et des métriques de performances qui :

• Aligner sur les objectifs de performances et de livraison partagés entre le développement, la sécurité et les opérations.
• Évitez la domination par un seul domaine.
• Hiérarchiser les résultats en fonction des points suivants :
  • Tolérance aux risques organisationnels.
  • Obligations réglementaires.
  • Responsabilité des entreprises.

L’équilibre doit s’adapter à mesure que les conditions de menace évoluent, que les modèles de distribution changent et que les priorités organisationnelles changent.

Établir une responsabilité partagée

L’efficacité de DevSecOps nécessite une propriété partagée entre les équipes de développement, de sécurité et d’exploitation en vue de :

• Alignement de la propriété des critères de viabilité de production.
• Alignement des objectifs de livraison entre les disciplines.
• Réduire les silos et les frictions non saines qui créent des lacunes de sécurité, des retards de livraison et une instabilité opérationnelle.

Appliquer des garde-fous de sécurité pilotés par des stratégies

Les garde-fous pilotés par les stratégies doivent appliquer des contrôles sans introduire de friction excessive. Les garde-fous doivent inclure :

• Exigences d’identité et d’accès.
• Normes de configuration et de conformité.
• Contrôles de déploiement et de mise en production.

Les garde-fous doivent être les suivants :

• Intégré à des bases de plateforme (par exemple des zones d’atterrissage).
• Incorporé dans des flux de travail de développement/déploiement.
• Appliqué automatiquement lorsque cela est possible.

Cette approche garantit que les exigences de sécurité sont appliquées de manière cohérente tout en conservant la vitesse de livraison.

Pour une approche équilibrée de la sécurité et de la rapidité de l’innovation, passez en revue l’adoption à l’aide de garde-fous pilotés par les politiques.

Soutenir et améliorer

La sécurité ne reste pas efficace en tant qu’ensemble statique de contrôles et doit évoluer au fil du temps.

Les organisations doivent évaluer et mettre à jour en permanence les pratiques de sécurité de développement en réponse aux modifications apportées à :

• Conditions de menace et comportement de l’attaquant.
• Architectures d’application et modèles de remise.
• Obligations réglementaires.
• Tolérance aux risques organisationnels.
• Critères de viabilité de production.
• Processus de livraison du développement
• Pratiques de gouvernance de la sécurité.

Les pratiques de sécurité doivent évoluer en même temps que les systèmes qu’ils protègent.

Techniques d’alignement

Teams doivent s’aligner sur les éléments suivants :

• Définir des objectifs communs : les responsables du développement, de la sécurité et des opérations doivent définir en collaboration des objectifs de livraison et des métriques de performances pour la livraison des charges de travail, afin de prendre en charge la planification cohérente des mises en production.
• Empêcher la domination des décisions à domaine unique : les décisions de remise doivent tenir compte des exigences de développement, de sécurité et opérationnelles pour éviter les déséquilibres susceptibles d’avoir un impact négatif sur la fiabilité, la conformité ou les fonctionnalités métier de la charge de travail.
• Hiérarchiser l’amélioration continue par rapport aux critères de mise en production statique : les pratiques de sécurité de développement doivent être affinées de manière itérative au fil du temps à mesure que les modèles de remise des applications, les conditions de menace et les priorités organisationnelles évoluent.
• Établir un contexte de distribution partagé entre les rôles des parties prenantes : les équipes de développement, de sécurité et d’exploitation doivent maintenir une compréhension partagée des éléments suivants :
  • Urgence métier et délais de livraison
  • Conditions de menace pertinentes et exposition aux risques
  • Exigences de disponibilité opérationnelle et de prise en charge
• Surveiller les frictions de livraison introduites par les exigences de sécurité : les exigences de sécurité peuvent introduire des frictions de livraison. Les responsables doivent évaluer si cette friction contribue à la réduction des risques (par exemple, en permettant l’identification antérieure des vulnérabilités) ou retarde inutilement la livraison de la charge de travail sans améliorer matériellement la résilience de production.
• Incorporer la sécurité du développement dans la planification et l’allocation des ressources : les exigences de sécurité pour les charges de travail d’application doivent être intégrées à la planification du développement et à l’allocation de ressources en plus des fonctionnalités et des exigences de support opérationnel.
• Définir des objectifs de performances de livraison partagés : les métriques de performances et de réussite pour les charges de travail d’application doivent refléter les résultats de développement, de sécurité et de livraison opérationnelle.

Aligner les flux de travail avec les exigences de sécurité

La sécurité doit être opérationnelle par le biais de flux de travail de développement. Les organisations doivent définir et aligner les flux de travail pour :

• Activités de conception architecturale.
• Processus de génération et de déploiement.
• Flux de travail de suivi et de correction des problèmes.

Les résultats de sécurité doivent être les suivants :

• Hiérarchisé et suivi.
• Géré en même temps que les défauts de production.
• Intégré aux décisions de préparation à la mise en production.

L’alignement du flux de travail garantit que les exigences de sécurité sont appliquées de manière cohérente tout au long de la livraison.

Étapes suivantes

En savoir plus sur le développement fondé sur les principes Confiance nulle