Le 31 octobre 2026, l’État de Vaud a confirmé la copie de l’annuaire et du contenu des demandes d’assistance de sa plateforme de support informatique des gymnases et écoles professionnelles, soit environ 41 500 personnes. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : ce qui est documenté, notre lecture MITRE ATT&CK, la détection, les questions d’audit ISO 27001 et des pistes de sensibilisation. Le vecteur d’entrée, l’outil concerné et la date de début de l’accès ne sont pas publiés à ce stade.
Pour une lecture orientée dirigeant, voir notre décryptage « Canton de Vaud : les demandes d’assistance informatique de 41 500 élèves et enseignants copiées par un intrus ».
Contexte
- Sources : communiqué de l’État de Vaud, 31 octobre 2026 ; Cyberattaque.org, 31 octobre 2026.
- Victime : Direction générale de l’enseignement postobligatoire (DGEP) du canton de Vaud ; plateforme de gestion des demandes d’assistance utilisée par les enseignants et les élèves des gymnases et écoles professionnelles.
- Personnes concernées : environ 3 500 enseignants et 38 000 élèves.
- Chronologie : accès non autorisé détecté le 26 octobre 2026 ; plateforme déconnectée d’Internet le jour même ; communication publique le 31 octobre. Début de l’accès non communiqué.
- Données copiées (à ce stade des analyses) : noms, prénoms, adresses e-mail scolaires, contenu des demandes d’assistance. Hors périmètre selon le canton : mots de passe (non stockés sur la plateforme), notes, dossiers d’élèves.
- Réponse : sécurisation avec le centre opérationnel de sécurité du canton ; annonce à l’Office fédéral de la cybersécurité (OFCS) et à l’autorité cantonale de protection des données ; information directe des personnes avec consignes ; plainte pénale annoncée.
- Attribution : aucune. Aucune revendication connue, aucun rançongiciel mentionné.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | Non publié. La plateforme était exposée sur Internet (elle en a été déconnectée). Faille applicative, compte détourné ou mauvaise configuration restent des hypothèses de presse, non confirmées | Non déterminable ; hypothèses seulement : T1190 Exploit Public-Facing Application ou T1078 Valid Accounts |
| Collecte | Annuaire des utilisateurs et contenu des demandes d’assistance | T1213 Data from Information Repositories |
| Exfiltration | Données « copiées » ; canal, volume et durée non publiés | Non déterminable |
| Suite probable | Risque annoncé par le canton : messages frauduleux ciblés au nom de l’école ou du support ; aucune campagne constatée publiquement à ce stade | T1589 Gather Victim Identity Information (préparation) ; T1566 Phishing ; T1656 Impersonation |
Faits techniques connus
- L’application était joignable depuis Internet, ce qui est la norme pour un portail de demandes d’assistance utilisé hors des établissements.
- Les mots de passe des comptes ne sont pas stockés dans l’outil : ce qui suggère, selon notre lecture, une authentification déléguée à un autre système (annuaire ou fournisseur d’identité) ; cela limite l’impact direct sur les comptes.
- Le contenu des tickets a été copié. Par nature, il peut contenir des éléments que l’organisation ne maîtrise pas : captures d’écran, descriptions d’environnement, noms de logiciels, voire secrets collés par erreur. Le canton indique qu’aucune donnée sensible n’est concernée, sans détailler la nature des demandes copiées.
Ce qu’on ne sait pas
- Le logiciel utilisé (produit du marché, développement interne, service en ligne) et donc s’il existe une faille connue à corriger ailleurs.
- La porte d’entrée et la durée de présence de l’intrus.
- Le moyen de détection.
- L’usage qui sera fait des données (revente, campagne d’hameçonnage).
Détection : un délai inconnu, une réaction rapide
- Ce qui est publié : la DGEP a « détecté » l’accès le 26 octobre et a coupé l’accès Internet de la plateforme le jour même. Le communiqué ne précise ni l’origine de l’alerte, ni la date de début de l’accès : le délai de détection ne peut pas être évalué.
- Ce qui a bien fonctionné (visible de l’extérieur) : confinement immédiat, appui d’un centre opérationnel de sécurité, notifications aux autorités et information des personnes en cinq jours, consignes concrètes données aux utilisateurs.
- Signaux utiles sur ce type d’application : connexions d’agents ou d’administrateurs depuis des lieux, des heures ou des adresses inhabituels ; création de comptes à privilèges ; exports massifs, appels d’API ou pagination anormale sur les tickets ; alertes du pare-feu applicatif web sur l’interface exposée ; requêtes vers des pages d’administration depuis Internet.
- Après la fuite : surveiller les messages entrants qui citent des numéros ou objets de tickets, et donner aux utilisateurs un canal de signalement simple.
Questions d’audit ISO 27001:2022
- A.5.9 et A.5.12 (inventaire des informations et autres actifs associés ; classification des informations) : « L’outil de gestion des demandes d’assistance figure-t-il à l’inventaire, avec un propriétaire désigné ? Quelle classification avez-vous donnée au contenu des tickets, qui peut inclure des données personnelles, des captures d’écran ou des secrets collés par un utilisateur ? »
- A.8.10 et A.5.34 (suppression des informations ; vie privée et protection des DCP) : « Quelle durée de conservation est fixée pour les tickets clos et les pièces jointes ? Montrez-moi la preuve de la dernière purge. Combien d’années d’historique contient l’outil aujourd’hui ? »
- A.8.20, A.8.5 et A.8.15 (sécurité des réseaux ; authentification sécurisée ; journalisation) : « Quelle analyse justifie l’exposition de l’interface sur Internet, et pour quels profils (utilisateurs, agents, administrateurs) ? Les comptes d’agents et d’administrateurs sont-ils protégés par une authentification multifacteur ? Quels journaux d’accès et d’export sont conservés, combien de temps, et qui les analyse ? »
- A.5.26, A.5.34 et A.6.3 (réponse aux incidents de sécurité de l’information ; protection des DCP ; sensibilisation) : « Votre procédure de réponse prévoit-elle, après une fuite, l’information des personnes sur le risque d’hameçonnage ciblé et les délais de notification aux autorités ? Les utilisateurs connaissent-ils le canal officiel par lequel le support les contacte, et la liste de ce qu’il ne demande jamais ? »
En complément, si l’outil est un service en ligne ou infogéré : A.5.19 et A.5.23 (relations avec les fournisseurs ; utilisation de services en nuage) : « Le contrat précise-t-il la localisation des données, la journalisation fournie, la purge et le délai d’alerte en cas d’incident chez le fournisseur ? »
Pistes de sensibilisation
- Pour tous les utilisateurs : « Le faux ticket » (10 minutes). Comparer un hameçonnage générique et un faux message du support qui cite une vraie demande (numéro, date, problème). Conclure sur deux règles : le support ne demande jamais de mot de passe ni de code reçu par SMS ; en cas de doute, on recontacte le support par le canal habituel, jamais par celui du message. Supports : les fiches de Cybermalveillance.gouv.fr « Faux support technique, que faire ? » et « Hameçonnage (phishing), que faire ? ».
- Pour l’équipe support ou l’infogérant : atelier « Ce qu’il y a dans nos tickets ». Échantillonner une cinquantaine de tickets d’époques différentes, compter ceux qui contiennent un mot de passe, une donnée personnelle sensible ou une capture révélatrice, puis en tirer une règle d’écriture, une durée de conservation et une purge planifiée.
À lire aussi : notre décryptage « Canton de Vaud : les demandes d’assistance informatique de 41 500 élèves et enseignants copiées par un intrus » et notre bulletin de veille du 1er novembre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.