On en parle – Cybersécurité et Résilience : passez de la conformité à l’anticipation

Pourquoi la conformité ne suffit-elle plus, même quand elle est sérieuse ?

Parce qu’un attaquant ne respecte pas vos procédures, et qu’une crise ne suit pas votre organigramme.
La conformité est nécessaire. Elle fixe un socle, elle formalise, elle aligne. Mais elle peut aussi donner une illusion de contrôle.

Or, une attaque est un événement vivant : elle progresse, elle se déplace, elle exploite un enchaînement.

Et surtout, elle arrive au pire moment, quand les équipes sont déjà sous tension. Le passage à l’anticipation consiste à accepter une vérité simple : la sécurité n’est pas un état, c’est une capacité à réagir vite et proprement.

Qu’est-ce que la résilience, au sens opérationnel, pour un Acteur Public ?

La résilience, c’est continuer à servir, même dégradé, même sous pression.
On imagine souvent la résilience comme un “retour à la normale” rapide. C’est une partie du sujet, mais pas la plus importante. La résilience, c’est d’abord la continuité : savoir ce qui doit tenir coûte que coûte, ce qui peut tomber sans drame, ce qui doit revenir en premier, et ce qui peut attendre. C’est une hiérarchie assumée des services, des données, des dépendances. Sans cette hiérarchie, le jour de crise, tout devient prioritaire, donc rien ne l’est, et l’organisation s’épuise à courir partout.

A Stratis, nous recommandons une approche très concrète : écrire la “liste des indispensables” comme on écrirait une liste de secours. Courte, claire, utilisable dans le stress.

Pourquoi les crises cyber deviennent-elles si souvent des crises de communication ?

Parce que le silence coûte plus cher que l’incident.
Dans le service public, l’attaque ne touche pas seulement un SI. Elle touche la confiance. Et la confiance se perd vite quand l’information est confuse, tardive, ou contradictoire. La communication de crise n’est pas un “plus”, c’est un composant de la résilience. Il faut savoir dire ce qui est impacté, ce qui ne l’est pas, ce qui est en cours, et ce que l’on demande aux usagers et aux agents. Même quand on ne sait pas tout.

Astuce : préparez des messages “prêts à adapter” avant la crise. Pas pour dramatiser, pour gagner du temps. Le jour J, le temps est votre ressource la plus rare.

Où se trouve la vulnérabilité la plus fréquente, et la plus négligée ?

Dans les dépendances, celles que personne ne possède vraiment.
Prestataires, SaaS, connecteurs, plugins, bibliothèques, outils de supervision, chaînes CI/CD, comptes techniques, annuaires, certificats. La surface d’attaque est devenue un écosystème. Et dans un écosystème, le risque se glisse dans les interstices : un accès trop large, un compte oublié, une clé non renouvelée, un composant non maintenu. Ce qui est dangereux, ce n’est pas “le cloud” ou “l’on-premise”. C’est l’absence de cartographie vivante des dépendances.

A Stratis, nous insistons sur un exercice simple : lister “ce dont nous dépendons pour fonctionner”. Si vous n’avez pas la liste, vous ne pourrez pas protéger, ni restaurer.

Qu’est-ce qui fait basculer un incident en catastrophe ?

L’absence de sauvegardes testées, plus que l’absence de pare-feu.
On peut discuter longtemps de solutions de sécurité. Mais, dans la réalité des crises, la différence majeure tient souvent à une question brutale : “Pouvez-vous restaurer proprement, vite, et sans réinfecter :”. Une sauvegarde qui n’est pas testée n’est pas une sauvegarde, c’est un espoir. Une restauration non répétée est une improvisation.

À Stratis, nous recommandons de traiter la restauration comme un entraînement : restaurer un service, restaurer une base, restaurer une configuration, dans un temps cible, avec une procédure écrite. Quand on sait restaurer, on respire. Et quand on respire, on décide mieux.

Comment passer d’une sécurité “documentaire” à une sécurité “pratiquée” ?

En transformant les règles en réflexes, puis les réflexes en automatismes.
Les politiques et les chartes sont utiles. Mais elles ne protègent pas seules. Ce qui protège, ce sont des gestes intégrés : mises à jour régulières, contrôle des accès, principe du moindre privilège, segmentation, surveillance, gestion des secrets, durcissement. Et surtout, un rythme : on corrige, on vérifie, on rejoue. La sécurité “pratiquée” ressemble à l’hygiène : elle est répétitive, parfois ingrate, mais elle évite l’urgence.

À Stratis, nous aimons une formule : moins de règles, plus de rituels. Une règle sans rituel finit oubliée.

Quelle est la place du DevSecOps dans la résilience, au-delà du mot ?

Faire de la sécurité un flux, pas un contrôle final.
Le DevSecOps, quand il est bien compris, n’ajoute pas une couche. Il déplace le contrôle plus tôt, et le rend automatique : analyse de dépendances, scan de vulnérabilités, tests de configuration, contrôle des secrets, revue des permissions, durcissement des pipelines. Le bénéfice est double : on réduit le risque, et on réduit les surprises tardives. C’est exactement l’esprit de l’anticipation.

À Stratis, nous recommandons de démarrer par une chaîne simple : détecter, prioriser, corriger, prouver. La preuve est importante : elle évite les débats, elle rend le progrès visible.

Comment hiérarchiser les risques sans se noyer dans des matrices ?

Prioriser, c’est choisir ce qui vous arrête, pas ce qui vous gêne.
La priorisation cyber devient vite un millefeuille. Or, une organisation a besoin d’une lecture claire : qu’est-ce qui, si cela tombe, empêche de servir : qu’est-ce qui expose des données sensibles : qu’est-ce qui met en risque la sécurité des personnes : qu’est-ce qui compromet la chaîne de décision :”. Ces questions ramènent le sujet au réel.

Astuce : utilisez un langage “service” plutôt qu’un langage “technique”. Au lieu de dire “vulnérabilité critique sur composant”, dites “risque d’indisponibilité de telle démarche”, ou “risque de fuite sur telles données”. Les arbitrages deviennent plus justes, et plus rapides.

Pourquoi l’humain reste-t-il le maillon le plus attaqué, même avec un SI solide ?

Parce que l’attaque vise la confiance, pas seulement la faille.
Phishing, usurpation, faux supports, faux documents, faux ordres, faux urgent. Les attaques modernes aiment l’urgence, la confusion, et la peur de mal faire. La réponse n’est pas de “former une fois par an”. La réponse est de créer une culture de la vérification : le droit de douter, le réflexe de confirmer, des canaux clairs, et des procédures simples pour signaler.

À Stratis, nous recommandons d’entraîner sur des scénarios réalistes, courts, répétés. Comme un exercice incendie. La répétition crée le calme.

Comment organiser une réponse à incident qui ne se transforme pas en chaos ?

En exigeant la résilience dans les contrats, pas seulement dans les discours.
Vos prestataires font partie de votre surface d’attaque, mais aussi de votre capacité à revenir. La question n’est donc pas seulement “sont-ils conformes :”. C’est “peuvent-ils vous aider à restaurer :”, “dans quel délai :”, “avec quelles preuves :”, “avec quelle transparence :”. La réversibilité, la disponibilité, les procédures de crise, les engagements de support, les tests : ce sont des clauses de résilience.

Astuce : demandez une démonstration d’incident. Pas un document. Une démonstration : comment on isole, comment on restaure, comment on communique.

À quoi ressemble un plan réaliste pour passer à l’anticipation en quelques mois ?

Un plan court, orienté capacité : sauvegarder, détecter, isoler, restaurer, communiquer.
L’anticipation n’exige pas un programme interminable. Elle exige des fondamentaux exécutables. Une trajectoire efficace commence par la cartographie des actifs critiques, la mise à niveau des sauvegardes et de la restauration, la réduction des accès trop larges, la surveillance des événements, et un exercice de crise. Ensuite, seulement, on renforce.

À Stratis, nous aimons cette idée : la première victoire cyber n’est pas d’empêcher toute attaque. C’est de rendre l’attaque gérable.