Le nombre d’incidents signalés ne suffit pas à décider d’un budget de sécurité. Une fraude fréquente et une interruption rare peuvent avoir des conséquences très différentes. L’organisation doit comprendre le chemin de l’attaque, les actifs exposés et le rôle de chaque protection avant de hiérarchiser ses investissements.
Les rapports de l’Office fédéral de la cybersécurité documentent des situations qui concernent aussi les entreprises et les administrations suisses. Les cinq scénarios suivants relient ces mécanismes à des contrôles concrets. Ils permettent d’examiner la protection d’un système sans supposer qu’un produit unique couvre tous les risques.
1. Un accès distant exposé ouvre le réseau interne
Un pare-feu filtre les communications ; une passerelle VPN permet un accès distant au réseau ; un service d’administration peut donner le contrôle d’un serveur. Lorsqu’un de ces composants présente une faille ou une configuration insuffisante, il devient lui-même un point d’entrée.
Les autorités suisses ont notamment décrit les attaques du groupe Akira, avec des accès distants et des systèmes mal protégés parmi les voies observées. Une vulnérabilité précise ne doit toutefois pas être attribuée à tous les incidents d’un groupe sans preuve.
L’inventaire des services accessibles depuis internet permet de vérifier leur utilité et leur responsable. Un accès de maintenance temporaire ne devrait pas rester ouvert simplement parce que sa fermeture n’a pas été attribuée. L’équipe vérifie les interfaces exposées, les comptes autorisés et les moyens de surveillance.
Les équipements de sécurité demandent leur propre suivi de versions. L’application d’un correctif peut également nécessiter un changement de mots de passe ou la fermeture de sessions. Ces étapes répondent à une compromission possible antérieure à la mise à jour. Installer seulement le logiciel corrigé ne retire pas nécessairement un accès déjà obtenu.
Le contrôle utile combine donc l’état de la version, la configuration et les instructions du fabricant. Un essai de connexion autorisée et un examen des accès qui devraient être fermés permettent de vérifier le résultat. L’organisation garde les éléments nécessaires pour comprendre les exceptions encore présentes.
2. Un compte protégé reste exposé par sa session
Un logiciel voleur d’informations peut récupérer les mots de passe enregistrés et les cookies de session. Ces derniers permettent à un navigateur de rester connecté après l’authentification. Un attaquant qui les réutilise dans les conditions acceptées par le service peut agir sans redemander le mot de passe.
Une autre attaque passe par une fausse page qui relaie la connexion vers le vrai service. La victime y saisit son mot de passe et un code temporaire ; l’intermédiaire transmet ces éléments et tente de récupérer la session. L’authentification multifacteur reste utile, mais toutes ses formes ne résistent pas de la même manière à ce relais.
Les clés de sécurité et les clés d’accès compatibles avec les mécanismes résistants à l’hameçonnage lient la preuve d’authentification à l’origine du service. Elles limitent ce type de tromperie. Elles ne rendent pas pour autant inoffensif un logiciel malveillant déjà présent sur l’appareil.
La protection du poste associe les correctifs du système, la détection des comportements suspects, la révocation des sessions à distance et une nouvelle authentification avant les opérations sensibles. La récupération du compte demande une attention comparable. Une procédure de réinitialisation faible peut contourner la protection mise en place à la connexion.
L’équipe vérifie cette chaîne sur les comptes qui donnent accès à la messagerie et à l’administration. Elle prévoit les moyens de secours nécessaires sans créer un accès permanent oublié. Le résultat attendu est une connexion utilisable par la personne légitime et un retrait rapide lorsqu’un compte ou un appareil paraît compromis.
3. Un message crédible détourne un paiement
L’arnaque au président décrite par l’OFCS utilise l’identité apparente d’un dirigeant pour obtenir un virement. Une variante imite un fournisseur et annonce de nouvelles coordonnées bancaires. Le message peut provenir d’une boîte légitime compromise, ce qui réduit la valeur d’un contrôle limité à l’adresse de l’expéditeur.
La protection porte sur la décision de paiement. La personne responsable confirme une demande inhabituelle par un moyen de contact connu avant l’arrivée du message. Pour un changement de coordonnées bancaires, elle utilise le numéro déjà enregistré ou une autre procédure de vérification approuvée.
La séparation entre préparation et validation apporte un deuxième contrôle. Au-dessus du seuil défini, une autre personne vérifie le bénéficiaire, le montant et le motif dans l’outil de paiement. Un accord reçu par courriel ne remplace pas cette vérification lorsque le courriel lui-même peut être compromis.
L’urgence et la confidentialité invoquées doivent pouvoir être traitées sans abandonner la procédure. Un scénario d’exercice permet de vérifier que l’équipe sait qui appeler et quels justificatifs demander. Les nouveaux collaborateurs et les remplaçants ont besoin de ces mêmes repères.
Le contrôle technique et le contrôle métier répondent ici à des mécanismes différents. La messagerie peut signaler une anomalie ; les personnes autorisées doivent encore vérifier que l’organisation a réellement décidé ce paiement.
4. Une attaque chez un prestataire expose les données confiées
Un fournisseur peut détenir des copies de dossiers ou disposer d’un accès de maintenance. Une attaque contre ses systèmes peut donc toucher l’organisation sans atteindre directement son propre réseau. Le périmètre dépend des données confiées et des droits accordés, qui doivent être connus avant l’incident.
L’inventaire relie chaque service aux catégories de données, aux lieux de traitement et au responsable interne. Il permet d’identifier rapidement les activités et les personnes potentiellement concernées lorsqu’un fournisseur annonce un incident. Sans cette information, l’organisation doit reconstruire ses dépendances pendant la crise.
Les accès de maintenance utilisent des identités attribuées, des droits limités et une durée adaptée à l’intervention. Les journaux permettent de retrouver les actions effectuées. L’équipe vérifie également les comptes techniques, les accès de secours et les interfaces qui ne passent pas par la connexion habituelle d’un utilisateur.
Le contrat précise le délai d’alerte, les contacts et la coopération attendue. L’organisation doit pouvoir obtenir les informations nécessaires à son analyse, sans attendre uniquement un communiqué public. L’organisation prépare aussi la continuité du service et le sort des données à la fin du contrat.
À la fin d’un mandat, la revue des comptes, des tokens et des permissions permet de vérifier le retrait des accès attribués au prestataire. L’article sur les engagements d’un fournisseur communal explique comment documenter le traitement confié et les accès du prestataire.
5. Un rançongiciel interrompt les activités
Le rançongiciel peut arriver après l’exploitation d’un accès distant, le vol d’un compte ou la compromission d’un prestataire. L’attaquant peut rechercher les données, tenter de neutraliser les copies accessibles et chiffrer les systèmes dont l’activité dépend.
Les sauvegardes réduisent certaines conséquences si elles restent utilisables après l’incident. Une copie isolée ou protégée contre la suppression doit résister aux comptes et aux scénarios retenus. L’organisation vérifie notamment les droits de production, ceux de l’outil de sauvegarde et les procédures permettant de modifier la protection.
La restauration doit remettre en service les applications et leurs dépendances, avec des données assez récentes. Le test mesure le temps nécessaire, contrôle l’intégrité et vérifie les accès. Le résultat donne un repère pour la reprise ; un incident réel peut présenter des conditions différentes, notamment lorsqu’une enquête ou une reconstruction supplémentaire est nécessaire.
Le plan de reprise suit les dépendances des applications. Un logiciel qui utilise l’annuaire pour authentifier ses utilisateurs et une base pour enregistrer ses transactions nécessite la remise en service de ces deux dépendances avant ses propres tests. L’ordre de démarrage est documenté dans le runbook et vérifié lors d’un exercice.
L’article sur le test de restauration détaille cette préparation. La remise en service ne répare toutefois pas une divulgation. Les données volées et les obligations liées à l’incident demandent un traitement distinct de la récupération technique.
Choisir les priorités selon les conséquences
Ces cinq scénarios donnent des points d’examen, pas un ordre universel. Une boutique en ligne doit aussi considérer la disponibilité de son service face à un déni de service. Une organisation de soins examine d’abord les dépendances qui conditionnent la prise en charge. Une équipe financière accorde une attention particulière aux autorisations de paiement.
L’inventaire identifie les serveurs et les comptes exposés. Un test de révocation vérifie qu’un accès retiré est effectivement refusé. Un exercice de restauration mesure les données récupérées et le temps de remise en service. Ces résultats documentent séparément la couverture des protections, les autorisations et la capacité de reprise.
La décision suivante découle d’un écart identifié. L’organisation peut corriger un accès, modifier une procédure ou financer une capacité supplémentaire en expliquant l’effet attendu sur un scénario précis.