Version : 1.0
Date de rédaction : [JJ/MM/AAAA]
Propriétaire du document : [Nom, Fonction]
Classification : Confidentiel — Interne uniquement
- Décrire l'objectif du PAS : formaliser l'ensemble des engagements, mesures et dispositifs de sécurité mis en œuvre pour protéger la solution SaaS, ses données et ses utilisateurs
- Détailler le périmètre de la solution SaaS concernée :
- Services applicatifs (API, interface web, applications mobiles)
- Infrastructure sous-jacente (cloud, réseau, stockage)
- Données traitées (données clients, données métier, données internes)
- Environnements couverts (production, staging, développement, DR)
- Définir les objectifs de sécurité alignés sur les critères DICP :
- Disponibilité : maintien de l'accès au service selon les SLA contractuels
- Intégrité : garantie de la non-altération des données et des traitements
- Confidentialité : protection contre les accès non autorisés aux données
- Preuve / Traçabilité : capacité à démontrer et auditer les actions réalisées sur le système
- Identifier le public cible du document :
- Direction générale et comité de direction
- Équipes techniques (développement, infrastructure, SRE)
- Équipes conformité et juridique
- Clients et prospects (version expurgée si nécessaire)
- Auditeurs internes et externes
- Préciser la relation avec les contrats de service :
- Le PAS constitue une annexe de sécurité pouvant être intégrée aux contrats clients
- Il traduit en engagements opérationnels les exigences de sécurité contractuelles
- Il sert de référence pour les audits de conformité clients
- Référencer les cadres réglementaires et normatifs applicables :
- RGPD (Règlement Général sur la Protection des Données)
- ISO 27001 / ISO 27002 (Système de management de la sécurité de l'information)
- ISO 27017 (Sécurité cloud) et ISO 27018 (Protection des données personnelles dans le cloud)
- SOC 2 (Trust Services Criteria)
- NIS2 (Directive européenne sur la sécurité des réseaux et systèmes d'information)
- DORA (Digital Operational Resilience Act — si secteur financier)
- Référentiels sectoriels spécifiques (HDS pour la santé, PCI DSS pour le paiement)
- Mentionner l'articulation avec les autres plans de sécurité et de résilience :
- PCA (Plan de Continuité d'Activité) : le PAS alimente le PCA en identifiant les menaces et les mesures de prévention
- PRA (Plan de Reprise d'Activité) : le PAS définit les exigences de sécurité que le PRA doit respecter lors de la reprise
- PSSI (Politique de Sécurité des Systèmes d'Information) : le PAS est la déclinaison opérationnelle de la PSSI pour la solution SaaS
- Décrire l'organisation interne de la sécurité et les rôles clés :
- RSSI / CISO : responsable de la stratégie de sécurité globale, pilote du PAS, interlocuteur des audits
- DPO (Délégué à la Protection des Données) : garant de la conformité RGPD, conseiller sur le traitement des données personnelles
- Responsable sécurité opérationnelle (SecOps) : supervision quotidienne de la sécurité, gestion des incidents de sécurité
- Architecte sécurité : conception de l'architecture sécurisée, revue des choix techniques
- Référents sécurité par équipe : relais opérationnels au sein des équipes de développement et d'infrastructure
- Responsable conformité : suivi des certifications, préparation des audits, veille réglementaire
- Définir la responsabilité de la direction :
- Engagement formel de la direction générale sur la politique de sécurité (lettre d'engagement signée)
- Allocation des ressources dédiées à la sécurité (budget, effectifs, outils)
- Revue de direction de la sécurité au minimum semestrielle
- Responsabilité ultime en cas d'incident majeur de sécurité
- Formaliser les processus de décision en matière de sécurité :
- Comité de sécurité mensuel (composition, ordre du jour type, livrables attendus)
- Processus d'escalade des risques de sécurité (de l'opérationnel au stratégique)
- Circuit de validation des dérogations de sécurité (qui peut accorder une exception, sous quelles conditions, pour quelle durée)
- Processus d'approbation des changements impactant la sécurité (Change Advisory Board — volet sécurité)
- Encadrer la gestion des tiers :
- Processus d'évaluation sécurité des fournisseurs avant contractualisation (questionnaire de sécurité, audit, certifications exigées)
- Clauses de sécurité obligatoires dans les contrats fournisseurs (confidentialité, droit d'audit, notification d'incident, réversibilité)
- Suivi périodique de la posture de sécurité des fournisseurs critiques (revue annuelle minimum)
- Registre des sous-traitants avec classification par niveau de risque
- Mettre en place les mécanismes de reporting sécurité :
- Tableau de bord sécurité mensuel (KPI / KRI — indicateurs clés de performance et de risque)
- Rapport trimestriel au comité de direction
- Rapport annuel de sécurité (bilan des incidents, évolution de la posture, plan d'action)
- Alertes temps réel sur les indicateurs critiques (taux de vulnérabilités critiques, tentatives d'intrusion, etc.)
- Présenter la méthodologie d'analyse des risques utilisée :
- Méthode retenue : EBIOS RM (recommandée par l'ANSSI) ou ISO 27005
- Justifier le choix de la méthodologie par rapport au contexte SaaS
- Décrire les étapes du processus :
- Identification du périmètre et des actifs à protéger (cartographie des actifs)
- Identification des sources de menaces et des événements redoutés
- Évaluation des scénarios de risques (vraisemblance × impact)
- Définition du plan de traitement des risques (réduction, transfert, acceptation, évitement)
- Suivi et réévaluation périodique
- Cartographier les actifs critiques de la solution SaaS :
- Données clients (bases de données, fichiers uploadés, logs applicatifs)
- Code source et propriété intellectuelle
- Infrastructure cloud (instances, stockage, réseau, DNS)
- Secrets et credentials (clés API, certificats, mots de passe de service)
- Services tiers intégrés (authentification, paiement, email, monitoring)
- Lister les principaux risques identifiés pour le SaaS :
- Fuite de données : exfiltration de données clients par attaque externe ou acte malveillant interne
- Indisponibilité du service : panne prolongée impactant les engagements SLA
- Compromission des accès : usurpation d'identité, élévation de privilèges, accès non autorisé
- Attaque par rançongiciel : chiffrement des données et demande de rançon
- Injection et exploitation de vulnérabilités applicatives : SQL injection, XSS, SSRF, RCE
- Attaque sur la chaîne d'approvisionnement : compromission d'une dépendance logicielle ou d'un fournisseur tiers
- Erreur humaine : mauvaise configuration, suppression accidentelle, déploiement défectueux
- Non-conformité réglementaire : violation RGPD, non-respect des obligations sectorielles
- Attaque DDoS : saturation des ressources rendant le service inaccessible
- Perte de maîtrise des secrets : fuite de clés API, de tokens ou de certificats
- Décrire la manière dont les risques sont évalués et traités de façon cyclique :
- Matrice de risques (vraisemblance × impact) avec échelle de notation (ex : 1-5)
- Définition des seuils d'acceptabilité validés par la direction
- Registre des risques maintenu et révisé trimestriellement
- Plan de traitement des risques avec responsables, échéances et indicateurs de suivi
- Revue annuelle complète avec mise à jour de la cartographie des risques
- Intégration des retours d'incidents réels dans l'analyse des risques
- Décrire la protection des infrastructures hébergeant la solution :
- Localisation géographique des datacenters (pays, région, nombre de sites)
- Certifications des datacenters (Tier III/IV, ISO 27001, SOC 2, HDS si applicable)
- Dispositifs de sécurité physique :
- Contrôle d'accès biométrique et par badge
- Vidéosurveillance 24/7 avec rétention des enregistrements
- Gardiennage permanent et détection d'intrusion périmétrique
- Sas de sécurité et mantrap pour l'accès aux salles serveurs
- Protection environnementale :
- Système anti-incendie (détection précoce, extinction par gaz inerte)
- Climatisation redondante et monitoring de la température/hygrométrie
- Alimentation électrique secourue (onduleurs, groupes électrogènes, contrats de maintenance)
- Protection contre les dégâts des eaux (surélévation, détection de fuite)
- Préciser les fournisseurs cloud utilisés et leur posture de sécurité :
- Fournisseur(s) principal(aux) : AWS, Azure, GCP (préciser les régions utilisées)
- Certifications du fournisseur cloud : ISO 27001, SOC 2 Type II, CSA STAR, C5, HDS
- Localisation des données : conformité avec les exigences de souveraineté (données en UE)
- Disponibilité des rapports d'audit du fournisseur (SOC 2 report, pentest report)
- Définir le périmètre de responsabilité partagée (Shared Responsibility Model) :
- Fournisseur cloud : sécurité physique, hyperviseur, réseau physique, mise à jour de l'infrastructure
- Éditeur SaaS : configuration sécurisée des services cloud, gestion des identités et accès, chiffrement des données, sécurité applicative, monitoring, sauvegarde
- Matrice de responsabilité documentée pour chaque couche de la stack technique
- Détailler comment la sécurité physique des fournisseurs est auditée :
- Revue annuelle des certifications et rapports d'audit du fournisseur
- Droit d'audit contractuel (si applicable) ou recours aux audits tiers
- Suivi des incidents de sécurité physique déclarés par le fournisseur
- Veille sur les alertes et CVE affectant l'infrastructure du fournisseur
- Politique de gestion des identités :
- Provisionnement et dé-provisionnement automatisé des comptes (intégration avec l'annuaire d'entreprise)
- Revue des accès périodique (trimestrielle pour les accès privilégiés, semestrielle pour les autres)
- Principe du moindre privilège appliqué systématiquement
- Séparation des fonctions (Segregation of Duties) pour les opérations sensibles
- Authentification :
- Authentification multi-facteurs (MFA) obligatoire pour :
- Tous les accès administrateurs (infrastructure, cloud, applicatif)
- Les accès aux environnements de production
- Les accès VPN et distants
- Les accès clients aux données sensibles (recommandé)
- Politique de mots de passe conforme aux recommandations ANSSI (longueur minimale, complexité, non-réutilisation)
- SSO (Single Sign-On) via protocoles standards (SAML 2.0, OIDC) pour centraliser l'authentification
- Gestion des sessions : durée de vie limitée, invalidation automatique après inactivité, révocation à la déconnexion
- Gestion des accès privilégiés (PAM — Privileged Access Management) :
- Solution PAM dédiée pour les comptes à privilèges (CyberArk, HashiCorp Vault, AWS SSM Session Manager)
- Accès juste-à-temps (Just-In-Time Access) pour les interventions de production
- Enregistrement et audit de toutes les sessions privilégiées
- Rotation automatique des credentials de service (API keys, service accounts)
- Gestion des accès des clients :
- Isolation stricte des données par tenant (multi-tenant architecture sécurisée)
- Contrôle d'accès basé sur les rôles (RBAC) configurable par le client
- Journalisation des accès consultable par le client (audit trail)
- Chiffrement au repos (data at rest) :
- Algorithme : AES-256 (ou équivalent validé ANSSI)
- Gestion des clés : service de gestion de clés dédié (AWS KMS, Azure Key Vault, GCP Cloud KMS)
- Rotation automatique des clés de chiffrement (au minimum annuelle)
- Possibilité de BYOK (Bring Your Own Key) ou HYOK (Hold Your Own Key) pour les clients exigeants
- Périmètre : bases de données, fichiers stockés, sauvegardes, volumes disque
- Chiffrement en transit (data in transit) :
- TLS 1.2 minimum (TLS 1.3 recommandé) pour toutes les communications externes
- Certificats émis par une autorité de certification reconnue, renouvelés automatiquement
- HSTS (HTTP Strict Transport Security) activé sur tous les endpoints publics
- Chiffrement des communications internes (service-to-service) via mTLS ou service mesh
- Chiffrement des sauvegardes :
- Chiffrement systématique des backups avec clés distinctes de celles de production
- Stockage des clés de chiffrement des backups dans un coffre-fort séparé
- Architecture réseau sécurisée :
- Segmentation en zones de sécurité (DMZ, zone applicative, zone données, zone administration)
- Isolation des environnements (production, staging, développement) par VPC / réseau virtuel distinct
- Micro-segmentation au niveau applicatif (network policies Kubernetes, security groups, NSG)
- Règles de pare-feu strictes avec politique de deny-by-default
- Restriction des flux inter-zones au strict nécessaire (matrice de flux documentée et revue périodiquement)
- Protection périmétrique :
- WAF (Web Application Firewall) devant les endpoints publics avec règles personnalisées
- Protection DDoS (AWS Shield, Cloudflare, Azure DDoS Protection)
- CDN avec filtrage géographique si pertinent
- Rate limiting et throttling sur les API publiques
- Sécurité des accès distants :
- VPN chiffré pour les accès d'administration
- Bastion / jump host comme point d'entrée unique vers les environnements de production
- Pas d'accès SSH direct aux instances de production (accès via Session Manager ou équivalent)
- Dispositifs de détection :
- IDS/IPS (Intrusion Detection/Prevention System) réseau
- EDR (Endpoint Detection and Response) sur les postes de travail et les serveurs
- SIEM (Security Information and Event Management) centralisant les journaux de sécurité :
- Sources collectées : logs applicatifs, logs d'accès, logs cloud (CloudTrail, Azure Activity Log), logs réseau, logs WAF
- Règles de corrélation et de détection d'anomalies
- Durée de rétention des logs : minimum 12 mois (ou selon exigences réglementaires)
- SOAR (Security Orchestration, Automation and Response) pour l'automatisation des réponses aux alertes
- Monitoring et alerting sécurité :
- Surveillance 24/7 des alertes de sécurité (SOC interne ou externalisé)
- Alertes temps réel sur les événements critiques (tentatives d'intrusion, comportements anormaux, élévation de privilèges)
- Tableaux de bord de sécurité en temps réel
- Indicateurs de compromission (IoC) mis à jour via des flux de threat intelligence
- Programme de gestion des vulnérabilités :
- Scan de vulnérabilités automatisé continu sur l'infrastructure et les applications
- Outils utilisés : scanner réseau (Nessus, Qualys), scanner applicatif (DAST — OWASP ZAP, Burp Suite)
- Politique de remédiation par niveau de criticité :
- Critique (CVSS ≥ 9.0) : correction sous 24h ou mitigation immédiate
- Haute (CVSS 7.0–8.9) : correction sous 7 jours
- Moyenne (CVSS 4.0–6.9) : correction sous 30 jours
- Faible (CVSS < 4.0) : correction au prochain cycle de maintenance
- Suivi centralisé des vulnérabilités (registre, assignation, vérification de la remédiation)
- Veille de sécurité :
- Abonnement aux flux de vulnérabilités (CVE, NVD, CERT-FR, bulletins éditeurs)
- Processus de qualification et priorisation des vulnérabilités affectant la stack technique
- Notification proactive des clients en cas de vulnérabilité impactant leurs données
- Intégrer la sécurité dans chaque phase du cycle de vie du développement (SDLC) :
- Conception :
- Modélisation des menaces (Threat Modeling) pour chaque nouvelle fonctionnalité significative
- Revue d'architecture sécurité avant implémentation
- Définition des exigences de sécurité dans les user stories (Security Requirements)
- Développement :
- Standards de codage sécurisé (OWASP Secure Coding Practices) documentés et partagés
- Analyse statique du code (SAST — SonarQube, Semgrep, CodeQL) intégrée au pipeline CI
- Détection de secrets dans le code (git-secrets, truffleHog, GitGuardian)
- Linting de sécurité des fichiers d'infrastructure as code (tfsec, checkov, kics)
- Revue de code :
- Revue de code obligatoire par au moins un pair avant merge (pull request)
- Checklist de sécurité dans la revue de code (validation des entrées, gestion des erreurs, authentification, autorisation)
- Revue de sécurité approfondie par un référent sécurité pour les changements sensibles (authentification, chiffrement, gestion des droits)
- Tests :
- Tests de sécurité automatisés dans le pipeline CI/CD :
- SAST (analyse statique)
- DAST (analyse dynamique — scan de l'application déployée)
- SCA (Software Composition Analysis — vérification des dépendances tierces)
- Tests de fuzzing sur les endpoints critiques
- Tests d'intrusion réguliers :
- Pentest externe annuel minimum par un prestataire qualifié (PASSI si applicable)
- Pentest interne semestriel (red team ou purple team si applicable)
- Bug bounty program (optionnel, selon la maturité)
- Tests de régression sécurité après correction de vulnérabilités
- Déploiement :
- Pipeline CI/CD sécurisé :
- Intégrité de la chaîne de build (signature des artefacts, attestation de provenance)
- Scan des images conteneur avant déploiement (Trivy, Snyk Container, Clair)
- Politique d'admission en production (aucune vulnérabilité critique ou haute non traitée)
- Déploiement progressif (canary, blue/green) pour limiter l'impact des régressions
- Capacité de rollback automatisé en cas de détection d'anomalie post-déploiement
- Exploitation :
- Monitoring de sécurité en production (cf. section 5.4)
- Patch management continu (mise à jour des dépendances, des images de base, de l'OS)
- Inventaire à jour des composants logiciels (SBOM — Software Bill of Materials)
- Gestion des dépendances et de la chaîne d'approvisionnement logicielle :
- Registre de dépendances (lock files, registries privés)
- Alertes automatisées sur les vulnérabilités connues des dépendances (Dependabot, Renovate, Snyk)
- Politique de mise à jour des dépendances (correctifs de sécurité appliqués sous 48h pour les critiques)
- Vérification de l'intégrité des packages (checksums, signatures)
- Présenter le plan de réponse aux incidents de sécurité (IRP — Incident Response Plan) :
- Préparation :
- Équipe de réponse aux incidents constituée et formée (CSIRT / CERT interne ou externalisé)
- Outils de réponse pré-déployés (forensics toolkit, accès d'urgence, canaux de communication sécurisés)
- Playbooks de réponse pré-rédigés pour les scénarios les plus probables
- Détection et identification :
- Sources de détection : SIEM, EDR, WAF, alertes applicatives, signalements utilisateurs, threat intelligence
- Critères de qualification d'un incident de sécurité vs un événement de sécurité
- Grille de classification des incidents par niveau de gravité :
- P1 — Critique : compromission confirmée, fuite de données avérée, ransomware actif
- P2 — Majeur : tentative d'intrusion avec indicateurs de succès partiel, vulnérabilité activement exploitée
- P3 — Significatif : anomalie de sécurité nécessitant une investigation, tentative d'intrusion détectée et bloquée
- P4 — Mineur : événement de sécurité sans impact immédiat, alerte informative
- Confinement :
- Actions immédiates de confinement (isolation du système compromis, révocation des accès, blocage d'IP)
- Préservation des preuves numériques (capture de mémoire, copie de disques, sauvegarde des logs)
- Évaluation de l'étendue de la compromission (lateral movement, données exposées)
- Éradication :
- Suppression de la cause racine (malware, backdoor, configuration vulnérable)
- Vérification de l'absence de persistance de l'attaquant
- Correction de la vulnérabilité exploitée
- Remédiation et reprise :
- Restauration des systèmes à partir de sauvegardes saines (en coordination avec le PRA si nécessaire)
- Vérification de l'intégrité des données restaurées
- Remise en service progressive avec monitoring renforcé
- Réinitialisation des credentials potentiellement compromis
- Post-incident :
- Analyse post-mortem formelle (root cause analysis)
- Chronologie détaillée de l'incident (timeline)
- Identification des améliorations à apporter (processus, outils, formation)
- Mise à jour du registre des incidents de sécurité
- Communication du retour d'expérience aux équipes concernées
- Détailler les obligations de notification :
- CNIL : notification sous 72h en cas de violation de données personnelles (article 33 RGPD)
- Personnes concernées : notification si risque élevé pour les droits et libertés (article 34 RGPD)
- ANSSI : notification en cas d'incident significatif (NIS2)
- Clients : notification selon les engagements contractuels (délai, format, contenu)
- Assureur cyber : déclaration de sinistre dans les délais contractuels
- Coordonner la gestion des incidents avec le PCA et le PRA :
- Critères de basculement d'un incident de sécurité vers l'activation du PCA/PRA
- Interface entre le CSIRT et la cellule de crise PCA
- Maintien des exigences de sécurité pendant la phase de reprise (pas de raccourci sécurité sous la pression)
- Documenter les mesures de protection des données personnelles :
- Registre des traitements de données personnelles (article 30 RGPD)
- Analyse d'impact relative à la protection des données (AIPD / DPIA) pour les traitements à risque élevé
- Base légale de chaque traitement identifiée et documentée
- Minimisation des données collectées (seules les données strictement nécessaires sont traitées)
- Droits des personnes concernées :
- Procédures opérationnelles pour répondre aux demandes d'exercice des droits :
- Droit d'accès (délai de réponse : 1 mois maximum)
- Droit de rectification
- Droit à l'effacement (droit à l'oubli)
- Droit à la portabilité des données
- Droit d'opposition et limitation du traitement
- Processus technique d'effacement et d'anonymisation des données
- Traçabilité des demandes traitées
- Gestion des sous-traitants (article 28 RGPD) :
- Contrat de sous-traitance conforme au RGPD avec chaque prestataire traitant des données personnelles
- Registre des sous-traitants maintenu et communiqué aux clients
- Évaluation régulière de la conformité des sous-traitants
- Clauses de transfert international des données (clauses contractuelles types si transfert hors UE)
- Durée de conservation des données :
- Politique de rétention définie par type de données
- Suppression ou anonymisation automatisée à l'expiration de la durée de conservation
- Procédure de purge des données en fin de contrat client (réversibilité)
- Privacy by Design et Privacy by Default :
- Intégration de la protection des données dès la conception des fonctionnalités
- Paramètres de confidentialité les plus protecteurs activés par défaut
- Pseudonymisation et anonymisation des données lorsque possible
- Expliquer le processus de gestion des changements (Change Management) :
- Classification des changements par niveau de risque :
- Standard : changements pré-approuvés, à faible risque (mise à jour mineure de dépendance, modification cosmétique)
- Normal : changements nécessitant une évaluation et une approbation (nouvelle fonctionnalité, modification d'architecture)
- Urgent : correctifs de sécurité critiques nécessitant un déploiement en dehors du cycle normal
- Pour chaque changement, documenter :
- L'évaluation de l'impact sécurité (Security Impact Assessment)
- Les mesures de mitigation des risques associés
- Le plan de test (fonctionnel, sécurité, performance)
- Le plan de rollback en cas de problème
- Circuit de validation :
- Développeur → Revue de code → Tests automatisés (CI) → Validation QA → Approbation sécurité (si changement sensible) → Déploiement
- Changements urgents : procédure accélérée avec validation a posteriori documentée
- Détailler le processus de gestion des versions :
- Versioning sémantique (SemVer) des releases
- Changelog maintenu et accessible aux clients
- Notes de version incluant les correctifs de sécurité (sans divulguer les détails exploitables avant application)
- Gestion des correctifs de sécurité (Patch Management) :
- Veille continue sur les vulnérabilités des composants utilisés
- Processus de qualification et de priorisation des correctifs
- Délais d'application :
- Correctifs critiques : sous 24h (ou mitigation immédiate)
- Correctifs importants : sous 7 jours
- Correctifs modérés : au prochain cycle de release
- Vérification post-déploiement de l'efficacité du correctif
- Assurer la capacité de rollback :
- Stratégie de déploiement permettant un retour arrière rapide (blue/green, canary, feature flags)
- Procédure de rollback documentée et testée
- Rétention des versions précédentes de l'application et de la base de données (migrations réversibles)
- Temps de rollback cible : < 15 minutes
- Documenter les pratiques de sécurité opérationnelle :
- Durcissement des systèmes (hardening) :
- Images de base minimales et durcies (CIS Benchmarks)
- Désactivation des services et ports non nécessaires
- Configuration sécurisée par défaut (Infrastructure as Code avec validation de sécurité)
- Gestion des secrets :
- Coffre-fort de secrets centralisé (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Injection dynamique des secrets dans les applications (pas de secrets en dur dans le code ou les fichiers de configuration)
- Rotation automatique des secrets selon une politique définie
- Audit trail de l'accès aux secrets
- Gestion des logs :
- Centralisation des logs applicatifs, systèmes et de sécurité
- Protection contre la falsification des logs (stockage immuable, chaînage cryptographique)
- Politique de rétention des logs conforme aux exigences réglementaires et contractuelles
- Accès aux logs restreint et audité
- Sauvegarde et restauration :
- Stratégie de sauvegarde documentée (fréquence, rétention, chiffrement, localisation — cf. PRA pour le détail)
- Tests de restauration réguliers (au minimum trimestriels)
- Sauvegardes immuables (WORM) pour protection contre les ransomwares
- Lier avec le PCA et le PRA :
- Le PAS définit les exigences de sécurité que le PCA et le PRA doivent respecter
- Garantir que la disponibilité du service est assurée en cas de sinistre tout en maintenant le niveau de sécurité requis
- Pas de compromis sur la sécurité lors des procédures de reprise (ex : pas de désactivation du MFA pour accélérer la reprise)
- Planifier les audits internes et externes :
- Audits internes :
- Audit de sécurité interne au minimum annuel couvrant l'ensemble du périmètre du PAS
- Revues de configuration trimestrielles (cloud, réseau, applicatif)
- Audit de conformité RGPD annuel en coordination avec le DPO
- Audits externes :
- Audit de certification ISO 27001 (initial puis surveillance annuelle, renouvellement triennal)
- Audit SOC 2 Type II annuel
- Tests d'intrusion externes annuels par un prestataire qualifié PASSI
- Audit de conformité réglementaire si requis (HDS, PCI DSS, DORA)
- Audits clients :
- Droit d'audit contractuel des clients (modalités : questionnaire, audit sur site, audit à distance)
- Fourniture des rapports d'audit et certifications sur demande (NDA si nécessaire)
- Réponses aux questionnaires de sécurité clients (SIG, CAIQ, questionnaires personnalisés)
- Réaliser des auto-évaluations régulières :
- Auto-évaluation trimestrielle de la posture de sécurité (basée sur les contrôles ISO 27001 Annexe A)
- Revue mensuelle des indicateurs de sécurité (KPI/KRI)
- Benchmark par rapport aux standards du secteur
- Décrire comment les preuves de conformité sont collectées et maintenues :
- Registre centralisé des preuves d'audit (GRC — Governance, Risk & Compliance tool)
- Types de preuves maintenues :
- Politiques et procédures approuvées et datées
- Rapports de scan de vulnérabilités et de tests d'intrusion
- Journaux de revue des accès
- Comptes-rendus des comités de sécurité
- Attestations de formation du personnel
- Rapports d'incidents et post-mortems
- Matrices de risques et plans de traitement
- Accessibilité des preuves pour les auditeurs (portail dédié ou espace documentaire sécurisé)
- Détailler les programmes de formation continue par population :
- Tous les employés :
- Formation initiale à la sécurité lors de l'onboarding (politique de sécurité, règles d'utilisation du SI, signalement des incidents)
- Sensibilisation annuelle obligatoire (e-learning ou session en présentiel)
- Campagnes de simulation de phishing régulières (au minimum trimestrielles) avec suivi individuel et accompagnement des récidivistes
- Communication régulière sur les menaces actuelles (newsletter sécurité, alertes)
- Développeurs :
- Formation au développement sécurisé (OWASP Top 10, SANS Top 25)
- Ateliers pratiques de sécurité applicative (CTF — Capture The Flag, exercices de code review sécurité)
- Formation spécifique sur les outils de sécurité intégrés au pipeline CI/CD (SAST, DAST, SCA)
- Mise à jour annuelle sur les nouvelles techniques d'attaque et les bonnes pratiques
- Administrateurs et équipes infrastructure :
- Formation au durcissement des systèmes et à la sécurité cloud
- Certification sécurité cloud recommandée (AWS Security Specialty, Azure Security Engineer, GCP Professional Cloud Security Engineer)
- Formation à la réponse aux incidents et au forensics de base
- Exercices pratiques de détection et réponse (purple team)
- Management et direction :
- Sensibilisation aux enjeux stratégiques de la cybersécurité
- Formation sur les obligations légales et réglementaires (RGPD, NIS2, responsabilité des dirigeants)
- Participation aux exercices de crise (tabletop)
- Évaluer l'efficacité du programme de sensibilisation :
- Indicateurs de suivi : taux de complétion des formations, taux de clic sur les simulations de phishing, nombre d'incidents signalés proactivement
- Objectifs mesurables (ex : taux de clic phishing < 5%, taux de complétion formation > 95%)
- Ajustement du programme en fonction des résultats
- Formaliser les engagements de sécurité envers les clients :
- SLA de sécurité :
- Temps de détection d'un incident de sécurité (MTTD — Mean Time to Detect)
- Temps de réponse à un incident de sécurité (MTTR — Mean Time to Respond)
- Temps de notification client en cas d'incident impactant leurs données
- Disponibilité du service (lien avec le PCA)
- Engagements de transparence :
- Publication d'une page de statut de sécurité (security status page)
- Communication proactive en cas d'incident de sécurité
- Mise à disposition des rapports d'audit et certifications
- Publication d'une politique de divulgation responsable (Responsible Disclosure Policy)
- Engagements contractuels :
- Annexe sécurité intégrée aux contrats (basée sur le PAS)
- DPA (Data Processing Agreement) conforme RGPD
- Clause de réversibilité et de portabilité des données en fin de contrat
- Clause de notification d'incident (délai, format, contenu)
- Droit d'audit du client (modalités et limites)
- Documenter les niveaux de service de sécurité proposés aux clients :
- Niveau standard : couverture de base (chiffrement, MFA, backups, monitoring)
- Niveau avancé : options supplémentaires (BYOK, audit logs dédiés, environnement dédié, SLA renforcé)
- Personnalisation contractuelle possible pour les clients stratégiques
- Définir le calendrier des tests de sécurité :
- Tests continus :
- Scans de vulnérabilités automatisés (SAST, DAST, SCA) à chaque déploiement
- Monitoring de sécurité 24/7
- Tests trimestriels :
- Exercice tabletop de réponse à incident de sécurité (simulation d'un scénario d'attaque)
- Campagne de simulation de phishing
- Revue des accès et des configurations
- Tests semi-annuels :
- Test d'intrusion interne (réseau, applicatif)
- Exercice de restauration de sauvegardes (lien avec le PRA)
- Revue de l'architecture de sécurité
- Tests annuels :
- Test d'intrusion externe par un prestataire qualifié PASSI
- Exercice de crise complet (simulation d'un incident majeur de sécurité avec activation de la chaîne complète : détection → réponse → communication → remédiation)
- Revue annuelle complète du PAS
- Audit interne de sécurité
- Pour chaque type de test, préciser :
- Les objectifs mesurables et les critères de succès
- Le périmètre couvert
- Les responsables de l'exécution et de la validation
- Le format du rapport et les destinataires
- Le processus de suivi des actions correctives
- Documenter les résultats des tests précédents et les plans d'amélioration associés
¶ 15. Maintenance et amélioration continue
- Décrire le processus de mise à jour du PAS :
- Révision trimestrielle planifiée (a minima vérification de la pertinence des mesures, des contacts, des processus)
- Mise à jour immédiate après :
- Tout incident de sécurité significatif (intégration du retour d'expérience)
- Tout changement majeur de l'architecture technique ou organisationnelle
- Toute évolution réglementaire impactant les obligations de sécurité
- Tout résultat d'audit nécessitant des actions correctives
- Tout changement significatif dans le paysage des menaces
- Revue annuelle complète avec validation par la direction générale et le RSSI
- Indiquer le responsable de la maintenance du document (RSSI) et le processus de validation des modifications :
- Rédaction par le RSSI ou son délégué
- Revue par les parties prenantes concernées (technique, juridique, conformité)
- Validation formelle par la direction
- Communication des changements aux équipes concernées
- Intégrer un processus d'amélioration continue (PDCA — Plan, Do, Check, Act) :
- Plan : identification des améliorations à partir des audits, incidents, tests, veille
- Do : mise en œuvre des actions d'amélioration avec responsables et échéances
- Check : vérification de l'efficacité des actions mises en œuvre
- Act : ajustement et pérennisation des améliorations validées
- Prévoir un registre des versions avec historique des changements
- Documenter la matrice RACI (Responsible, Accountable, Consulted, Informed) pour les activités clés de sécurité :
| Activité |
RSSI |
DPO |
SecOps |
Dev |
Infra |
Direction |
| Politique de sécurité |
A |
C |
R |
I |
I |
A |
| Gestion des risques |
R/A |
C |
R |
C |
C |
I |
| Gestion des accès |
C |
I |
R |
R |
R |
I |
| Réponse aux incidents |
A |
C |
R |
C |
R |
I |
| Conformité RGPD |
C |
A |
R |
C |
C |
I |
| Tests d'intrusion |
A |
I |
R |
C |
C |
I |
| Formation sécurité |
A |
C |
R |
I |
I |
I |
| Audit et certification |
A |
C |
R |
C |
C |
I |
- Légende : R = Réalise, A = Approuve, C = Consulté, I = Informé
- Liste des indicateurs clés à suivre et reporter :
- Vulnérabilités :
- Nombre de vulnérabilités critiques/hautes ouvertes
- Temps moyen de remédiation par niveau de criticité
- Couverture des scans de vulnérabilités (% de l'infrastructure et des applications scannées)
- Incidents :
- Nombre d'incidents de sécurité par mois et par niveau de gravité
- MTTD (Mean Time to Detect) et MTTR (Mean Time to Respond)
- Nombre de violations de données
- Accès :
- Pourcentage de comptes avec MFA activé
- Nombre de comptes orphelins détectés lors des revues
- Nombre de dérogations de sécurité actives
- Conformité :
- Taux de complétion des formations sécurité
- Taux de clic sur les campagnes de phishing
- Nombre de non-conformités détectées en audit
- Pourcentage de correctifs de sécurité appliqués dans les délais
- Opérationnel :
- Taux de disponibilité du service
- Nombre de déploiements avec validation sécurité
- Couverture des tests automatisés de sécurité dans le pipeline CI/CD
- Définir tous les termes utilisés dans le document :
- ANSSI : Agence Nationale de la Sécurité des Systèmes d'Information
- AIPD / DPIA : Analyse d'Impact relative à la Protection des Données / Data Protection Impact Assessment
- BIA : Business Impact Analysis — Analyse d'impact métier
- BYOK : Bring Your Own Key — Apportez votre propre clé de chiffrement
- CAIQ : Consensus Assessments Initiative Questionnaire (CSA)
- CDN : Content Delivery Network
- CNIL : Commission Nationale de l'Informatique et des Libertés
- CSIRT / CERT : Computer Security Incident Response Team / Computer Emergency Response Team
- CVSS : Common Vulnerability Scoring System — Système de notation des vulnérabilités
- DAST : Dynamic Application Security Testing — Test de sécurité dynamique
- DDoS : Distributed Denial of Service — Attaque par déni de service distribué
- DICP : Disponibilité, Intégrité, Confidentialité, Preuve
- DORA : Digital Operational Resilience Act — Règlement européen sur la résilience opérationnelle numérique
- DPA : Data Processing Agreement — Accord de traitement des données
- DPO : Data Protection Officer — Délégué à la Protection des Données
- EBIOS RM : Expression des Besoins et Identification des Objectifs de Sécurité — Risk Manager
- EDR : Endpoint Detection and Response
- GRC : Governance, Risk & Compliance
- HDS : Hébergeur de Données de Santé
- HSTS : HTTP Strict Transport Security
- IAM : Identity and Access Management — Gestion des identités et des accès
- IaC : Infrastructure as Code
- IDS / IPS : Intrusion Detection System / Intrusion Prevention System
- IoC : Indicator of Compromise — Indicateur de compromission
- IRP : Incident Response Plan — Plan de réponse aux incidents
- KPI : Key Performance Indicator — Indicateur clé de performance
- KRI : Key Risk Indicator — Indicateur clé de risque
- MFA : Multi-Factor Authentication — Authentification multi-facteurs
- MTTD : Mean Time to Detect — Temps moyen de détection
- MTTR : Mean Time to Respond — Temps moyen de réponse
- mTLS : Mutual TLS — TLS mutuel
- NIS2 : Network and Information Security Directive 2 — Directive européenne sur la sécurité des réseaux et systèmes d'information
- OWASP : Open Worldwide Application Security Project
- PAM : Privileged Access Management — Gestion des accès à privilèges
- PAS : Plan d'Assurance Sécurité
- PASSI : Prestataires d'Audit de la Sécurité des Systèmes d'Information (qualification ANSSI)
- PCA : Plan de Continuité d'Activité
- PCI DSS : Payment Card Industry Data Security Standard
- PDCA : Plan, Do, Check, Act — Cycle d'amélioration continue
- PRA : Plan de Reprise d'Activité
- PSSI : Politique de Sécurité des Systèmes d'Information
- RBAC : Role-Based Access Control — Contrôle d'accès basé sur les rôles
- RGPD : Règlement Général sur la Protection des Données
- RSSI / CISO : Responsable de la Sécurité des Systèmes d'Information / Chief Information Security Officer
- SAST : Static Application Security Testing — Test de sécurité statique
- SBOM : Software Bill of Materials — Nomenclature logicielle
- SCA : Software Composition Analysis — Analyse de composition logicielle
- SDLC : Software Development Life Cycle — Cycle de vie du développement logiciel
- SIEM : Security Information and Event Management
- SIG : Standardized Information Gathering (questionnaire)
- SLA : Service Level Agreement — Accord de niveau de service
- SOAR : Security Orchestration, Automation and Response
- SOC 2 : Service Organization Control 2 — Framework d'audit de sécurité
- SSO : Single Sign-On — Authentification unique
- WAF : Web Application Firewall — Pare-feu applicatif web
- WORM : Write Once Read Many — Écriture unique, lectures multiples (stockage immuable)