Sécurité de l’innovation

L’innovation est la force vitale d’une organisation à l’ère numérique et doit être à la fois encouragée et protégée. La sécurité de l’innovation protège les processus et les données de l’innovation contre les cyberattaques. À l’ère numérique, l’innovation prend la forme du développement d’applications à l’aide de la méthode DevOps ou DevSecOps afin d’innover rapidement sans attendre le calendrier traditionnel des expéditions en cascade qui peut prendre des mois ou des années entre deux versions.

Le développement de nouvelles capacités et applications nécessite de réussir à répondre à trois différents types d’exigences :

• Développement métier (Dev) : Votre application doit répondre aux besoins de l’entreprise et des utilisateurs, qui évoluent souvent rapidement.
• Sécurité (Sec) : Votre application doit être résiliente aux attaques d’attaquants qui évoluent rapidement et tirer parti des innovations en matière de défenses de sécurité.
• Opérations informatiques (Ops) : Votre application doit être fiable et fonctionner efficacement.

La fusion de ces trois exigences et la création d’une culture commune sont très importantes, mais souvent difficiles. Les responsables des équipes chargées du développement, de l’informatique et de la sécurité doivent collaborer pour conduire ce changement. Pour plus d’informations, consultez l’impératif de la direction : fusionner les cultures.

Regardez la vidéo suivante pour en savoir plus sur la méthode DevSecOps pour une innovation sécurisée et rapide.

Qu’est-ce que DevSecOps ?

L’innovation technologique est souvent développée dans le contexte d’une approche de développement rapide, légère et agile qui combine le développement et les opérations dans un processus DevOps. Nous avons appris que l’intégration de la sécurité à ce processus est essentielle pour atténuer les risques pour le processus d’innovation, la croissance de l’organisation et les ressources existantes dans l’organisation. L’intégration de la sécurité au processus crée un processus DevSecOps.

Sécurité dès la conception et déplacement vers la gauche

À mesure que les organisations adoptent DevOps et d’autres méthodologies d’innovation rapide, la sécurité doit être un fil tissé tout au long de la tapisserie de l’organisation et de ses processus de développement. L’intégration tardive de la sécurité au processus est coûteuse et difficile à corriger.

Déplacez la sécurité vers la gauche dans la chronologie pour l’intégrer à la vision, à la conception, à l’implémentation et au fonctionnement des services et des produits. À mesure que les équipes de développement passent au DevOps et adoptent les technologies du cloud, la sécurité doit faire partie de cette transformation.

Dans le modèle en cascade, la sécurité était traditionnellement une barrière de qualité une fois le développement terminé.

DevOps a élargi le modèle de développement traditionnel (personnes, processus et technologie) pour inclure les équipes des opérations. Ce changement a permis de réduire les frictions résultant de la séparation des équipes de développement et des opérations. De même, DevSecOps prolonge DevOps pour réduire les frictions dues à des équipes de sécurité séparées ou disparates.

DevSecOps est l’intégration de la sécurité à chaque étape du cycle de vie DevOps, de l’introduction de l’idée à l’exploitation, en passant par la conception architecturale et le développement itératif de l’application. Les équipes doivent s’aligner simultanément sur les objectifs de vitesse d’innovation, de fiabilité et de résilience de la sécurité. Grâce à une compréhension mutuelle et au respect des besoins de chacun, les équipes travailleront d’abord sur les questions les plus importantes, quelle que soit la source.

La méthodologie d’organisation du Cloud Adoption Framework fournit davantage de contexte sur les structures DevSecOps dans une organisation. Pour plus d’informations, consultez Comprendre la sécurité des applications et les fonctions DevSecOps.

Pourquoi DevSecOps ?

Si DevOps offre l’agilité, DevSecOps offre l’agilité sécurisée.

Presque toutes les organisations de la planète se tournent vers le développement de logiciels pour obtenir un avantage concurrentiel grâce à l’innovation. La sécurisation du processus DevOps est essentielle au succès de l’organisation. Les attaquants ont remarqué cette évolution tournée vers les applications personnalisées et s’en prennent de plus en plus à ces dernières lors de leurs attaques. Ces nouvelles applications sont souvent de riches sources de propriété intellectuelle qui contiennent de nouvelles idées précieuses qui ne sont pas encore une commodité sur le marché.

Pour protéger cette innovation, les organisations doivent corriger les faiblesses de sécurité et les attaques potentielles tant dans le processus de développement que dans l’infrastructure hébergeant les applications. Cette approche s’applique aussi bien au cloud que localement.

Les attaquants peuvent exploiter les faiblesses dans :

• Le processus de développement : Les attaquants peuvent détecter les faiblesses dans le processus de conception de l’application, par exemple, l’utilisation d’un chiffrement faible ou inexistant pour les communications. Les attaquants peuvent également trouver une faiblesse dans l’implémentation de la conception, par exemple, le code ne valide pas les entrées et permet des attaques courantes comme l’injection de code SQL. En outre, les attaquants peuvent implanter des portes dérobées dans le code, ce qui leur permet de revenir ultérieurement pour générer un code malveillant exploitant une faille de sécurité dans votre environnement ou celui de votre client.
• L’infrastructure informatique : Les attaquants peuvent compromettre les éléments de point de terminaison et d’infrastructure sur lesquels le processus de développement est hébergé en utilisant des attaques standard. Les attaquants peuvent également mener une attaque en plusieurs étapes qui utilise des informations d’identification volées ou des programmes malveillants pour accéder à l’infrastructure de développement à partir d’autres parties de l’environnement. En outre, le risque d’attaques de la chaîne d’approvisionnement des logiciels rend indispensable l’intégration de la sécurité à votre processus pour les deux :
• Protection de votre organisation : Contre les codes malveillants et les vulnérabilités dans votre chaîne d’approvisionnement en code source.
• Protection de vos clients : Contre tout problème de sécurité dans vos applications et systèmes qui pourrait nuire à votre réputation, engager votre responsabilité ou avoir d’autres répercussions négatives sur votre entreprise.

Le parcours DevSecOps

La plupart des organisations constatent que DevOps ou DevSecOps pour une charge de travail ou une application donnée est en fait un processus en deux phases, où les idées incubent d’abord dans un espace sécurisé, puis sont ensuite mises en production et mises à jour de manière itérative et continue.

Ce diagramme illustre le cycle de vie de ce type d’approche de la fabrique d’innovation :

L’innovation sécurisée est une approche intégrée pour les deux phases suivantes :

• L’incubation d’idées où une idée initiale est construite, validée et rendue prête pour une première utilisation en production. Cette phase commence par une nouvelle idée et se termine lorsque la première version de production répond aux critères du produit minimum viable (MVP) dans les domaines suivants :
  • Développement : Les fonctionnalités répondent aux exigences métier minimales.
  • Sécurité : Les capacités répondent aux exigences réglementaires en matière de conformité, de sécurité et de sûreté pour une utilisation en production.
  • Opérations : Les fonctionnalités répondent aux exigences minimales de qualité, de performances et de prise en charge d’un système de production.
• DevOps : Cette phase correspond au processus de développement itératif en cours de l’application ou de la charge de travail qui permet une innovation et une amélioration continues.

L’impératif de la direction : fusionner les cultures

Pour répondre à ces trois exigences, il faut fusionner ces trois cultures afin de s’assurer que tous les membres de l’équipe valorisent tous les types d’exigences et travaillent ensemble pour atteindre des objectifs communs.

L’intégration de ces cultures et de ces objectifs dans une véritable approche DevSecOps peut être difficile, mais l’investissement en vaut la peine. De nombreuses organisations connaissent un niveau élevé de frictions malsaines entre les équipes de développement, d’exploitation informatique et de sécurité qui travaillent de manière indépendante, ce qui crée des problèmes tels que :

• Livraison lente et agilité faible
• Problèmes de qualité et de performances
• Problèmes de sécurité

Si quelques problèmes sont normaux et prévisibles dans le cadre d’un nouveau développement, les conflits entre les équipes augmentent souvent considérablement le nombre et la gravité de ces problèmes. Les conflits surviennent souvent parce qu’une ou deux équipes ont un avantage politique et passent sans cesse outre les exigences des autres équipes. Au fil du temps, les problèmes qui ont été négligés augmentent en volume et en gravité. Si elle n’est pas résolue, cette dynamique pourrait s’aggraver avec DevOps, car la vitesse de prise de décision augmente pour répondre à l’évolution rapide des besoins métier et des préférences des clients.

Pour résoudre ces problèmes, vous devez créer une culture commune qui valorise les exigences des équipes de développement, de sécurité et d’exploitation, soutenues par la direction. Cette approche permettra à vos équipes de mieux travailler ensemble et contribuera à résoudre les problèmes les plus urgents sur un sprint donné, qu’il s’agisse d’améliorer la sécurité, la stabilité opérationnelle ou d’ajouter des fonctionnalités métier critiques.

Techniques de direction

Ces techniques clés peuvent aider les dirigeants à créer une culture commune :

1. Personne ne remporte tous les arguments : Les dirigeants doivent s’assurer qu’aucun état d’esprit ne domine toutes les décisions, ce qui pourrait provoquer un déséquilibre ayant un impact négatif sur l’entreprise.

2. Attendez-vous à une amélioration continue, pas à la perfection : Les dirigeants doivent définir une attente en matière d’amélioration continue et d’apprentissage permanent. La création d’un programme DevSecOps réussi ne se fait pas du jour au lendemain. Il s’agit d’un voyage continu avec une progression incrémentielle.

3. Célébrez à la fois les intérêts communs et les valeurs individuelles uniques : Veillez à ce que les équipes puissent voir qu’elles travaillent à des résultats communs et que chaque individu apporte quelque chose que les autres ne peuvent pas apporter. Tous les types d’exigences visent à créer et à protéger la même valeur commerciale. Les équipes de développement essaient de créer une nouvelle valeur, tandis que les équipes d’exploitation et de sécurité essaient de protéger et de préserver cette valeur contre différents scénarios de risque. Les dirigeants à tous les niveaux de l’organisation doivent communiquer sur ce point commun et sur l’importance de répondre à tous les types d’exigences pour un succès immédiat et à long terme.

4. Développez une compréhension commune : Tous les membres de l’équipe doivent avoir une compréhension de base des éléments suivants :

   • Urgence commerciale : L’équipe doit avoir une image claire du chiffre d’affaires en jeu. Cette vue doit inclure le chiffre d’affaires actuel (si le service est hors ligne) et le futur chiffre d’affaires possible qui sera affecté par un retard dans la livraison des applications et des fonctionnalités. Cela doit être directement basé sur les signaux des parties prenantes de la direction.
   • Risques et menaces probables : À partir de la contribution de l’équipe de renseignement sur les menaces, le cas échéant, l’équipe doit se faire une idée des menaces probables auxquelles le portefeuille d’applications sera confronté.
   • Exigences en matière de disponibilité : L’équipe doit avoir une idée commune des exigences opérationnelles telles que la durée requise de bon fonctionnement et la durée de vie prévue de l’application ainsi que des exigences en matière de résolution des problèmes et de maintenance, par exemple la mise à jour corrective pendant que le service est en ligne.

5. Montrez et incarnez le comportement souhaité : Les dirigeants doivent incarner publiquement le comportement qu’ils attendent de leurs équipes. Par exemple, faire preuve d’humilité, se concentrer sur l’apprentissage et valoriser les autres disciplines. Autre exemple : des responsables du développement discutent de la valeur de la sécurité et des applications de haute qualité ou des responsables de la sécurité discutent de la valeur de l’innovation rapide et de la performance des applications.

6. Surveillez le niveau de friction relatif à la sécurité : La sécurité crée naturellement des frictions qui ralentissent les processus. Il est essentiel pour les dirigeants de surveiller le niveau et le type de friction que la sécurité génère :

   • Friction saine : De la même manière que l’exercice renforce les muscles, l’intégration d’un niveau approprié de friction de sécurité dans le processus DevOps renforce l’application en forçant une réflexion critique au moment opportun. Si les équipes apprennent et utilisent ces apprentissages pour améliorer la sécurité, par exemple, en examinant comment et pourquoi un attaquant pourrait tenter de compromettre une application et en trouvant et corrigeant les bogues de sécurité importants, alors elles sont sur la bonne voie.
   • Friction malsaine : Faites attention aux frictions qui entravent davantage la valeur qu’elles ne la protègent. Cela se produit souvent lorsque des bogues de sécurité générés par des outils présentent un taux élevé de faux positifs ou de fausses alarmes ou lorsque l’effort de sécurité pour corriger quelque chose dépasse l’impact potentiel d’une attaque.

7. Intégrez la sécurité dans la planification budgétaire : Assurez-vous que le budget de sécurité est alloué proportionnellement à d’autres investissements en matière de sécurité. Ceci est analogue à un événement physique comme un concert où le budget de l’événement inclut la sécurité physique comme une norme. Certaines organisations allouent 10 % du coût total à la sécurité de manière générale pour garantir l’application cohérente des meilleures pratiques en matière de sécurité.

8. Établissez des objectifs communs : Assurez-vous que les mesures de performance et de réussite pour les charges de travail des applications reflètent les objectifs de développement, de sécurité et d’exploitation.

Remarque

Dans l’idéal, ces équipes doivent créer collectivement ces objectifs communs afin de maximiser l’adhésion, que ce soit pour l’ensemble de l’organisation ou pour un projet ou une application en particulier.

Identifier le MVP DevSecOps

Lors du passage d’une idée à la mise en production, il est essentiel de s’assurer que la capacité est conforme à la configuration minimale requise, ou au produit minimum viable (MVP), pour chaque type d’exigence :

• Les développeurs (dev) se concentrent sur la représentation des besoins métier pour une livraison rapide des capacités qui répondent aux attentes des utilisateurs, des clients et des chefs d’entreprise. Identifiez la configuration minimale requise pour garantir que la capacité contribue à la réussite de l’organisation.
• La sécurité (sec) met l’accent sur le respect des obligations de conformité et la défense contre les attaquants qui cherchent continuellement à tirer un profit illicite des ressources de l’organisation. Identifiez la configuration minimale requise pour respecter les exigences réglementaires en matière de conformité, maintenir la posture de sécurité et garantir que les opérations de sécurité peuvent rapidement détecter une attaque active et y répondre.
• Les opérations (ops) se concentrent sur les performances, la qualité et l’efficacité, en veillant à ce que la charge de travail puisse continuer à fournir de la valeur à long terme. Identifiez la configuration minimale requise pour garantir que la charge de travail peut fonctionner et être prise en charge sans nécessiter de changements importants dans l’architecture ou la conception dans un avenir prévisible.

Les définitions du MVP peuvent changer au fil du temps et avec différents types de charges de travail, à mesure que l’équipe apprend de sa propre expérience et de celle d’autres organisations.

Intégrer la sécurité en mode natif dans le processus

Les exigences en matière de sécurité doivent être axées sur l’intégration native au processus et aux outils existants. Par exemple :

• Les activités de conception telles que la modélisation des menaces doivent être intégrées à la phase de conception.
• Les outils d’analyse de la sécurité doivent être intégrés aux systèmes d’intégration continue et livraison continue (CI/CD) comme Azure DevOps, GitHub et Jenkins.
• Les problèmes de sécurité doivent être signalés à l’aide des mêmes processus et systèmes de suivi des bogues (par exemple, le schéma de hiérarchisation) que les autres bogues.

La façon dont la sécurité est intégrée au processus doit être continuellement améliorée, à mesure que les équipes apprennent et que les processus mûrissent. Les révisions de sécurité et les évaluations de risques doivent garantir l’intégration des mesures d’atténuation aux processus de développement de bout en bout, au service de production final et à l’infrastructure sous-jacente.

Pour plus d’informations sur DevSecOps, consultez Contrôles techniques DevSecOps.

Astuces pour naviguer sur le parcours

La transformation nécessite de se rapprocher progressivement de cet état idéal au cours d’un parcours. De nombreuses organisations devront faire face à la complexité et aux défis de ce parcours. Cette section décrit quelques-uns des défis les plus courants auxquels elles sont confrontées.

• La formation et les changements de culture sont des étapes initiales essentielles :vous partez en guerre avec l’armée dont vous disposez. L’équipe dont vous disposez devra souvent développer de nouvelles compétences et adopter de nouvelles perspectives pour comprendre les autres parties du modèle DevSecOps. Cette formation et ce changement de culture nécessitent du temps, de la concentration, un parrainage de la direction et un suivi régulier pour aider les individus à comprendre et à voir pleinement la valeur du changement. Changer radicalement de culture et de compétences peut parfois toucher à l’identité professionnelle des individus, créant ainsi un potentiel de forte résistance. Il est essentiel de comprendre et d’exprimer le pourquoi, le quoi et le comment du changement pour chaque individu et sa situation.
• Le changement prend du temps : vous ne pouvez avancer qu’aussi vite que votre équipe peut s’adapter à ce qu’implique l’adoption de nouvelles méthodes de travail. Les équipes devront toujours faire leur travail actuel tout en se transformant. Il est essentiel de privilégier soigneusement ce qui est le plus important et de gérer les attentes quant à la vitesse à laquelle ce changement peut se produire. Une stratégie de type « ramper, marcher, courir », où les éléments les plus importants et les plus fondamentaux sont utilisés en premier, servira bien à votre organisation.
• Des ressources limitées : un défi auquel les organisations sont généralement confrontées dès le début est de trouver des talents et des compétences en matière de sécurité et de développement d’applications. À mesure que les organisations commencent à collaborer plus efficacement, elles peuvent découvrir des talents cachés, comme des développeurs avec une mentalité axée sur la sécurité ou des professionnels de la sécurité ayant une formation en développement.
• La nature changeante des applications, du code et de l’infrastructure : la définition technique et la composition d’une application changent fondamentalement avec l’introduction de technologies telles que les modèles serverless, les services cloud, les API cloud et les applications sans code, comme Power Apps. Cette évolution modifie les pratiques de développement et la sécurité des applications et permet même aux non-développeurs de créer des applications.

Remarque

Certaines implémentations associent les responsabilités liées aux opérations et à la sécurité à un rôle Ingénieur en fiabilité des sites (SRE) .

Bien que la fusion de ces responsabilités en un seul rôle puisse être l’état final idéal pour certaines organisations, il s’agit souvent d’un changement extrême par rapport aux pratiques, à la culture, aux outils et aux ensembles de compétences actuels de l’entreprise.

Même si vous ciblez un modèle SRE, nous vous recommandons de commencer par incorporer la sécurité dans DevOps à l’aide de mesures pratiques à effet rapide et de la progression incrémentielle présentées dans cette aide afin de garantir un bon retour sur investissement (ROI) et de répondre aux besoins immédiats. Cela permet d’ajouter progressivement des responsabilités en matière de sécurité à votre personnel d’exploitation et de développement, ce qui rapprochera vos employés de l’état final d’un SRE (si votre organisation prévoit d’adopter ce modèle ultérieurement).

Étapes suivantes

Pour obtenir des instructions plus détaillées sur DevSecOps, consultez les contrôles techniques DevSecOps.

Pour plus d’informations sur la façon dont la sécurité avancée de GitHub intègre la sécurité à vos pipelines d’intégration continue et livraison continue (CI/CD), consultez About GitHub advanced security (À propos de la sécurité avancée de GitHub).

Pour plus d’informations et d’outils sur la façon dont l’organisation informatique de Microsoft a implémenté DevSecOps, consultez Secure DevOps toolkit (Boîte à outils DevOps sécurisée).