ObjectifCyber

Chapitre 11 — Gouvernance, Conformité & Sensibilisation

La gouvernance établit le cadre stratégique de la sécurité. Ce module couvre les politiques de sécurité, les réglementations clés (GDPR, HIPAA, PCI-DSS), et la sensibilisation à la sécurité.

Mémorisez ! Hiérarchie des documents de sécurité : Politique (QUOI) → Standard (spécifications, COMMENT mesurer) → Guideline (recommandation, non obligatoire) → Procédure (instructions étape par étape, COMMENT faire). Les politiques viennent de la direction — les procédures viennent des techniciens.

RéglementationDomaineGéographieSanctions
GDPRProtection des données personnelles (PII)UE (tout organisme traitant des données de citoyens EU)4% du CA mondial ou 20M€
HIPAADonnées de santé (PHI)États-UnisJusqu'à 1,9M$/an/catégorie
PCI-DSSDonnées de carte de paiementMondial (toute organisation qui traite des cartes)Amendes des réseaux de cartes, perte de droits de traitement
SOX (Sarbanes-Oxley)Contrôles financiers des sociétés cotées USÉtats-Unis (cotées en bourse)Pénalités pénales pour dirigeants
GLBADonnées financières personnellesÉtats-Unis (institutions financières)Amendes fédérales

Astuce Examen

Le GDPR s'applique à TOUTE organisation qui traite des données de citoyens UE — même une entreprise américaine. Les 72 heures de notification sont une cible fréquente. PCI-DSS est un standard de l'industrie (non une loi), mais le non-respect peut mener à la perte du droit de traiter des paiements par carte.

1. Le GDPR exige qu'une violation de données soit notifiée à l'autorité de contrôle dans un délai de :

GDPR Article 33 = 72 heures pour notifier l'autorité de contrôle (CNIL en France) dès qu'on prend connaissance d'une violation de données personnelles. Si l'organisation est incapable de notifier dans ce délai, elle doit expliquer pourquoi dans sa notification tardive. Les particuliers (personnes affectées) sont notifiés si le risque est élevé.

2. PCI-DSS s'applique à :

PCI-DSS = standard de l'industrie des cartes de paiement, pas une loi. S'applique à TOUTE entité qui touche aux données de carte : commerçants en ligne, restaurants, hôtels, prestataires de paiement. La conformité est exigée par les réseaux de cartes (Visa, MC). Non-conformité = amendes, perte du droit d'accepter les cartes.

3. La hiérarchie des documents de sécurité du plus général au plus spécifique est :

Politique = QUOI (haut niveau, stratégie). Standard = spécifications mesurables (COMMENT satisfaire la politique). Guideline = recommandation non obligatoire. Procédure = instructions étape par étape (COMMENT faire concrètement). Exemple : Politique "les données doivent être chiffrées" → Standard "AES-256 minimum" → Guideline "préférer ECC" → Procédure "voici comment chiffrer avec BitLocker..."

4. Une politique d'AUP (Acceptable Use Policy) est principalement :

AUP = règles d'utilisation des ressources IT. Couvre : utilisation d'internet, email professionnel, logiciels autorisés, appareils personnels, réseaux sociaux, surveillance des communications. Signée à l'embauche. Protège l'organisation légalement si un employé abuse des ressources IT (utilisation personnelle excessive, téléchargement illégal...).

5. Le "Privacy by Design" exigé par le GDPR signifie :

Privacy by Design = principe de conception. Ex: lors du développement d'une nouvelle application : collecter le minimum de données nécessaires (data minimisation), consentement intégré dans le workflow, données pseudonymisées par défaut, options de suppression prévues. Pas une protection qu'on ajoute après le lancement — elle doit être architecturée dès le départ.

6. La "tokenisation" en PCI-DSS est utilisée pour :

Tokenisation = substitution. Le numéro de carte 4111-1111-1111-1111 est remplacé par un token "8a2e3f7c" stocké chez le marchand. Seul le prestataire de paiement maintient la correspondance token ↔ vrai numéro. Si le marchand est piraté, le token volé est inutilisable. Réduit la portée PCI-DSS car le marchand ne détient plus de données de carte.

7. Le principe de "séparation des tâches" (Separation of Duties) est conçu pour :

SoD = "four eyes principle". Ex bancaire : une personne crée un virement, une autre l'approuve, une troisième l'exécute. Si ces trois rôles sont une seule personne = fraude possible. Ex IT : le développeur ne doit pas pouvoir déployer son propre code en production sans revue. SoD est un contrôle compensant majeur contre la fraude interne.

8. Les simulations de phishing (phishing simulations) sont utilisées pour :

Phishing simulations = campagnes de phishing contrôlées envoyées aux employés. Mesures : taux d'ouverture, taux de clic sur le lien, taux de saisie de credentials. Les "cliqueurs" sont redirigés vers une page de formation immédiate. Outil clé de sensibilisation — démontre concrètement la vulnérabilité à l'ingénierie sociale.

9. SOX (Sarbanes-Oxley) concerne principalement :

SOX (2002) = réaction aux scandales Enron/WorldCom. Exige des contrôles internes sur les rapports financiers (Section 302 : attestation par le CEO/CFO, Section 404 : évaluation annuelle des contrôles). Implications IT : audit trails des modifications de données financières, contrôle d'accès strict aux systèmes ERP, intégrité des logs. Dirigeants passibles de prison en cas de fraude.

10. Le "congé obligatoire" (Mandatory Vacation) est un contrôle de sécurité qui :

Mandatory Vacation = contrôle anti-fraude. Exemple : un employé qui gère seul les paiements fournisseurs peut dissimuler des détournements. Pendant ses congés obligatoires, un remplaçant prend le relais — et peut détecter des irrégularités. Ce contrôle est particulièrement important dans les postes financiers et IT avec accès privilégié.