Conformité au Cadre de sécurité de l'information du Pakistan (PISF)
Le Pakistan Information Security Framework (PISF) définit les contrôles nationaux de cybersécurité, notamment la sécurité des applications web et un SDLC sécurisé. Découvrez comment ImmuniWeb vous aide à vous conformer.
Conformité au Cadre de sécurité de l'information du Pakistan (PISF)
Le Pakistan Information Security Framework (PISF) est le cadre national de cybersécurité publié par le PKCERT, l’équipe nationale pakistanaise d’intervention en cas d’urgence informatique. Il regroupe les exigences de sécurité en domaines et contrôles que les organisations doivent adopter — et dont elles doivent fournir la preuve lors des audits — pour protéger leurs systèmes, applications et données. Parmi eux, les contrôles de sécurité des applications du domaine 11 concernent directement toute organisation développant ou exploitant des applications web et mobiles. Le cadre officiel est publié sur le site du PKCERT (pkcert.gov.pk).
Qu'est-ce que le Pakistan Information Security Framework (PISF)?
Le PISF est le cadre national pakistanais de sécurité de l'information, publié par le PKCERT (le CERT national, créé en 2024 et relevant de la Division du Cabinet). Il traduit les attentes nationales en matière de cybersécurité en un ensemble structuré de domaines, chacun contenant des contrôles spécifiques et auditables que les organisations mettent en œuvre pour protéger leurs actifs de l'information.
Le PISF est conçu pour une adoption réelle: les organisations effectuent une évaluation des écarts par rapport aux contrôles, élaborent une feuille de route de mise en œuvre et se préparent aux audits formels. Pour soutenir cette démarche, PKCERT a introduit un schéma d'enregistrement pour les consultants en cybersécurité couvrant la sécurité IT, la sécurité des technologies opérationnelles (OT) et la sécurité cloud, organisé en paliers professionnels — afin que les évaluations des écarts et les travaux de préparation aux audits soient réalisés selon une norme cohérente.
Le PISF s'inscrit dans les réformes plus larges de cybersécurité au Pakistan, notamment la Loi sur la cybersécurité de 2025, qui institue l'Autorité nationale de cybersécurité (NCA) et étend le mandat de PKCERT à la réponse nationale aux incidents et au renseignement sur les menaces.
Comment le PISF s'intègre dans le paysage cyber du Pakistan
Le PISF n'agit pas isolément. Il complète les initiatives nationales et les règles sectorielles, et s'aligne conceptuellement sur les normes internationales, ce qui le rend familier aux organisations qui travaillent déjà vers ISO 27001 ou NIST:
- PKCERT & NCA: réponse nationale aux incidents, avertissements et renseignements sur les menaces ; le PISF est le cadre de contrôles auquel les organisations s'alignent.
- Cybersecurity Act 2025: crée la National Cybersecurity Authority et renforce les obligations nationales.
- Attentes sectorielles: les institutions financières se conforment également aux exigences de sécurité de la State Bank of Pakistan ; le PISF fournit une base commune à tous les secteurs.
- Alignement international: Le modèle de contrôles et domaines de PISF s'aligne sur la norme ISO/IEC 27001 et le NIST Cybersecurity Framework, et ses contrôles de sécurité applicative s'articulent clairement avec l'OWASP Top 10 et les meilleures pratiques en matière de SDLC sécurisé.
Qui doit se conformer au PISF?
Le PISF s'adresse aux organisations dont la sécurité a une incidence significative sur la résilience nationale, ainsi qu'aux fournisseurs qui les desservent:
- Organismes gouvernementaux et entités du secteur public.
- Opérateurs d'infrastructures nationales critiques (énergie, télécoms, transports, etc.).
- Services financiers — banques et fintech, complétant les attentes de la State Bank of Pakistan.
- Fournisseurs et vendeurs de technologies qui conçoivent ou exploitent des systèmes et applications pour les entités susmentionnées.
Dans la pratique, la conformité est un cycle: une évaluation des écarts par rapport aux contrôles PISF, une feuille de route d'implémentation pour combler ces écarts, la collecte de preuves, un audit formel et une surveillance continue. Toute organisation qui développe ou exploite des applications web et mobiles exposées sur Internet et traitant des données sensibles devra satisfaire aux contrôles de sécurité applicative du Domain 11.
Structure du PISF: domaines et contrôles
Le PISF structure les exigences en domaines numérotés, chacun contenant des contrôles individuels identifiés par des codes (par exemple, le domaine de la sécurité des applications mentionné sur cette page est le Domain 11). Les contrôles décrivent une attente spécifique et testable: ce qui doit être mis en place et démontrable à un auditeur.
Cette page se concentre sur les deux contrôles les plus pertinents pour la sécurité des applications: EDC-WAS-07.6 (Web Application Security) et ESSDLC-SDLC-2.1 (Secure Software Development Life Cycle). La formulation exacte de chaque contrôle doit toujours être tirée du document officiel du PISF publié par PKCERT.
Exigences de sécurité des applications du PISF en détail
EDC-WAS-07.6 — Sécurité des applications Web
Ce contrôle aborde la sécurité des applications web: les organisations doivent protéger les applications web contre les vulnérabilités courantes et les tester régulièrement. En pratique, cela signifie se défendre contre l'OWASP Top 10 (injection, contrôle d'accès brisé, failles d'authentification et plus encore), valider les entrées et encoder les sorties, sécuriser les sessions et les API, et vérifier — par des tests — que ces protections tiennent effectivement avant et après la mise en production.
ESSDLC-SDLC-2.1 — Cycle de vie du développement logiciel sécurisé
Ce contrôle exige que la sécurité soit intégrée tout au long du cycle de vie du développement logiciel plutôt qu'ajoutée en fin de processus. Cela implique une modélisation des menaces et la définition des exigences de sécurité en amont, un codage sécurisé et une révision du code pendant le développement, des tests de sécurité avant la mise en production, ainsi que des tests continus dans le cadre du CI/CD — l'approche «shift-left», également connue sous le nom de DevSecOps.
Vulnérabilités courantes des applications Web que le PISF vous demande de traiter
Les contrôles de sécurité applicative correspondent étroitement à l'OWASP Top 10 — la liste de référence sectorielle des risques les plus critiques pour les applications web. Les auditeurs comme les attaquants les recherchent:
- Contrôle d'accès cassé — des utilisateurs accédant à des données ou actions interdites.
- Échecs cryptographiques — chiffrement faible ou absent exposant des données sensibles.
- Injection — injection SQL, de commande ou autre via une entrée non validée.
- Insecure Design — des contrôles de sécurité manquants par conception, et non pas seulement par bug.
- Mauvaise configuration de sécurité — configuration par défaut, incomplète ou non sécurisée.
- Composants vulnérables et obsolètes — bibliothèques et frameworks non patchés.
- Échecs d'identification et d'authentification — gestion faible des connexions, des sessions ou des identifiants.
- Échecs d'intégrité des logiciels et des données — mises à jour non fiables, pipelines CI/CD non sécurisés.
- Échecs de la journalisation et de la surveillance de la sécurité — attaques non détectées.
- Server-Side Request Forgery (SSRF) — le serveur est induit en erreur pour effectuer des requêtes malveillantes.
Pour les applications mobiles, la référence équivalente est l'OWASP Mobile Top 10 (stockage des données non sécurisé, communication non sécurisée, cryptographie faible, etc.). Détecter ces problèmes de manière fiable nécessite de tester l'application en cours d'exécution — et non de se limiter à une revue de documentation.
Construire un SDLC sécurisé pour PISF (ESSDLC-SDLC-2.1)
Un SDLC sécurisé intègre une activité de sécurité à chaque phase. Voici ce qu’un auditeur s’attend à voir documenté:
| Phase du SDLC | Activité de sécurité | ImmuniWeb |
|---|---|---|
| Exigences | Exigences de sécurité, modélisation des menaces | - |
| Conception | Vérification de l'architecture et de la conception sécurisées | - |
| Mise en œuvre | Normes de codage sécurisé, revue de code | - |
| Tests | DAST, tests d'intrusion manuels | On-Demand, Neuron, MobileSuite, Neuron Mobile |
| Déploiement / CI-CD | Portes de test automatisées dans le pipeline | Continuous |
| Opérations | Scanning continu, ré-tests périodiques, ASM | Continuous, Discovery |
Comment se préparer à un audit PISF (étape par étape)
- Définissez le périmètre de vos actifs. Inventoriez les applications web, API et applications mobiles exposées à Internet avec la gestion de la surface d'attaque (ImmuniWeb Discovery).
- Effectuez une évaluation des écarts de vos applications par rapport aux contrôles du Domaine 11 (sécurité des applications web, SDLC sécurisé).
- Testez les applications web avec des tests d'intrusion manuels (On-Demand) et des scans automatisés (Neuron).
- Testez les applications mobiles avec MobileSuite et Neuron Mobile.
- Corrigez les vulnérabilités et effectuez un nouveau test à l'aide de rapports exploitables et exempts de faux positifs pour générer des preuves d'audit.
- Intégrer les tests dans le CI/CD avec Continuous pour satisfaire au contrôle SDLC sécurisé de manière continue.
- Conservez les preuves grâce à une surveillance continue et à des tests périodiques entre les audits.
Comment ImmuniWeb vous aide à atteindre la conformité PISF
ImmuniWeb prend directement en charge les contrôles de sécurité des applications du Domain 11 grâce à des tests qui produisent des preuves claires, prêtes pour l'audit.
| Exigence | Ce que cela nécessite | Produits ImmuniWeb |
|---|---|---|
| EDC-WAS-07.6 | Sécuriser et tester régulièrement les applications web contre les vulnérabilités (OWASP Top 10), avec une correction rapide. | ImmuniWeb On-Demand, Neuron, Continuous |
| ESSDLC-SDLC-2.1 | Intégrer les tests de sécurité à chaque phase du SDLC (DevSecOps, CI/CD). | ImmuniWeb Continuous, Neuron, On-Demand |
ImmuniWeb On-Demand offre des tests d'intrusion manuels d'applications Web avec un SLA zéro faux positif et une conformité des rapports. ImmuniWeb Neuron et Neuron Mobile assurent des analyses automatisées Web et mobiles. ImmuniWeb MobileSuite couvre les tests d'intrusion mobiles complets. ImmuniWeb Continuous intègre les tests dans le CI/CD pour un SDLC sécurisé, et ImmuniWeb Discovery cartographie votre surface d'attaque externe pour qu'aucune application ne reste non testée.
PISF vs Référentiels internationaux
Si vous travaillez déjà selon des normes internationales, PISF vous semblera familier — et les mêmes tests ImmuniWeb supportent toutes ces normes:
| Framework | Perspective sécurité des applications | Comment ImmuniWeb s'aligne |
|---|---|---|
| PISF (Pakistan) | Domaine 11: sécurité des applications web + SDLC sécurisé | Pentest web/mobile, scans, tests CI/CD |
| ISO/IEC 27001 | Annexe A: contrôles techniques | Tests d'intrusion et analyses comme preuves de contrôle |
| NIST CSF 2.0 | Protect / Detect functions | Tests d'applications et surveillance continue |
| PCI DSS 4.0.1 | Req 6 (secure dev) & Req 11 (testing) | Test d'intrusion d'applications web + analyse de vulnérabilités |
| OWASP ASVS | Niveaux de vérification pour les applications web | Tests conformes aux exigences ASVS |
Tests d'intrusion vs analyse de sécurité pour le PISF
Les deux sont nécessaires. L'analyse automatisée (DAST) offre une couverture large et fréquente, idéale pour les tests continus en CI/CD ; les tests d'intrusion manuels identifient les vulnérabilités de logique métier et complexes que les scanners manquent, et fournissent la profondeur attendue par les auditeurs. Pour le PISF, combinez l'analyse continue avec des tests d'intrusion manuels périodiques — et effectuez des retests après des changements majeurs.
Liste de vérification de conformité PISF (Sécurité des applications)
- Inventaire complet des applications web, API et applications mobiles exposées sur Internet
- Applications web testées contre le Top 10 OWASP
- Applications mobiles testées par rapport à la liste OWASP Mobile Top 10
- Tests de sécurité intégrés au pipeline CI/CD (SDLC sécurisé)
- Les corrections ont été appliquées et validées, avec conservation des preuves.
- Une surveillance continue et des retours de tests périodiques sont en place
- Rapports prêts pour l'audit, alignés sur les contrôles du Domaine 11
Pourquoi la conformité PISF est importante
Le PISF s'impose comme la référence commune en matière de maturité sécuritaire au Pakistan, notamment pour le secteur public, les infrastructures critiques et les services financiers. La démonstration de la conformité soutient les appels d'offres publics et privés, les audits et les relations avec les régulateurs, et renforce la confiance des partenaires et des clients.
Il permet également de gérer les risques réels. Le Pakistan a connu des fuites de données très médiatisées, et les applications web et mobiles restent parmi les points d'entrée les plus exploités par les attaquants. Le respect des contrôles du Domaine 11 — par le biais de tests concrets et non de simples formalités — réduit considérablement les risques de violation de données, d'interruption de service, de perte financière et de dommage réputationnel.
Foire aux questions
Glossary
- PKCERT — Équipe nationale pakistanaise d'intervention d'urgence informatique — éditeur du PISF.
- NCA — National Cybersecurity Authority, établie en vertu du Cybersecurity Act 2025.
- Domaine / Contrôle — Le PISF regroupe les exigences en domaines ; chaque contrôle représente une exigence spécifique et auditable.
- Secure SDLC — Un cycle de vie de développement logiciel intégrant une activité de sécurité à chaque phase.
- DAST —Dynamic Application Security Testing — test des vulnérabilités d'une application en cours d'exécution.
- Tests d'intrusion — Tests manuels dirigés par des experts qui identifient les vulnérabilités complexes et celles liées à la logique métier.
- OWASP Top 10 — La liste de référence sectorielle des risques de sécurité des applications web les plus critiques.
- Évaluation des écarts — Revue des contrôles actuels par rapport au PISF afin d'identifier les manquants avant un audit.