Du plan directeur à la conformité démontrable en audit : maîtriser les exigences de sécurité des applications pour ISO 27001, DORA et NIS2

La tension précédant l’audit était palpable. Pour Maria, RSSI d’une fintech de taille intermédiaire, l’évaluation de conformité DORA à venir ressemblait moins à une revue qu’à une mise à l’épreuve. Son équipe était compétente, son infrastructure durcie, mais une vulnérabilité persistante l’empêchait de dormir : l’univers étendu et chaotique de leurs applications.

La préoccupation la plus récente concernait un nouveau portail de paiement destiné aux clients, mis sur le marché dans l’urgence pour atteindre les objectifs trimestriels. L’équipe de développement, soumise à un modèle agile très exigeant, avait coché toutes les cases fonctionnelles. Mais lorsque l’équipe de Maria a exécuté une analyse préliminaire, les résultats ont confirmé ses craintes.

Le portail ne disposait pas de règles robustes d’expiration de session, ses champs de saisie étaient exposés à des attaques d’injection élémentaires, et ses messages d’erreur divulguaient des informations système sensibles. Il ne s’agissait pas d’exploits zero-day sophistiqués, mais de défauts de conception fondamentaux. La cause racine était douloureusement évidente : les exigences de sécurité n’avaient jamais été formellement définies, documentées ni intégrées aux sprints de développement. L’équipe disposait d’un mandat vague visant à « sécuriser l’application », mais sans plan directeur concret, la sécurité demeurait une préoccupation ambiguë, souvent reléguée au second plan.

Ce scénario n’a rien d’exceptionnel. Il met en évidence l’écart critique auquel de nombreux RSSI et responsables conformité sont confrontés : transformer l’intention « nous faisons de la sécurité » en exigences de sécurité des applications explicites, testables et alignées sur des normes fondamentales comme ISO/IEC 27001:2022 et sur des réglementations majeures telles que NIS2, DORA et GDPR.

Le coût élevé de l’ambiguïté : ce que la conformité attend réellement

Le problème central de Maria tient à une défaillance organisationnelle fréquente : considérer la sécurité comme un attribut de qualité plutôt que comme un ensemble d’exigences non négociables. Une exigence de sécurité efficace est spécifique, mesurable et testable. « L’application doit être sécurisée » est un souhait. « L’application doit imposer l’expiration des sessions après 15 minutes d’inactivité, valider toutes les entrées fournies par les utilisateurs par rapport à un jeu de caractères prédéfini et chiffrer toutes les données en transit au moyen de TLS 1.3 » est une exigence. C’est cette clarté que les auditeurs recherchent et dont les développeurs ont besoin pour construire des logiciels sécurisés.

À défaut, vous ouvrez la voie à une cascade de défaillances :

• Mise en œuvre incohérente : chaque développeur interprète la notion de « sécurisé » différemment, ce qui aboutit à une juxtaposition de contrôles présentant des lacunes imprévisibles.
• Coûts de remédiation accrus : identifier et corriger un défaut de conception en production coûte exponentiellement plus cher que le traiter pendant la phase de conception.
• Non-conformités d’audit : les auditeurs identifieront rapidement l’absence de processus structuré de définition des exigences de sécurité, ce qui entraînera des constats majeurs.
• Risque métier : chaque exigence non définie constitue un vecteur d’attaque potentiel, exposant l’organisation à des violations de données, à des pertes financières et à un préjudice réputationnel.

Dans les normes modernes, l’attente est constante : la sécurité doit être définie sous forme d’exigences, dès le début, et rattachée au risque ainsi qu’au droit applicable. Les lignes directrices ISO/IEC 27002:2022 relatives à la mesure 8.26, exigences de sécurité des applications, attendent des organisations qu’elles déterminent, documentent et approuvent systématiquement les exigences de sécurité sur la base d’une appréciation formelle des risques et des exigences réglementaires.

Ce principe unique constitue le pivot d’un large ensemble d’obligations de conformité. La cartographie de conformité croisée de Clarysec dans Zenith Controls : le guide de conformité croisée Zenith Controls montre que ce concept est présent partout :

• GDPR Articles 25 et 32 exigent la « protection des données dès la conception » et la « sécurité du traitement ».
• NIS2 Article 21(2)(d)-(e) met l’accent sur le développement sécurisé et la sécurité de la chaîne d’approvisionnement.
• DORA Articles 6(4), 8, 10 et 11 exigent la gestion des risques liés aux TIC et la sécurité dès la conception pour les entités financières.
• NIST SP 800-53 Rev.5, dans les contrôles SA-4 et SA-15, exige des exigences de sécurité système définies et des pratiques de développement sécurisé.
• COBIT 2019, dans les processus BAI03 et DSS05, exige que les exigences liées à la sécurité soient alignées sur l’activité et la conformité avant la construction d’une solution.

L’objectif consiste à définir, selon les termes de Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur Zenith Blueprint, « ce que la sécurité signifie pour vos applications, avant qu’une seule ligne de code ne soit écrite ».

Pourquoi les approches traditionnelles échouent : listes de contrôle, tests tardifs et sécurité de façade

La plupart des organisations pratiquent déjà une forme de sécurité des applications. Le problème est qu’elle est rarement structurée de manière à résister à une certification ISO/IEC 27001:2022 ou à un examen réglementaire.

Les schémas d’échec courants incluent :

1. Listes de contrôle génériques : les équipes réutilisent une « liste de contrôle de programmation sécurisée » d’une page pour chaque projet. Elle n’est pas rattachée aux risques spécifiques de l’application, à la sensibilité des données ni au contexte réglementaire. Lorsqu’un auditeur demande comment cette liste correspond à l’Article 25 de GDPR, aucune réponse claire n’existe.
2. Sécurité comme point de contrôle tardif : les exigences de sécurité ne sont pas intégrées à la conception ni aux récits utilisateur. Elles apparaissent à la fin sous la forme d’une demande de test d’intrusion. Le Zenith Blueprint avertit que « s’appuyer sur une liste de contrôle de sécurité en fin de projet ne fonctionne pas ; ces exigences doivent structurer l’architecture, influencer les choix de bibliothèques et guider la priorisation des fonctionnalités dès le premier jour ».
3. Absence de traçabilité entre exigence et test : une exigence peut exister pour « chiffrer les données en transit », mais aucun cas de test lié ne vérifie l’application de la version TLS, la validité du certificat et la robustesse des suites cryptographiques. Le Zenith Blueprint exige que les attentes soient mesurables et testables, avec des tests de sécurité directement associés aux exigences correspondantes.
4. Gestion ad hoc du code tiers : les applications modernes sont souvent « assemblées à partir de code interne, de bibliothèques tierces, d’interfaces de programmation (API) et de services natifs du cloud », comme le souligne le Zenith Blueprint. Sans exigences explicites visant les fournisseurs et les composants open source, le risque lié à la chaîne d’approvisionnement reste un angle mort majeur et non maîtrisé.

Le résultat est une sécurité de façade : des documents existent et des tests sont réalisés, mais lorsqu’un auditeur ou une autorité de régulation exige une histoire cohérente autour des exigences, l’ensemble du processus s’effondre.

Construire le socle : de la politique à la pratique

Une approche disciplinée de la sécurité des applications commence par une gouvernance claire. Une politique n’est pas une simple bureaucratie ; elle constitue la source officielle de vérité qui donne aux équipes les moyens d’agir et fournit aux auditeurs une déclaration d’intention claire. Chez Clarysec, nous concevons des politiques à la fois applicables et opérationnelles.

Notre Politique relative aux exigences de sécurité des applications Politique relative aux exigences de sécurité des applications établit des règles de base non négociables. Par exemple, la clause 5.2, dans les « Exigences de gouvernance », impose :

Toutes les applications doivent faire l’objet d’une validation des exigences de sécurité pendant la planification ou l’approvisionnement, avec une approbation documentée de l’équipe de sécurité des applications.

Cette directive simple empêche la logique consistant à « construire d’abord, sécuriser ensuite ». La politique attribue également une responsabilité claire. La clause 4.3.1, dans les « Rôles et responsabilités », indique que les développeurs sont tenus de :

Mettre en œuvre les applications conformément aux exigences et normes de sécurité définies.

Cette formulation déplace la responsabilité de la sécurité d’une équipe sécurité distincte, parfois perçue comme adversaire, vers les créateurs du logiciel eux-mêmes. En outre, la politique relie les différents domaines de sécurité. La clause 10.2 mentionne son intégration à d’autres contrôles clés :

P4 – Politique de contrôle d’accès. Définit les normes de gestion des identités et des sessions qui doivent être appliquées par toutes les applications, y compris l’authentification forte, le moindre privilège et les exigences de revue des accès.

Pour les organisations plus petites, une politique adaptée comme notre Politique relative aux exigences de sécurité des applications – PME Politique relative aux exigences de sécurité des applications – PME garantit que ces principes restent proportionnés. Elle reconnaît que, si les risques sont similaires, la mise en œuvre doit rester pragmatique. Les deux versions visent au final le même résultat : assurer que la sécurité des applications est pleinement intégrée au SMSI et prête pour l’audit.

Feuille de route pratique : construire des exigences de sécurité des applications auditables

La politique définit le « quoi » et le « pourquoi », mais les développeurs et chefs de projet ont besoin du « comment ». Un guide de mise en œuvre structuré est indispensable pour traduire des contrôles de haut niveau en étapes exploitables. L’étape 21 du Zenith Blueprint, centrée sur la mesure ISO/IEC 27002:2022 8.26, propose une méthode claire en six étapes.

Parcourons ce processus en utilisant le portail de paiement de Maria comme exemple.

Étape 1 : partir du risque et du contexte réglementaire

À partir des résultats d’appréciation des risques alignés sur ISO/IEC 27005:2024 (traitement des risques), vous identifiez d’abord le contexte :

• Application : portail de paiement en libre-service client.
• Données : données à caractère personnel (PII), identifiants, jetons de paiement.
• Juridictions : UE, services financiers, hébergement cloud.
• Réglementations : GDPR, DORA, PCI DSS.

Sur la base des orientations relatives à la mesure 8.26 dans Zenith Controls et de ses normes ISO associées (27034-1, 27017, 27701), vos catégories initiales d’exigences doivent inclure l’identification et l’authentification, l’autorisation, la classification des données, la validation des entrées, la journalisation, ainsi que la protection des données en transit et au repos.

Étape 2 : créer ou adopter un modèle d’exigences de sécurité

Le Zenith Blueprint recommande de créer un modèle standardisé afin que chaque projet réponde aux mêmes questions fondamentales de sécurité. Ce document doit devenir un élément de votre boîte à outils de lancement de projet.

Les sections minimales doivent inclure :

• nom de l’application, propriétaire et criticité ;
• catégories de données et niveaux de sensibilité ;
• obligations réglementaires et contractuelles applicables (GDPR, DORA, etc.) ;
• données d’entrée sur le paysage des menaces (issues du contrôle 5.7 renseignement sur la menace) ;
• exigences de sécurité spécifiques par catégorie (authentification, journalisation, etc.) ;
• liens avec les récits utilisateur et les critères d’acceptation ;
• liens avec les cas de test (fonctionnels, sécurité, intrusion) ;
• exigences applicables aux fournisseurs et aux composants tiers.

Étape 3 : intégrer les exigences aux livrables agiles

Les exigences de sécurité doivent être intégrées directement dans les récits utilisateur et les critères d’acceptation. Pour la fonctionnalité majeure « inscription client » du projet de portail de Maria, cela signifie transformer un simple récit fonctionnel en un récit tenant compte de la sécurité.

• Récit utilisateur initial : « En tant que nouvel utilisateur, je peux créer un compte. »
• Récit utilisateur sécurisé : « En tant que nouveau client, je veux créer un compte sécurisé afin que mes informations de paiement soient protégées. »
• Critères d’acceptation (avec sécurité intégrée) :
  • Le système doit imposer une politique de mots de passe robuste conforme à la P4 – Politique de contrôle d’accès.
  • Le système doit exiger une vérification par courriel au moyen d’un lien à usage unique avant l’activation du compte.
  • Le formulaire de création de compte doit être protégé par CAPTCHA afin de prévenir les attaques de bots.
  • Toutes les tentatives d’inscription doivent être journalisées avec l’adresse IP source et l’empreinte de l’appareil.
  • Toutes les données soumises via le formulaire doivent être validées et neutralisées afin de prévenir le cross-site scripting (XSS).

Il ne s’agit pas de tâches de sécurité séparées ; elles font partie intégrante de la définition du terminé pour la fonctionnalité.

Étape 4 : rattacher les exigences aux tests de sécurité

À l’aide du contrôle 8.29 Tests de sécurité de Zenith Controls, vous vous assurez que chaque exigence dispose d’un cas de test associé. Cela ferme la boucle et fournit des éléments de preuve auditables de l’efficacité des contrôles.

• Exigence : chiffrement en transit avec TLS 1.3. → Test : analyse automatisée pour vérifier l’application de TLS, la validité du certificat et les suites cryptographiques approuvées.
• Exigence : validation des entrées pour prévenir l’injection SQL. → Test : analyses automatisées SAST/DAST et fuzzing manuel pendant l’assurance qualité.
• Exigence : expiration de session après 15 minutes d’inactivité. → Test : tests automatisés et manuels confirmant l’invalidation côté serveur après 15 minutes d’inactivité.

Étape 5 : étendre les exigences à la chaîne d’approvisionnement

Comme la mesure ISO 8.26 est liée à la sécurité des fournisseurs (5.19, 5.20) et au développement externalisé (8.30) dans Zenith Controls, votre processus doit couvrir le code tiers. Pour les PME fortement dépendantes de bibliothèques externes, la clause de politique issue de la Politique relative aux exigences de sécurité des applications – PME est critique :

Tout outil tiers, module d’extension ou bibliothèque de code externe utilisé dans une application doit être enregistré et revu chaque année au regard de son impact sur la sécurité et de son niveau de correctifs.

Cette exigence simple et pragmatique impose une logique de nomenclature logicielle (SBOM), qui constitue une attente importante au titre de réglementations comme NIS2. Pour les fournisseurs majeurs, les mêmes exigences de sécurité des applications doivent être incluses dans les contrats, avec référence à ISO/IEC 27036-1 (sécurité de la chaîne d’approvisionnement TIC).

Étape 6 : instaurer une réévaluation périodique

À mesure que les applications évoluent, leurs risques évoluent également. Les orientations du Zenith Blueprint sur la réévaluation périodique sont essentielles. Lorsque vous intégrez une nouvelle API ou migrez vers un autre service cloud, le contexte de risque change. Cela doit déclencher une revue des exigences de sécurité existantes afin de vérifier qu’elles demeurent adéquates. Cette démarche s’aligne sur ISO/IEC 27005:2024 (traitement continu des risques) et transforme la sécurité des applications en pratique continue, non en projet ponctuel.

Décomposer l’écosystème de contrôles

Une mesure ISO n’existe jamais isolément. Une sécurité efficace repose sur un réseau interdépendant de mesures. La véritable valeur de la mesure 8.26 apparaît lorsqu’on comprend sa relation avec les autres contrôles, perspective détaillée dans Zenith Controls.

La mesure 8.26 est classée comme contrôle préventif, mais elle agit comme le point central de l’ensemble du processus de développement sécurisé, en se connectant à :

• 8.25 - Cycle de vie du développement sécurisé : il s’agit du cadre général. La mesure 8.26 fournit le quoi spécifique (les exigences) qui doit être intégré au comment (le processus SDLC).
• 8.27 - Architecture système sécurisée et principes d’ingénierie : les exigences orientent les décisions d’architecture et garantissent que la sécurité est fondatrice.
• 8.28 - Programmation sécurisée : une fois les exigences définies (par exemple, « prévenir l’injection SQL »), les normes de programmation sécurisée fournissent aux développeurs les techniques nécessaires pour y répondre.
• 8.29 - Tests de sécurité dans le développement et l’acceptation : ce contrôle valide que les exigences définies dans 8.26 ont été correctement mises en œuvre.
• 5.34 - Protection de la vie privée et des PII : lorsqu’une application traite des données à caractère personnel, les exigences issues de 8.26 doivent intégrer les principes de protection de la vie privée dès la conception.
• 5.19 & 5.20 - Sécurité de l’information dans les relations avec les fournisseurs : pour les applications acquises ou externalisées, la mesure 8.26 impose d’étendre vos exigences de sécurité à la chaîne d’approvisionnement.

Considérer ces contrôles comme un écosystème plutôt que comme une liste de contrôle permet de construire un niveau de sécurité multicouche et défendable.

Le regard de l’auditeur : se préparer à l’examen

Les auditeurs raisonnent en termes d’éléments de preuve. Pour vous préparer, vous devez comprendre les différentes perspectives qu’un auditeur peut adopter. La section méthodologie d’audit de Zenith Controls anticipe ces approches variées.

Comprendre ces angles d’analyse vous permet de préparer un portefeuille complet d’éléments de preuve démontrant un processus vivant, opérationnel et intégré à votre organisation.

La boussole de conformité croisée : un processus, plusieurs cadres

Pour une entreprise comme celle de Maria, satisfaire à DORA, GDPR et NIS2 est obligatoire. Cartographier manuellement les contrôles conduit à des efforts dupliqués et à des lacunes de conformité. Une approche centralisée de conformité croisée apporte une valeur considérable. Définir les exigences de sécurité des applications constitue la mise en œuvre concrète du principe de sécurité dès la conception qui sous-tend toutes ces réglementations modernes.

En mettant en œuvre un processus robuste d’exigences de sécurité des applications fondé sur ISO/IEC 27002:2022, vous construisez simultanément des éléments de preuve permettant de satisfaire une part significative de ces autres réglementations. Vous ne vous contentez pas de « faire de l’ISO » ; vous bâtissez un programme de sécurité conforme de manière transversale.

Du chaos au contrôle : votre trajectoire

L’histoire de Maria connaît une issue positive. Elle a utilisé l’incident du portail de paiement comme catalyseur du changement. Munie d’un cadre de politique clair fourni par Clarysec et d’un guide pratique de mise en œuvre, elle a réuni les équipes développement, sécurité et produit. Elles ont appliqué la méthode du Zenith Blueprint pour définir rétrospectivement les exigences du portail, en priorisant la remédiation selon le risque.

Plus important encore, elles ont établi une nouvelle manière de travailler. La « liste de contrôle de sécurité » a été remplacée par des sessions collaboratives de conception. Lorsque les auditeurs DORA sont arrivés, Maria a pu non seulement leur présenter une application sécurisée, mais aussi démontrer un processus mature et répétable garantissant que toutes les applications futures seraient construites sur un socle de sécurité.

Transformer votre niveau de sécurité des applications commence par une étape unique et structurée. Votre trajectoire est claire :

1. Établir la gouvernance : mettez en œuvre une politique formelle de définition des exigences de sécurité des applications. Nos modèles, comme la Politique relative aux exigences de sécurité des applications, fournissent un point de départ prêt pour l’audit.
2. Adopter un cadre pratique : utilisez le Zenith Blueprint pour intégrer les exigences de sécurité directement dans votre cycle de vie du développement, afin de les rendre exploitables, testables et traçables.
3. Comprendre le contexte complet : exploitez Zenith Controls pour comprendre comment ce contrôle critique s’articule avec l’écosystème de sécurité plus large et se cartographie avec DORA, NIS2, GDPR et d’autres exigences.
4. Étendre l’approche à votre portefeuille : une fois l’approche validée sur une application, déployez-la à l’ensemble de votre portefeuille en intégrant votre modèle d’exigences de sécurité aux listes de contrôle standard de lancement de projet, aux modèles agiles et aux processus d’approvisionnement.

Si vous souhaitez accélérer cette transformation, Clarysec fournit les politiques préconstruites, les feuilles de route de mise en œuvre et les cartographies de conformité croisée nécessaires pour passer d’efforts fragmentés à un programme démontrablement mature et prêt pour l’audit. Cessez de traiter la sécurité des applications comme une inspection de fin de parcours. Intégrez-la au plan directeur de tout ce que vous créez.