Un vecteur d'attaque sous-estimé dans les PME romandes
Un fournisseur vous envoie une facture modifiée avec un IBAN différent. L'email provient apparemment de votre propre domaine. Votre comptable règle 18 000 CHF. Aucun système interne n'a été compromis : l'attaquant a simplement envoyé un email en usurpant votre domaine, sans jamais accéder à votre infrastructure. Ce scénario — le BEC (Business Email Compromise) — représente la majorité des pertes financières liées à la cybersécurité dans les PME. SPF, DKIM et DMARC sont les trois couches techniques qui l'empêchent. Leur configuration correcte prend entre deux heures et une journée selon la maturité du parc. Leur absence expose l'organisation, ses clients et ses partenaires.
Cadre légal : ce que la nLPD implique pour la messagerie
La nouvelle Loi fédérale sur la protection des données (nLPD), entrée en vigueur le 01.09.2023, impose aux responsables du traitement de mettre en œuvre des mesures techniques et organisationnelles proportionnées à la sensibilité des données traitées (art. 8 nLPD). La messagerie électronique est un canal de traitement de données personnelles : coordonnées clients, contrats, données RH, dossiers médicaux pour les cabinets. Une usurpation de domaine qui permet à un attaquant d'intercepter ou de détourner ces échanges constitue une violation de données au sens de l'art. 24 nLPD.
En cas de violation susceptible d'entraîner un risque élevé pour les personnes concernées, la notification au Préposé fédéral à la protection des données (PFPDT) est obligatoire dans les meilleurs délais. L'absence de mesures techniques élémentaires comme DMARC peut aggraver l'appréciation du PFPDT sur le respect de l'obligation de sécurité. Pour les entités régulées (banques, assurances), la FINMA attend des mesures de sécurité des communications conformes aux standards du secteur.
Sur le plan pratique, l'absence de DMARC n'est pas une infraction en soi, mais elle constitue un manquement aux mesures techniques raisonnables. Dans une PME de 50 employés traitant des données clients, c'est un risque documentable lors d'un audit ISO 27001 ou d'une due diligence.
Architecture technique : SPF, DKIM, DMARC — rôles et interactions
SPF (Sender Policy Framework)
SPF est un enregistrement DNS de type TXT publié sur votre domaine. Il liste les serveurs IP autorisés à envoyer des emails au nom de ce domaine. Lorsqu'un serveur de réception reçoit un email prétendant venir de votre-entreprise.ch, il interroge le DNS et vérifie si l'IP d'envoi figure dans la liste. Un résultat FAIL indique une usurpation potentielle.
Syntaxe minimale pour une PME utilisant Microsoft 365 comme seul expéditeur :
v=spf1 include:spf.protection.outlook.com -all
Le mécanisme -all (hardfail) rejette tous les expéditeurs non listés. Le ~all (softfail) marque sans rejeter — acceptable en phase de test, à éviter en production. Attention : SPF valide uniquement l'adresse MAIL FROM (enveloppe SMTP), pas l'adresse From: visible par l'utilisateur. C'est cette limite qui rend SPF seul insuffisant.
Limite technique : SPF ne résiste pas aux redirections et forwardings email. Un email transféré depuis un serveur tiers échoue souvent le check SPF même s'il est légitime.
DKIM (DomainKeys Identified Mail)
DKIM ajoute une signature cryptographique à chaque email sortant. Le serveur d'envoi signe le message avec une clé privée ; le serveur de réception vérifie la signature via la clé publique publiée en DNS (enregistrement TXT sous selector._domainkey.domaine.ch). Si le contenu du message a été modifié en transit, la signature est invalide.
Contrairement à SPF, DKIM survit au forwarding puisque la signature est portée par le message lui-même. La longueur de clé recommandée est 2048 bits minimum (les clés 1024 bits sont considérées insuffisantes depuis 2018). Microsoft 365 et Google Workspace génèrent et gèrent automatiquement les clés DKIM si la fonctionnalité est activée — ce n'est pas le cas par défaut sur tous les tenants.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC est la couche de politique et de reporting. Il indique aux serveurs de réception ce qu'ils doivent faire quand SPF et/ou DKIM échouent, et envoie des rapports XML agrégés à une adresse email définie. Un message passe DMARC si :
- SPF réussit ET l'adresse MAIL FROM est alignée avec le domaine From:, OU
- DKIM réussit ET le domaine de la signature est aligné avec le domaine From:.
Enregistrement DMARC minimal publié en DNS (_dmarc.domaine.ch) :
v=DMARC1; p=none; rua=mailto:dmarc-rapports@domaine.ch; ruf=mailto:dmarc-forensics@domaine.ch; fo=1
Les trois politiques (p=) :
- none : monitoring uniquement, aucune action. Phase initiale obligatoire.
- quarantine : les emails échouant sont placés en spam/quarantaine.
- reject : les emails échouant sont rejetés. Objectif final.
Délai recommandé avant de passer à reject : minimum 4 à 8 semaines d'analyse des rapports agrégés, pour s'assurer qu'aucun expéditeur légitime n'est manquant dans SPF ou DKIM.
Interactions et dépendances
SPF sans DKIM protège partiellement contre le spoofing d'enveloppe. DKIM sans SPF laisse la porte ouverte aux serveurs non autorisés. DMARC sans les deux en dessous n'a aucun effet. La chaîne complète SPF + DKIM + DMARC avec politique reject constitue le standard minimal recommandé par le Centre national pour la cybersécurité (NCSC) pour les organisations suisses.
Déploiement pas à pas pour une PME de 20 à 150 employés
- Inventaire des expéditeurs légitimes (Responsable : DSI ou administrateur système) — Listez tous les services qui envoient des emails depuis votre domaine : serveur de messagerie principal (M365, Google Workspace, Exchange on-prem), ERP (Abacus, SAP Business One), CRM, outil de newsletter (Mailchimp, Brevo), formulaires web, serveur de monitoring. Oubliez un seul expéditeur et vous risquez de bloquer des emails légitimes en phase
reject. - Publication SPF (Responsable : DSI, accès DNS requis) — Créez l'enregistrement TXT sur votre zone DNS. Vérifiez avec
nslookup -type=TXT domaine.chou un outil en ligne de votre choix. Testez avec un envoi réel et vérifiez les en-têtes (Authentication-Results) côté réception. - Activation DKIM (Responsable : DSI) — Sur M365 : portail admin > Sécurité > Email et collaboration > Politiques > DKIM. Activez pour chaque domaine, publiez les deux enregistrements CNAME générés en DNS. Attendez la propagation DNS (TTL habituel : 300 à 3600 secondes selon l'hébergeur). Même démarche sur Google Workspace : Admin > Apps > Google Workspace > Gmail > Authentifier les emails.
- Déploiement DMARC en mode
none(Responsable : DSI/RSSI) — Publiez l'enregistrement avecp=noneet une adresse de réception des rapports. Vous recevrez des rapports XML agrégés (RUA) quotidiennement. Utilisez un parseur ou un service dédié pour les lire lisiblement. - Analyse des rapports RUA pendant 4 à 8 semaines (Responsable : RSSI ou DSI) — Identifiez les sources d'échec : serveurs tiers non listés dans SPF, signatures DKIM absentes sur certains flux. Corrigez chaque source avant de passer à l'étape suivante.
- Passage à
p=quarantine(Responsable : DSI, validation RSSI) — Après correction de tous les expéditeurs légitimes. Attendez 2 à 4 semaines supplémentaires. - Passage à
p=reject(Responsable : DSI, validation RSSI et direction si impact métier potentiel) — C'est l'état cible. Continuez à surveiller les rapports RUA mensuellement. - Documentation et registre (Responsable : RSSI ou DPO interne) — Archivez la configuration dans le registre des mesures techniques. Utile en cas d'incident et pour répondre aux exigences de traçabilité de la nLPD.
Cas pratique : fiduciaire vaudoise, 35 employés, 4 200 dossiers clients actifs
Une fiduciaire de la région lausannoise (35 collaborateurs, domaine fiduciaire-exemple.ch) traite des données fiscales, salariales et comptables pour des PME clientes. En décembre 2023, un partenaire signale avoir reçu un email apparent de la fiduciaire demandant un virement de 11 500 CHF pour régulariser une situation TVA. L'email provient d'un serveur en Pologne. Le partenaire n'a pas donné suite, mais l'incident révèle l'absence totale de DMARC.
État initial constaté lors de l'audit :
- SPF publié mais en
~all(softfail) depuis 2019, n'incluant pas le serveur de relai utilisé par leur logiciel de paie Swissdec. - DKIM non activé sur leur tenant M365 (tenant migré depuis un Exchange on-prem en 2021, DKIM non reconfiguré).
- Aucun enregistrement DMARC.
Procédure appliquée :
- Inventaire des expéditeurs : M365 (messagerie principale), Abacus (envoi de décomptes PDF), serveur SMTP du logiciel Swissdec (IP fixe chez leur hébergeur), formulaire de contact WordPress (via SMTP authentifié M365).
- Mise à jour SPF :
v=spf1 include:spf.protection.outlook.com ip4:185.x.x.x -all(IP du serveur Swissdec). Passage de~allà-all. - Activation DKIM sur M365 : deux enregistrements CNAME publiés chez leur registrar (Infomaniak), propagation en 20 minutes (TTL 300).
- Publication DMARC
p=noneavec adressedmarc@fiduciaire-exemple.chdédiée. - Analyse des rapports sur 6 semaines : découverte d'un troisième expéditeur oublié — un outil de signature électronique (Skribble) qui envoyait des notifications au nom du domaine client. Ajout de l'include correspondant dans SPF.
- Passage à
p=quarantineen semaine 7, puisp=rejecten semaine 11.
Résultat : Zéro email usurpé détecté sur le domaine dans les 90 jours suivant le déploiement complet (vérifiable via les rapports RUA : toute tentative externe de spoofing génère une entrée disposition: reject). Durée totale du projet : 11 semaines calendaires, charge effective estimée à 6 heures de travail technique.
Coût : Zéro CHF de licence additionnelle — SPF, DKIM et DMARC sont des fonctionnalités natives de M365 et du DNS. La seule ressource consommée est le temps DSI/admin. Pour une PME sans ressource interne, un prestataire facturera entre 800 et 2 500 CHF pour l'audit et le déploiement complet selon la complexité du parc d'expéditeurs.
Récapitulatif opérationnel
- Vérifiez immédiatement si votre domaine a un enregistrement DMARC : interrogez
_dmarc.votre-domaine.chvianslookup -type=TXT. Si la réponse est vide, vous êtes exposé. - N'activez pas
p=rejectsans au moins 4 semaines de monitoring enp=none. Un rejet précipité bloque des emails légitimes et crée un incident métier. - Passez votre SPF de
~allà-alldès que vous êtes certain de la liste complète de vos expéditeurs. Le softfail n'offre qu'une protection symbolique. - Activez explicitement DKIM dans votre console d'administration (M365, Google Workspace). La migration depuis Exchange on-prem ne l'active pas automatiquement.
- Créez une boîte dédiée pour les rapports DMARC (RUA) et consultez-la au moins toutes les deux semaines en phase de déploiement, mensuellement ensuite.
- Documentez la configuration dans votre registre des mesures techniques au titre de la nLPD — date de mise en place, politique active, liste des expéditeurs SPF autorisés.
- Incluez le check DMARC dans vos revues annuelles de sécurité : une migration cloud, un nouvel outil SaaS ou un changement d'hébergeur peut invalider SPF ou DKIM sans alerte visible.
- Pour les sous-domaines non utilisés en messagerie (
intranet.domaine.ch,dev.domaine.ch), publiez également un DMARCp=rejectet un SPFv=spf1 -all: ils sont des vecteurs fréquents d'usurpation. - En cas d'incident de spoofing avéré, signalez-le au NCSC via son formulaire de signalement et évaluez l'obligation de notification au PFPDT si des données personnelles ont été exposées ou des tiers lésés.
SynGuard accompagne les PME suisses dans l'audit et la mise en conformité de leur posture email dans le cadre de déploiements MDM et sécurité endpoints.
Sources
- Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD, art. 8 (sécurité) et art. 24 (notification des violations).
- Obligation de notifier les violations de données — PFPDT (edoeb.admin.ch) — Procédure et critères de notification au Préposé fédéral.
- Formulaire de signalement d'incidents — NCSC (ncsc.admin.ch) — Signalement d'incidents cyber pour entreprises suisses.
- CIS Controls v8 — cisecurity.org — Contrôle 9 (Email and Web Browser Protections) couvrant DMARC/DKIM/SPF.
- NIST Cybersecurity Framework — nist.gov — Référentiel de gestion du risque cyber, fonction Protect (PR.AC, PR.DS).