Pourquoi la classification des risques applicatifs est importante pour les organisations réglementées
Les organisations réglementées exploitent des dizaines — parfois des centaines — d’applications, chacune présentant un profil de risque différent. Sans cadre de classification structuré, les ressources de sécurité sont trop dispersées : les applications critiques bénéficient du même niveau d’examen que les utilitaires internes, et les auditeurs se trouvent dans l’impossibilité d’évaluer si les contrôles sont proportionnés au risque réel.
La classification des risques applicatifs est le socle qui relie le risque métier aux exigences de contrôle de sécurité. Pour les auditeurs et les responsables de la conformité, elle répond à une question simple : l’organisation sait-elle quelles applications comptent le plus, et applique-t-elle ses contrôles en conséquence ?
Les régulateurs l’attendent de plus en plus. DORA (Digital Operational Resilience Act) impose aux entités financières de classer leurs actifs informatiques selon leur criticité. NIS2 exige des mesures de sécurité proportionnées au risque. PCI DSS impose que les environnements de données de titulaires de cartes bénéficient de contrôles renforcés. Sans cadre de classification défendable, une organisation ne peut démontrer sa conformité à aucun de ces régimes.
Un cadre de classification bien mis en œuvre prévient également deux défaillances d’audit courantes : la surclassification (où tout est étiqueté « critique » et où les ressources sont gaspillées) et la sous-classification (où des applications réellement critiques sont traitées comme ordinaires).
Critères de classification des risques
Un cadre de classification robuste évalue les applications selon plusieurs dimensions. Aucun critère n’est suffisant à lui seul — la classification doit refléter le profil de risque combiné.
Sensibilité des données
La nature des données traitées, stockées ou transmises par l’application est le principal facteur de classification. À prendre en compte :
- Données à caractère personnel (DCP) : nom, adresse, numéros d’identification nationale, données biométriques
- Données financières : numéros de cartes de paiement, coordonnées bancaires, relevés de transactions
- Informations de santé : dossiers de patients, données de diagnostic, informations de prescription
- Données métier confidentielles : secrets d’affaires, plans stratégiques, opérations de fusion-acquisition
- Identifiants d’authentification : mots de passe, jetons, clés d’API, certificats
Périmètre réglementaire
Les applications qui relèvent de mandats réglementaires spécifiques comportent des obligations de conformité inhérentes :
- DORA : systèmes informatiques soutenant des fonctions critiques ou importantes dans les services financiers
- NIS2 : systèmes exploités par des entités essentielles ou importantes
- PCI DSS : tout système au sein de l’environnement de données de titulaires de cartes
- RGPD : systèmes traitant les données personnelles de résidents de l’UE
- Réglementation sectorielle : santé (équivalents HIPAA), énergie, télécommunications
Criticité métier
Dans quelle mesure l’application est-elle essentielle au fonctionnement continu de l’activité ? À prendre en compte :
- Impact sur le chiffre d’affaires en cas d’indisponibilité de l’application
- Fonction en contact avec le client ou fonction de support interne
- Objectif de temps de reprise (RTO) et objectif de point de reprise (RPO)
- Obligations contractuelles liées à la disponibilité de l’application
Exposition
La surface d’attaque varie considérablement selon le mode d’accès à l’application :
- Exposée au public : accessible depuis Internet sans authentification
- Externe avec authentification : accessible depuis Internet mais nécessitant une connexion (portails clients, API de partenaires)
- Interne : disponible uniquement au sein du réseau de l’entreprise
- Interne restreinte : accessible uniquement depuis des segments de réseau ou des postes de travail spécifiques
Complexité d’intégration
Les applications comportant de nombreuses intégrations présentent un risque accru, car une compromission peut se propager :
- Nombre de connexions à des systèmes en amont et en aval
- Accès à des bases de données ou à des lacs de données partagés
- Exposition d’API à des tiers
- Utilisation de comptes de service ou d’identifiants partagés
Paliers de classification
Le modèle à quatre paliers suivant fournit un cadre pratique. Les organisations doivent adapter les critères spécifiques à leur contexte, mais le principe de contrôles différenciés doit être préservé.
| Palier | Libellé | Critères | Exemples | Contrôles requis |
|---|---|---|---|---|
| Palier 1 | Critique | Traite des données hautement sensibles (DCP à grande échelle, transactions financières) ; soumis à plusieurs mandats réglementaires ; exposé au public ; critique pour l’activité avec un RTO inférieur à 4 heures ; intégrations tierces étendues | Plateforme bancaire centrale, système de traitement des paiements, portail de santé destiné aux clients, plateforme de trading | Suite complète de tests de sécurité (SAST, DAST, SCA, tests d’intrusion) ; modélisation des menaces requise ; validation de sécurité pour chaque livraison ; surveillance continue ; revue d’audit trimestrielle |
| Palier 2 | Élevé | Traite des données sensibles ; soumis à au moins un mandat réglementaire ; exposé en externe avec authentification ; impact métier significatif en cas de compromission ; complexité d’intégration modérée | Système de gestion de la relation client, plateforme RH avec DCP des salariés, passerelle d’API partenaires, reporting financier interne | SAST et SCA à chaque build ; DAST trimestriel ; tests d’intrusion annuels ; modèle de menaces pour les changements majeurs ; revue de sécurité pour les livraisons importantes |
| Palier 3 | Modéré | Données sensibles limitées ; périmètre réglementaire direct minimal ; exposé en interne ; impact métier modéré ; intégrations limitées | Outils internes de gestion de projet, intranet d’entreprise, système de gestion documentaire, plateformes de communication interne | SAST et SCA à chaque build ; DAST annuel ; revue de sécurité pour les changements d’architecture ; gestion du changement standard |
| Palier 4 | Faible | Aucune donnée sensible ; aucun périmètre réglementaire direct ; exposé en interne avec accès restreint ; faible impact métier ; système isolé | Bacs à sable de développement, wikis internes à contenu non sensible, environnements de test (sans données de production) | SCA pour les vulnérabilités des dépendances ; pratiques standard de codage sécurisé ; revue périodique |
Comment la classification détermine les exigences de contrôle de sécurité
L’objectif même de la classification est de créer une correspondance défendable et proportionnée entre le risque et les contrôles. Le principe est simple : les applications de palier supérieur exigent davantage de contrôles, des tests plus fréquents, une gestion du changement plus stricte et une collecte de preuves plus rigoureuse.
Cette correspondance doit être documentée dans une politique, et non laissée au jugement individuel. Les auditeurs rechercheront une norme claire et écrite qui précise quels contrôles sont obligatoires à chaque palier.
| Domaine de contrôle | Palier 1 (Critique) | Palier 2 (Élevé) | Palier 3 (Modéré) | Palier 4 (Faible) |
|---|---|---|---|---|
| Fréquence SAST | À chaque commit / pull request | À chaque build | À chaque build | Périodique / à la demande |
| Fréquence DAST | Automatisé hebdomadaire + avant chaque livraison | Trimestrielle | Annuelle | Non requise |
| Fréquence SCA | Surveillance continue | À chaque build | À chaque build | Trimestrielle |
| Tests d’intrusion | Semestriels (au minimum) | Annuels | Fondés sur le risque / biennaux | Non requis |
| Modélisation des menaces | Requise ; mise à jour à chaque changement majeur | Requise pour les changements majeurs | Recommandée | Non requise |
| Approbation des livraisons | Validation du responsable sécurité requise | Revue de sécurité pour les changements significatifs | Gestion du changement standard | Gestion du changement standard |
| Conservation des preuves | 7 ans (ou minimum réglementaire) | 5 ans | 3 ans | 1 an |
| Cadence de revue d’audit | Trimestrielle | Semestrielle | Annuelle | Dans le cadre de la revue périodique du programme |
Modèle de gouvernance de la classification
La classification n’est pas un exercice ponctuel. Elle requiert un modèle de gouvernance qui définit la responsabilité, la cadence de revue et les procédures d’escalade.
Qui classe
Le propriétaire de l’application (généralement un responsable de ligne métier ou un product owner) propose la classification initiale sur la base des critères ci-dessus. Cette responsabilité ne doit pas être laissée aux seules équipes de développement, qui peuvent manquer de visibilité sur les dimensions réglementaires et métier du risque.
Qui examine et approuve
La classification proposée doit être examinée et approuvée par :
- L’équipe sécurité de l’information / sécurité applicative : valide l’évaluation technique du risque
- La fonction conformité / risque : confirme que le périmètre réglementaire est correctement identifié
- La direction métier : confirme l’évaluation de la criticité métier
Processus d’escalade
Lorsque le propriétaire de l’application et l’équipe sécurité sont en désaccord sur la classification, la question doit être escaladée au comité des risques ou au RSSI pour décision finale. Toutes les décisions d’escalade doivent être documentées avec leur justification.
Déclencheurs de reclassement
Les applications doivent être reclassées lorsque :
- L’application commence à traiter une nouvelle catégorie de données sensibles
- Un nouveau mandat réglementaire s’applique (par exemple, l’organisation devient soumise à DORA)
- L’application passe d’une exposition interne à une exposition externe
- Un incident de sécurité significatif survient impliquant l’application
- Des changements architecturaux majeurs modifient le profil d’intégration
- Le cycle de revue annuel identifie un changement de criticité métier
Ce que les auditeurs doivent vérifier
Lors de l’évaluation du cadre de classification des risques applicatifs d’une organisation, les auditeurs doivent vérifier les points suivants :
- Politique de classification documentée : une politique formelle et approuvée existe, qui définit les critères de classification, les paliers et les exigences de contrôle associées
- Inventaire applicatif complet : toutes les applications sont classées — pas seulement celles que l’organisation juge importantes
- Application cohérente des critères : des applications similaires sont classées au même palier ; il n’y a aucune preuve de classification arbitraire ou incohérente
- Les contrôles correspondent au palier : échantillonner des applications à chaque palier et vérifier que les contrôles imposés sont effectivement en place — non seulement documentés, mais opérationnels
- La cadence de revue est respectée : preuve que les classifications sont revues à la fréquence requise, avec des résultats documentés
- Traces de reclassement : lorsque des applications ont été reclassées, preuve que le déclencheur a été identifié, que la revue a été menée et que les contrôles ont été ajustés
- Traces de gouvernance : comptes rendus des réunions de revue de classification, décisions d’escalade avec justification, traces d’approbation
Signaux d’alerte
Les constats suivants doivent susciter une préoccupation immédiate lors d’un audit :
- Toutes les applications classées au même palier : cela indique que le cadre n’est pas appliqué de manière significative. Il est statistiquement invraisemblable que chaque application comporte le même risque.
- Aucun processus de reclassement : si aucune application n’a jamais été reclassée, soit le processus n’existe pas, soit l’organisation ne surveille pas les évolutions du profil de risque.
- Contrôles non différenciés par palier : si les applications de palier 1 et de palier 3 bénéficient de tests de sécurité identiques, le cadre de classification est décoratif plutôt qu’opérationnel.
- Classification réalisée uniquement par les équipes de développement : sans apport métier et conformité, les classifications risquent de sous-évaluer le risque réglementaire et métier.
- Aucune preuve de supervision de gouvernance : les décisions de classification existent, mais il n’y a aucune trace de revue, de contestation ou d’approbation par les fonctions sécurité ou risque.
- Classifications obsolètes : des applications classées il y a deux ans ou plus, sans aucune preuve de revue, malgré des changements connus dans l’environnement.
Pour aller plus loin
Pour des recommandations connexes sur la gouvernance de la sécurité applicative et les pratiques d’audit, voir :
- Vue d’ensemble de la sécurité applicative
- Fondamentaux du SDLC sécurisé
- Comment les auditeurs évaluent les contrôles de sécurité applicative
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Architecture de sécurité NIS2
- L’article 28 de DORA expliqué
- Contrôles de sécurité fondamentaux du CI/CD
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
