Nexaris Finance — Présentation de l'Entreprise
Groupe financier régional · Services bancaires & assurance · Données sensibles réglementées
Activité & Exposition Cyber
Nexaris Finance est un groupe financier régional fondé en 1991, opérant dans les services bancaires aux particuliers et professionnels (crédit, épargne, assurance) via 45 agences en France. Avec 180 000 clients actifs et 400 M€ d'encours gérés, le groupe traite quotidiennement des données financières hautement sensibles : données bancaires, données de santé (assurance), données patrimoniales.
Sa surface d'attaque est considérable : portail client web, application mobile, 45 postes VPN agences, 3 000 comptes Active Directory, 12 interfaces avec des partenaires externes (courtiers, CBS, Banque de France). En 2023, Nexaris a subi une tentative d'intrusion par ransomware stoppée in extremis, révélant des vulnérabilités critiques dans sa posture de sécurité.
Infrastructure Actuelle & Risques
L'infrastructure repose sur deux datacenters on-premise vieillissants (Bordeaux + Paris), sous VMware vSphere 6.5 et Windows Server 2012/2016 — partiellement en fin de support éditeur. L'AD n'a jamais fait l'objet d'un audit de sécurité. Aucun EDR n'est déployé sur les postes, le pare-feu est un Cisco ASA de 2015, et il n'existe ni SIEM ni SOC opérationnel.
La Direction Générale a validé un programme de transformation sur 18 mois : migration vers un cloud souverain certifié SecNumCloud (OVHcloud ou Outscale), hardening de l'Active Directory, déploiement d'un SOC managé, et mise en conformité avec le règlement européen DORA (entrée en vigueur janvier 2025) et la directive NIS2. Budget alloué : 950 000 €.
Votre Mission & Contexte
La DSI de Nexaris Finance vous mandate, en tant qu'Expert en Architecture Cyber-Cloud au sein de votre ESN, pour piloter l'étude, la conception et la planification de la transformation de l'infrastructure vers un cloud souverain sécurisé. Votre mission couvre simultanément le volet technique (architecture Zero Trust, migration Cloud), le volet conformité réglementaire (DORA, NIS2, ISO 27001) et le volet opérationnel (SOC, réponse aux incidents). Les livrables que vous produisez servent de base contractuelle au programme de 18 mois.
Vulnérabilités & Risques Critiques Identifiés
🔴 Active Directory non durci
Kerberoasting, Pass-the-Hash et DCSync possibles. Comptes de service avec Kerberos sans contrainte. Délégation non contrôlée.
CVSS 9.8 — Critique🔴 Absence d'EDR & SIEM
Aucune détection comportementale sur les 3 000 endpoints. Temps de détection moyen d'intrusion estimé à > 200 jours (benchmark secteur).
CVSS 9.1 — Critique🔴 OS en fin de support
40% des serveurs sous Windows Server 2012 R2 (EoL octobre 2023). Aucun patch de sécurité disponible depuis 18 mois. CVEs non corrigées connues.
CVSS 8.8 — Élevé🟡 VPN agences non segmenté
Accès VPN full-tunnel sans MFA. Compromission d'une agence = accès total au réseau interne. Pas de micro-segmentation.
CVSS 8.1 — Élevé🟡 Non-conformité DORA
Absence de TLPT (Threat-Led Penetration Testing), pas de registre des tiers ICT, pas de plan de résilience opérationnelle testé. Amende potentielle : jusqu'à 1% du CA.
DORA Art. 26 — ÉlevéRéférentiels de conformité cibles
Contraintes du projet
💰 Budget 950 000 €
Toutes dépenses : migration infra, licences sécurité (EDR, SIEM, PAM, CASB), audit/pentest, formation, conseil. Réparti sur 18 mois.
☁️ Cloud souverain uniquement
Données financières et données de santé (assurance) : obligation d'hébergement sur un cloud certifié SecNumCloud (ANSSI). AWS/Azure/GCP exclus.
⏱️ DORA — Échéance janvier 2025
Non-négociable. Les livrables de conformité DORA (registre tiers ICT, TLPT, plan ICT) doivent être opérationnels avant M12 du projet.
🔄 Continuité de service 99,9%
La migration Cloud et les opérations de sécurité ne peuvent pas interrompre les services bancaires. Fenêtres de maintenance < 30 min/mois.
🛡️ Zero Trust Architecture
Principe imposé par la DSI : "Never Trust, Always Verify". L'architecture cible doit implémenter les 5 piliers Zero Trust (Identity, Device, Network, App, Data).
👥 Équipe projet
4 ingénieurs Cloud/Infra, 2 experts Cybersécurité, 1 DPO conseil, 1 chef de projet. Équipe mixte ESN + ressources internes Nexaris.
Livrables & Consignes Précises
-
1Réalisez le Cloud Readiness Assessment de l'infrastructure actuelle de Nexaris : évaluez la capacité de migration des 3 workloads critiques (Core Banking System, portail client, Active Directory) vers le cloud souverain. Pour chaque workload, précisez le modèle de migration retenu (Rehost, Replatform, Refactor, Retain ou Retire) selon le framework des 6R d'AWS, et justifiez ce choix par des arguments techniques et de sécurité.
-
2Évaluez la maturité cybersécurité actuelle de Nexaris sur les 5 fonctions du framework NIST CSF (Identify, Protect, Detect, Respond, Recover). Pour chaque fonction, attribuez un niveau de maturité (Initial, Répétable, Défini, Géré, Optimisé) et justifiez-le par les observations du contexte. Identifiez les 3 gaps les plus critiques et hiérarchisez les actions correctives selon le ratio effort/réduction de risque.
-
3Construisez une comparaison TCO sur 3 ans : coût total de maintien de l'infrastructure on-premise actuelle vs coût total de la solution Cloud souverain cible (incluant migration, licences, opérations). Calculez le ROI en intégrant les coûts évités : amende DORA potentielle (1% du CA), coût d'un incident ransomware (estimez sur la base du secteur financier), économies sur l'infra vieillissante.
-
4Produisez la matrice de risques du programme (probabilité × impact) couvrant au minimum 8 risques spécifiques au contexte Nexaris : risque de fuite de données pendant la migration, indisponibilité des services bancaires, non-atteinte de la conformité DORA dans les délais, dépendance excessive à un fournisseur Cloud, résistance des équipes IT internes, etc. Chaque risque doit avoir une mesure de mitigation applicable dans le contexte financier réglementé.
La certification SecNumCloud de l'ANSSI exclut de facto les hyperscalers américains (AWS, Azure, GCP) pour les données sensibles des secteurs bancaire et assurantiel. Votre étude de faisabilité doit impérativement justifier le choix entre OVHcloud, Outscale (Dassault Systèmes) ou Scaleway sur des critères objectifs : périmètre de certification, SLA, catalogue de services disponibles, tarification.
-
1Définissez les domaines de veille prioritaires pour Nexaris Finance : menaces ciblant le secteur financier (APT alignées sur FS-ISAC, attaques sur CBS, fraudes BEC), évolutions des référentiels de conformité (DORA Level 2 RTS/ITS, mises à jour NIS2, nouvelles normes ANSSI), nouveautés cloud souverain (nouvelles régions, certifications, services de sécurité managés OVHcloud/Outscale), et vulnérabilités critiques des technologies utilisées (VMware, Windows Server, Active Directory). Pour chaque domaine, expliquez son lien direct avec les risques de Nexaris.
-
2Construisez votre stack de sources CTI (Cyber Threat Intelligence) en les organisant par niveau de maturité : sources ouvertes gratuites (MITRE ATT&CK, CVE/NVD, CERT-FR, CISA KEV, Shodan, VirusTotal), sources sectorielles (FS-ISAC, SWIFT ISAC, CERT Banque de France), sources payantes si justifiées (Recorded Future, Mandiant Advantage). Pour chaque source, précisez le type d'intelligence produit (IOC, TTP, vulnérabilité, réglementaire) et la fréquence de consultation.
-
3Décrivez le processus CTI opérationnel au sein de l'équipe projet : comment les IOC (Indicateurs de Compromission) collectés sont-ils intégrés dans le futur SIEM de Nexaris ? Comment une nouvelle CVE critique affectant l'Active Directory déclenche-t-elle une procédure de patching d'urgence ? Qui arbitre entre "appliquer le patch immédiatement" et "attendre la prochaine fenêtre de maintenance planifiée" ?
-
4Produisez une fiche de Threat Intelligence opérationnelle sur le groupe APT Scattered Spider (ou un groupe ciblant activement le secteur financier européen de votre choix) : TTPs utilisées (MITRE ATT&CK), secteurs ciblés, indicateurs de compromission connus, mesures de détection et de protection recommandées pour Nexaris. Cette fiche illustre la qualité de votre veille.
La Cyber Threat Intelligence opérationnelle produit des renseignements actionnables : un IOC (hash de malware, IP malveillante, domaine C2) que le SOC peut bloquer immédiatement. Distinguez dans votre livrable la veille stratégique (tendances, réglementation) de la veille tactique/opérationnelle (IOC, TTPs) — Nexaris a besoin des deux niveaux.
-
1Concevez l'architecture Zero Trust cible pour Nexaris Finance en articulant les 5 piliers (Identity, Device, Network, Application, Data). Présentez un schéma d'architecture identifiant les composants de sécurité déployés sur le cloud souverain (IAM/PAM centralisé, EDR cloud-managed, micro-segmentation réseau, WAF applicatif, DLP sur les données financières). Pour chaque pilier, précisez le principe Zero Trust appliqué et son implémentation concrète dans le contexte bancaire de Nexaris.
-
2Concevez la Landing Zone Cloud souverain : définissez l'organisation des comptes/projets cloud (Production, Pré-production, Sécurité/Log, Shared Services), les guardrails de sécurité automatisés (SCPs ou équivalent OVHcloud), la stratégie de réseau (VPC/VNet, subnets, passerelles, interconnexion vers les agences). Justifiez la stratégie IAM retenue : fédération avec l'Active Directory existant, MFA obligatoire, gestion des accès privilégiés (PAM) avec coffre-fort de mots de passe.
-
3Détaillez la stratégie de chiffrement et de gestion des clés : chiffrement au repos et en transit pour les données financières et de santé (AES-256, TLS 1.3 minimum), gestion des clés via HSM dédié ou service cloud KMS (Key Management Service), politique de rotation des clés, procédure de révocation d'urgence. Précisez comment cette stratégie s'articule avec les exigences de souveraineté des clés de chiffrement imposées par SecNumCloud.
-
4Décrivez la stratégie de migration sans interruption des services bancaires : comment coexistent l'infrastructure on-premise et le cloud souverain pendant les 18 mois de transition ? Quels patterns utilisez-vous (Strangler Fig pour les applications, Blue/Green pour les bases de données, Shadow Mode pour valider la cohérence des données migrées) ? Quels sont les critères de validation avant bascule définitive de chaque workload critique ?
Toute architecture qui héberge des données financières ou de santé sur un cloud non certifié SecNumCloud sera rejetée. La souveraineté des données (clés de chiffrement, hébergement physique en France, pas d'accès possible par juridiction étrangère) doit être explicitement démontrée dans votre architecture.
-
1Rédigez les exigences de sécurité techniques mesurables pour les domaines suivants, en vous appuyant sur les référentiels NIST SP 800-53, CIS Controls v8 et OWASP ASVS : gestion des identités et des accès (longueur mots de passe, durée de session, délai de révocation des comptes sortants), sécurité réseau (segmentation, règles de pare-feu, gestion des flux autorisés), sécurité des applications (authentification API, chiffrement des communications, gestion des secrets), et journalisation/audit (rétention des logs, intégrité, accessibilité en cas d'incident). Chaque exigence doit être numérotée, vérifiable et testable.
-
2Rédigez les exigences de conformité DORA applicables à Nexaris Finance (Articles 5 à 24 du règlement) : gestion des risques ICT (Art. 5-16), classification et notification des incidents (Art. 17-23), tests de résilience opérationnelle numérique dont le TLPT (Art. 24-27), gestion des risques liés aux prestataires tiers ICT (Art. 28-44). Pour chaque article applicable, précisez l'action concrète à mener, le responsable, et l'échéance par rapport au calendrier du projet.
-
3Définissez le programme de tests de sécurité du projet : pentest d'infrastructure avant migration (scope, méthodologie PTES ou OWASP, profil de l'équipe red team), TLPT conforme DORA (Threat-Led Penetration Testing basé sur le framework TIBER-EU), audit de configuration Cloud (CIS Benchmark pour OVHcloud/OpenStack), revue de code sécurité des applications migrées (SAST/DAST), et exercice de crise cyber (tabletop exercise). Pour chaque test, précisez la fréquence, le prestataire (interne/externe), et les critères de succès.
-
4Rédigez les exigences de continuité d'activité et de résilience conformes à DORA : RTO (Recovery Time Objective) et RPO (Recovery Point Objective) pour chaque service critique (Core Banking System, portail client, messagerie interne), stratégie de sauvegarde (règle 3-2-1 avec vérification d'intégrité), plan de reprise d'activité (PRA) avec tests de basculement semestriels, et exigences vis-à-vis des prestataires tiers ICT (OVHcloud SLA, garanties contractuelles de résilience).
Toute exigence doit suivre le format : Identifiant · Libellé · Critère de vérification · Référentiel source. Exemple : SEC-IAM-007 · Tout accès privilégié (admin) doit être authentifié par MFA et journalisé · Vérifier dans les logs SIEM + rapport PAM mensuel · CIS Control 5.4 / DORA Art. 9(4)(b).
-
1Découpez le programme en 4 phases cohérentes sur 18 mois : (1) Fondations sécurité et Quick Wins (M1-M3) — corriger les vulnérabilités critiques AD, déployer EDR, MFA ; (2) Build Cloud et SOC (M4-M9) — déploiement Landing Zone, migration workloads non critiques, déploiement SIEM/SOAR ; (3) Migration services critiques et conformité (M10-M15) — migration CBS et portail client, certification ISO 27001, préparation DORA ; (4) Optimisation et consolidation (M16-M18) — TLPT, bilan conformité, clôture. Pour chaque phase : objectifs, livrables de sécurité, budget consommé.
-
2Définissez les jalons de conformité non négociables du programme : (a) M3 — MFA déployé sur 100% des comptes administrateurs et VPN (DORA Art. 9) ; (b) M6 — SIEM opérationnel, premier rapport de surveillance des incidents (DORA Art. 17) ; (c) M10 — Registre des prestataires ICT tiers finalisé et approuvé par le CODIR (DORA Art. 28) ; (d) M12 — Audit ISO 27001 Étape 1 passé ; (e) M15 — TLPT réalisé et rapport remis à l'autorité compétente (DORA Art. 26) ; (f) M17 — Certification ISO 27001:2022 obtenue. Pour chaque jalon : définition de Done, responsable, conséquence en cas de dépassement.
-
3Présentez le plan de gestion du changement pour les équipes IT internes de Nexaris : les administrateurs système qui gèrent l'infra on-premise depuis 10 ans doivent devenir des cloud engineers. Comment organisez-vous la montée en compétences (certifications OVHcloud, formation DevSecOps, hands-on labs) ? Comment gérez-vous la résistance potentielle ? Quel est le plan de transfert de compétences pour l'autonomie de Nexaris à la fin du projet ?
-
4Identifiez le chemin critique du programme : quels jalons de sécurité sont bloquants pour la migration des services bancaires critiques ? Comment gérez-vous la dépendance entre le durcissement de l'Active Directory (M1-M2) et la migration vers le cloud (M4+) ? Présentez un diagramme de Gantt macro ou roadmap sur 18 mois avec les dépendances critiques en évidence.
L'entrée en application du règlement DORA est une échéance externe incontournable. Votre planning doit démontrer que les articles 5 à 44 sont couverts avant cette date — soit en M12 du projet si démarrage en janvier 2024. Un planning qui ne respecte pas cette contrainte sera considéré non conforme.
-
1Définissez les KPIs de posture de sécurité opérationnels (mesurés en temps quasi-réel par le SOC) : MTTD (Mean Time To Detect — temps entre intrusion et détection), MTTR (Mean Time To Respond — temps entre détection et containment), taux de vulnérabilités critiques non patchées sous 72h (CVSS ≥ 9.0), taux de couverture EDR (% d'endpoints supervisés), nombre de tentatives d'authentification bloquées par MFA/mois, taux de faux positifs des alertes SIEM. Pour chaque KPI : valeur actuelle estimée (baseline), cible à M18, source de données, fréquence de mesure.
-
2Définissez les KPIs de conformité DORA & ISO 27001 permettant de mesurer la progression vers la certification : taux de contrôles ISO 27001 implémentés (sur 93 contrôles de l'Annexe A), pourcentage des risques ICT évalués et traités (DORA Art. 6), délai moyen de déclaration d'incident significatif aux autorités (DORA Art. 19 — cible < 24h pour notification initiale), taux de couverture du registre des prestataires tiers ICT, date de réalisation du prochain TLPT. Pour chaque KPI : propriétaire, outil de mesure, seuil d'alerte.
-
3Définissez les KPIs Cloud & FinOps permettant de maîtriser les coûts et la performance de l'infrastructure Cloud souverain : coût mensuel Cloud par workload (avec cible et écart max acceptable), taux d'utilisation des ressources (éviter le surprovisionnement), disponibilité effective vs SLA contractuel (cible 99,9%), temps de restauration testé (PRA — cible RTO < 4h pour le CBS), score de conformité CIS Benchmark (% de contrôles cloud respectés). Quel outil de FinOps recommandez-vous pour Nexaris (CloudHealth, Apptio, native OVHcloud) ?
-
4Proposez la structure et la gouvernance du tableau de bord : quels dashboards pour quelles audiences (SOC Analysts — temps réel SIEM, RSSI — hebdomadaire posture sécurité, COMEX — mensuel conformité et risques, Régulateur — trimestriel rapport DORA) ? Quel outil retenu (Splunk, Microsoft Sentinel, Grafana, Power BI) ? Comment les KPIs du tableau de bord alimentent-ils les décisions de la gouvernance sécurité de Nexaris ?
Le règlement DORA impose des indicateurs de notification réglementaire non négociables : délai de notification initiale (4h après classification d'un incident majeur), délai de rapport intermédiaire (72h), délai de rapport final (1 mois). Ces KPIs doivent figurer dans votre tableau de bord avec un statut de conformité en temps réel.
Logs & Events
SIEM Rules
L1/L2 SOC
L3 / CSIRT
SOAR Playbook
DORA Art.19
-
1Concevez la gouvernance du SOC de Nexaris Finance : définissez les 3 niveaux d'analystes (L1 — Triage & qualification, L2 — Investigation, L3 — Threat Hunting & CSIRT), leurs missions respectives, le processus d'escalade entre niveaux, et les SLA de traitement par sévérité d'alerte (P1 — Critical : < 15 min, P2 — High : < 1h, P3 — Medium : < 4h). SOC interne ou externalisé (SOC-as-a-Service) ? Comparez les deux modèles selon les contraintes de Nexaris (taille, budget, exigences DORA sur la connaissance des tiers ICT).
-
2Rédigez deux playbooks de réponse aux incidents complets :
Playbook A — Ransomware : détection (indicateurs SIEM déclencheurs), containment immédiat (isolation réseau, désactivation comptes compromis), éradication, recovery depuis les sauvegardes, notification DORA (article 19 — délai, contenu, destinataires : BCE, ACPR, ANSSI), et retour d'expérience.
Playbook B — Compromission de compte administrateur : détection des anomalies comportementales (UEBA), révocation immédiate, investigation forensique AD, remédiations, communication interne. -
3Définissez le dispositif de notification réglementaire DORA : construisez le logigramme de décision "cet incident est-il majeur au sens de DORA ?" (critères de l'Article 18 : impact sur la continuité des services critiques, nombre de clients affectés, durée d'indisponibilité), les templates de notification initiale (4h), intermédiaire (72h) et finale (1 mois) à soumettre à l'ACPR (Autorité de Contrôle Prudentiel et de Résolution), et la procédure de coordination avec les autres entités financières potentiellement affectées.
-
4Concevez le programme d'exercices de crise cyber de Nexaris conformément à DORA Article 24 : exercice de simulation d'incident (tabletop exercise) semestriel avec le COMEX, exercice de basculement PRA annuel avec reconstitution complète du CBS depuis les sauvegardes cloud, et TLPT (Threat-Led Penetration Testing) biennal réalisé par un prestataire agréé TIBER-EU. Pour chaque exercice : scénario, participants, critères de succès, documentation produite, et modalités d'amélioration continue.
Le non-respect des délais de notification DORA expose Nexaris à des sanctions de l'ACPR pouvant atteindre 10% du chiffre d'affaires annuel. Vos procédures de notification doivent être automatisables : le SIEM/SOAR doit générer un pre-rempli du rapport réglementaire dès la classification de l'incident en P1/P2. Un processus entièrement manuel est inacceptable pour les délais imposés.
Consignes Transversales & Critères d'Évaluation
| Critère | Description | Poids |
|---|---|---|
| Contextualisation Nexaris | Chaque livrable doit s'ancrer dans les vulnérabilités identifiées, les contraintes réglementaires (DORA, SecNumCloud) et le contexte bancaire de Nexaris. Les réponses génériques "copier-coller de cours" sans lien avec le cas sont pénalisées. | Forte |
| Cohérence inter-livrables | L'architecture Zero Trust (L3) conditionne les exigences (L4), les jalons de conformité (L5) alimentent les KPIs (L6), et les playbooks (L7) utilisent les outils SIEM définis en L3. Une architecture qui mentionne Splunk en L3 mais Microsoft Sentinel en L7 sans justification sera sanctionnée. | Forte |
| Maîtrise des référentiels | DORA (articles cités précisément), ISO 27001:2022 (contrôles de l'Annexe A référencés), NIST CSF/SP 800-53, MITRE ATT&CK, CIS Controls v8. Les livrables doivent montrer une connaissance opérationnelle des référentiels, pas seulement leur existence. | Forte |
| Souveraineté & SecNumCloud | L'argument de souveraineté (données hébergées en France, clés sous contrôle, pas d'accès USA CLOUD Act) doit être démontré à chaque niveau : architecture (L3), exigences (L4), contrats fournisseurs (L5). Toute proposition impliquant AWS/Azure/GCP pour les données sensibles est éliminatoire. | Critique |
| Réalisme budgétaire | Le budget de 950 000 € doit être ventilé par phase et par poste de dépense. Les licences de sécurité (EDR, SIEM, PAM, CASB) ont des coûts réels à estimer et justifier. Un programme à 2 M€ dans une enveloppe de 950 k€ sera rejeté. | Importante |
| Conformité DORA opérationnelle | DORA n'est pas une simple liste de cases à cocher. Les livrables L4, L5, L6 et L7 doivent démontrer que chaque article applicable est couvert par une action concrète, un responsable, une échéance et un indicateur de mesure. | Importante |
| Forme et visuels | Schéma d'architecture Zero Trust (L3), diagramme de Gantt cyber (L5), logigramme de notification DORA (L7), et dashboard KPIs maquetté (L6) sont attendus. Un dossier 100% textuel sans aucun schéma sera pénalisé sur la clarté. | Standard |
- Dossier structuré PDF, page de garde, sommaire, une section par livrable
- Volume indicatif : 28 à 40 pages hors annexes
- Schémas : Lucidchart, Draw.io, Miro (architecture Zero Trust, flux SOC)
- Logigramme de décision DORA : Miro, Figma, ou PowerPoint
- Matrice de risques et registre ICT : tableau Excel ou Notion intégré en annexe
- 20 minutes de présentation (slides obligatoires)
- 15 minutes de questions-réponses avec le jury
- Le jury se focalisera sur L3 (Zero Trust + SecNumCloud) et L7 (DORA notification)
- Questions types : "Pourquoi OVHcloud et pas Scaleway ?" · "Que notifiez-vous à l'ACPR à H+4 et à H+72 ?" · "Comment implémentez-vous le micro-segmentation réseau dans une Landing Zone OVHcloud ?" · "Qu'est-ce que le TIBER-EU et comment Nexaris doit-il s'y préparer ?"